Transaction monitoring is the AML control that reviews transactions, in real time or in batch, against rules and scenarios designed to detect money laundering, terrorism financing, and fraud. It turns raw payment activity into alerts an analyst can investigate. Done well, it produces a small number of accurate alerts. Done badly, it buries a compliance team in false positives.
Most transaction monitoring guides stop at the definition. This one covers what a regulator actually expects the system to do, how rules and scenarios are built, and why tuning is the part that separates a working programme from an expensive one.
What is transaction monitoring in AML?
Transaction monitoring is the automated review of transactions against detection logic, to flag activity that may indicate money laundering, terrorism financing, or fraud. It sits downstream of onboarding and name screening. Where screening checks who a customer is against sanctions and watchlists, transaction monitoring checks what that customer does once the account is live. A rule or scenario fires an alert, an analyst investigates, and a confirmed suspicion becomes a Suspicious Transaction Report.
The control is not optional. Under FATF Recommendation 10, financial institutions must conduct ongoing due diligence on the business relationship, including scrutiny of transactions throughout its course, to confirm they are consistent with the institution's knowledge of the customer. FATF Recommendation 20 sets the reporting obligation that transaction monitoring exists to feed. An AML transaction monitoring system is how an institution operationalises both.
How is transaction monitoring different from name screening?
They answer different questions, at different points, and confusing them leaves a real gap. Name screening is an identity check: it compares a customer, or a payment's parties, against sanctions lists, PEP lists, and adverse media, usually before a payment executes. Transaction monitoring is a behaviour check: it evaluates patterns of activity, usually after execution, against what is normal for that customer and that segment.
An institution can run a strong screening programme and still miss a mule account moving stolen funds, because the account holder is not on any list. The behaviour is the signal, not the name. This is why the two controls are complementary, not interchangeable, and why a monitoring programme that leans on screening to catch behavioural risk will not catch it. For the identity side of the control, see our work on why ongoing customer due diligence does not end at onboarding.
What are transaction monitoring rules and scenarios?
A rule is a single condition that fires an alert when met. A scenario is a set of rules and parameters modelling one money-laundering typology end to end. In practice the terms are used loosely, but the distinction matters when you tune: you calibrate a rule, you validate a scenario.
The typologies most scenarios are built to catch are well established. Structuring, or smurfing, breaks a large sum into many transactions below a reporting threshold. Layering moves funds through a chain of accounts to obscure their origin. A fan-in, fan-out pattern sees many inbound transfers from unrelated parties converge on one account, followed by rapid outbound movement, the classic money-mule signature. Rapid movement of funds, dormant accounts that suddenly activate, and transactions inconsistent with a customer's stated profile round out the core set.
Tuning: above- and below-the-line testing feeds calibration back into Rules & scenarios
What is real-time transaction monitoring, and when do you need it?
Real-time transaction monitoring evaluates a transaction before or at the moment it settles, so the institution can block or hold it, rather than only detecting it afterward. Batch monitoring runs on a schedule, typically overnight, and reviews activity after the fact. Neither is universally correct.
Real-time monitoring is necessary where a payment is irreversible once settled, which is most instant-payment rails, and where a control has to act before value leaves the institution, such as a sanctions block. Batch monitoring is well suited to pattern detection that needs a window of history to see, such as structuring across a week. Most mature programmes run both: real-time controls on the payment path, and aggregated, windowed scenarios in batch to catch what no single transaction reveals. The mistake is assuming real-time capability replaces the need for aggregation, or that batch is enough on real-time rails.
What does a regulator expect from a transaction monitoring system?
More than a rule set. BSP's own guidance, Memorandum M-2023-013, the Guidance Paper for an Effective AML/CTPF Transaction Monitoring System, sets out what supervised institutions are expected to demonstrate, and most vendor content ignores it entirely. It covers board and senior-management oversight, system design and pre-implementation testing, risk-based and holistic monitoring, alert and case management, red-flag and scenario coverage, suspicious-transaction reporting, and independent testing of the whole thing.
Two points in that list are where programmes most often fall short. Pre-implementation testing means an institution is expected to know how a rule behaves before it goes live, not discover its alert volume in production. Independent testing means the calibration has to be documented well enough that an examiner, or an internal auditor, can verify it works. Both are examiner-facing evidence questions, the same shift toward demonstrable effectiveness we cover in the complete BSP Circular 950 compliance guide. A monitoring system that cannot show its calibration rationale satisfies the older paperwork test and fails this one.
Why do transaction monitoring systems generate so many false positives?
Because most rules are written broadly, configured without the compliance team's input, and never tested against the institution's own data before deployment. A threshold set for a generic typology, applied to a customer base it was never calibrated for, fires on ordinary activity. Each false positive is analyst time not spent on a real risk, and a queue of thousands is not a detection success. It is a tuning failure wearing the costume of diligence.
The volume itself is a symptom. The disease is imprecision, and it has a specific cause: the people closest to the risk usually cannot change the rules. When a threshold has to move through an engineering ticket and a release cycle, it does not move, and the queue stays dirty for a quarter.
How do you tune and calibrate transaction monitoring thresholds?
Tuning is the disciplined adjustment of thresholds and parameters so a rule catches genuine risk without flooding the queue. It rests on two tests. Above-the-line testing samples the alerts a rule generated and measures how many were productive, to see whether the threshold is too loose. Below-the-line testing samples the activity that fell just under the threshold and did not alert, to see whether the threshold is too tight and missing real risk. A defensible programme runs both, on a schedule, and documents the result.
The single highest-leverage capability here is aggregation. Single-transaction rules catch single transactions, but structuring and layering happen across many transactions over time. A rule built on a variable, the sum or count of a transaction attribute over a defined window, catches the pattern a fixed per-transaction threshold cannot. The other is pre-deployment testing: running a candidate rule against real historical activity before it touches the live queue, so its volume is known in advance. This is exactly the practice M-2023-013 calls for, and the discipline that keeps a queue clean instead of merely large. A continuously updated view of the customer, rather than a point-in-time snapshot, is what makes that windowed logic possible.
FyscalTech's Transaction Monitoring module is built around the tuning problem specifically. A compliance team builds and owns its own rules without an engineering ticket. It constructs aggregation variables over any window it defines, and tests a new rule against historical transaction data before activation, so alert volume is known ahead of go-live.
Where does transaction monitoring fit in your AML program?
It is the behavioural core of the programme, sitting between screening at the front and reporting at the back. A confirmed monitoring alert is the suspicion that triggers a Suspicious Transaction Report, filed the next working day under AMLC's GoTRACS framework. Institutions confuse that deadline with the CTR window more often than any other. The investigation between alert and filing is a case-management problem, and the filing itself a regulatory-reporting one. That closes the two gaps most responsible for a dirty queue: rules the compliance team cannot change, and rules that go live untested.