Table of contents
Transaction monitoring is the automated review of customer transactions against rules and risk models to identify activity that may indicate money laundering, terrorist financing or fraud, generating alerts for investigation. Regulated firms must run it for the life of each customer relationship, and the alerts it raises are the main source of suspicious activity reports.
Where identity verification answers who the customer is at onboarding, transaction monitoring answers what they are doing afterwards. It is the control aimed at the layering stage of money laundering and at structuring and mule activity, and it is where most of a compliance team’s alert volume comes from. The commercial detail, engine design, fields and pricing, is on the transaction monitoring software page; this entry covers the concept.
How transaction monitoring works
- Data in: every payment, deposit, withdrawal or transfer is captured with its amount, currency, direction, counterparty, country and timing, and joined to the customer’s profile and risk rating.
- Rules and models: the transaction is evaluated against rules (thresholds, velocity, pattern and typology rules) and, at some firms, behavioural models that compare it with the customer’s history and peer group.
- Alert: a transaction or pattern that trips a rule raises an alert, scored and routed by severity.
- Investigation: an analyst, or an agent working within limits, assembles the customer history and related activity and decides whether the alert is a false positive, needs enhanced due diligence, or is suspicious.
- Report and record: suspicious activity is reported to the financial intelligence unit, and every alert and decision is recorded for examiners.
Real-time versus batch monitoring
Batch monitoring evaluates the day’s transactions overnight and raises alerts the next morning, after the funds have moved. Real-time monitoring evaluates each payment synchronously and can hold or block it before settlement. Sanctions screening on payments has to be real-time; for money-laundering typologies, real-time monitoring is what allows a firm to stop a mule pay-out rather than report it afterwards.
Rules engines versus machine learning
A rules engine is deterministic: the same transaction against the same rules always produces the same result, and the decision can be explained by listing the rules that fired. Machine-learning models can find patterns rules miss but produce a score rather than a reason, which supervisors increasingly challenge under model-governance expectations. Many firms run rules as the control and use models to tune thresholds or prioritise alerts.
The false positive problem
Transaction monitoring generates false positives, and rates above 90 percent of alerts are ordinary. Tightening thresholds risks missing genuine activity and being unable to defend the change; hiring analysts does not scale. What works is segmentation so rules reflect actual customer behaviour, backtesting a rule change against history before analysts feel it, grouping related alerts into one case, and automating the evidence-gathering so the analyst decides rather than assembles.
Transaction monitoring at Zyphe
Zyphe runs a deterministic rules engine: every payment is evaluated synchronously and returns Allow, Review or Block with the fired rules attached, before funds move. Rules read transaction, list, identity and velocity fields, are versioned, and can be backtested for free. Alerts from screening are worked by agents behind a deterministic guard; agent triage of transaction-monitoring alerts is planned and not yet shipped, and the transaction monitoring alert triage desk describes how the service works today.
Written by Michelangelo Frigo (Co-Founder at Zyphe) Reviewed September 18, 2026 Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.