Transaction monitoring: tuning what it finds.

What the system is actually for

Most transaction monitoring programmes can tell you how many scenarios they run, how many alerts they produced and what proportion became reports. Very few can tell you whether any of it was useful. That gap is the subject of this course.

The standard-setters moved first. When the FATF revised its evaluation methodology in 2013, it stopped assessing countries only on whether the right laws existed and began assessing whether the system produced results. The private sector followed. In its 2019 Statement on Effectiveness, the Wolfsberg Group — an association of large international banks that publishes financial crime standards — set out three things an institution should be measured against, now usually called the Wolfsberg Factors:

1. Comply with AML and counter-terrorist-financing law and regulation.
2. Provide highly useful information to relevant government agencies in defined priority areas.
3. Maintain a reasonable, risk-based set of controls to mitigate the risk of being used to facilitate illicit activity.

Read the second one again. It is not "file reports". It is provide information someone can use.

Monitoring is wider than transaction monitoring. In its 2024 Statement on Effective Monitoring for Suspicious Activity, the Wolfsberg Group deliberately used the broader term Monitoring for Suspicious Activity (MSA), because customer behaviour and customer attributes, considered alongside transactions, give a fuller picture than transactions alone. Transaction monitoring is a subset of MSA, which also takes in ongoing customer due diligence — and, in principle, activity by employees, vendors and counterparties, not only customers.

The Group's criticism of current practice is blunt, and worth sitting with. It does not believe the value derived from the constantly increasing volume of reports is contributing proportionately to effective outcomes. It identifies specific practices that institutions continue because they look like compliance:

• Expanding red flag and typology coverage across the whole customer and product range, even where the institution's own data shows those scenarios produce little or no escalation.
• Ensuring no historical report is "left behind", which produces over-alerting programmes that are kept alive by precedent rather than risk.
• Defensive filing — reporting wherever a flag triggered and the legitimacy of the transaction could not be fully established. The Group notes that this gradually lowers the threshold for filing. It removes regulatory risk for the institution and is unlikely to give law enforcement anything useful.

There is a sharper observation underneath. Published red flag and typology papers are public. Criminals read them too, and adapt their behaviour to avoid the patterns everyone has implemented. A scenario library built entirely from public typologies is, to some degree, a list of the behaviours sophisticated actors already know to avoid.

So what does the institution owe? Not maximum coverage. A defensible account of the risks it actually faces, detection aimed at those risks, and evidence that what it sends out is worth reading.

From typology to scenario

A typology is a description of how a crime moves money. A scenario is a piece of executable logic that tries to spot it. Translating one into the other is where most of the quality is won or lost, and it is largely a design problem rather than a technical one.

Start with the risk, not the catalogue. The question is not "which published red flags exist" but "which of them could plausibly happen here, given this institution's customers, products, channels and geographies". A rural savings institution with no trade finance does not need trade-based laundering scenarios; running them produces nothing but noise and a line in a coverage table.

A scenario worth having can answer four things:

• What behaviour does it describe? Stated in a sentence, in business terms, before any logic is written. If nobody can say what it is looking for, nobody can judge whether it works.
• Which risk does it address, and where is that risk recorded? It should trace back to the institution's own risk assessment. A scenario that addresses no assessed risk is decoration.
• What would a true positive look like? If the team cannot describe one, they cannot tune it, and they will not recognise one when it arrives.
• What does the data have to support? Most scenario failures are data failures: the field is not populated, the counterparty name arrives truncated, the originator country is absent on a quarter of payments. Design against the data you have, and record the data you need.

Scenario shapes, and what each is good for.

