A scenario is a configured detection rule or model aimed at one specific money laundering or fraud pattern, defined by its own parameters and thresholds. Scenarios are the building blocks of a transaction monitoring program, and each one should trace back to a real risk you have actually identified.
What is a scenario, in plain English?
A scenario is a single, targeted piece of detection logic that watches for one specific behavior. Common examples are rapid movement of funds through an account, structuring cash just under a reporting limit, or a sudden spike in payments to a high-risk country. Each scenario is defined by its parameters: which accounts it looks at, what behavior it measures, and the thresholds that decide when it fires an alert.
Scenarios are the working parts of a transaction monitoring system. Instead of one giant rule trying to catch everything, a program runs a library of scenarios, each pointed at a known typology. When a customer's activity trips a scenario's conditions, the system generates an alert that lands in an analyst's queue for review.
The governing principle is simple: every scenario should map back to a real risk in your AML risk assessment. If you cannot say which risk a scenario covers, it has no reason to exist. Unmapped scenarios waste analyst time, and missing scenarios leave whole categories of risk unwatched.
How a scenario turns risk into alerts
A scenario is not written once and forgotten; it moves through a lifecycle from design to retirement:
- Design — Map to a risk. Start from a typology in your risk assessment, such as funnel accounts or structuring, and define the behavior to catch.
- Configure — Set parameters and thresholds. Decide which segment it applies to, the measure it watches, and the value that triggers an alert.
- Tune — Test above and below the line. Check that real risk fires alerts and that lowering the threshold would not surface much you are missing.
- Review — Retire or revise. Revisit as behavior and risk change; kill scenarios that chase outdated patterns and add ones for new threats.
What it looks like in practice
In practice
A payments firm identifies funnel accounts as a key laundering risk during its annual risk assessment. The team builds a scenario that flags any account receiving deposits from six or more unrelated senders within seven days, followed by a near total withdrawal.
An analyst opens the resulting alert and sees a personal account taking small transfers from strangers across three states, then wiring the pooled balance abroad the same afternoon. Because the scenario was documented and mapped to a named risk, the investigator can move straight to the funds flow and build a SAR narrative rather than justifying why the rule exists.
Why scenarios matter to operators
Scenarios are where a program's risk appetite becomes concrete. A vague policy about watching for structuring means nothing until a scenario defines exactly what structuring looks like in your data and when it fires. Weak or missing scenarios are among the most damaging exam findings, because they mean a risk you claimed to manage was never actually being monitored.
They also drive your workload. Too many loose scenarios flood analysts with noise; too few or too tight and genuine activity slips through. Getting the library right, and keeping it documented and current, is the difference between a monitoring program that generates useful cases and one that just generates volume.
What to watch with scenarios
- Unmapped logic. A scenario nobody can tie to a named risk in the risk assessment is a finding waiting to happen.
- Stale parameters. Thresholds set years ago that no longer match current customer behavior either miss risk or bury analysts.
- Coverage gaps. Typologies in your risk assessment with no matching scenario mean whole risk categories go unwatched.
- No testing evidence. Scenarios without above and below the line testing cannot be defended as calibrated to real risk.
- Alert quality. A scenario that produces near zero productive alerts over time is either broken, mistuned, or aimed at a dead risk.
Quick questions
How is a scenario different from a rule?
In practice the terms overlap. A scenario is usually a rule or model built around a specific typology, with its own parameters and thresholds. Vendors often call the configured detection logic a scenario and the underlying condition a rule.
How many scenarios should a program run?
There is no magic number. The right count is driven by your risk assessment: enough scenarios to cover the typologies you are actually exposed to, and no orphan scenarios covering risks you do not face.
Who owns scenario design?
Typically the AML or financial crime team defines what each scenario should catch, working with data and technology teams to configure it. Model risk or validation functions often review the logic independently.
Why retire a scenario?
Because risk changes. A scenario built for a product you no longer offer, or a laundering method criminals have abandoned, just adds noise. Retiring it, with documentation, keeps the library focused on live threats.
Can a scenario be a model rather than a simple rule?
Yes. Some scenarios are threshold rules, others are statistical or machine learning models that score behavior. Both still need mapping to risk, tuning, and documentation, and models add validation requirements.
What proves a scenario works?
A documented link to a specific risk, tuning evidence from above and below the line testing, and a track record of producing alerts that lead to genuine investigations rather than only false positives.
Go deeper
- FinCEN ↗ — The US financial intelligence unit. Bank Secrecy Act rules, advisories, and SAR and CTR guidance.
- FFIEC BSA/AML Examination Manual ↗ — The manual US examiners use to assess BSA and AML programs.