September 12, 2026

Common Transaction Monitoring Scenarios (and When to Retire Them)

Axle Team

Key takeaways

Most programs run the same core transaction monitoring scenarios — structuring, rapid movement, high-risk geography, cash intensity, dormancy spikes — and most have at least one that hasn't produced a SAR in years.
Scenarios decay because the customer base, products, and typologies drift while thresholds stay frozen. The FFIEC expects parameters to be tailored to your risk, not inherited from a vendor default.
Retirement is a model risk decision, not just a tuning decision. SR 11-7's ongoing monitoring standard is the cleanest framework for justifying it.
Never retire a scenario without documenting the compensating coverage. The evidence file matters as much as the analysis.

The transaction monitoring scenarios most programs run

Transaction monitoring scenarios are the rules a monitoring system applies to flag potentially suspicious activity — structuring below reporting thresholds, rapid movement of funds, flows to high-risk jurisdictions, cash activity inconsistent with profile, and dormant accounts that suddenly reactivate. A scenario is a candidate for retirement when it has produced no SARs over a full review cycle, duplicates another rule's coverage, and the risk it targets is documented as covered elsewhere.

That second half is where programs stall. Adding transaction monitoring scenarios is easy; every new typology advisory, exam finding, or risk assessment refresh adds one. Removing them feels like signing your name to a future exam finding. So rule libraries only grow, alert volume compounds, and analysts spend their days on scenarios that stopped earning their keep years ago.

Here are the scenario families that show up in nearly every rule library, and how each one typically decays:

Structuring below CTR threshold — What it targets: Cash deposits kept under $10,000. Typical failure mode: Threshold set exactly at $10,000 misses deliberate structuring just below it.
Rapid movement / flow-through — What it targets: Funds in and out within days. Typical failure mode: Fires constantly on payroll, sweep accounts, and normal fintech wallet behavior.
High-risk jurisdiction corridors — What it targets: Wires to/from listed geographies. Typical failure mode: Country list frozen since implementation; risk ratings long out of date.
Cash intensity vs. profile — What it targets: Cash activity inconsistent with stated business. Typical failure mode: Expected-activity profiles never refreshed after onboarding.
Dormancy reactivation — What it targets: Inactive account suddenly transacting. Typical failure mode: Duplicates velocity rules; two alerts, one investigation.
Velocity / peer deviation — What it targets: Volume spikes vs. peer group. Typical failure mode: Peer groups defined once, never re-segmented as the book changes.

The FFIEC BSA/AML Examination Manual is explicit that these choices are supposed to be institution-specific:

"Parameters and filters should be reasonable and tailored to the activity that the bank is trying to identify or control."
— FFIEC BSA/AML Examination Manual, Suspicious Activity Reporting

The manual even supplies the canonical example of a badly calibrated scenario: a structuring filter that only triggers above $10,000, which misses the transactions deliberately placed just under the CTR threshold. If your rule library still contains that exact defect — and many do — the problem isn't the scenario concept, it's that nobody has revisited the parameters since go-live.

Why transaction monitoring scenarios decay

Scenarios don't break; the world around them moves. A fintech that launched with consumer wallets and now does B2B payouts has a different structuring risk. A bank that exited correspondent relationships no longer needs the same corridor rules at the same sensitivity. Peer groups built on the 2021 customer base misclassify the 2026 one.

This is why scenario retirement belongs under model risk management, not just annual tuning. The Federal Reserve and OCC's supervisory guidance on model risk (SR 11-7) frames it directly:

"Ongoing monitoring is essential to evaluate whether changes in products, exposures, activities, clients, or market conditions necessitate adjustment, redevelopment, or replacement of the model and to verify that any extension of the model beyond its original scope is valid."
— Federal Reserve SR 11-7, Supervisory Guidance on Model Risk Management

"Replacement" is doing real work in that sentence. The guidance anticipates that some models — and monitoring scenarios are models or model-adjacent in most validation inventories — reach the end of their useful life. Treating every scenario as permanent is itself a deviation from the standard.

When to retire a transaction monitoring scenario: a five-step process

