AML AI: How to Use It in Transaction Monitoring

In a 12-month comparison published by HSBC, AML AI found two to four times as much suspicious activity as the rules engine it replaced, while alert volume fell 60%. That is the best public number in the field, and it comes with a catch: it was reported by the bank and its vendor, on a bank that already screened more than a billion transactions a month. If you run a financial crime program, the useful question is not whether machine learning beats static rules. It often does. The question is what has to be true in your data, your model governance and your investigation team before that result can be repeated and defended to an examiner.

This guide is written for the people who carry that question: chief compliance officers, MLROs, heads of financial crime technology, and the COOs and CEOs of mid-sized banks, fintechs and payment firms who sign the budget. It covers where AI earns its place in anti-money laundering, where it does not, what the rules say in the US and the EU, how to run a parallel test, and what a realistic first 90 days looks like.

One boundary before we start. This is an operating guide, not legal advice. Your counsel and your regulator have the last word on your program.

What AML AI actually changes, and what it leaves alone

Most AML programs run on the same chain. A monitoring system generates alerts. Level 1 analysts clear the obvious noise. Level 2 investigators build cases. A qualified person decides whether to file a suspicious activity report. Each step has its own failure mode, and AI touches each one differently.

Rules-based monitoring has one structural weakness: it looks for what somebody already wrote down. A scenario that flags cash deposits just under a threshold catches structuring and misses a mule network moving small amounts through forty accounts. To cover more ground, teams widen the thresholds. Alert volume rises, quality drops, and analysts spend their day clearing activity that was never suspicious.

A Bournemouth University doctoral thesis on AML transaction monitoring puts the false positive rate of traditional systems above 95%. You will see that range quoted everywhere, usually with no source. Treat it as an order of magnitude, then measure your own rate, because your own rate is the only baseline your board and your examiner care about.

AI changes three things in this chain:

• Detection. Behavioral and network models score customers and relationships rather than single transactions against a fixed rule.
• Prioritization. Scoring models rank the existing alert queue so that investigators see the likely cases first.
• Investigation. Language models gather the context, summarize the history and draft the narrative for human review.

It leaves one thing alone: accountability. Keep the decision to file a suspicious activity report with a named person. The regulators quoted below all stress human oversight, and none of the guidance reviewed here hands that judgment to a model.

Where the evidence is strong, and where it is only promising

Before spending money, separate what has been shown in production from what has been shown on synthetic data and what is still vendor marketing. These are three different kinds of evidence.

The HSBC case. The most detailed public account is HSBC's own write-up on the Google Cloud blog, published in November 2023. The bank screens more than 1.2 billion transactions a month. It compared the 12 months after go-live with the previous 12 months of rules, adjusted for seasonality, and excluded the first month to avoid backlog distortion. Financial crime identified roughly doubled in commercial banking and nearly quadrupled in retail. Suspicious accounts were detected within eight days of the first alert.

The method matters as much as the headline. A before-and-after window with seasonality adjustment is what a good evaluation looks like. What the write-up does not describe is model validation or regulatory dialogue, which is exactly the work your team will have to do.

Project Aurora. The BIS Innovation Hub's Project Aurora report tested machine learning on synthetic payment data across siloed, national and cross-border views. Its finding is the one that should shape your architecture: behavioral, network-based methods were more effective at detecting laundering networks than the rules approach, which is limited by its siloed view. The value came from the wider picture as much as from the algorithm.

The academic work. The same Bournemouth thesis proposes a model, Tab-AML, that reached a 93.01% ROC-AUC, cut false positives by 17% and kept a 98% true positive rate. It was evaluated on the author's own synthetic dataset. A 17% reduction in a controlled setting is a more sober number than most sales decks offer, and a useful reality check when you read them.

The honest reading. Large alert reductions are possible, and they are least proven at firms with thin data and few confirmed cases to learn from. If your institution files a few hundred SARs a year, you have far less signal for supervised training than HSBC has, and your plan should reflect that.

Six AML use cases, ranked by how fast they pay back

