Transaction Monitoring
Transaction monitoring is the automated surveillance of customers' payments and account activity for patterns that may indicate money laundering, terrorist financing or fraud — structuring below reporting thresholds, rapid movement of funds in and out, activity inconsistent with the customer's profile, links to high-risk jurisdictions — producing alerts that analysts investigate and, where suspicion remains, report to the financial intelligence unit. It is the largest operational cost in a fintech's compliance function and the control most often named in enforcement.
- Also known as
- TM, AML transaction monitoring, Suspicious activity monitoring
- Used at
- every bank, payment and e-money institution, lender, broker and crypto firm; required by the AML rules as ongoing monitoring of the business relationship
- Binding
- yes — the obligation to monitor and to report suspicious activity is in the AML directives, the UK regulations and the US Bank Secrecy Act; the rules do not prescribe the system, only that it be effective and risk-based
- Typical architecture
- rules (thresholds, velocities, patterns) per customer segment; increasingly machine-learning models that score alerts or detect anomalies; a case-management system for investigation; documentation of every rule's rationale and tuning; a suspicious activity report workflow
- Typical numbers
- alert rates of 1–3% of customers a month; 90–98% false positives; 20–40 minutes per alert; SARs on 1–5% of alerts; backlogs are the finding regulators cite most
- Parties
- the compliance operations team, the MLRO, the technology vendors, the financial intelligence unit, and the regulator, which inspects the rules, the tuning evidence and the backlog
How transaction monitoring works in practice
Every transaction is evaluated overnight, or in real time for higher-risk products, against a rule set: a customer whose monthly inflows exceed three times their declared expected activity; cash deposits just below the reporting threshold; funds received and forwarded within a day; transfers to or from high-risk countries above a limit; a dormant account that suddenly moves €50,000. A rule that fires creates an alert with the transactions and the customer's profile attached. An analyst investigates — reads the history, checks the source and destination, sometimes asks the customer — and either closes the alert with a documented reason or escalates it. Escalations the MLRO agrees with become suspicious activity reports; the firm keeps records of all of it for the regulator.
The quality of the system is in the tuning. Rules copied from a vendor's defaults fire on every customer; rules segmented by customer type and calibrated on the firm's own data fire on the unusual. Each threshold needs a documented reason and a test showing that raising it does not lose true cases; regulators ask for both. Machine-learning models help by ranking alerts so the likely-true ones are worked first, and by finding patterns rules cannot describe — but a model that cannot explain its alert is a model the regulator distrusts.
The failure mode is the backlog: alerts generated faster than investigated, ageing for months, with true cases inside them undetected. Enforcement actions against fast-growing fintechs describe this almost every time.
Example
An e-money institution with 500,000 customers runs 42 rules. Before tuning: 18,000 alerts a month, 3% true, a backlog of 11,000 aged over 60 days — the finding in its last inspection. The remediation: rules segmented into four customer types with thresholds calibrated on twelve months of data; a scoring model that ranks alerts; twelve temporary analysts to clear the backlog. After nine months: 7,500 alerts a month, 8% true, no alert older than 30 days, SARs up from 45 to 60 a month. The regulator closes the finding; the firm's next funding round's diligence reads the tuning documentation as evidence that the compliance function works. Total cost: €1.9m, less than the fine a peer paid for the same backlog left uncleared.
Common mistakes
- Vendor default rules never calibrated to the firm's own customers. - Thresholds raised to cut alerts without a back-test against known cases. - A backlog managed by closing old alerts in bulk, which the regulator will find and describe. - Models that score alerts nobody can explain to an inspector. - Monitoring designed for a bank's products and applied to a prepaid card programme or a crypto exchange without new typologies.