September 10, 2026

A Risk-Based Approach to Transaction Monitoring Thresholds

Axle Team

Key takeaways

Examiners don't ask whether your thresholds match industry norms. They ask whether you can explain why each threshold fits your risk profile — and show the tuning evidence.
A single threshold applied across the whole book is a calibration error in both directions: it floods analysts with false positives in low-risk segments and misses structuring in high-risk ones.
Segmentation quality matters more than threshold precision. A perfectly tuned threshold on a stale segment is still miscalibrated.
Below-the-line testing is the part most programs skip — and the first thing a validator or examiner looks for.
The 2018 interagency statement gives explicit cover for piloting AI-driven approaches alongside existing rules without automatic supervisory penalty.

What is risk-based transaction monitoring?

Risk-based transaction monitoring means calibrating detection scenarios and alert thresholds to each customer segment's risk profile, rather than applying one rule set across the entire book. Higher-risk segments get tighter thresholds and more scenarios; lower-risk segments get looser ones — with documented rationale, periodic tuning, and independent validation to prove the calibration works.

That definition sounds obvious. In practice, most monitoring programs drift away from it: thresholds get set at vendor defaults during implementation, segments get assigned at onboarding and never revisited, and tuning happens only when alert volumes become operationally painful. None of that is risk-based transaction monitoring — it's volume management wearing a risk-based costume.

The regulatory anchor here is direct. The FFIEC BSA/AML Examination Manual states:

"The sophistication of monitoring systems should be dictated by the bank's risk profile, with particular emphasis on the composition of higher-risk products, services, customers, entities, and geographies."
— FFIEC BSA/AML Examination Manual, Suspicious Activity Reporting

Why flat thresholds fail in both directions

A flat threshold — say, alerting on aggregate cash activity above $8,000 in a rolling week for every customer — is wrong for almost everyone it touches.

For a cash-intensive grocery wholesaler, it generates an alert every week. Your analysts learn to close those alerts on autopilot, which is exactly the habituation that lets a real anomaly slide through. For a retail customer whose expected activity is two card transactions a day, meaningful structuring can sit comfortably below the line forever.

The FFIEC manual calls out the second failure mode explicitly: a structuring filter triggered only by daily cash over $10,000 will miss the obvious cases, because common structuring techniques deliberately keep transactions slightly under the CTR threshold. The manual's answer is not a better universal number — it's tailoring:

"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

Note the two verbs: document and explain. A spreadsheet of threshold values with no rationale fails the second test even if the numbers happen to be defensible.

A five-step workflow for risk-based threshold calibration

Segment the book on risk-relevant attributes. Customer type, product usage, expected activity from CDD, and geography. Keep segments coarse enough to have statistically useful populations — a segment of 40 customers can't support distribution-based tuning.
Baseline actual activity per segment. Pull 6–12 months of transaction distributions per segment. Thresholds should be set relative to what's normal for the segment, not to what the vendor shipped.
Set thresholds per segment with written rationale. For each scenario–segment pair, record the threshold, the percentile or logic behind it, and the typology it targets. This document is what you hand the examiner.
Run above-the-line and below-the-line testing. Sample alerts just above the threshold to measure productivity, and — critically — sample activity just below it to confirm you're not systematically missing reportable behavior. Below-the-line results are the only real evidence a threshold isn't too loose.
Schedule periodic re-tuning and independent validation. Tie the tuning cadence to segment volatility, not the calendar alone. Fintech and crypto books shift faster than community bank books; an annual cycle that's fine for one is negligent for the other.

Where segmentation goes stale

Here's the practitioner observation that rarely makes it into tuning methodologies: threshold tuning gets a quarterly calendar slot, but segment membership almost never does. We consistently see programs re-derive thresholds from fresh data while leaving customers in the risk segment they were assigned at onboarding two or three years earlier. The customer who onboarded as a low-volume sole proprietor and now moves 30x that volume through the account is being monitored against the wrong distribution — and no amount of threshold tuning on the segment fixes it. If you have to choose where to spend a limited tuning budget, re-scoring segment membership against current activity beats shaving another few basis points off the false-positive rate. It's also a place where an AML agent that continuously re-evaluates customer activity does work a quarterly batch process structurally cannot.

Making room for smarter models

Risk-based transaction monitoring doesn't have to mean hand-tuned rules forever. The federal banking agencies and FinCEN said as much in their December 2018 joint statement:

"The Agencies recognize that private sector innovation, including new ways of using existing tools or adopting new technologies, can help banks identify and report money laundering, terrorist financing, and other illicit financial activity by enhancing the effectiveness and efficiency of banks' BSA/AML compliance programs."
— Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing, Dec. 3, 2018

The same statement removes the most common objection to piloting: "pilot programs in and of themselves should not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful." You can run a model-driven approach in parallel with your existing rules, compare outcomes, and keep the evidence — the supervisory path for that experiment is already paved.

The practical pattern we recommend: keep your documented rule thresholds as the system of record, run adaptive detection alongside them, and use the comparison to justify each threshold change. That gives you the risk-based calibration examiners want with an audit trail attached. If you're evaluating whether your program is ready for that step, the AI readiness playbook walks through the prerequisites, and the ROI calculator puts numbers on the alert-volume side of the case.

FAQ

How often should transaction monitoring thresholds be reviewed?

There is no mandated interval. The FFIEC manual requires periodic review and testing to ensure thresholds remain effective, with the cadence driven by your risk profile. In practice, high-growth or high-risk books warrant semiannual or quarterly tuning; stable retail books can defend an annual cycle — if segment membership is also refreshed.

What is below-the-line testing in transaction monitoring?

Sampling and investigating activity that falls just below alerting thresholds to test whether the threshold is suppressing reportable activity. If below-the-line sampling surfaces SAR-worthy cases, the threshold is too loose. It's the counterpart to above-the-line testing, which measures whether alerts above the threshold are productive.

Do regulators require specific transaction monitoring thresholds?

No. Neither the BSA nor the FFIEC manual prescribes threshold values. The requirement is that thresholds be reasonable, tailored to the institution's risk profile, documented with rationale, periodically tested, and independently validated.

Rose, Axle's transaction monitoring agent, investigates alerts with full customer context and keeps a written rationale for every disposition — the documentation trail this whole discipline depends on. See how Rose works →

A Risk-Based Approach to Transaction Monitoring Thresholds

More from the blog