Not every application carries the same risk or needs the same data. Here is the order I would recommend for most mid-sized institutions, starting with the ones that can show value without touching the detection logic your examiner has already reviewed.

1. Investigation copilots. A language model pulls KYC files, prior alerts, transaction summaries and adverse media into one view, then drafts a case summary. The analyst checks every claim against the underlying records. Nothing about what gets detected changes, so model risk is lower and the benefit shows up quickly in handling time.

2. Alert prioritization. A model scores the alerts your current rules already produce and ranks the queue. Every alert still exists and can still be worked. This is the safest first step for machine learning, because you can measure it against history before you let it influence anything.

3. Alert hibernation or auto-closure. Low-score alerts are closed or parked with a documented rationale. This is where real capacity is released, and also where real risk starts. It needs below-the-line sampling, written approval and a clear record of why each one was closed.

4. Sanctions and name screening. Better entity resolution reduces the false matches that come from transliteration and common names. Keep the distinction clear: sanctions obligations are strict and thresholds need careful governance, so improve matching quality rather than simply suppressing hits.

5. Dynamic customer risk rating. Models update a customer's risk score from observed behavior rather than waiting for a periodic review. In the EU, changing the depth of due diligence on the basis of such a score triggers the human intervention requirement discussed below.

6. Behavioral and network detection. Replacing or supplementing scenarios with models that learn from behavior and relationships. This has the highest potential and the heaviest validation burden, which is why it comes last, once your data and governance have been tested on the earlier steps.

If you want a second opinion on where your own program should start, describe your alert volumes and your team size in a short request for a consultation: the sequencing conversation is usually where the most money gets saved.

AI in AML transaction monitoring: rules, models, or both?

The practical answer for almost every regulated firm in 2026 is both. Retiring every scenario on day one is hard to defend and rarely necessary. A layered design lets you keep the transparency of rules while adding the reach of models.

A workable architecture has four layers:

1. Deterministic controls. Regulatory thresholds, sanctions lists and known red flags stay as rules. They are simple to explain and hard requirements should not depend on a probability.
2. Behavioral models. Unsupervised or semi-supervised models flag departures from a customer's and peer group's normal pattern. These matter when confirmed cases are scarce.
3. Network analytics. Graph features expose shared devices, addresses, counterparties and circular flows. This is the layer the Aurora results point to.
4. Scoring and triage. A supervised model combines the signals and ranks the output for investigators, trained on your own dispositions and filing outcomes.

A warning on labels. SAR filing is an imperfect label. It tells you what your team decided to report, not what was really laundering. Train only on past decisions and you teach the model to reproduce past blind spots. The director of Italy's financial intelligence unit made the same point in the UIF's 2025 annual report presentation: uncritical use of automated models can reduce the capacity to intercept new phenomena, and technology cannot replace professional judgment.

The mitigation is a deliberate exploration budget. Keep a share of investigator capacity for cases the model ranks low and for samples chosen at random. Feed what they find back into training. Law enforcement feedback, where you can get it, is a better label than your own filing history.

On explainability. You do not need every model to be simple. You do need every alert to carry reasons a person can read: which behavior changed, which counterparties are linked, how this compares with peers. If an investigator cannot explain why a case was raised, they cannot write a credible narrative, and your examiner will notice.

Generative AI and agents in the investigation workflow

Language models are good at reading a lot of text and writing a first draft. That maps closely onto the worst part of an investigator's day: moving between systems, assembling a timeline and writing it up. It maps badly onto deciding whether something is suspicious, which should stay human.

Useful tasks include:

• Summarizing account history and prior alerts into a single chronology.
• Screening adverse media and separating allegations from convictions.
• Drafting SAR narratives from verified facts, with citations to source records.
• Checking a draft against internal policy for missing elements.
• Translating foreign language documents for review.

The risks are specific. A language model can invent a transaction that sounds plausible, so every figure and date in a narrative must trace back to a system of record, and the interface should show that link. Prompts and outputs contain highly confidential data, and SAR confidentiality rules apply in full, so a personal chatbot account is out of the question. We covered the broader version of this problem in our guide to shadow AI risk management.