• Thresholds — activity above an amount, or a count within a period. Simple, explainable, and easily defeated by anyone who knows the number.
• Deviation from expected behaviour — activity inconsistent with what this customer, or customers like them, normally do. Stronger, but entirely dependent on the quality of the comparison, which is the subject of the next lesson.
• Patterns over time — structuring, rapid movement through an account, round-tripping, dormancy followed by sudden activity.
• Relationship and network — activity that makes sense only when accounts are seen together. The Wolfsberg Group points towards linking internal customer, account and transaction data with external data to build a contextual, network-based view, and towards building risk profiles for key entities including underlying customers and ultimate beneficial owners.
• Anomaly detection and machine learning — finding what no one wrote a rule for. Powerful, and carrying its own obligations: explainability to a supervisor, validation, and a route for an investigator to understand why something surfaced.

Coverage is a weak measure of quality. A library of 200 scenarios where 30 produce every meaningful escalation is not better than a library of 40 that are understood, tuned and owned. Retiring a scenario that has produced nothing in two years is a legitimate, documentable decision — and a far better use of effort than adding the next one.

Segmentation, or why behaviour needs a baseline

Almost every scenario worth running compares a customer against something: their own history, or their peers. Segmentation is how those peer groups are drawn, and it quietly determines whether "unusual" means anything at all.

How most institutions do it. Traditional segments are built from static attributes — customer type, industry, type of business, inherent customer risk — captured at onboarding and refreshed at review.

What the Wolfsberg Group says is wrong with that. Two specific drawbacks are identified. First, such segments do not consistently capture common transaction activity among the entities grouped together: customers sharing an industry code may behave nothing alike. Second, they rely mainly on outdated information — the static data gathered at onboarding, refreshed only at periodic, event-driven or perpetual review. A segment built on what a customer said they would do three years ago is not a description of what they do now.

The consequence in practice. If a segment is too broad, it averages across genuinely different behaviours, the expected range becomes wide, and real anomalies sit comfortably inside it. If it is too narrow, there is not enough data to establish any stable baseline, and ordinary variation looks alarming. Either way the alerts are wrong, and no amount of threshold tuning fixes a badly drawn population.

The direction of travel. The Group suggests monitoring and analysing actual transactions and patterns of activity to create new, more meaningful segments on an ongoing basis — a combination of known attributes with dynamic statistical clustering, so that segments account for changes in behaviour and stay current. It notes that more advanced, dynamic segmentation at a lower level can improve the performance and accuracy of detection models and reduce false positives.

What that demands of you, if you go that way. Behavioural clustering is a model, and inherits every obligation a model carries: documented purpose, a basis for the number of segments chosen, validation that the clusters are stable over time, monitoring for drift, and an explanation a supervisor can follow. A segment that silently re-forms every month, moving customers between populations without record, will not survive examination — and will make your own tuning history impossible to interpret, because the baseline moved underneath it.

A practical middle path. Many institutions keep a stable, explainable segmentation for regulatory scenarios and run behavioural clustering alongside it to find what the fixed segments miss. That is defensible, provided both are documented and the relationship between them is understood.

Thresholds, and testing them honestly

A threshold is a decision about how much risk to leave undetected. Treating it as a technical setting rather than a risk decision is how programmes end up with numbers nobody can justify.

Where thresholds usually come from, and why that is a problem. Most were set at implementation — inherited from a vendor default, a peer institution, or an estimate of how many alerts the team could handle. Capacity-driven thresholds are extremely common and almost never written down as such, because stating "this number is what we can staff" invites the obvious question.

A defensible threshold is derived from the data. Take the population the scenario applies to, look at the actual distribution of the behaviour, and decide where in that distribution the institution's risk appetite sits. That produces a number you can explain, and a basis to revisit when the distribution changes.

Above-the-line and below-the-line testing are how a threshold is tested.

• Above-the-line (ATL) testing samples alerts the system did produce, at and above the current setting, and asks how many were worth producing. It measures precision.
• Below-the-line (BTL) testing is the important one. It samples activity that fell below the threshold — activity the system deliberately ignored — and asks whether anything in it should have alerted. The Wolfsberg Group's 2025 Part II describes this as lowering the thresholds or criteria below the baseline to identify the point at which the system may generate false negatives and miss potentially suspicious activity.

