In 2014, financial intelligence units across the European Union received almost a million suspicious transaction reports.

Around ten per cent of them were investigated further. Roughly one per cent of criminal proceeds were confiscated. Europol, publishing those figures in 2017, noted that the ten per cent had not moved since 2006.

Those reports are what survives the filter. Long before a report is written, an analyst has worked through a queue of machine-generated alerts, and the overwhelming majority of those close with no further action at all.

I cannot give you a defensible industry-wide percentage for that last part, and I want to be straight about why. The figure everyone quotes; ninety to ninety-five per cent appears in dozens of compliance vendor publications, each citing another vendor publication, with the earliest reference I can trace being unpublished consultancy analysis from 2017. There is no regulator, no financial intelligence unit and no peer-reviewed study behind it. In every team I have run across over about twenty years, the true rate was somewhere in that region, but that is my observation rather than a measurement, and I am not going to dress it up as one.

What is documented is the shape of the funnel. And the shape is what matters here.

If you run production systems, that shape should feel familiar. It is the signal-to-noise profile of a mature alerting stack that nobody has pruned in eighteen months. The pager goes off, someone acknowledges it, someone looks, and almost always the answer is that everything is fine.

I have spent about twenty years in financial crime compliance; banks, payment institutions, fintechs, crypto firms, and most of that time on one problem: how do you build a system sensitive enough to catch a rare bad thing without burning out the humans who read the output?

Banking has not solved this. It has been failing at it, publicly and expensively, for long enough to have learned things that engineering teams keep rediscovering from scratch.

Here is what transfers.

The false positive rate is not a bug you can fix.

The first instinct on any team drowning in alerts is to tune the thresholds until the noise stops. In compliance, this is a well-trodden road, and it ends badly, because the arithmetic is not on your side.

Money laundering is rare relative to the volume of legitimate activity it hides inside. Nobody can tell you precisely how rare — the prevalence is unobservable by definition, which is part of the problem, but the direction is not in dispute, and the direction is all the argument needs.

Build a detector for a rare event across a very large negative class and the maths is unforgiving. At 99% specificity, which no rules-based system achieves, a portfolio of ten million transactions produces a hundred thousand false positives. If the true positives number in the low hundreds, they arrive outnumbered by roughly a thousand to one. Drop the specificity to something realistic, and it gets worse quickly.

This is Bayes, not incompetence. Engineers hit the identical wall with anomaly detection, security alerting, and any monitor watching for a rare failure across a large surface. You cannot tune your way to a clean queue without also tuning away the thing you built the system to catch.

The compliance industry spent years pretending otherwise before accepting the consequence: if the false positive rate is structural, the design problem is not the detector. It is the triage.

That reframe is the whole lesson. Once you stop trying to make the queue clean and start trying to make the queue fast to clear, everything downstream changes.

Clearing an alert correctly is real work, and should be measured.

Here is the thing that took banking longest to internalise, and that most engineering teams still get wrong.

If the great majority of alerts are nothing, then the great majority of the value your on-call engineer produces is correctly deciding that something is nothing. That is the job. It is not the boring prelude to the job.

Yet almost every incentive structure quietly punishes it. Metrics track incidents caught, not incidents correctly dismissed. Post-mortems examine the alert that should have fired and didn't, never the four hundred that fired and shouldn't have. An engineer who escalates unnecessarily is cautious; an engineer who correctly closes something is invisible.

Compliance has learned what that produces: over-reporting. Analysts escalate anything ambiguous because escalation is rarely career-limiting, while dismissing a case incorrectly might be. The result is a defensive backlog that buries genuine cases beneath a mountain of covered backsides. At the far end of that process is the customer whose account gets closed over activity that was ultimately perfectly explainable.

When I build training material, I use a free version of CasePilot. One in five cases contains nothing wrong, and clearing those cases correctly earns the same score as identifying a genuine issue. That scoring choice is deliberate. It changes analyst behaviour within about a week.

Whether the wider regime achieves anything is a separate and sharply contested question. Ronald Pol's 2020 paper in Policy Design and Practice argues the global anti-money-laundering system is among the least effective policy interventions of its scale anywhere, and the Europol confiscation figure is difficult to read any other way. That debate is beyond this piece. It is worth knowing that the people inside these systems are not unaware of it.

If your team has a dashboard, put "alerts correctly closed with rationale" on it next to "incidents caught".

Read the alert before you open the system.

This is the habit with the best return of anything I teach, and it costs nothing to adopt.

The instinct when a page fires is to jump straight into the dashboard, form a view, then go looking for data that supports it. By the time you reach the metrics, you are no longer reading them. You are confirming yourself.

The discipline is to commit to a test before you have the answer. Read what actually fired: which rule, over what window, on what magnitude, in what direction. Then write down, in one sentence, what would have to be true for this to be entirely ordinary.

