Transaction monitoring threshold tuning: set, tested, written down

Transaction monitoring threshold tuning is the work of setting, testing and adjusting the values at which each monitoring scenario raises an alert: the dollar amount, the count of transactions, the number of days, the share of funds moved out. Every threshold is a trade. Lower it and the scenario catches more, at the cost of more alerts for analysts to clear; raise it and the queue shrinks, at the risk of missing activity a bank must report. Tuning is how a bank shows it made that trade on evidence. Botminds' AML Alert Triage does not tune: it works the alerts each threshold produces, and its tuning analyst agent turns patterns in those decisions into proposals that the tuning team and the Head of the financial intelligence unit decide.

What is threshold tuning in AML?

Threshold tuning is the adjustment of the parameters in a monitoring scenario so that it alerts on the activity the bank needs to see, at a volume its staff can review properly. A scenario such as "cash deposits aggregating more than a set amount within 15 days" has at least two thresholds, the amount and the window; a rapid-movement scenario adds the share of funds that leaves and how fast. Each is a number someone chose.

The FFIEC manual is specific about what that choice owes the bank's examiner: "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. In addition, the monitoring system's programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity" (FFIEC BSA/AML Examination Manual). Document, explain, test, validate: that sentence is the job description of a tuning team.

The manual also gives a worked example of a threshold that looks right and is not. "A bank may discover that its filter for cash structuring is triggered only by a daily cash transaction in excess of $10,000. The bank may need to refine this filter in order to avoid missing potentially suspicious activity because common cash structuring techniques often involve transactions that are slightly under the CTR threshold." Its own example report filters cash "between $7,000 and $10,000", and a second filter for smaller amounts of around $3,000 that add up to a large total over a couple of weeks; its example is $30,000 across 15 days. These are illustrations, not thresholds the law sets.

What is above the line and below the line testing?

Above-the-line and below-the-line testing are the two halves of threshold testing. Above-the-line testing raises a threshold on historical data to see what the bank would stop seeing; below-the-line testing lowers it, or samples activity just under it, to see what the bank is not seeing now. The Wolfsberg Group's definitions are the cleanest: above-the-line testing "helps identify the threshold at which false positives might increase, potentially overwhelming investigators with non-suspicious alerts", while below-the-line testing "helps identify the point at which the system may generate false negatives, potentially missing potentially suspicious activity" (Wolfsberg Group, 2024, glossary).

In practice a below-the-line test takes a random sample of transactions or customers that fell just short of alerting, has experienced investigators work them as if they had alerted, and counts how many would have led to a SAR. That yield, compared with the yield just above the line and with a false-negative tolerance the bank sets in advance, is the evidence for keeping or moving the threshold. Wolfsberg warns that the usual version is too timid: "for false negative testing, only minor adjustments to current model parameters are made in the controls by incrementally dropping the existing model's detection thresholds (e.g. 10% below the current value). Minor modifications to existing parameters are unlikely to produce meaningful results."

What Bank of America's below-the-line tests found

Bank of America ran below-the-line tests for years, and FinCEN's October 2026 order shows how a bank can test a threshold and still keep the wrong one. Its system investigated a customer's group of alerts only once the group's score reached 20 points, a threshold "initially set by stakeholder judgment" that stayed in place until December 2023. A 2022 validation found that "the SAR Yield difference is not statistically significant between uncased event groups with risk score 15 – 19 and cases" (FinCEN, Bank of America consent order, 2026).

The bank also tested an alternative it called an "unconstrained threshold" and found it would "uncover more SARs (85.4% vs. 20.2% on below-the-line samples)". It rejected the change because of the "practical concern of pushing too many below-the-line event groups to cases". FinCEN's criticism was precise: the testing "generally focused on whether there was a statistically significant difference" between yields above and below the line "without taking into account the implications of the suspicious activity being missed", and the bank set no false-negative tolerance to measure against until late in the period.

