Engineers know how to write a good bug report. Compliance rarely gets one. So here is one, for the most expensive defect in many AML operations.
Title: Analyst capacity drops sharply when retrieval is manual
Severity: high, but invisible on every dashboard
Environment: an investigation team with several systems and no single case view
Steps to reproduce
Open an alert.
Try to find the customer’s earlier cases.
Try to find linked accounts.
Try to assemble a timeline.
Observe how long it takes before you can start thinking.
Expected: the case opens with history, links and a draft chronology.
Actual: the analyst assembles them by hand, then decides.
Workaround: ask a senior colleague. This works until that colleague leaves.
Suggested fix: retrieve before the analyst opens the case, show sources, keep the person in charge of the decision. See the idea behind RAG-powered AI that generates evidence.
Notes for triage
This is not a model-accuracy bug. It’s a workflow bug.
Measure it before fixing. A one-week log is enough: https://www.pearltrees.com/technoxander47/item838554012 shows how to sort which tasks to fix first.
Reproduced in a hypothetical day: [https://verificationofpayee.blogspot.com/2026/11/day-in-two-aml-workflows.html](https://verificationofpayee.blogspot.com/2026/11/day-in-two-aml-workflows.html).
Context: [AML investigation capacity](https://technoxander.com/aml-ai-investigation-throughput-scaling/) and [organisational memory in AML](https://technoxander.com/organisational-memory-aml-ai-investigations/).
Over to you
How do you label tickets that cost time but never break anything?
Would you ship a fix that moves work from analysts to a retrieval layer, even if accuracy needs monitoring?
Hot take: the worst bugs are the ones with no error message. Agree, or fight me?
From the team at TechnoXander.