Agents raise the stakes. An agent that gathers data, opens tickets and proposes dispositions is attractive and already being marketed; the term "ai agent for aml transaction monitoring" now has its own search volume. Let agents read and prepare. Do not let them close, file or contact customers without a person approving the specific action. Permissions, logs and kill switches need designing before launch, along the lines set out in our guide on how to govern AI agents in the enterprise.

Keep your expectations in line with how the wider industry behaves. In the Bank of England and FCA's 2024 survey, 75% of UK financial firms were already using AI, 55% of use cases had some automated decision-making, and only 2% had fully autonomous decision-making. AML and fraud were among the areas firms named as having the highest perceived benefits. Autonomy is the exception, even among large firms.

What regulators expect: US, EU and the FATF view

The regulatory picture has moved in favor of responsible use, but it has not lowered the bar on outcomes. Here is what matters in each regime.

United States. In April 2026 FinCEN proposed a rewrite of AML/CFT program requirements that would define "effective" for the first time. According to Orrick's summary, the proposal requires no specific technology, strongly encourages tools such as machine learning and generative AI, and says responsible adopters would not face more supervisory or enforcement risk solely because they adopted them. Comments closed on June 9, 2026. It was a proposal when those sources were written, so check its current status before relying on it.

Model risk. US banks also operate under model risk guidance, which US agencies revised in April 2026. Orrick's note on the revision is a good starting point. Whatever your size, expect to document development, validation, ongoing monitoring and change control for anything that influences what gets investigated.

What failure looks like. TD Bank's 2024 resolution is the reference case, and it is about coverage. FinCEN assessed a record $1.3 billion penalty and a four-year monitorship, finding that trillions of dollars a year went unmonitored. Axios, citing the Justice Department, put automatically unmonitored activity at about $18.3 trillion from January 2018 to April 2024. Total penalties exceeded $3 billion. The lesson for AI buyers: a clever model on incomplete feeds is still a coverage failure.

European Union: the AMLR. Regulation (EU) 2024/1624 applies from July 10, 2027, and addresses this topic directly. Article 76(5) allows decisions from automated processes, profiling and AI systems, under three conditions:

• The data processed is limited to data obtained under the regulation's customer due diligence chapter.
• Any decision to enter, refuse or maintain a relationship, to carry out or refuse an occasional transaction, or to increase or decrease due diligence is subject to meaningful human intervention.
• The customer can obtain an explanation and challenge the decision, except in relation to a suspicious activity report.

That first condition deserves attention from anyone planning to feed external data into a model. Article 76(4) also bars processing this data for commercial purposes, so your AML feature store cannot quietly double as a marketing asset.

EU supervision and the AI Act. The new EU authority, AMLA, is expected to supervise about 40 selected groups directly from 2028, with selection during 2027. Under the AI Act, creditworthiness assessment is high-risk under Annex III, point 5(b), with an explicit carve-out for detecting financial fraud, and Annex III obligations apply from December 2, 2027. AML monitoring is not named in that annex. Do not read that silence as an all-clear: run your own classification with counsel, particularly for anything that affects access to financial services.

Italy as a preview. Italy shows where national practice is heading. Italian firms sent the UIF 162,059 suspicious transaction reports in 2025, up 11.5% on 2024. The UIF's December 2025 instructions, as summarized by DirittoBancario, allow AI to detect anomaly indicators if it uses verifiable data, keeps human intervention and supervision, and makes decisions traceable. Expect similar language elsewhere.

The FATF view. The Financial Action Task Force's horizon scan on AI and deepfakes, summarized here, focuses on the other side: criminals using synthetic media to defeat customer due diligence. The UIF reports the same thing in practice, with generative AI used to create documents for remote account opening. Your KYC controls are now part of your AI risk, whether or not you deploy any AI yourself.

Self-assessment: is your program ready for AML AI?

Score each statement from 0 (not true) to 2 (true and documented). Be strict. If you cannot show the evidence, it is a 0 or a 1.

Data

