A transaction monitoring scenario is a single detection rule or model inside an anti-money laundering monitoring system that describes one pattern of possibly suspicious activity, such as cash deposits kept just below a reporting limit or money that leaves an account almost as soon as it arrives. Each scenario has a written logic, a set of parameters and one or more thresholds, and when a customer's activity meets them the system generates an alert for an analyst to review.
Scenarios are the building blocks of transaction monitoring. A bank's transaction monitoring system may run dozens of them, each aimed at a risk the firm has identified in its AML risk assessment. The term is used in vendor software, regulatory exams and model governance; some vendors say "rule" or "detection model" for the same thing.
Transaction monitoring scenarios in plain terms
Think of a shopping centre with many security cameras, each pointed at a different spot: one watches the fire exit, one watches the till, one watches the car park at night. A scenario is one camera with one job. It does not try to see everything; it looks for a particular kind of behaviour and rings a bell when it sees it.
The bell is the alert. A person then watches the footage to decide whether something wrong actually happened. Because each camera only covers one spot, a shopping centre needs enough of them, pointed in the right places, to cover the risks it worries about. Banks think about scenarios the same way: which behaviours matter for their customers, and is there a scenario watching for each one?
Parts of a scenario
A scenario is normally documented with the same set of elements, so that it can be tested and explained to examiners:
- Risk addressed. The typology or red flag the scenario is meant to catch, for example structuring or rapid movement of funds.
- Population. Which customers, accounts and transaction types it runs on, often split by customer risk segmentation so that a business and a student are not judged against the same limits.
- Lookback period. The window of activity it examines, such as one day, seven days or a calendar month.
- Parameters and thresholds. The values that must be exceeded, such as a total amount, a count of transactions or a ratio of money out to money in.
- Alert output. What the alert shows the analyst and how it is scored or prioritised.
Common scenario types
Scenario libraries differ by firm, but most cover a familiar set of patterns:
- Cash structuring. Several cash deposits just under the threshold for a currency transaction report, which in the US is more than $10,000 in a day.
- Rapid movement of funds. Large credits followed by debits of a similar amount within a short time, a common layering indicator.
- High-risk geography. Wires to or from countries flagged by a geographic risk indicator.
- Velocity and spikes. A sudden jump in the number or value of transactions compared with the customer's own history, related to velocity checking in fraud control.
- Many-to-one and one-to-many flows. Many unrelated senders paying into one account, which can point to a funnel account or a money mule network.
- Profile mismatch. Activity out of line with the occupation, turnover or purpose declared at onboarding.
Rule-based scenarios are the traditional form. Many firms now add statistical or machine-learning models that score unusual behaviour without a fixed threshold, but regulators still expect each model to be tied to a defined risk and to be explainable.
Coverage and governance
Firms keep a coverage map that links each risk in their assessment to one or more scenarios, so that gaps are visible. A risk with no scenario is either handled by another control or recorded as a gap to fix. In New York, the Department of Financial Services' Part 504 rule, effective 1 January 2017, requires regulated institutions to maintain a transaction monitoring program whose detection scenarios reflect their risk assessment, and a senior officer or the board must certify compliance each year by 15 April.
US banking supervisors also treat complex scenarios and models as subject to model risk management guidance (SR 11-7, issued by the Federal Reserve and the OCC in 2011), which asks for documented design, independent validation and ongoing performance checks. Thresholds are set and reviewed through transaction monitoring tuning, and scenario performance is often measured by how many alerts turn into cases or a suspicious activity report, along with estimates of the false negative rate.
Limitations
Scenarios only see what they are designed to see. Criminals who know common thresholds can stay just under them, and patterns that cross several firms are invisible to any one firm's rules. Badly calibrated scenarios produce floods of false positives, which feed an alert backlog and pull analysts away from real cases. Scenarios also depend on clean data: a missing country code or a mislabelled transaction type can quietly switch a rule off for part of the population. For these reasons supervisors expect regular testing of data feeds as well as of the scenario logic itself.