Transaction monitoring vs AML screening: what is the difference?
AML screening and transaction monitoring are two different anti-money-laundering controls that are often confused. Screening checks who a party is, comparing a customer or a payment counterparty against sanctions, PEP and adverse-media data. Transaction monitoring checks what a party does, watching the pattern of activity across an account over time for behaviour that looks like laundering. They answer different questions, fail in different ways, and a regulated firm generally needs both. This guide sets out what each control does, where they diverge, why one cannot stand in for the other, and how they feed a single case record.
AML screening establishes whether a party is a prohibited or high-risk person, while transaction monitoring establishes whether an account's behaviour looks like money laundering. Screening is an identity control: it compares a customer or counterparty against watchlists and risk data. Transaction monitoring is a behavioural control: it tests the flow of money against rules and models to surface patterns such as structuring or layering. Both are standard parts of an anti-money-laundering program, and because they cover different risks, a firm that runs only one is exposed on the side it left uncovered.
What is AML screening?
AML screening is the control that checks who a party is. It compares a customer, or a counterparty on a payment, against sanctions lists, politically exposed person data and adverse-media reporting, then resolves whether that specific person or company is prohibited, restricted or higher risk. The output is about identity: this party is a sanctions match, this one is a PEP, this one is the subject of credible negative reporting. Screening runs at onboarding to decide whether to take a customer on, and it re-runs over time because the underlying lists change, so a party who was clear can become a match later. What screening does not do is judge behaviour. It will tell you that a counterparty is designated; it will not tell you that an otherwise clean customer is moving money in a suspicious way. That second question belongs to a different control.
What is transaction monitoring?
Transaction monitoring is the control that checks what a party does. Rather than comparing a name against a list, it watches the pattern of activity across an account (amounts, frequency, counterparties, timing and geography) and tests that behaviour against rules and models. The aim is to surface conduct consistent with laundering typologies: structuring deposits below reporting thresholds, rapid movement of funds through layered accounts, or flows that make no sense for the customer's stated profile. Monitoring is inherently about behaviour over time, so it works on transaction history and trends rather than on a single point-in-time check. Its blind spot is the mirror image of screening's: a monitoring model tuned to behavioural anomalies will happily pass a payment to a sanctioned counterparty as long as the pattern looks ordinary, because nothing about the amount or timing stands out. Identity is not what it is looking at.
How do screening and monitoring differ?
The two controls differ in what they examine, when they run, and what a hit means. The table below sets the distinction out directly.
| Dimension | AML screening | Transaction monitoring |
|---|---|---|
| Core question | Who is this party? | What is this account doing? |
| Compared against | Sanctions, PEP and adverse-media data | Rules and models for laundering typologies |
| Unit of analysis | A customer or a payment counterparty | A pattern of activity over time |
| Typical trigger | Onboarding, payment, and list changes | Ongoing transaction flow |
| What a hit means | The party is prohibited, exposed or adverse | The behaviour looks like laundering |
| Blind spot | Suspicious behaviour by a clean party | A designated party transacting normally |
Read across the rows and the point is clear: neither column contains the other. A firm that only screens sees prohibited parties but misses laundering by clean ones; a firm that only monitors sees odd behaviour but misses designated counterparties whose activity looks routine.
Do you need both?
In almost every regulated context, yes. Screening and transaction monitoring defend against different risks, and supervisors expect a program to address both. Screening answers the identity question and is the only control that reliably catches a sanctions target, because a sanctions breach does not depend on the transaction looking unusual. Monitoring answers the behavioural question and is the only control that catches structuring or layering by a customer who screens perfectly clean. Treating them as complementary rather than competing is the practical model: an identity hit and a behavioural alert are worked with the same rigour, through the same investigation process. A program that leans on one to cover the other has a predictable gap, and it tends to be exactly the gap an examiner probes first. The related question of how often to re-screen sits in our ongoing monitoring frequency guide.
How do they feed one case record?
Screening and monitoring produce different signals, but an investigator often needs both to make sense of a single customer. When a sanctions match and an unusual-pattern alert land in one case rather than two separate queues, the reviewer sees that the counterparty is designated and that the account behaviour is abnormal at the same time, and can weigh them together instead of in isolation. Keeping the two on one record also builds a single audit trail: what was screened, what the monitoring rules flagged, what the investigator concluded, and why. When these live in disconnected tools, the same customer gets reviewed twice, with neither reviewer seeing the whole picture, and the audit story fragments across systems. The workable arrangement is for a screening engine to write its hits into the same case management the monitoring system feeds, so one investigation covers both. That mechanics of triage is covered in alert triage and case investigation.
How does BriteBase fit alongside transaction monitoring?
BriteBase is a screening and risk-intelligence platform, not a transaction-monitoring engine, and it is worth being precise about that. Our engine covers sanctions, PEP, adverse-media and trade screening, and it re-screens the enrolled customer book continuously so a party who becomes a new match is caught rather than missed. What it does not do is run behavioural models over transaction flows; that is the job of a dedicated monitoring system. The two fit together. Our screening runs alongside a firm's transaction-monitoring stack, and screening hits can be raised into the same case management the monitoring alerts feed, so an investigator works one record. Positioned this way, screening handles the identity dimension of AML risk with strong entity resolution and the 50% Rule, while the monitoring system handles the behavioural dimension. The screening side is available through the screening platform and the underlying sanctions, PEP and adverse-media data layer.
FAQ
What is the difference between transaction monitoring and AML screening?
Screening checks who a party is; transaction monitoring watches what a party does. Screening compares a customer or a payment counterparty against sanctions, PEP and adverse-media data to establish whether that specific person or company is prohibited, politically exposed or the subject of negative reporting. Transaction monitoring looks at the pattern of activity across an account over time, testing it against rules and models to flag behaviour that looks like structuring, layering or other laundering typologies, regardless of who the counterparty is. The two answer different questions and fail in different ways. Screening will not notice that a clean customer is moving money in a suspicious pattern, and monitoring will not tell you that a counterparty is on a sanctions list. A firm needs both because identity risk and behavioural risk are separate exposures, and a program that covers one while neglecting the other leaves an obvious gap.
Do you need both screening and transaction monitoring?
Yes, in almost every regulated context you need both, because they defend against different risks. Screening establishes whether a party is someone you are prohibited or restricted from dealing with, a sanctions target, a politically exposed person or the subject of adverse media. Transaction monitoring establishes whether the money movement itself looks like laundering, even when every party involved screens clean. Neither substitutes for the other. A sanctioned counterparty can transact in a perfectly ordinary pattern, and a customer with no adverse listing at all can run a classic structuring scheme. Supervisors expect a program to address both dimensions, and a firm that runs only one is exposed on the side it left uncovered. The practical model is to treat them as complementary controls feeding a shared case and investigation process, rather than as competing tools, so that an identity hit and a behavioural alert are worked with the same rigour.
Can transaction monitoring replace sanctions screening?
No, transaction monitoring cannot replace sanctions screening, because they test for different things and one does not imply the other. Sanctions screening asks whether a party to a relationship or a payment is a designated person or entity that you are legally barred from dealing with. Transaction monitoring asks whether an account's behaviour fits a laundering typology. A sanctions breach does not depend on the transaction looking unusual; dealing with a designated party is prohibited even if the payment is small, routine and indistinguishable from ordinary activity. A monitoring model tuned to behavioural anomalies would let that payment through precisely because nothing about the pattern stands out. Sanctions obligations are also strict in most regimes, meaning the breach occurs regardless of intent, so relying on behavioural detection to catch designated parties is a serious control weakness. Screening against current lists is the only control that reliably addresses that specific risk, and it has to run continuously.
How do screening and monitoring feed one case record?
They feed one case record when both controls raise their alerts into a shared investigation system rather than into separate queues. A screening hit and a monitoring alert are different signals, but an investigator often needs both to make sense of a customer. If the sanctions match and the unusual-pattern alert land in one case, the reviewer sees that the counterparty is designated and that the account behaviour is abnormal at the same time, and can weigh them together. Keeping the two on one record also builds a single audit trail: what was screened, what the monitoring rules flagged, what the investigator concluded, and why. When these live in disconnected tools, the same customer is reviewed twice with neither reviewer seeing the whole picture, and the audit story fragments. The practical arrangement is for a screening engine to write its hits into the same case management the monitoring system feeds, so one investigation covers both.
Is BriteBase a transaction monitoring system?
No. BriteBase is a screening and risk-intelligence platform, not a transaction-monitoring engine, and it is honest to be clear about that boundary. Our engine covers sanctions, PEP, adverse-media and trade screening, and it re-screens the enrolled customer book continuously so that a party who becomes a new match is caught rather than missed. What it does not do is run behavioural models over transaction flows to detect structuring or layering; that is the job of a dedicated monitoring system. The two fit together rather than compete. Our screening runs alongside a firm's transaction-monitoring stack, and the screening hits can be raised into the same case management the monitoring alerts feed, so an investigator works one record. Positioned this way, screening handles the identity dimension of AML risk with strong entity resolution, while the monitoring system handles the behavioural dimension, and the firm gets both without either tool pretending to be the other.
Sources
Screening that works with your monitoring.
Book a demo and we will show you sanctions, PEP and adverse-media screening with continuous re-screening, deep-tier ownership and the 50% Rule, raising hits into the same case record your transaction-monitoring alerts already feed.
Book a demo