1. We can reconcile monitoring feeds against source systems and prove that every product and channel is covered.
2. We hold at least 24 months of alerts, dispositions and filings in a usable, linked form.
3. Customer, account and counterparty entities are resolved across systems.

Baseline

4. We know our alert volume, false positive rate, alert-to-SAR rate and cost per alert for each scenario.
5. We know the median age of alerts and our backlog at month end.
6. We tune scenarios on a documented cycle with above-the-line and below-the-line testing.

Governance

7. A named executive owns financial crime models, and the board has seen the risk appetite for them.
8. Our model inventory includes vendor models, and independent validation covers them.
9. We have written criteria for what a model may decide and what requires a person.

People and vendors

10. Investigators have been involved in designing the workflow, and we have measured how they use the current tools.
11. Our contracts give us access to model documentation, performance data and audit rights.
12. We have tested a rollback to the previous process.

Reading the score:

The most common surprise is question 1. Plenty of programs have never proved complete feed coverage. Do this first, and whatever you later learn about models will be worth more.

How to run a parallel test your examiner will respect

A demo proves nothing about your portfolio. A shadow run on your own data does. The design below applies to prioritization and to detection, with more rigor for the latter.

Step 1: write the test plan first. State the hypothesis, population, period, metrics and thresholds for success or failure before seeing any output. Have model risk and compliance sign it. A plan written afterwards will be read as a justification.

Step 2: use out-of-time data. Train on one period and test on a later one. Random splits leak information across time and flatter the model. Keep a holdout that the vendor never sees.

Step 3: run in shadow. The model scores live activity while the existing process continues untouched. No alert is suppressed. Run long enough to cover seasonal patterns where you can; a few weeks of data prove little.

Step 4: investigate the disagreements. This is where the learning happens. Send a sample of what the model flagged and rules missed to experienced investigators, blind to the source. Review what rules flagged and the model ranked low. A model that merely finds a different kind of noise is not an improvement.

Step 5: test below the line. Sample alerts the model would have closed, and have people work them. Set the acceptable miss rate in advance with your compliance leadership and record it.

Step 6: test for bias. Check outcomes across nationality, geography, age and business type, within what your law permits. AMLR Article 76 explicitly prohibits biased and discriminatory outcomes when processing special categories of data. Unjustified account closures also carry a reputational cost of their own.

Metrics to report:

Do not lead with cost. An examiner reading a validation pack wants to see better detection and controlled risk, with efficiency as a consequence. That is also a more honest description of what you want. The same logic applies to any evaluation of this kind, as we argue in our enterprise AI adoption framework.

Build, buy or layer: how to choose

There are three realistic options. Which one fits depends far more on your data and team than on vendor claims.

Layer on your current platform. Add a scoring or case-assist module on top of existing monitoring. This is the fastest route and keeps rules in place. The limit is that your underlying data model limits how much network context you can use. For most mid-sized firms, this is where to start.

Buy a specialist platform. Replace or run alongside the incumbent. You gain modern data architecture and purpose-built models. You also take on migration risk and a dependency that needs managing. Treat vendor models as your models for governance purposes; regulators will.

Build in-house. Justified only when you have data scientists who understand financial crime, a large volume of labeled outcomes and a real differentiator in your data. It is the most control and the longest road.

Ask every vendor the following:

• On which population was the headline number measured, and can I speak to that client's model risk team?
• How does the model perform at institutions of my size with my volume of confirmed cases?
• What documentation do I receive for validation, and may my validator see feature importance?
• How do I produce reasons for each alert in language an investigator can use?
• Is my data used to train models for other customers?
• How do you detect drift, and who pays for retraining?
• What happens if I leave: do I keep the labels, features and audit trail?
• Which sub-processors and foundation models sit underneath, and how will I hear about changes?

The build-or-buy logic is the same as in other enterprise software, and our build vs buy decision guide covers it in more depth. The AML-specific twist is that outsourcing the technology does not outsource accountability.

Costs and the business case, without invented numbers

I am not going to give you a benchmark ROI. Public figures in this area are usually vendor-sourced and not comparable. What you can do is build a defensible case from your own data in an afternoon.