When the threshold finally moved, it moved a long way: from 20 points to 10 or 12, with the window for grouping alerts cut from 13 months to four, and a 5% false-negative tolerance for management oversight, with 7.5% as the level for escalation to the board. A one-time lookback under the new parameters found nearly 8,900 SARs the bank had failed to file. FinCEN fined it $1.2 billion. The alert to SAR ratio explains why the bank-wide ratio never showed any of this.

Tuning trades workload for coverage: TD Bank's 250%

Tuning decisions are staffing decisions in disguise, and TD Bank's record shows what happens when the staffing side wins every time. After internal audit found in 2018 that not all jurisdictions the bank rated high-risk were covered by its scenarios, AML management concluded that only proposed changes that "would have no impact or lower the volume of false positives have been approved to proceed". As FinCEN put it, "the AIU was not allowed to add new jurisdictions, because doing so would increase the volume of alerts" (FinCEN, TD Bank consent order, 2024).

A later review of the ATM scenarios concluded the high-risk country list should be updated, but that "adding all high-risk jurisdictions would increase the monthly alert volume by more than 250%". Staff recommended updating the list while "simultaneously modifying another parameter to reduce relevant resulting alerts". That is tuning in its most dangerous form: a coverage change paired with a volume change, chosen to keep the queue flat.

How do you justify an AML threshold? A methodology examiners can follow

Justify it with evidence a reviewer can re-run: what the threshold is meant to catch, the data it was set on, what testing on both sides of it found, the tolerance it was measured against, who approved it, and when it will be tested again. A threshold "set by stakeholder judgment" is not wrong in itself; one never tested against a tolerance is.

The FFIEC's access rule belongs in the methodology, not the IT policy: "Controls should ensure limited access to the monitoring systems, and changes should generally require the approval of the BSA compliance officer or senior management." So does Wolfsberg's advice that banks "conduct regular testing against de-scoped" monitoring routines "to confirm the absence of material risk": a scenario switched off is a threshold set to infinity, and it needs the same below-the-line evidence.

What is scenario tuning, and how is it different from threshold tuning?

Scenario tuning changes what a rule looks for; threshold tuning changes how much of it triggers an alert. Adding a transaction type to a rapid-movement scenario, splitting a scenario by customer segment, or adding a condition (cash in, wire out to a new payee) is scenario tuning. Moving the amount from $10,000 to $8,000 is threshold tuning.

The distinction matters because each fails differently. A threshold set too high misses activity just over the customer's usual pattern, which below-the-line testing can find. A scenario that never looks at a transaction type misses everything in it, and no threshold test can find that, because there is no line to test below. Bank of America's own 2019 analysis found that one ATM cash scenario required five conditions to alert when "SARs could be filed even when only one condition…was satisfied". Transaction monitoring scenarios, with examples covers how to prove a scenario set reaches every product.

One worry about thresholds turns out to be less pressing than many assume. A 2025 peer-reviewed study tested whether launderers know alert thresholds and break transactions just under them. On real data from a large Danish bank, the authors "find no evidence of smurfing and, thus, no evidence of leaked thresholds", while their method could detect it when as little as 0.1% to 0.5% of transactions were structured (Jensen, Ferwerda and Wewer, Journal of Quantitative Criminology, 2025). Thresholds still need protecting, but the stronger reason to test below them is ordinary drift, not leaks.

How often should transaction monitoring be tuned?

No regulation sets a frequency. The FFIEC asks for thresholds to be reviewed and tested "periodically", and for independent testing it says plainly that no regulation fixes a frequency, offering every 12 to 18 months only as an example and asking for testing sooner when the bank's risk profile, systems, compliance staff or processes change significantly (FFIEC manual, Independent Testing).

A practical cadence follows the triggers rather than the calendar: a new product or channel, a new high-risk geography, a FinCEN advisory with new red flags, a sustained change in a scenario's escalation or SAR yield, or a quality-control finding that analysts are closing the same pattern repeatedly. TD Bank's record is the warning against the opposite approach: scenarios "paused" and left dormant for years, and no new scenarios added for four years while a system replacement was pending.

Do examiners review transaction monitoring thresholds?

