Below-the-line testing samples the activity that falls just under a monitoring threshold to check whether genuinely suspicious behavior is slipping through undetected. It is the evidence that a threshold is drawn to catch risk, not set so high it leaves a blind spot criminals can hide inside.
What is below-the-line testing, in plain English?
Every monitoring scenario has a threshold: a dollar amount, a count, or a velocity that decides which activity becomes an alert and which stays quiet. Below-the-line testing looks at the quiet side. It pulls a sample of transactions and customers that landed just below the cutoff, then asks a simple question: is anything down here that should have alerted?
The point is to find false negatives, the risk your rules are missing. Above-the-line testing checks that the alerts you do generate are worth reviewing; below-the-line testing checks that the silence beneath the threshold is actually earned. If a reviewer keeps finding suspicious cases in the below-the-line sample, the threshold is set too high and needs to come down.
It sits squarely inside tuning and model validation. Regulators and internal validators treat it as the standard way to prove a threshold is defensible, because it is the only test that speaks to what a program cannot see.
How a below-the-line test runs
- Scope — Pick the scenario and band. Choose the rule to test and define the range just under its threshold, for example transfers between 8,000 and 10,000 dollars.
- Sample — Pull a statistically meaningful set. Draw enough records from that band that the result actually means something, not a handful of cherry-picked items.
- Review — Investigate each sampled item. Analysts work the sample as if it had alerted, checking whether the activity is truly benign or quietly suspicious.
- Decide — Adjust or affirm the threshold. If suspicious cases turn up, lower the threshold or reshape the rule; if the band is clean, document that the setting holds. Clean sampleThreshold affirmedDocument the result and keep the setting, with evidence in hand for the next exam.Hits foundThreshold too highTune it down, retest, and record the change through model governance.
Below-the-line vs above-the-line
What changes | Above-the-line testing | Below-the-line testing |
What it samples | Activity that did alert | Activity that did not alert |
Error it hunts | False positives and weak alerts | False negatives and blind spots |
Question answered | Are our alerts worth the effort? | Are we missing risk we should catch? |
Typical outcome | Raise a threshold or refine logic to cut noise | Lower a threshold or widen a rule to close a gap |
What it looks like in practice
In practice
A validation analyst is testing a structuring rule that alerts on cash deposits at or above 10,000 dollars. She pulls a sample of deposits between 8,500 and 9,999 dollars over the prior quarter and reviews them one by one.
Most are ordinary retail and payroll cash. But a cluster of accounts keep depositing 9,200 to 9,700 dollars every few days across different branches, always ending just short of the line. None had ever alerted. She flags the pattern, the team lowers the cash scenario threshold and adds a multi-branch velocity rule, and the retest surfaces several cases that become SAR filings.
Why it matters to operators
Without below-the-line testing you can only ever prove what you catch, never what you miss. A threshold set too high looks efficient on a dashboard, because alert volume is low, while it is quietly handing criminals a safe zone to operate in. That is exactly the gap sophisticated actors probe for when they size their transactions just under a round number.
It is also an examiner expectation. When a validator or regulator asks why a threshold is set where it is, a documented below-the-line result is the answer that holds up. Skipping it leaves you unable to defend the setting, and an undefended threshold is a finding waiting to happen.
Operator notes
- Sample size matters. A too-small sample proves nothing; draw enough volume from the band that the result is statistically meaningful.
- Watch the band just under round numbers. Clusters sitting a few hundred dollars below 10,000 are the classic sign of deliberate structuring.
- Document everything. The value of the test is the record; unwritten testing is the same as no testing when the exam comes.
- Retest after tuning. Lowering a threshold is not the end; confirm the new setting actually closes the gap without burying analysts.
- Pair it with above-the-line work. One without the other tells only half the story about whether a scenario is calibrated.
Quick questions
Why not just set every threshold low to be safe?
Because very low thresholds bury analysts in false positives and starve the real cases of attention. Below-the-line testing is how you find the point where a threshold is low enough to catch risk but not so low it drowns the team.
How often should you run it?
At least during periodic model validation and after any material change to a scenario, its data, or the customer base. Many programs run it annually and again whenever a new typology or product launches.
What counts as a below-the-line hit?
A sampled item that a reviewer decides should have been alerted and investigated, meaning the threshold let genuinely suspicious activity pass silently. A pattern of such hits is the trigger to retune.
Who should perform the testing?
Ideally someone independent of the people who built or tuned the rule, so the review is objective. In model validation this independence is often required, not just preferred.
Does a clean sample prove the threshold is perfect?
No, it provides reasonable evidence that the current setting is not leaving obvious risk uncovered. It is a point-in-time check, which is why it has to be repeated as behavior and typologies shift.
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.