Pull the yield data. For each scenario over the last 12–24 months: alerts generated, escalation rate, SAR conversion, and whether any SAR it produced was unique (would not have been caught by another rule). A scenario with zero unique SARs across two review cycles is a candidate — not a conclusion.
Run overlap analysis. Map every alert the candidate scenario produced against alerts on the same customer within the same window from other scenarios. High overlap means you're paying twice for the same coverage.
Do below-the-line testing. Sample activity just under the scenario's thresholds and disposition it as if alerted. If below-the-line sampling shows the scenario is mis-set rather than useless, the answer is retuning, not retirement.
Map the risk to compensating coverage. Write down, typology by typology, which surviving scenario or control covers what the retired one covered. If nothing does, you're not retiring a scenario — you're accepting a coverage gap, and that's a different governance conversation.
Take it through governance and keep the file. Retirement should carry the same approval weight as deployment: documented rationale, BSA officer sign-off, and inclusion in the next independent validation scope.

The FFIEC sets the documentation bar, and it applies on the way out just as much as on the way in:

"Management should document and be able to explain filtering criteria, thresholds used, and how both are appropriate for the bank's risks. Management should also periodically review and test the filtering criteria and thresholds established to ensure that they are still effective."
— FFIEC BSA/AML Examination Manual, Suspicious Activity Reporting

The shadow-mode retirement

Here's the workflow trick that makes retirement politically survivable: don't turn the scenario off. Route its alerts out of the analyst queue into a suppressed bucket for 90 days while it keeps running. At the end of the window, disposition a sample of the suppressed alerts and check whether anything in the bucket would have been escalated. You convert an argument about hypothetical risk into a dataset about actual risk — and the person approving the retirement signs off on evidence, not on a prediction. In our experience the sign-off conversation changes completely when the memo says "we reviewed 400 suppressed alerts and zero warranted escalation" instead of "we believe yield will remain low."

The political reality is worth naming: nobody wants to be the person who turned off the rule that would have caught the next enforcement-action case. Pairing every retirement with its compensating-control map in the same memo distributes that risk across the governance process, where it belongs.

Where AI agents change the math

The reason dead scenarios survive is cost asymmetry: keeping a low-yield rule costs analyst hours, but those hours are diffuse and already budgeted, while retiring it costs a concentrated governance effort. AI agents shift that asymmetry from both sides. An agent working transaction monitoring alerts dispositions the low-value volume with a documented rationale on every alert, which means the yield and overlap data you need for step 1 and step 2 accrues as a byproduct of daily work instead of a quarterly data-pull project. Axle's transaction monitoring agent, Rose, works L1/L2 alerts this way — every disposition is written down, consistent, and queryable, which is exactly the evidence base scenario governance runs on. If you want to quantify what your current alert volume costs before and after, the ROI calculator is a reasonable starting point.

FAQ

How often should transaction monitoring scenarios be reviewed?

At minimum annually, and after any material change in products, customer segments, or risk assessment — the trigger-based standard in SR 11-7's ongoing monitoring expectations. High-volume scenarios at fintechs with fast-moving books justify semi-annual review. The review should cover yield, overlap, and below-the-line testing, not just threshold sensitivity.

Can you retire a scenario without regulatory pushback?

Yes, if the file is complete: yield analysis, overlap analysis, below-the-line results, a compensating-coverage map, and governance approval. Examiners challenge undocumented retirements, not documented ones. What draws findings is a scenario that disappeared between exams with no record of why.

What's the difference between tuning and retiring a scenario?

Tuning changes parameters — thresholds, segments, lookback windows — because the scenario targets a real risk but fires imprecisely. Retirement removes the scenario because the risk is gone, was never present at your institution, or is fully covered elsewhere. Below-the-line testing is usually what tells you which situation you're in.

If your team is carrying a rule library that has only ever grown, see how Rose, Axle's transaction monitoring agent, turns alert-by-alert dispositions into the evidence base that makes scenario governance — including retirement — defensible.

Common Transaction Monitoring Scenarios (and When to Retire Them)

More from the blog