Transaction Monitoring Tuning

Transaction monitoring tuning is the structured process of testing and adjusting the scenarios, parameters and thresholds in an anti-money laundering monitoring system so that they detect suspicious activity effectively while keeping false positive alerts to a manageable level. It is carried out when a scenario is first deployed, at regular intervals afterwards, and whenever a firm's products, customers or risks change.

Tuning applies to each transaction monitoring scenario rather than to the system as a whole. It is part of the wider governance of transaction monitoring and, in the US, is often treated as model risk management under supervisory guidance SR 11-7. The term is industry practice; regulators describe the same work as ongoing testing and calibration of detection scenarios.

A guitar goes out of tune as the strings stretch and the room warms up. A guitarist checks each string against a reference note and turns the peg a little until it sounds right. Turn too far one way and the string is flat; too far the other and it may snap.

Monitoring rules drift in the same way as a bank's customers and payment habits change. Tuning means checking each rule against real results and adjusting it. If a rule is set too loose, it fires on almost everything and analysts waste their time. If it is set too tight, it stays silent while real money laundering slips past. The goal is a setting that catches the bad cases without burying staff in noise.

A typical tuning exercise follows a fixed sequence:

1. Data checks. Confirm that the transactions and customer fields the scenario uses are complete and correctly mapped.
2. Segmentation. Group customers using customer risk segmentation, so that thresholds can differ by segment.
3. Statistical analysis. Study the distribution of the relevant value (for example monthly cash deposits) in each segment and pick candidate thresholds, often at high percentiles.
4. Above-the-line testing. Review the outcomes of alerts that the current threshold already produces, using their alert dispositions, to see which settings generate productive alerts.
5. Below-the-line testing. Run the scenario at lower thresholds on historical data, sample the extra alerts that would have appeared and have analysts review them. If suspicious activity is found below the current line, the threshold is too high.
6. Decision and approval. Document the proposed change, its expected effect on alert volume and detection, and get sign-off from the model owner and compliance governance.
7. Post-implementation review. Check after a few months that volumes and outcomes match expectations.

The most common measure of a scenario's productivity is the share of its alerts that turn into something useful:

For example, a scenario that produced 4,000 alerts in a quarter, of which 120 were escalated to cases, has a productivity of $120 \div 4{,}000 \times 100 = 3\%$. A rate this low is common in AML monitoring, but a scenario far below its peers is a candidate for recalibration.

Productivity alone is not enough, because cutting alerts always improves it. Tuning also needs an estimate of missed activity, usually expressed as the false negative rate, drawn from below-the-line samples, later suspicious activity reports that the scenario did not trigger, and law enforcement requests about customers who never alerted. A scenario can only be judged fairly when both numbers are reported side by side.

Supervisors expect tuning to be risk-based and documented. New York's Part 504 rule requires regulated institutions to test and update monitoring scenarios and thresholds, and the senior officer certification each April covers this work. Model risk guidance asks for independent validation of significant changes, and an independent AML review or internal AML audit often checks tuning files. The AML compliance officer is usually the final approver. US federal agencies have also encouraged responsible innovation in BSA/AML, including statistical and machine-learning approaches, provided they are tested and explainable.

• Tuning for volume. Raising thresholds mainly to shrink an alert backlog is a common criticism in exam findings.
• Small samples. Below-the-line samples that are too small cannot support confident conclusions.
• Stale data. Using history from before a major product launch or customer shift gives misleading thresholds.
• Ignoring typologies. A threshold that is statistically tidy may still miss a pattern such as structuring, which is designed to stay below obvious limits.
• Too rare a review. Firms that tune only every few years can leave thresholds badly out of date after rapid growth or a shift in the customer base, so many review high-risk scenarios at least once a year.
• Poor records. Changes made without written rationale are hard to defend in a later enforcement action.

• New York State Department of Financial Services
• Board of Governors of the Federal Reserve System