AML transaction monitoring: a complete guide
In October 2024, TD Bank paid more than $3 billion in penalties. While they were ultimately convicted of money laundering conspiracy, the disaster started because they ran a transaction monitoring program that did not work. For roughly a decade, the bank monitored only a fraction of the transaction volume it should have, completely ignoring internal staff who had flagged the gaps for years.
That is the shape of most transaction monitoring failures. The system exists. The rules exist. The alerts fire. But the coverage has gaps nobody escalated, or the queue is so full of noise that the thing that mattered got cleared in forty seconds.
AML transaction monitoring is the ongoing review of customer transactions against defined rules and risk criteria, to identify activity that may indicate money laundering or terrorist financing. Unlike identity verification, which happens once at onboarding, monitoring runs for the life of the customer relationship.
This guide covers what monitoring detects, how the process runs end to end, which rules actually matter, what regulators expect in 2026, and how to tell a system that scales with your team from one that just generates more work for it. If you want to see how Unit21's AML transaction monitoring handles it, that link goes straight to the product.
What is AML transaction monitoring?
AML transaction monitoring is the practice of reviewing customer transactions against rules and risk criteria to flag activity that may indicate money laundering or terrorist financing. Matching activity generates an alert, an analyst reviews it, and confirmed suspicious activity is reported to FinCEN through a suspicious activity report.
It applies to any organisation that moves money on behalf of customers. Deposits, transfers, withdrawals, and payments are evaluated either as they occur or shortly after.
The obligation is not optional, and it does not depend on outcomes. Regulators treat an inadequate monitoring program as a violation in its own right, whether or not laundering is ever found. That is why an effective anti-money laundering operation is a risk program rather than a reporting exercise.
What does AML transaction monitoring detect?
Money laundering deserves a closer look, because its structure shapes how most AML rulesets get built. It moves through three stages: placement, layering, and integration, and each stage leaves a different kind of evidence. Placement is the most detectable, because the money is still close to its source. Layering is the hardest, because it is engineered to look like ordinary activity.
AML monitoring vs anti-fraud monitoring
Both watch the same transaction stream. They look for different things, and they usually sit in different parts of the organisation.
A rule tuned for one is rarely useful to the other. Teams that run both from a single ruleset generally end up with a queue that serves neither well, which is an argument for a platform that can hold both without collapsing them into one.
Transaction screening vs transaction monitoring
These are separate controls answering different questions, and the distinction matters when you are scoping a program.
Transaction screening checks a transaction against lists before it completes: sanctions lists, watchlists, politically exposed persons, prohibited jurisdictions. It is a real-time gate, and it answers "am I allowed to process this?" A hit holds or blocks the payment.
Transaction monitoring evaluates behavior over time. It asks "is this pattern consistent with what I know about this customer?" It generates an alert for review rather than blocking outright.
You need both. Screening catches the prohibited counterparty. Monitoring catches the customer whose activity has quietly stopped making sense. Payment screening and sanctions screening run as distinct controls for this reason.
Who is required to do transaction monitoring?
Any regulated entity that moves money on behalf of customers. In practice:
- Banks and credit unions, under Bank Secrecy Act obligations
- Money services businesses, including money transmitters and currency exchanges
- Fintechs and neobanks, either directly or through a sponsor bank relationship. Worth understanding the money laundering typologies specific to neobanks, how the sponsor bank relationship works in practice, and what compliance looks like when starting one. Chime and other high-growth neobanks have had to scale monitoring alongside customer growth
- Payment processors and payment facilitators
- Crypto exchanges and virtual asset service providers
- Lenders, where exposure runs through origination and repayment sources. Non-compliance carries substantial fines and penalties
- Broker-dealers and investment platforms
- Insurers, particularly for life and annuity products
- Gaming and gambling operators
One point worth naming for fintechs: where a sponsor bank holds the charter, the bank carries the regulatory obligation, but the fintech generates the activity. Examiners increasingly look straight through to the fintech's controls, which means a fintech's monitoring quality is now a partnership risk as much as a compliance one.
Real-time vs batch transaction monitoring
This is the most consequential architectural decision in a monitoring program, and the answer is usually both.
Batch monitoring runs after the fact, typically overnight. It is good at pattern detection across a window of time: structuring across a week, velocity building across a month, relationships between accounts that only appear in aggregate. Most AML typologies are found this way.
Real-time monitoring evaluates a transaction before it completes, which means it can block. That matters on instant rails, where money is gone and unrecoverable within seconds of authorisation.
The reason this has become urgent is that instant payments compress the laundering timeline. A sequence that used to take days across placement, layering, and integration can now complete inside a single session. A program built entirely around overnight batch review is examining activity that already finished, which is fine for filing a SAR and useless for preventing a loss.
Unit21's real-time monitoring evaluates transactions in under 250 milliseconds, which is what FedNow, RTP, and Zelle latency budgets require, and it runs on the same platform as batch AML monitoring so the two share detection logic and case history rather than sitting in separate tools.
How does AML transaction monitoring work?
Seven steps. The first two determine whether everything after them is meaningful, and they are where most programs go wrong.
1. Risk assessment
Everything downstream depends on this. What customer types do you serve, what products do you offer, which geographies do you touch, and what laundering risk attaches to each combination?
A rule you cannot trace back to an identified risk is a rule you cannot defend to an examiner. Start by building the AML compliance program around documented risk, with clear procedures for onboarding, ongoing review, and investigation.
2. Define what suspicious looks like for your business
Suspicious is relative to a baseline. A $9,500 cash deposit is unremarkable at a cash-intensive merchant acquirer and a strong signal at a digital-only lender. Translating your risk assessment into concrete, testable behaviors is the work that determines whether your alerts mean anything at all.
3. Build rules and thresholds
Each defined behavior becomes a rule with explicit parameters. Setting up transaction monitoring rules covers the mechanics, and there are more scenario examples here.
The rules that earn their place in almost every program:
Aggregation is the parameter people underestimate. Structuring across ten accounts defeats a rule that only aggregates within one, and that is exactly how mule networks are built.
4. Tune against real outcomes
A rule at launch is a hypothesis. The only way to know whether a threshold is right is to see which alerts led to filings and which were cleared, then adjust.
This is where most programs stall, because tuning requires an engineering ticket. The rule goes untouched for eighteen months, the false positive rate climbs, and the team absorbs it as normal. The people who understand the typology should be able to change the rule that catches it, the same day.
Testing a change before it goes live matters as much as making it. You want to know the true impact on alert volume before your analysts feel it, which means running new logic against historical data, or silently against live traffic, before it starts generating real alerts.
5. Investigate and build the case
An alert becomes a case when an analyst confirms it warrants investigation. Most of the work is assembly: pulling transaction history, mapping related accounts and counterparties, checking prior alerts on the same entity, documenting what was reviewed.
This is the most expensive part of AML operations and the least differentiated. Entity-centred investigations help, because the unit of investigation becomes the customer rather than the individual alert.
6. File the SAR
Confirmed suspicious activity goes to FinCEN via a suspicious activity report, under Bank Secrecy Act deadlines. The narrative carries the weight. It has to explain what happened, why it is suspicious, and what the institution reviewed, clearly enough for an investigator with no prior context.
Deadlines are firm and the narrative is what gets scrutinised, so SAR quality is an operational risk rather than a formality. Case management and regulatory filing that sit on the same platform as detection remove the handoffs where context gets lost.
7. Maintain, validate, and audit
Programs decay. Typologies shift, products launch, customer mixes change, and rules calibrated correctly last year stop being calibrated.
Periodic model validation, independent testing, and documented risk reassessment are examination expectations, not optional hygiene. So is an internal audit function with genuine independence. It is worth seeing how teams like Intuit scale this as volume grows.
Red flags by laundering stage
A practical way to check coverage: map your rules against the three stages and see where you are thin.
Most programs are strongest at placement and weakest at layering, which is unfortunate, because layering is where the money actually gets clean. The reason is structural: a layering signal in one account only means something when connected to a signal in another, and connecting them is analyst work that most teams do not have the hours for.
Why transaction monitoring programs fail
False positives
Most alerts are not suspicious activity, and every one still consumes analyst time. Labour is the dominant cost in financial crime compliance.
The real damage is not the cost though. A high false positive rate trains a team to clear quickly, and a team clearing quickly misses things. Reducing false positives is a detection quality problem before it is a staffing problem, and it is directly connected to the total cost of AML compliance.
One ruleset for every customer
Applying a single risk scenario across a varied customer base produces both failure modes at once: noise from customers whose normal behavior trips the rule, and blind spots where the threshold sits above a segment's real risk. Segmentation is what makes a threshold mean anything.
Too many overlapping scenarios
The opposite failure. Scenarios accumulate as new threats appear, nobody retires the old ones, and eventually no one can say which rule covers which risk. Duplicate cases get generated for the same underlying activity, and coverage gaps hide inside the overlap.
Data that arrives incomplete
Rules are only as good as the fields feeding them. Fragmented data across systems, missing counterparty detail, and payment rails onboarded without a full data model all produce rules that technically run and practically miss. This is the failure mode that is hardest to see from the inside, because the system looks healthy.
All four share one root cause: nobody can see which rules are actually working. Reviewing scenario effectiveness on a schedule is what prevents it.
What regulators expect in 2026
Three shifts worth planning around.
Explainability is now an examination topic. Regulators are increasingly explicit that institutions must be able to demonstrate why a monitoring system produced the decision it produced. A model that cannot be explained in terms an examiner accepts is a finding waiting to happen, regardless of how well it performs. Our FinCEN regulatory hub tracks current proposals.
Real-time rails carry real-time obligations. As instant payment volume grows, the expectation that controls operate at the speed of the rail grows with it. The 2026 Nacha rule changes are a concrete example of this direction.
Enforcement is targeting program design, not just outcomes. While massive structural failures can lead to criminal money-laundering convictions (as seen in TD Bank’s $3 billion penalty) regulators are increasingly penalising the systemic gaps themselves before a disaster even happens. Look no further than Robinhood’s 2025 settlements, where the firm faced tens of millions in fines specifically for unreasonable AML program design, alert backlogs, and deficient monitoring infrastructure.
The pattern is clear: regulators are penalising the gap between what a program claimed to cover and what it actually covered. This makes documented coverage and defensible tuning decisions just as critical as your system's detection performance.
How to evaluate transaction monitoring software
Questions worth asking any vendor, roughly in order of how much they reveal. Choosing transaction monitoring software goes deeper.
- Can my team write and modify a rule without your help, and how long does it take? Ask for a live demonstration, not a description.
- Can I test a rule change against historical data, or silently against live traffic, before it goes live? If not, every change is an experiment on your analysts.
- When an alert fires, can you show me exactly why, in terms an examiner will accept?
- What does the alert-to-filing path look like, and how much of it is manual?
- How does the system handle a customer with activity across multiple accounts or entities?
- What happens when we add a payment rail or launch a product? Does the data model absorb it, or is it an implementation project?
- What is your actual false positive rate with customers like us, and how is that measured?
- What does the audit trail capture, and can we export it?
- Where does the AI make decisions, and where does it only prepare them? The answer should be that a human decides.
How Unit21 approaches AML transaction monitoring
Three things distinguish how Unit21's transaction monitoring works.
Your team owns the detection logic. Rules are written and tuned in a no-code interface by the people who understand the risk, not by an engineering team working from a ticket. Changes can be tested against historical data or run silently against live traffic first, so you see projected alert volume before your analysts do. When a typology shifts, the rule that catches it changes the same day.
Every decision is explainable. Detection logic is explicit and readable, and the audit trail records what changed, when, and why. There is no opaque score to defend in an examination. Given where regulatory attention is heading, this is becoming the difference between a defensible program and a finding.
Investigation is automated, judgment is not. Unit21's AI Agents work an alert end to end: gathering transaction history, mapping related entities, assembling the picture across accounts, drafting the narrative, and preparing the filing, with each step logged. The analyst reviews and decides. Customers see false positive reductions of up to 93% and investigation time reductions of up to 80%.
That last point is what addresses the layering problem specifically. Connecting activity across accounts is precisely the work a human analyst would spend hours assembling by hand, and it is the work that most often does not get done.
Detection, case management, customer risk rating, and regulatory filing run on one platform, which is what makes outcome-based tuning possible at all. Unit21 is trusted by more than 200 customers including Sallie Mae, Chime, Intuit, and Green Dot, and was named a Category Leader in fraud by Chartis.
See it against your own data
The gap between a transaction monitoring program that works and one that generates work is rarely the rules themselves. It is whether your team can change them, defend them, and get through the resulting queue.
Schedule a demo and we will walk through detection, investigation, and filing on your own scenarios.
Frequently asked questions
What is transaction monitoring in AML?
AML transaction monitoring is the ongoing review of customer transactions against defined rules and risk criteria to identify activity that may indicate money laundering or terrorist financing. Matching activity generates an alert for analyst review, and confirmed suspicious activity is reported to FinCEN through a suspicious activity report.
What is the difference between transaction monitoring and transaction screening?
Screening checks a transaction against sanctions lists, watchlists, and prohibited jurisdictions before it completes, answering whether the transaction is permitted. Monitoring evaluates patterns of behavior over time, answering whether activity is consistent with what is known about the customer. Screening usually blocks. Monitoring usually alerts.
Is transaction monitoring a legal requirement?
For regulated institutions that move money, yes. In the US it falls under the Bank Secrecy Act, and an inadequate program is treated as a violation regardless of whether laundering is found. Specific obligations vary by institution type and jurisdiction.
What are the most common AML transaction monitoring rules?
Structuring detection below reporting thresholds, velocity rules for rapid movement of funds, round-number transfers between related parties, dormancy reactivation, high-risk jurisdiction exposure, deviation from a customer's stated purpose, and peer group outlier detection. Thresholds should follow from your own risk assessment rather than a vendor default.
What is the difference between real-time and batch transaction monitoring?
Batch monitoring runs after transactions complete, usually overnight, and is better at detecting patterns across a window of time. Real-time monitoring evaluates a transaction before it completes and can block it. Most programs need both: batch for typology detection, real-time for instant payment rails where funds are unrecoverable within seconds.
Why do transaction monitoring systems produce so many false positives?
Usually because thresholds were set once and never tuned against outcomes, or because one ruleset is applied across customer segments with genuinely different normal behavior. Incomplete transaction data is a third common cause. All three are fixable, but only if the team can change rules quickly and see which ones led to filings.
Can AI replace analysts in transaction monitoring?
No, and a system claiming otherwise is a regulatory problem rather than a feature. What AI can do well is the assembly work: gathering evidence, mapping entity relationships, and drafting narratives. Judgment on whether activity is suspicious, and accountability for the filing, stays with a human. Explainability and a complete audit trail are what make the automation defensible in an examination.
How long does it take to implement a transaction monitoring system?
It varies with data readiness more than with the platform. The work that determines the timeline is mapping your transaction data, agreeing the risk assessment that drives your rules, and calibrating thresholds against your own history. Institutions that arrive with a documented risk assessment move considerably faster.
Gal Perelman is the Product Marketing Lead at Unit21, where she spearheads go-to-market strategies for AI-driven risk and compliance solutions. With over a decade of experience in the fintech and fraud sectors, she has led high-impact launches for products like Watchlist Screening and AI Rule Recommendations.
Previously, Gal held marketing leadership roles at Design Pickle, Sightfull, and Lusha. She holds a Master’s degree from American University and a Bachelor’s from UCLA, and is dedicated to helping banks and fintechs navigate complex regulatory landscapes through innovative technology.
