Transaction Monitoring in AML: Ultimate Guide For 2026

As per the United Nations Office on Drugs and Crime, an estimated $800 billion to $2 trillion is laundered globally every year, and the actual number could be much higher because it’s very hard to detect this activity. Businesses operating in the financial space, such as banks and crypto platforms, are often the first ones to get affected by these frauds.

The most effective way to lower the risks of these frauds is to have strong transaction monitoring software and policy in place that could track payments and make sure no bad money gets laundered.

Most compliance teams already have a monitoring system that they run to mitigate the risks. However, the solutions they use aren’t always optimal for stopping laundering and showing auditors that they did it effectively.

When asked by a regulator about their transaction monitoring efforts, they usually cannot answer who last changed a threshold, what evidence justified the change, and who approved it. This has become a real concern for businesses operating in finance because the end users have started asking questions about who authorized the payments without proper due diligence.

This guide covers what AML transaction monitoring is, how the process works end to end, which rules earn their place, how to reduce false positives without losing coverage, and why the binding constraint in 2026 is usually governance rather than software. 

What is AML transaction monitoring?

AML transaction monitoring is the continuous review of customer payment activity to detect patterns that point to money laundering, terrorist financing, or a related predicate offence. It checks each transaction against rules and models that define what’s normal for that customer, testing what they do, not who they are, for as long as the account stays open.

When activity matches a rule, an analyst reviews the alert and closes or escalates it, with escalation potentially ending in a Suspicious Activity Report to the relevant Financial Intelligence Unit. An AML transaction monitoring system is simply the software running this process; the two terms are used interchangeably in procurement. What separates one system from another isn’t the rule library at go-live, since most vendors ship comparable ones, but what happens to that logic over the following years. 

Why is transaction monitoring important for AML?

It’s important because it is the only AML control that observes a user’s behaviour rather than some one-time attributes. It involves sanctions screening, PEP checks, and customer due diligence, all of which help ensure the company knows what the customer is doing and where they’re transferring their money and for what purpose. 

The reporting volumes show how much weight the control carries. Across all seven filer groups, more than 4.105 million Suspicious Activity Reports were filed in 2025, an increase of just under 8% on 2024, with banks, savings associations, and credit unions accounting for more than 2.193 million of them. Every one of those reports began as a monitoring alert that an analyst judged worth escalating, so the quality of the rule set upstream sets a ceiling on the quality of the intelligence reaching law enforcement.

How does the transaction monitoring process in AML work?

The transaction monitoring process in AML runs in four stages, and the fourth is the one most programmes never close. Data feeds the engine, the engine applies logic, alerts reach analysts, and analyst outcomes feed back into the logic.

From transaction data to alert

Each transaction arrives carrying the amount, counterparty, channel, geography, timing, and device or session context where the institution captures it. The engine evaluates that record against the active rule set and against the customer’s own established baseline. A match produces an alert with a risk score and, in a well-built system, the specific rule that fired plus the evidence supporting it. 

Enrichment is what separates a usable alert from a bare flag. An alert saying an amount exceeded a threshold gives an analyst nothing to work with. An alert saying the amount exceeded the threshold, the beneficiary is new, the corridor is high risk, and the customer’s device changed last week gives them a decision.

What is real-time transaction monitoring?

Real-time transaction monitoring is the process of evaluating every transaction as it occurs, often within a few hundred milliseconds, so that the payment can be held or blocked before it settles. Batch monitoring reviews groups of transactions at fixed intervals, typically overnight, which suits pattern detection that only becomes visible across a longer window.

Most institutions run both. Real-time logic covers channels where money leaves quickly and cannot be recalled, and batch logic covers behavioural patterns that no single transaction reveals.

The feedback loop: The step most programmes skip

Every alert an analyst closes as “false alarm” tells you something: that rule isn’t working well. If a rule keeps firing but never turns up anything real, it’s not adding safety; it’s just wasting analyst time that could go toward real risks.

The fix is simple: feed those outcomes back into the rules and adjust them. That’s how a monitoring system actually improves. Yet this is usually the one step nobody owns, so the noise never gets fixed.

What transaction monitoring rules should a bank have? 

Here’s how the four rule families break down, and how each one gets exploited when used alone:

Most people know that the regulatory reference point for cash reporting threshold is $10,000 cash, as per the Bank Secrecy Act. Among banks, savings associations, and credit unions in 2025, transactions below the CTR threshold ranked among the most frequently reported SAR categories at 8.65%, behind suspicion concerning the source of funds at 9.08% and transactions with no apparent economic or lawful purpose at 9.04%. Structuring remains one of the highest-volume things institutions report, which tells you threshold rules do catch it, and also that criminals keep trying regardless.