Only then open the system.

If the sentence is answered, the spike tracks a deploy, the deposits track market days, the latency tracks a known batch job — you close in four minutes with a rationale. If it is not answered, you now have a real piece of work and, crucially, a specific question to work on rather than a vague sense of unease.

The cost is about ninety seconds. The saving is every investigation that would otherwise have wandered.

The rationale is the artefact, not the decision.

This is where compliance is well ahead of engineering practice, because regulators forced the issue.

When a reviewer opens a case file two years later, they cannot see what the analyst thought. They can only see what was written. And the standard applied is not whether the analyst is correct, correctness is frequently unknowable from inside one institution, which sees one slice of a network. The standard is whether a reasonable practitioner, given the information available at the time, could reach that conclusion by following the recorded reasoning.

That is defensibility, and it is achievable in every case in a way that correctness is not.

Translate it: "resolved, no action needed" is not an incident note. It is the last line of one. Which metric, compared against what baseline, over what window, and what alternative explanation was considered and rejected. A note that lets the next person reconstruct your logic is worth ten that record your verdict.

Two habits from compliance files port directly.

• Record negative findings -If you checked whether the spike correlated with the deploy and it didn't, that is a finding and it belongs in the note. An absent check and a completed check that found nothing look identical in an empty field, and the next responder has to redo your work.
• Write while working, not after -A rationale composed the following afternoon is a reconstruction. It reads like one, and it omits precisely the dead ends that would have saved the next person an hour.

A worked example

A composite, drawn from several institutions.

A retail customer, eleven years on file as a salaried administrator, receives fourteen inbound payments across nine days. Each is between £2,100 and £2,900. They come from twelve different individuals with no apparent relationship to her. Ninety per cent moves out within forty-eight hours to a single third party. Total across the period is a little under £34,000.

The junior analyst who first held this closed it. The recorded rationale: individual amounts were small, no adverse media, long tenure.

Every one of those statements was accurate. None of them addressed the pattern.

What the file needed was one line: nothing in the customer's known profile explains inbound payments from twelve unconnected individuals, and the rapid onward movement of nearly all of it to one recipient is inconsistent with personal use of funds.

The onward recipient was already the subject of reports from another institution.

The alert had not been misjudged so much as never engaged. And the reason it went wrong is one every on-call engineer will recognise: the analyst evaluated the attributes of the entity rather than the shape of the event. Long tenure and clean history are reasons this customer is unlikely to be a professional criminal. They are not reasons the account is not being used by someone else.

Substitute "this service has been stable for two years" for "eleven years on file", and you have written a hundred incident notes.

What I would actually change on Monday

Four things, in order of how cheap they are.

• Put a one-sentence hypothesis at the top of every incident note, written before the investigation, stating what would make this ordinary. It is the cheapest change on this list and the one that most improves the notes.
• Add correctly-closed alerts to whatever dashboard tracks caught incidents, so that dismissal becomes visible work rather than invisible non-work.
• Institute a monthly read-back where engineers reopen a handful of their own closed alerts from six weeks earlier and read the rationale as a stranger would. Nothing improves judgement faster than meeting your own reasoning without your memory attached to it.
• And stop trying to get the queue clean. Measure time-to-clear and quality-of-rationale instead. A noisy queue that clears in four minutes per item is a functioning system. A quiet queue that missed the thing is not.

** Bottom line:** if your alerting is mostly noise, that is arithmetic rather than failure — the funnel Europol measured has the same shape as the one on your pager, and the fix is not a better detector but a triage process where correctly deciding something is nothing counts as the work it actually is.

Sources

• Europol, From Suspicion to Action: Converting Financial Intelligence into Greater Operational Impact, 2017. Reports that EU financial intelligence units received almost one million reports in 2014, that on average around 10% of suspicious transaction reports are investigated further, that this figure was unchanged since 2006, and that the system overall results in approximately 1% of criminal proceeds being confiscated - https://www.europol.europa.eu/publications-documents/suspicion-to-action-converting-financial-intelligence-greater-operational-impact
• Europol press release summarising the above findings - https://www.europol.europa.eu/media-press/newsroom/news/global-anti-money-laundering-framework-%E2%80%93-europol-report-reveals-poor-success-rate-and-offers-ways-to-improve
• Ronald F. Pol, "Anti-money laundering: the world's least effective policy experiment? Together, we can fix it", Policy Design and Practice, vol. 3 no. 1, 2020. Peer-reviewed assessment of anti-money-laundering regime effectiveness.

Claims about alert closure rates within individual institutions, the behaviour of analyst teams, and the case example are drawn from the author's practitioner experience and are identified as such in the text. The case example is a composite and does not describe any identifiable person or institution.