Auditing Transaction-Monitoring Systems: Coverage and Tuning

The transaction-monitoring system, or TM, is the engine that scans activity for potentially suspicious patterns and generates alerts for investigation. Auditing it is one of the most technical and most tested fieldwork areas. A TM system works through scenarios, the patterns it looks for, like rapid movement of funds or structuring, with thresholds that decide when behavior is alert-worthy.

Your audit tackles three layers: coverage, does the system watch for the right risks across all products and channels; calibration, are the scenarios and thresholds tuned correctly; and handling, are the alerts it produces investigated and dispositioned well. A weakness in any layer means real suspicious activity can slip through unseen.

Begin with coverage, because the worst failure is a blind spot the system was never built to see. Map the active scenarios against the institution's risk assessment and ask whether every material risk has monitoring behind it. Is each product, channel, and known typology covered, wires, cash, ACH, trade finance, crypto on-ramps?

A frequent finding is a new product that launched but was never connected to monitoring, so months of activity flowed by unwatched. Coverage gaps are blind spots by design: no amount of tuning helps if the system simply isn't looking at a category of activity. Reconciling the scenario inventory to the product and risk inventory is how you find these holes.

Now tuning, and this is where the exam gets specific. A threshold draws a line: activity above it generates an alert, activity below it doesn't. Audit tests both sides.

Above-the-line testing samples the alerts the system did generate and asks whether they were productive and well-handled, or whether the system is drowning analysts in noise. Below-the-line testing is the crucial, often-skipped half: you deliberately sample activity that fell just below the threshold, the transactions that did not alert, and investigate whether any were actually suspicious. If below-the-line testing turns up genuine suspicious activity the system ignored, the threshold is set too high and is missing real risk.

Tuning without below-the-line testing is only half an audit.

Finally, audit how alerts are handled once generated. Look beyond the headline backlog number to the quality of the investigation: was each alert reviewed thoroughly, with the customer context considered, or rubber-stamped closed? A dangerous pattern is mass-closing, analysts clearing alerts in seconds to hit productivity targets, which you can spot by re-performing a sample and checking time-stamps and narrative depth.

Confirm that alerts which should escalate actually flow into the suspicious-activity-report decisioning process rather than dying in the queue. Productivity metrics that look great alongside thin, identical disposition narratives are a red flag the exam loves: efficiency bought by skipping the actual analysis.

Two adjacent areas can quietly break even a well-designed monitoring system, so audit them. The first is change management. Every change to a scenario or a threshold should be tested and formally approved before it goes live, because a careless tuning change can silently disable detection, raising a threshold so high that an entire class of suspicious activity stops alerting.

Ask to see the change records: was each change risk-assessed, tested, and approved, or did someone adjust a parameter on a hunch? The second is the data feeding the system, which we'll cover in depth later but flag here because it's foundational. A monitoring engine can only analyze what it receives, so if a transaction feed drops records or arrives malformed, the system shows green while sitting blind.

Reconcile the source transaction data against what actually reached the monitoring engine and look for gaps. A perfectly tuned scenario starved of complete data is just as useless as no scenario at all, and that failure mode is invisible unless you test for it.

Recapping: auditing transaction monitoring means testing coverage, tuning, and alert handling. Reconcile scenarios to the risk and product inventory to find blind spots, run both above-the-line and the crucial below-the-line testing to check whether thresholds miss real risk, and judge alert handling on disposition quality, not just backlog size. And don't overlook change management and the data feeds, because an untested tuning change or a dropped feed can silently disable detection while the system still shows green.

The TM system is also a model, which brings us to our next, closely related topic: model risk management and independent validation under SR eleven dash seven. Test yourself on transaction-monitoring auditing first.