What money mule activity actually looks like

Typology rules earn their place when they encode behaviour rather than amounts. Money mule networks are the clearest example, and the signals are consistent across institutions.

None of those signals is a single large transaction, which is why threshold rules alone will never surface them. They are shapes in a sequence, and detecting a shape requires the system to hold history.

How do you reduce false positives in transaction monitoring?

Here are five steps you can take to reduce false positives, which will save your analysts time and help them focus on the cases that actually need their attention:

1. Segment before you apply rules. A money services business and a professional services firm can post similar volumes for entirely different reasons, so monitoring both against one parameter set guarantees noise from one of them.
2. Give the system memory. Comparing a transaction against the customer’s own baseline of amount, frequency, timing, and counterparty resolves far more alerts than comparing it against a population average.
3. Suppress under governed conditions, never silently. Recurring low-risk patterns can be logged rather than escalated, provided every suppression stays auditable and reversible.
4. Tune velocity rules to real business cycles. A retailer’s December volume is not an anomaly, and a system that treats it as one will bury the team every year on schedule.
5. Run statistical models alongside rules, not instead of them. Rule logic is explainable to an examiner line by line. Models catch combinations that fixed rules miss. Replacing the first with the second trades away the audit trail.

The trap worth naming is that false positives can always be driven to zero by switching rules off. Any reduction claim is only meaningful if detection coverage is held, which means measuring both together and documenting the trade.

Who owns the rules? The governance gap regulators keep finding

The gap in most monitoring programmes is not the technology; it is that nobody owns the tuning. The European Banking Authority’s own data points squarely at this. In its 2025 Opinion on money laundering and terrorist financing risks, published 28 July 2025, the EBA reported that over half of the serious compliance failures logged in its EuReCA database involved the improper use of RegTech tools, which it attributes to poor implementation and weak oversight rather than to any absence of technology. The same Opinion found that 70% of competent authorities report high or rising ML/TF risks in the financial sector. Institutions are buying capable systems and then failing to run them.

That diffusion is the failure mode. Compliance assumes the vendor tunes the model, the vendor assumes compliance sets the policy, risk assumes technology owns the deployment, and the threshold set at go-live is still there four years later with nobody able to say why.

The practical test is simple. Pick any rule in your production set and ask who approved its current threshold, on what evidence, and when. If assembling that answer takes more than an afternoon, the governance gap is yours too.

What regulators expect from AML monitoring systems in 2026

Regulators expect monitoring to be proportionate to risk and demonstrably maintained, which means the documentation around the system now carries as much weight as the system itself. FATF Recommendation 1 establishes the risk-based approach, and monitoring rules are where an institution proves that approach exists in practice rather than on paper.

Payment transparency is the other live thread. FATF agreed revisions to Recommendation 16 at its June 2025 Plenary, retitling it “Payment transparency” and requiring more consistent originator and beneficiary information in payment messages. The timeline matters more than the headline, because countries have until the end of 2030 to implement, a notable departure from the FATF’s usual practice of immediate effect. The FATF then opened a public consultation on the implementing guidance in June 2026, seeking input on detecting misdirected payments, implementation in lower-capacity jurisdictions, how the standard applies to digital wallets and mobile money, and reconciling it with data protection requirements. Institutions have a runway here, and richer structured payment data will eventually make behavioural detection considerably more precise.

What examiners want to see now is unglamorous. Documented rationale for every threshold, dated evidence of periodic rule review, a record of alert outcomes feeding back into calibration, and named accountability for each of those. A monitoring system running unattended in the background is a finding waiting to be written.

How Shufti approaches AML transaction monitoring

Compliance teams rarely lack a monitoring system. What they lack is a defensible record of how the logic got to be the way it is, which is exactly what a supervisor asks for first.

Shufti’s transaction monitoring treats the rule set as a governed asset rather than a configuration file. Teams start from a typology rules library, write logic manually, or draft it with an AI wizard that still requires compliance review before anything deploys. Thresholds, filters, weights, velocity windows, approvals, and version history stay readable, and changes can be backtested against historical transaction and customer behaviour before they reach production. Where a required field is missing, the transaction is flagged Not Assessable rather than passed as low risk, so gaps stay visible instead of resolving quietly in the institution’s favour. 

That is the difference between a system you operate and a system you can defend.

Bring your own transaction data and see how the rule library, backtesting, and evidence trail hold up, then book a demo.