Why transaction monitoring rules produce false positives, and what to do about it

Every transaction monitoring rule is a hypothesis written in arithmetic: that a customer of this type, moving this much, in this pattern, over this window, is doing something worth a human look. A false positive is what happens when the hypothesis is right in general and wrong about this particular customer. The only rule that never produces one is a rule that never fires, and a rule that never fires is not a control.

So the useful question is never how to eliminate false positives. It is how to keep the volume proportionate to the risk you are actually covering, and how to prove — to internal audit, to a supervisor, to yourself in eighteen months — that the last round of tuning removed noise rather than coverage. This article is about both halves.

Where the noise actually comes from

In practice a small number of causes account for most of the alert volume that closes with no action. They are worth naming individually, because the fix for each is different and teams routinely apply the fix for one to another.

1. 01Segmentation that does not match the book

   One threshold applied across salary earners, market traders, logistics agents and a school collecting fees will be wrong for at least three of them. The trader clears the threshold weekly because that is the business; the salary earner clears it once and it means something. Segmentation is the highest-yield change available on most programmes and it is usually the least glamorous: it is a data exercise on occupation, entity type, expected turnover and product mix, not a modelling exercise.

2. 02Thresholds set by round numbers

   A threshold that sits on a round figure is almost always a threshold nobody derived. Look at the actual distribution of the behaviour in your own book, decide what proportion of it you intend to review, and set the parameter from that. Then write down the reasoning, because the reasoning is what you will be asked for, not the number.

3. 03Rules that restate one another

   Three rules that all key on rapid inbound-then-outbound movement will alert on the same customer on the same day, and the analyst will work the behaviour three times. Build an overlap matrix — for each pair of rules, the share of alerts raised on the same subject within the same window — before you conclude you have a volume problem. Sometimes you have a de-duplication problem.

4. 04Reference data that is stale or absent

   Rules that compare observed activity against expected activity are only as good as the expectation. If occupation, purpose of the relationship and anticipated turnover were captured once at onboarding and never revisited, the comparison is against a fact that was true three years ago. Missing values are worse: a rule that treats an absent expectation as zero will alert on everything, and a rule that treats it as unlimited will alert on nothing.

5. 05Time windows that do not match the behaviour

   Structuring played out over six weeks is invisible to a twenty-four-hour window, and ordinary business banking looks alarming inside one. Window length is a modelling choice about the typology you are trying to catch, and it deserves the same written rationale as the threshold beside it.

6. 06Name matching borrowed from screening

   Fuzzy matching is the right tool against a sanctions list and the wrong tool against a payment narrative. Narrative fields carry abbreviations, merchant descriptors and free text; a matcher tuned for transliterated personal names will find something in almost all of them.

Measure before you tune

Most tuning exercises fail because they begin with a threshold and end with a threshold, with an argument in the middle. You cannot tune what you have not counted. Before changing a parameter, the programme should be able to produce the following without a data request:

• Alert volume per rule per period, as a count and as a share of the total.
• Alert-to-case conversion per rule: what proportion of alerts a rule raises are escalated into an investigation at all.
• Case-to-report conversion per rule: of the investigations it caused, how many ended in a report to the financial intelligence unit.
• Disposition reasons per rule, drawn from a closed and governed vocabulary.
• Overlap between rules: alerts raised on the same subject, in the same window, by more than one rule.
• Analyst effort per alert, at least as a median, so the volume can be translated into cost.
• Age of the reference data each rule depends on, so you know which comparisons are still meaningful.

The fourth of those is the one that most often does not exist, and it is the one that makes the exercise possible. If analysts close alerts with free-text notes, you can count how many closed but not why. A closed vocabulary — expected activity for this customer segment, known counterparty, duplicate of an earlier alert, data quality defect, insufficient information, escalated — turns a queue metric into a diagnosis. Free text tells you the queue was long. A disposition taxonomy tells you which of the six causes above you actually have.

rule                 R-014 rapid pass-through, retail segment
period               last four complete quarters
alerts               volume, and share of all alerts
escalated            count and rate to investigation
reported             count and rate to filed report
dispositions         by governed reason code, not free text
overlap              share also alerted by R-009 / R-021 in window
effort               median analyst minutes per alert
proposal             parameter, old value, new value, rationale
evidence             above-the-line and below-the-line sample results
approver             maker, checker, effective date, review date

Tuning without losing coverage

A threshold change is a change to the institution's detection coverage. Treat it with the evidence and the approval that implies, because that is how it will be treated when somebody reviews it later.

1. 01Test above the line

   Replay the proposed parameters against a historical period and look at the alerts you would still have raised. This tells you the volume effect, which is the easy half.

2. 02Test below the line

   Then sample what the new parameters would have stopped raising, and have an experienced investigator work that sample as though it were live. This is the half that answers the question a reviewer will actually ask: what did you give up? A tuning proposal with no below-the-line sample is a volume-reduction proposal wearing a risk-management costume.

3. 03Keep the versions

   Record which rule version, with which parameters, produced each alert, and keep it. Without that, an alert closed last quarter cannot be explained, because the rule that produced it no longer exists in the form that produced it. Deterministic replay of an old alert against the exact rule version that raised it is the difference between a tuning history and a set of assertions about a tuning history.

4. 04Approve it like a change, not a setting

   One person proposes, a different person approves, both are recorded, and the change carries an effective date and a review date. Segregation of duties here is not bureaucracy: the same pressure that makes a long queue feel like a tuning problem is the pressure that makes self-approval feel reasonable.

5. 05Watch the effect deliberately

   Set the review date when you make the change and put the post-change metrics beside the pre-change ones. A tuning round with no scheduled look-back is indistinguishable, six months later, from a tuning round that did nothing.

Four things that look like tuning and are not

• Suppressing an alert type without recording why. The volume disappears from the queue and from the analysis at the same time, which is the worst possible combination.
• Whitelisting a customer permanently. Risk is a property of behaviour over time, and a permanent exemption is a decision that the customer's future behaviour does not need looking at. Exemptions need an owner, a rationale, an expiry and a review.
• Raising a threshold because the backlog is long. The backlog is a capacity fact. The threshold is a risk-appetite decision. Letting the first set the second is how coverage is lost without anyone deciding to lose it.
• Closing in bulk. If a hundred alerts can be closed with one reason in one action, the interesting question is why a rule raised a hundred identical alerts, and that question disappears the moment the queue is cleared.

What good looks like

A monitoring programme in decent health can answer these questions from its own records, without a project:

1. Which typology is each rule intended to detect, in a sentence a non-specialist can read?
2. Which customer segments is it applied to, and why those?
3. Where did each parameter come from, and when was it last examined?
4. For any alert closed in the last two years: which rule version and which input values produced it?
5. For each rule: what share of its alerts became investigations, and what share of those became reports?
6. What was given up at the last tuning round, and who accepted that trade?
7. Which rules have never produced an escalation, and is that a rule problem or a coverage decision?

Baobyte's monitoring module is built around that last point: rule evaluations retain the rule version and the evidence that produced them, alerts link to the case they became, and a decision can be replayed rather than reasoned about after the fact. That does not make the tuning judgement for you. It makes the judgement reviewable, which is the part institutions usually find they are missing.