Start with four inputs you already have or can get:

• Alerts per month, by scenario.
• Fully loaded cost of an analyst hour.
• Average handling time at Level 1 and Level 2.
• Current false positive rate.

From those, the capacity formula is simple:

Hours released per month = alerts per month x share safely deprioritized x average handling time per alert

Then subtract what people forget: licensing, integration, data engineering, validation (often external), model monitoring, and the investigator time needed for sampling and feedback. Add a realistic period of parallel running, when you pay for both processes.

Three things that belong in the case but resist a dollar figure:

1. Backlog risk. An aging alert queue is a regulatory finding waiting to happen, and clearing it has value that a cost-per-alert calculation misses.
2. Detection quality. Better SARs give law enforcement more to work with. The UIF's own report complains about poorly structured information in filings, a sign of what regulators value.
3. Analyst retention. Clearing false alerts all day burns people out, and experienced investigators are expensive to replace.

Be honest about the savings. In practice, released capacity often gets redeployed into deeper investigations and backlog before it shows up as a lower headcount. Budget on that basis.

I have seen the value of this discipline outside banking. At a sports distribution company where AI marketing lifted sales by 30%, the result could only be defended because there was a clear baseline before anything changed. The sector is different and the stakes here are far higher, but the principle holds: no baseline, no credible result.

A 30/60/90 day roadmap

This plan assumes a mid-sized institution starting with prioritization and investigation support. Timelines stretch with procurement and regulatory dialogue; do not cut validation to hold a date.

Days 1 to 30: establish the facts

• Reconcile monitoring feeds to source systems, and record any gap as an issue with an owner.
• Produce the baseline: alerts, false positives, handling time, backlog, by scenario.
• Inventory every AI tool already in use across compliance, including unofficial ones.
• Name an executive owner and form a working group from compliance, model risk, data, legal and investigators.
• Agree on what a model may never decide alone. Write it down.
• Brief your supervisor's contact point if your relationship and regime make that appropriate.

Days 31 to 60: test without touching production

• Choose one use case. For most firms: alert prioritization or an investigation copilot.
• Write the test plan and sign it before any output exists.
• Run in shadow on out-of-time data.
• Have senior investigators blind-review the disagreements.
• Assess data protection, including a DPIA where required, and check vendor contracts.
• Start investigator training on verifying AI output. Under the EU AI Act, Article 4 asks firms to take measures that support staff AI literacy; documented sessions are the easiest to evidence.

Days 61 to 90: decide on evidence

• Complete independent validation of the shadow results.
• Take a go or no-go decision to the risk committee against the criteria you set earlier.
• If go, roll out to one team or scenario with a tested rollback.
• Keep below-the-line sampling and drift monitoring live from day one.
• Report results to the board in the same metrics as your baseline.
• Plan the next use case only once this one is stable.

If that plan would benefit from an outside view before it goes to your risk committee, send a brief request for a consultation with your current volumes and the decision you face. I work as a founder who advises on these projects, and I will tell you if the answer is to wait.

Seven mistakes that sink AML AI projects

1. Buying a model to fix a data problem. If feeds are incomplete or entities unresolved, the model inherits the gaps and hides them behind a confident score.

2. Measuring only alert reduction. A model that suppresses alerts always looks efficient. Without measuring what it misses, you have no idea whether you improved anything.

3. Treating past SARs as ground truth. This reproduces historical blind spots. Keep an exploration budget for what the model ranks low.

4. Excluding investigators until launch. They know where the data lies, and they are the ones who decide whether the tool gets used or worked around.

5. Treating the vendor's validation as yours. A vendor can provide documentation, but it cannot own your risk. Validate on your own population, with your own people or an independent party.

6. Letting models drift unwatched. Laundering typologies change, partly in response to your controls. A model tested once and left alone decays quietly. Monitor it monthly and set retraining triggers.

7. Ignoring the customer on the other side. A wrongly restricted account is a real harm to a real person or business. Build explanation and challenge paths now, since the AMLR will require them for relevant decisions from July 2027.