Without BTL testing, an institution has no evidence about what it is missing, which is precisely the thing a supervisor will ask about. An ATL-only programme can only ever prove it is good at finding what it already finds.

Why small threshold reductions achieve little. A common tuning practice is to nudge an existing parameter — dropping a threshold by ten per cent below its current value and reviewing what falls in. The Wolfsberg Group is direct about this: minor modifications to existing parameters are unlikely to produce meaningful results, or to materially increase the overall effectiveness of detection. The reason is structural. If the scenario is looking at the wrong behaviour, or the segment is wrong, a slightly lower number finds slightly more of the wrong thing.

Challenger models. A more honest test is to run an alternative approach alongside the production one — a different scenario design, a different segmentation, a model rather than a rule — and compare what each surfaces over the same period. Part II encourages testing new challenger models through these reviews. The value is not only the better model; it is discovering what the incumbent systematically cannot see.

Sampling has to be defensible too. A BTL review of thirty items picked by an analyst proves nothing. The sample needs a stated method, a size with a basis, coverage of the segments that matter, and a record of who reviewed each item against what criteria. Reviewers should be able to escalate, and some should — a BTL review that never finds anything, year after year, is itself a finding.

Governance, metrics, and what a supervisor asks

Scenarios and thresholds are models, and change control is the whole game. Whatever framework the institution uses, the minimum is the same: every scenario and threshold has a documented rationale, an owner, a date, and an approval; every change records what changed, why, who approved it, and what evidence supported it; and the system's configuration at any past date can be reconstructed. That last one is routinely missing, and it is fatal — if you cannot show what the system was doing in the year under review, you cannot defend what it did or did not find.

The metrics most programmes report do not measure effectiveness. The Wolfsberg Group names the usual set: coverage of relevant red flags and typologies, alert and case volumes, alert productivity, and alert-to-report ratios. Its assessment is that these are limited in their ability to measure actual effectiveness, because they measure the quantity of information produced rather than its usefulness.

Consider the alert-to-report conversion rate, which many institutions report monthly. A rising rate can mean detection improved. It can equally mean the filing threshold dropped and the team is filing defensively — the exact behaviour the Group criticises. The same number describes both a success and a failure, which makes it useless on its own.

What is worth measuring instead is harder and more honest:

• What happened to what you sent. Feedback from the financial intelligence unit or law enforcement, where the jurisdiction provides any, is the only direct evidence of usefulness. Where it is not provided, record what you do receive: production orders, account freezing orders, information requests — each one is evidence that something you filed was being worked.
• What you missed, and how you know. BTL results, challenger model comparisons, and cases that came to light another way — from media, a law enforcement request, an internal referral — are the only honest measure of coverage.
• Whether detection matches the risk assessment. If the risk assessment names three priority risks and the alerts cluster entirely on a fourth, one of the two documents is wrong, and finding out which is valuable.
• Data quality underneath it all. Field completeness and accuracy on the data scenarios depend on. A monitoring system reading incomplete data produces confident output from nothing.

What a supervisor will actually ask. Expect the questions to be about reasoning rather than inventory: why these scenarios and not others; why this threshold and not another; what you did with what you learned; and what evidence you hold that the system finds what it is meant to find. "The vendor supplied it" and "it has always been set there" are not answers. A programme that can show a documented chain from risk assessment to scenario to threshold to tested outcome is in a strong position even where its numbers are modest. A programme with excellent numbers and no reasoning is not.

The uncomfortable conclusion. A smaller, well-reasoned, well-tested monitoring programme that files fewer but genuinely useful reports is closer to what the standards now ask for than a large one filing everything. Getting there requires the institution to accept a defensible lower number — and that is a governance decision taken at the top, not a tuning decision taken by an analyst.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.