Yes. Thresholds are part of the internal controls examiners assess, and the FFIEC expects management to explain them and the independent tester to validate the system's methodology. The OCC's community bank procedures, in force for exams from February 2026, ask examiners to consider whether the independent test covered how alerts are produced as well as how they are worked (OCC Bulletin 2025-37).

The model risk side changed in April 2026. The revised guidance treats deterministic rule-based software as outside the definition of a model and is aimed mainly at banks with more than $30 billion in assets; the 2021 interagency statement that discussed BSA/AML models and threshold reviews was rescinded (OCC Bulletin 2026-13). A statistical scoring layer still falls within the guidance's definition of a model. For a rule-based scenario, the FFIEC's document-explain-test-validate expectation is what an examiner will apply.

Thresholds near the cash reporting line need care in both directions since October 2025. The interagency SAR FAQs make clear that a transaction at or close to the $10,000 CTR threshold does not, on that fact alone, require a SAR; one is required only if the bank knows, suspects or has reason to suspect that the transactions are designed to evade reporting (SAR FAQs, October 2025, Q1; the guide to the October 2025 FAQs covers all four answers). A near-threshold scenario is still a sound way to find structuring; its alerts just need more than the amount to justify escalation.

The Bank failed to establish an objective benchmark (e.g., a "false negative" tolerance for suspicious activity not being timely identified) to help inform this testing.

FinCEN, Bank of America consent order, on the bank's threshold testing

How the alert queue feeds tuning in Botminds' AML Alert Triage

Tuning teams depend on the alert desk for their best evidence, and that evidence is usually locked in free-text closure notes. In Botminds' AML Alert Triage every closure carries a reason code and cited evidence, so patterns are countable. The tuning analyst agent finds alerts closed again and again for the same reason, and writes a proposal with its evidence and expected effect for the Head of FIU. It recommends no change where SARs were filed, and it never changes a scenario.

Take the sample bank, Corvane National Bank, a fictional regional bank with about 42,000 alerts a month in Botminds' sample data. Its queue screen shows, for each scenario, open alerts by risk band, the share the agents propose to close, the share where the challenger agent disagrees, and the escalation rate. A scenario whose closures are almost all one reason code and whose challenger rarely objects is a candidate for above-the-line testing. A scenario where the challenger often disagrees is telling the tuning team that something near its line is not as routine as the threshold assumes.

Per-scenario signals a tuning team can test, from every decision

Settings inside the solution follow the same discipline the FFIEC asks of thresholds. The confidence an agent needs before proposing a closure (85% in the sample settings), the batch rules and the QC sampling rates are versioned settings that an administrator proposes and the BSA Officer approves, and the person who proposes a change can never approve it. Every version is on the audit trail. Whether thresholds and scores should ever decide what a person sees at all is the question in AI in AML transaction monitoring.

Settings changes and who approved them travel with the audit trail

Questions people ask

Who should approve a transaction monitoring threshold change?

The FFIEC says changes "should generally require the approval of the BSA compliance officer or senior management", with access to the monitoring system limited. The analyst who ran the test should not be the one who approves the result.

Can criminals learn a bank's alert thresholds?

They may try, which is why thresholds are kept confidential. A 2025 peer-reviewed study of one large Danish bank's data found no evidence that launderers were splitting transactions just under its thresholds, using a method able to detect it in as little as 0.1% to 0.5% of transactions.

What is a tuning lookback?

A lookback re-runs changed thresholds or scenarios over past activity to find suspicious activity the old settings missed, and files SARs on what it finds. Bank of America's 2024 lookback under its lowered threshold found nearly 8,900 unfiled SARs on almost $4 billion of activity.

Should thresholds differ by customer segment?

Usually, yes. The FFIEC ties filtering criteria to the activity that is normal for each type of account, and a single threshold across retail customers and cash-intensive businesses will over-alert on one and under-alert on the other.

Does lowering a threshold always improve coverage?

It widens what alerts, but coverage only improves if the extra alerts are worked properly. USAA's new system raised so many alerts that about 90,000 went unreviewed, so a threshold change should be priced in staff before it goes live.