The broader compliance function has many of the same patterns; our guide on AI for compliance covers them outside financial crime, and the AI in enterprise risk management guide shows how to put this inside a wider risk framework.

What to do next week

If you take only one thing from this guide, make it the order of operations. Coverage first, baseline second, low-risk use cases third, detection last. The firms that get this backward end up with an impressive demo and an uncomfortable examination.

Next week, ask your team for three things: proof that every product and channel feeds your monitoring system, the false positive rate by scenario, and the list of AI tools people already use in compliance. How quickly you get those answers tells you more about your readiness than any vendor's slide.

FAQ

What is AML AI?

AML AI is the use of machine learning, network analytics and language models in anti-money laundering work. It is applied to transaction monitoring, alert prioritization, customer risk rating, name screening and investigation support. Unlike static rules, these models learn patterns from behavior and past outcomes. In a regulated program, they support people instead of replacing them: a named human remains accountable for the decision to report suspicious activity, and the institution has to validate, monitor and be able to explain the models it uses.

How does AI in AML transaction monitoring reduce false positives?

AI reduces false positives in two main ways. Scoring models rank the alerts that rules already generate, so low-risk ones can be deprioritized under documented controls. Behavioral and network models can also detect suspicious activity with fewer alerts by looking at relationships and changes in behavior instead of fixed thresholds. HSBC reported 60% fewer alerts with two to four times as much suspicious activity found. Results vary widely, so firms should test on their own data with below-the-line sampling.

Is AI allowed for anti-money laundering compliance?

Yes, with conditions. In the EU, Article 76(5) of Regulation 2024/1624, which applies from July 10, 2027, permits decisions involving AI systems if data use is limited, meaningful human intervention applies to key customer decisions, and customers can obtain an explanation and challenge the outcome, except for suspicious activity reports. In the US, FinCEN's April 2026 proposal encouraged machine learning and generative AI without requiring them. Institutions remain responsible for outcomes and should confirm current rules with counsel.

Can AI file suspicious activity reports automatically?

It should not. AI can gather evidence, build a timeline and draft a narrative, but a qualified person should verify the facts and decide whether to file. Language models can produce plausible statements that are false, so every figure in a draft must trace back to a system of record. Regulators consistently stress human supervision and traceability. Italy's financial intelligence unit, for example, allows AI for detecting anomaly indicators only with verifiable data, human oversight and traceable decisions.

Where should a mid-sized bank start with AI in AML?

Start by proving that every product and channel feeds your monitoring system, then measure your baseline by scenario: alerts, false positives, handling time and backlog. The first AI use case should carry low model risk, usually an investigation copilot or alert prioritization run in shadow mode. Move to auto-closure and new detection models only after validation, below-the-line testing and a tested rollback. Fixing coverage and data before buying a model avoids the most expensive mistakes.

How long does an AML AI implementation take?

A first low-risk use case can be tested in about 90 days if data is available: one month for baseline and data checks, one for a shadow run, and one for validation and a decision. Replacing or supplementing detection scenarios takes considerably longer, because of integration, longer parallel runs, independent validation and supervisory dialogue. Procurement often adds months. Treat any shorter timeline with suspicion, especially where it depends on skipping parallel running or validation.

Does AI in AML need to be explainable?

Each alert needs reasons a person can read, even if the underlying model is complex. Investigators must explain why a case was raised in order to write a credible narrative, validators need to understand drivers of performance, and examiners will ask. In the EU, the AMLR also gives customers a right to an explanation of relevant automated decisions, except in relation to suspicious activity reports. Choose tools that show which behaviors, links and peer comparisons drove a score.

What are the main risks of using AI for AML?

The main risks are missed activity from suppressed alerts, models that repeat historical blind spots, discriminatory outcomes such as unjustified account closures, invented facts in generated narratives, and silent performance decay as typologies change. Vendor dependency and confidentiality breaches through unapproved tools are also common. Coverage failures remain the most serious: TD Bank's $1.3 billion FinCEN penalty stemmed from trillions of dollars going unmonitored. Controls include sampling, validation, drift monitoring, access limits and a tested rollback.