Written by: Karol Sobieraj, Founder & CEO, Digital Colliers
If you run an AML function at a mid-market bank, you already know the number. Transaction-monitoring false-positive rates sit somewhere between 85 and 95 percent at typical mid-market banks. That's the industry baseline, not a worst case. Ninety-something percent of what your analysts open is noise, and they know it by lunchtime on their first week.
The cost isn't the alerts. The cost is the people. Investigators burn out fast when the job is clearing junk queues, and the good ones leave inside eighteen months. You then pay a recruiter, wait three months, onboard for six, and hand the new hire the same broken queue. That's the treadmill. And most remediation programmes are pointed at the wrong lever.
The false-positive rate is a data problem, not a rules problem
Most banks respond to bad alert quality by tuning rules. Raise a threshold here, add a suppression there, tweak the segmentation model. It buys you a quarter, maybe two. Then the rate creeps back because the underlying issue was never the rule logic. It was the thinness of the data the rule was firing against.
When an alert lands in front of an analyst, they typically have to go get:
- KYC data from the onboarding system
- Prior SAR history from a case management tool
- Counterparty information from a separate screening vendor
- Corporate structure from an external provider
- Recent transaction context from the core banking system
Five tabs, five logins, sometimes fifteen minutes of copy-paste before the analyst can even form a hypothesis. The alert isn't wrong because the rule is dumb. The alert is unresolvable at speed because the context lives in five places.
What joined data actually does to the queue
The operators quietly getting their false-positive rate down aren't buying a new monitoring platform. They're doing the unglamorous work of joining the data before the alert fires, so the rule engine has something to reason against and the analyst has something to read.
Concretely, that looks like:
- A single enriched customer record that carries KYC, screening, prior alerts, and beneficial ownership in one shape.
- Counterparty enrichment done at ingestion, not at investigation time.
- Behavioural baselines computed per segment, so "unusual" means unusual for that customer, not unusual for the bank.
- Case context pre-attached to the alert, so the analyst opens a file with the last six months of relevant history already there.
None of this is exotic. It's data engineering. But it moves the analyst's average handle time from twenty-plus minutes to something that fits inside a normal working day, and it lets the rules layer suppress alerts that were only ever noise because the joined view made the answer obvious.
The hiring math nobody puts on the slide
Here's the part that gets ignored in the business case. A mid-market AML team of forty investigators, with attrition running at the industry pattern, is replacing roughly two thirds of the team every eighteen months. Fully loaded cost per replacement, including recruiter fees, ramp time, and productivity lost during vacancy, comfortably clears six figures per head in most markets.
A data enrichment programme that halves the false-positive rate doesn't just improve throughput. It changes the job. Analysts who spend their day forming hypotheses instead of clicking through tabs stay longer. Retention goes up, ramp costs go down, and the recovered headcount funds the engineering work several times over.
Meanwhile the cost of not doing it keeps compounding. DORA has been in force since January 2025, so your operational resilience obligations already include the systems your AML function depends on. GDPR exposure on automated decisioning caps at 20 million euros or 4 percent of global turnover. And the EU AI Act's high-risk obligations start biting in December 2027, which will pull AML monitoring squarely into scope for documentation, data governance, and human oversight requirements you'll wish you'd built for earlier.
Where to start if you're the one holding this
Don't start with the model. Start with the record. Pick your top three alert typologies by volume, map every field an analyst touches to close them, and count the systems. If it's more than two, your false-positive rate is a symptom and your attrition is the invoice. Fix the join before you retune the rule, and the rest of the programme gets cheaper.
The banks that get ahead of this in 2026 won't be the ones with the fanciest monitoring vendor. They'll be the ones whose analysts can answer the question in one screen.