How to reduce false positives — without quietly reducing coverage

Every transaction monitoring team is asked to cut false positives, and most of them start in the same place: the thresholds. Raise the amount, widen the window, tighten the segment. Volume falls, the metric improves, and nobody can say with any confidence what stopped being detected.

That is the whole problem in a sentence. Reducing alerts is trivial. Reducing alerts while being able to demonstrate that you did not reduce coverage is the actual work, and it has an order of operations.

First, find out what your alerts actually are

Before touching a single parameter, produce a breakdown of the current alert population by rule, by segment, and by outcome. Most firms cannot do this quickly, and the exercise alone usually pays for itself.

What it typically reveals: a small number of rules generating a large majority of volume, almost all of it closing benign. A rule that has never produced an escalation in two years. Two rules firing on the same underlying behaviour and creating duplicate work. Entire alert clusters driven by a single customer type doing something entirely ordinary for that customer type.

None of that is fixed by moving a threshold. It is fixed by rule design, deduplication and segmentation — and those changes reduce noise without touching sensitivity to the behaviour you actually care about.

Anyone can cut alert volume. The question is whether you can show a supervisor what you gave up to get it.

Second, fix segmentation before sensitivity

A threshold is only meaningful relative to what is normal for the customer it applies to. One global parameter across a book containing salaried individuals, cash-intensive retailers and small importers will be simultaneously too tight for one group and too loose for another. It generates noise at one end and blind spots at the other.

Better segmentation usually delivers a larger volume reduction than threshold movement, and it is far easier to defend — because the argument is "we applied a more accurate expectation of normal behaviour", not "we decided to look at less".

Third — and only third — tune the thresholds

When you do reach parameters, the method matters more than the numbers:

• Above-the-line and below-the-line testing. Sample what the proposed setting would have caught, and critically, what it would have missed in the band you are giving up. Below-the-line sampling is the evidence that the change was safe. Without it you have an assertion.
• Test on a real historical window, long enough to include seasonal behaviour. A quarter is usually too short.
• Model the volume and the detection consequence together. A change that removes 40% of alerts and one confirmed escalation is not a win.
• Change one thing at a time. Simultaneous changes to two rules make it impossible to attribute the effect, and impossible to reverse cleanly.

What "good" looks like as an outcome

Not a target percentage. Anyone quoting you a universal false positive benchmark is guessing — the right number depends entirely on customer base, product and risk appetite.

The defensible outcome is a documented position: here is what we changed, here is the testing that supported it, here is the detection we accepted losing, here is who approved that trade, and here is when we will look again. A firm that can produce that after cutting volume by half is in a strong position. A firm that halved volume and cannot explain the basis is in a worse position than before it started, because now the gap is self-inflicted and undocumented.

The failure mode nobody plans for

Tuning is treated as a project, completed, and then never revisited. Two years later the customer base has shifted, new products have launched, and the parameters are calibrated for a business that no longer exists.

Build the review trigger into the original decision — material change in customer mix, new product, new channel, a spike in confirmed cases below the line — and the programme stays alive rather than decaying quietly between examinations.

Where the leverage actually is

Ranked by return, in most estates I have seen:

• Removing duplicate and dead rules — fast, no detection cost at all
• Better customer segmentation — large volume reduction, strong defensibility
• Data quality fixes upstream — a surprising share of noise is bad reference data
• Alert ranking so analysts see the meaningful cases first — changes nothing about what is detected, changes everything about what gets proper attention
• Threshold movement — the smallest of the five, and the one everyone starts with

If a programme has never done the first four, threshold tuning is premature. It will produce a number that looks better and a control that is weaker.

More insights