Machine learning in AML transaction monitoring: Beyond fewer alerts

Efficiency is not the same as detection

Machine learning can help financial institutions improve anti-money laundering (AML) transaction monitoring. But reducing alert volumes is not the same as improving the detection of suspicious activity. The question is whether a model helps identify relevant risks – or reproduces the limitations of existing controls more efficiently.

Efficiency matters. Fewer unnecessary alerts can free up time for more focused investigations. Yet alert volumes alone do not tell us what a system fails to detect. Evaluating machine learning therefore means examining both operational efficiency and detection performance.

Previous decisions are not established facts

Consider an alert that an analyst closed without further investigation. The activity may have been legitimate. The available information may have been incomplete. Or the analyst may have overlooked something relevant.

If that decision is used as a “not suspicious” training example, the model may learn to reproduce the earlier judgement – including any error it contained. A closed alert records a decision; it does not, by itself, establish that the underlying activity was legitimate.

“The machine learns from the record it receives, including the blind spots that record may contain.”

For compliance teams, this raises a practical question: how much confidence should we place in historical case decisions when using them to train or evaluate a model?

Efficiency and detection need to be assessed together

Machine learning can identify relationships and patterns beyond those explicitly captured in monitoring rules. Used thoughtfully, it can help institutions examine customer behaviour from a different perspective.

But an anomaly is not proof of money laundering, and a familiar pattern is not evidence of legitimacy. Interpretation remains essential.

The objective should therefore be to assess efficiency and detection together: reducing unnecessary work while maintaining or improving the ability to identify relevant risks.

Start with a question you can test

Before selecting a model, define the problem it should help solve and the evidence needed to assess its performance. For example:

• Can it identify relevant patterns that existing monitoring scenarios miss?
• Can it prioritise alerts without systematically overlooking particular customer groups or behaviours?
• Does it add useful information, or mainly reproduce previous case decisions?
• Can it reduce unnecessary alerts while maintaining or improving detection?

These questions turn a broad ambition to “use AI” into a specific use case with measurable objectives.

Establish a baseline before relying on the model

A meaningful evaluation requires a baseline and a controlled comparison.

Historical cases, representative operational data and carefully designed synthetic scenarios can help assess what existing controls and a proposed model detect – and where each falls short. Each source has limitations: historical decisions may contain errors, while synthetic scenarios can test only the situations they are designed to represent.

Running a model alongside established controls allows teams to investigate differences before relying on its outputs in day-to-day operations. The aim is to understand not only whether performance changes, but why – and whether the evidence supports the intended use.

How Compliance Networks can help

At Compliance Networks, experts help institutions establish a baseline through testing and benchmarking of AML transaction monitoring systems. They identify detection gaps, assess the effects of different configurations and translate findings into practical improvements.

For institutions considering machine learning, this provides a structured starting point for selecting and evaluating a first use case.

Better monitoring starts with evidence: what your controls detect, where their limitations lie and whether a proposed change delivers a demonstrable improvement.