Cutting false positives in transaction monitoring with ML

To cut false positives in transaction monitoring, keep your rules as the detection layer and add a machine learning model that scores the alerts they raise, then suppress or deprioritise the lowest-risk scores within a false-positive budget you set. The gain comes from entity-level and behavioural features the rules cannot express, validated against confirmed suspicious activity rather than analyst dispositions.

Most AML monitoring runs on thresholds. A transaction above a round-number amount, a velocity count over a window, a jump against a customer’s own history. These rules are cheap to explain to a regulator and terrible at precision. A retiree who sells a car trips the same structuring pattern as someone actually structuring. The team’s answer is usually to widen the net, because a missed SAR is a headline and a false alert is just an analyst’s afternoon. So the alert queue grows, and the same analysts who are supposed to catch the real cases spend most of their week clearing noise.

The model does not replace the rules. It reads the alerts the rules produce and decides which ones deserve a human.

Keep the rules, score their output

There is a strong temptation to throw out the rule engine and let a model detect everything end to end. Resist it. The rule layer is your coverage story: you can point at each scenario, map it to a typology, and show an examiner why it exists. A pure model gives you a number and a shrug. What works instead is a two-layer arrangement. The rules stay as the recall floor and fire as generously as they do today. The model sits behind them and assigns each alert a probability that it is worth investigating.

That framing changes what you have to prove. You are no longer claiming the model finds crime. You are claiming that among alerts the rules already raised, the model ranks them well enough that you can safely stop looking at the bottom slice. The safety of that slice is an empirical question you answer with data, not a promise.

Concretely:

• The rules define the population. Every alert still gets a record and an audit trail, including the ones the model wants to suppress.
• The model produces a score, and you cut the score into tiers: straight-through-close, deprioritise, normal, escalate.
• You set a false-positive budget per tier and hold to it. The lowest tier only exists if its measured miss rate against confirmed-suspicious labels stays under the number your MLRO signed off on.

The point is that suppression is a policy decision with a number attached, and the number is backtested. Nothing gets closed automatically because a model felt confident.

The features that actually move precision

The rules are blind to context because a threshold is a single number. Precision comes from features that describe behaviour and relationships, and almost all of the engineering effort goes here rather than into model choice.

The families that carry the signal:

• Deviation from the customer’s own baseline. A flat “amount over 10,000” says nothing about this customer. What carries signal is where the amount sits in a rolling distribution of their own activity, standardised, with the current alert excluded from the window.
• Peer-group behaviour. A 50,000 wire is unremarkable for a commercial importer and loud for a student account. Segment customers and compare within segment.
• Counterparty and network features from entity resolution. How many distinct counterparties, how concentrated, whether counterparties connect to previously filed cases, whether beneficiaries were seen days ago on a different alerting customer.
• Temporal structure. Bursts, round-tripping, dormancy followed by sudden throughput, timing near reporting thresholds.
• Alert history for the entity. Prior dispositions, prior SARs, how many times this scenario has fired and been cleared.

Every one of these is a leakage trap if you build it carelessly. The classic mistake is computing a rolling aggregate over a window that includes the alert date, or joining KYC fields as they look today rather than as they looked when the transaction settled. The model then learns from information no analyst had at decision time, scores beautifully offline, and collapses in production. Build features as of the transaction timestamp, enforce point-in-time correctness in the feature store, and make lineage explicit so you can reconstruct exactly what any score saw. This is also where reconciliation matters: if the transaction amounts feeding features disagree with the ledger, your baseline is wrong before the model starts.

Validate against outcomes, not analyst opinion

The seductive label is the analyst disposition, because you have millions of them. It is also the wrong target if you use it alone. Dispositions are noisy, they inherit the biases of whoever cleared the queue that day, and training a model to agree with past analysts teaches it to reproduce their misses. Use dispositions as a signal, but anchor evaluation on the outcomes that matter: confirmed-suspicious cases and filed SARs.

Split the eval set by time, never at random. Train on one period, test on the next, so the evaluation mirrors how the model will actually be used, forward in time. Random splits leak future entity behaviour into training through shared customers and let you claim precision you will not see. Then read two numbers together:

• Recall against confirmed-suspicious cases in the held-out period. This is the number that must not drop. Alert reduction that quietly sheds real cases is worse than the noise it replaced.
• Precision, or equivalently the size of the suppressible tier at a fixed recall. This is the workload you give back to the team.

Watch drift on both. Typologies move, mules rotate, quarter-end and payroll cycles shift volumes, and a threshold calibrated in January is stale by summer. Monitor score distributions and tier miss rates on a schedule, keep every suppressed alert reproducible from stored features, and re-tune when recall on fresh labels slips rather than on a calendar. When an examiner asks why a given alert was never worked, the answer has to be a tier, a policy, a version, and the data the model saw, all recoverable from the audit trail.

The honest version of this work is unglamorous. Most of the win is in point-in-time feature construction and in refusing to let disposition labels stand in for ground truth. Get those two right and the model layer earns its place. Get them wrong and you have automated the act of missing the cases you were built to catch.