Your transaction monitoring alerts are over ninety per cent false positive. Is that a defect, and what would you do about it?

Define the rate before defending it

The first move is to ask what the number counts, because "false positive" is doing unearned work in the question. An alert closed with no further action is not proven innocent; it is unproven. Nobody hands you a labelled dataset of laundered transactions. The only labels you ever get are the bank's own dispositions — closed, escalated to a case, reported to the financial intelligence unit — and occasionally, years later, a law-enforcement outcome for a tiny subset.

So the measurable quantity is the alert-to-case or alert-to-report conversion rate, and it is a statement about your triage decisions as much as about the transactions. That distinction matters practically: a programme can drive its "false positive rate" down by closing alerts more aggressively, which improves the metric while making the control worse. Any candidate who takes the ninety-plus per cent figure at face value and starts optimising it has already missed the trap.

The arithmetic that makes the rate inevitable

Work it through with explicit assumptions rather than asserting industry figures. Take a portfolio pushing a million transactions through monitoring in a month. Suppose the true incidence of transactions that a well-informed investigator would find reportable is one in ten thousand — a hundred of them. Suppose your rules are good: they catch eighty of those hundred, and they wrongly flag only half a per cent of the clean traffic.

Half a per cent of the roughly 999,900 clean transactions is about five thousand alerts. Add the eighty true ones and you have around 5,080 alerts of which eighty matter: a precision under two per cent. Nothing in that calculation is a bug. A specificity of 99.5% would be excellent in most classification problems and it still buries you, purely because the negative class is four orders of magnitude larger than the positive one. To get precision to fifty per cent at that recall you would need the false-positive rate on clean traffic to fall to roughly eight in a hundred thousand, which is a different order of discrimination than transaction features support.

This is the argument to make out loud, because it reframes the question from "fix the model" to "given that precision is structurally low, where should the cost go". It also explains why the asymmetry of errors is not negotiable: a missed report is a control failure with consequences for the bank and its licence, while an extra alert costs analyst minutes. Any tuning that trades recall for precision is trading a regulatory obligation for an operating cost, and that trade needs evidence and sign-off, not a pull request.

Rules and models are not competing for the same job

Candidates commonly propose replacing rules with machine learning. The stronger position is that they do different things and both stay.

Rules encode specific typologies and specific obligations. Structuring just under a reporting threshold, rapid movement through a pass-through account, transactions touching a high-risk jurisdiction, activity inconsistent with a stated occupation. Their virtue is that they are explainable by construction and mappable to a documented typology, which is exactly what an examiner asks you to show. Their vice is that they are brittle, they proliferate, and each new rule adds alerts without anyone retiring an old one.

Models earn their place in two roles that do not require them to be the decision. The first is scoring and ranking alerts that rules have already raised, so that analyst attention goes to the top of the queue rather than to the oldest item. The second is detecting behaviour no rule describes — anomaly detection against the customer's own history and against peer groups, and network analysis that finds structure across accounts, such as funds converging on a beneficiary through unrelated-looking parties. Segment-level anomaly detection is also how you catch the typology you have not written a rule for yet, which is the whole category rules cannot cover.

Where a model does change a decision, it inherits every governance obligation a credit model has: documented purpose, held-out validation, monitoring for drift, a version pinned to each alert it scored, and a written explanation of why it fired that a human can read.

Move the cost, not just the count

The pressure that actually hurts is analyst hours, and hours are alerts multiplied by minutes per alert. Most programmes attack only the first factor.

Reducing minutes per alert is the cheaper win and gets less attention. An alert that arrives as a transaction reference forces the analyst to gather context by hand across six systems, and that gathering is most of the elapsed time. An alert that arrives pre-enriched with the customer's risk rating and expected-activity profile, the counterparty history, the related-party graph, prior alerts and their dispositions, and the specific rule logic that fired, can be dispositioned in a fraction of that. Deduplication and consolidation matter for the same reason: several rules firing on one behaviour should present as one investigation of a customer over a period, not as five independent alerts that each get worked from scratch. Auto-closure of narrowly defined, evidenced patterns — with the rationale recorded and a sampled quality review over the closures — is legitimate when the pattern is genuinely benign and documented, and indefensible when it is a volume-management device.

Case management is where this becomes real. The alert is a signal; the case is the unit of record. It holds the narrative, the evidence gathered, the four-eyes review, the escalation decision and the report if one is filed. It is also the source of your only labels, which is why disposition reasons must be structured rather than free text — a queue of alerts closed as "no concern" teaches you nothing, whereas dispositions coded to a reason taxonomy let you find which rule produces which kind of noise.

Tuning you can defend

The move that separates a strong answer is knowing how a threshold change is evidenced. If you propose raising a rule's threshold, the question you will be asked is whether you have suppressed genuine suspicion, and the answer cannot be "volumes fell". The technique is below-the-line testing: sample the population that sits just under the proposed new threshold — the alerts the change would have prevented — investigate that sample as though it had alerted, and show what the outcomes were. If the sample yields nothing that would have escalated, you have evidence. If it yields cases, the threshold stays. The same logic runs above the line to check that the retained band is producing value.

That evidence pack, plus a record of who approved it, is the deliverable. Tuning without it is the one change in this domain most likely to be found as a finding, because it looks identical to deliberately blinding the control.

A ninety-five per cent no-further-action rate is what a recall-first screening control looks like against a base rate of one in ten thousand. Treat it as a cost-allocation problem — better enrichment, consolidated investigations, models ranking rather than replacing rules — and change a threshold only with below-the-line evidence attached.