Transaction Monitoring: Tuning Thresholds to Cut Alert Noise

Transaction monitoring is where many AML programs quietly fail. Not because rules are missing, but because they fire too often. Industry surveys routinely report false-positive rates above 90%, meaning fewer than one in ten alerts leads to a Suspicious Activity Report. Analysts burn hours clearing noise, genuine risk hides in the backlog, and regulators ask why alerts sat unreviewed for weeks. Tuning is the discipline of raising signal without dropping the transactions that actually matter.

Why Default Thresholds Fail

Out-of-the-box rules ship with generic parameters: flag any cash deposit over 10,000, any wire above a fixed amount, any velocity spike over a round number. These defaults ignore how your specific customers behave. A rule that makes sense for a retail savings account generates constant noise on a merchant settlement account that moves the same volume daily by design.

The result is alert inflation. When every third transaction trips a rule, analysts develop clearance fatigue and start rubber-stamping dispositions. That is the exact opposite of what the rule was meant to achieve. A monitoring system that produces 40,000 alerts a month but investigates each for 90 seconds is weaker than one producing 4,000 alerts reviewed properly.

Segment Before You Tune

Effective tuning starts with customer segmentation, not threshold math. Group customers by expected behavior so that a rule compares each account to a realistic baseline:

• Product type — payroll accounts, merchant accounts, and personal wallets have different normal ranges.
• Risk rating — align monitoring intensity with the customer risk score you already assign at onboarding.
• Expected activity — capture anticipated volume and geography during KYC, then flag deviations from the customer's own stated profile rather than a population-wide number.
• Tenure — a new account moving large sums warrants a lower threshold than a five-year account with a stable pattern.

Chat-based onboarding helps here: asking a customer their expected monthly volume and typical counterparties during verification gives monitoring a per-customer baseline to measure against, instead of a one-size-fits-all limit.

The Tuning Cycle

Threshold tuning is not a one-time project. Treat it as a documented, repeatable cycle:

• Above-the-line testing — sample alerts that fired and measure how many were productive. If a rule's productivity is below a few percent, it is a tuning candidate.
• Below-the-line testing — sample transactions that did not alert to confirm you are not missing genuine risk. This step is what separates defensible tuning from simply muting inconvenient rules.
• Parameter changes — adjust amounts, lookback windows, and velocity counts one variable at a time so you can attribute the effect.
• Impact analysis — model the change against historical data before deploying, projecting new alert volume and any coverage gaps.

Every change needs a rationale, an approver, and a date. When an examiner asks why you moved a threshold from 10,000 to 15,000,