---
title: "Transaction Monitoring"
url: "https://mahouse.world/glossary/transaction-monitoring"
type: "glossary term"
topic: "Compliance"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# 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

## Key facts

- **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.

## Related terms

- [False Positives](https://mahouse.world/glossary/false-positives.md)
- [Risk-Based Monitoring](https://mahouse.world/glossary/risk-based-monitoring.md)
- [AML](https://mahouse.world/glossary/aml.md)
- [Sanctions Screening](https://mahouse.world/glossary/sanctions-screening.md)
- [Velocity Check](https://mahouse.world/glossary/velocity-check.md)
- [Audit Trail](https://mahouse.world/glossary/audit-trail.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov