At most banks, the anti-money laundering (AML) compliance team starts the morning the same way: staring at a queue of hundreds of transaction monitoring alerts, knowing that roughly 95 out of every 100 will turn out to be harmless. A restaurant owner deposits weekend cash receipts and trips the $10,000 currency transaction report (CTR) threshold. A freelance consultant receives a wire from a client in a high-risk jurisdiction. A retiree moves money between accounts at two different banks. Each of these generates an alert. Each requires a human analyst to open a case, review the customer's history, check for suspicious patterns, and write a disposition. The vast majority end the same way: closed, no suspicious activity found.
This isn't a minor inconvenience. The global banking industry spends an estimated $25 to $35 billion per year on AML compliance, and a large share of that cost goes toward investigating alerts that never should have been generated. In the United States alone, financial institutions filed over 4 million suspicious activity reports (SARs) with the Financial Crimes Enforcement Network (FinCEN) in fiscal year 2023. The volume has been climbing steadily for a decade.
The question isn't whether the system is broken. Compliance officers already know it is. The question is whether machine learning can fix it without creating new risks that regulators won't accept.
How Rule-Based Monitoring Creates the Problem
Traditional transaction monitoring systems operate on static rules. If a cash deposit exceeds $10,000, flag it. If a wire transfer goes to a country on a sanctions list, flag it. If a customer's monthly transaction volume exceeds three standard deviations from their peer group average, flag it. These rules were written to satisfy Bank Secrecy Act (BSA) requirements, and they've barely changed since the early 2000s at many institutions.
The problem is that static thresholds don't account for context. A $15,000 cash deposit means something very different for a bodega owner than for a salaried accountant. But the rule doesn't know the difference. It fires for both. Multiply this across dozens of scenarios (structuring, rapid movement of funds, round-dollar wires, high-risk geography, politically exposed person (PEP) associations) and you get an alert queue that overwhelms even large compliance teams.
Banks respond by hiring more analysts, which raises costs. Or they raise thresholds to reduce alert volumes, which risks missing real laundering activity and drawing regulatory criticism. It's a lose-lose configuration, and it's been the status quo for twenty years.
The false positive rate at most institutions sits between 95% and 99%. Some banks have reported rates above 99.5%. That means for every genuine suspicious case, analysts review 100 to 200 that aren't. The burnout rate among AML analysts is well-documented, and experienced compliance officers regularly cite alert fatigue as their top operational challenge.
What ML-Based Monitoring Actually Does Differently
Machine learning-based AML monitoring doesn't throw out the rules. The better implementations layer ML on top of existing rule-based systems, or run both in parallel and use ML to prioritize which alerts analysts see first.
The core difference is behavioral baselining. Instead of comparing a transaction against a fixed dollar threshold, an ML model builds a profile of what's normal for each individual customer. It considers transaction history, account tenure, declared occupation, peer group behavior, and seasonal patterns. A $12,000 cash deposit from a customer who regularly deposits $8,000 to $15,000 in cash every Monday is scored very differently from the same deposit by a customer who's never deposited more than $500 in cash.
Network analysis adds another layer. Graph-based models map relationships between accounts, entities, and transactions to identify suspicious patterns that no single-transaction rule would catch. Money laundering often involves layering funds through multiple intermediary accounts, and graph analytics can detect these multi-hop patterns even when each individual transaction looks unremarkable.
Contextual scoring combines both approaches. Rather than a binary flag/don't-flag decision, the model assigns a risk score that reflects how anomalous a transaction is given everything the system knows about that customer and their network. Analysts see their queue ranked from highest to lowest risk, which means the genuinely suspicious cases rise to the top.
Companies Building ML-Based AML Tools
Several companies have built products that address the false positive problem directly. They differ in approach, target market, and scope.
Feedzai operates at the largest scale in this space. The company's real-time ML platform processes billions of transactions for some of the world's top-five banks by asset size. Feedzai's models run scoring at transaction time, meaning the risk assessment happens before the payment settles, not hours or days later in a batch process. Their system generates a risk score for each transaction and each customer interaction, which feeds into both real-time blocking decisions and downstream alert generation. For AML specifically, Feedzai's approach reduces false positives by contextualizing each transaction against the customer's full behavioral history. The company has disclosed that some clients have seen false positive reductions of 50% or more after deployment.
Hawk AI takes a hybrid approach that's particularly well-suited to mid-tier European banks. Rather than replacing a bank's existing rule-based system, Hawk layers ML models on top of traditional monitoring output. Their cloud-native platform ingests alerts from legacy systems and re-scores them, effectively triaging the queue so analysts focus on the highest-risk cases first. For institutions that can't rip out their existing monitoring infrastructure (which is most of them, given regulatory expectations around system validation), this overlay approach reduces friction. Hawk has built a strong footprint among European banks subject to the EU's Anti-Money Laundering Directives.
Sardine comes at the problem from a different angle: device intelligence and behavioral biometrics. Founded by former members of Revolut's compliance team, Sardine captures signals like typing speed, mouse movement patterns, and device fingerprints to assess whether a transaction is being initiated by the account holder or by someone else. This is more commonly associated with fraud detection, but the same signals are useful for AML. If a customer who normally logs in from a phone in Chicago suddenly initiates a large wire transfer from a desktop in a different country with different behavioral patterns, that's a signal worth investigating. Sardine's founders built the product after experiencing firsthand how thin the line is between fraud prevention and AML detection at a high-growth fintech.
Unit21 approaches the problem from the analyst's workbench. Their no-code platform lets compliance teams build, test, and deploy custom detection rules and ML models without writing code or waiting for a vendor's engineering team. This matters because AML typologies change. When criminals shift tactics, compliance teams need to adjust their detection logic quickly. Unit21's case management system also streamlines the investigation workflow, reducing the time analysts spend on each alert even when the alert volume stays constant.
Alloy focuses on the identity verification and customer due diligence (CDD) side of AML compliance. Their platform automates the enhanced due diligence (EDD) workflows that banks run when onboarding higher-risk customers. By pulling data from multiple sources and applying ML-based risk scoring at the point of onboarding, Alloy aims to catch problems before they generate transaction monitoring alerts downstream. Preventing a bad actor from opening an account in the first place is, in some ways, more effective than trying to spot their transactions later.
Chainalysis and TRM Labs address AML compliance for cryptocurrency transactions, which present a different set of challenges. Both companies provide blockchain analytics that trace the flow of funds across public ledgers. Chainalysis has become the dominant provider in this niche; its tools are used by government agencies including the IRS, FBI, and DEA, as well as by crypto exchanges meeting their BSA obligations. TRM Labs competes directly with Chainalysis, offering blockchain intelligence and transaction monitoring. As regulatory expectations around crypto AML have tightened, particularly after the collapse of FTX, both companies have seen demand grow. Their tools can identify when funds have passed through sanctioned wallets, mixing services, or darknet marketplaces. You can explore more companies working in this space in the risk and compliance directory.
What Regulators Actually Think
The single biggest concern compliance officers raise about ML-based monitoring is whether regulators will accept it. The answer, increasingly, is yes.
FinCEN issued a joint statement in 2018 with the federal banking regulators explicitly encouraging banks to consider "innovative approaches" to BSA/AML compliance, including artificial intelligence and machine learning. The statement noted that the agencies would not penalize banks for experimenting with new technologies, provided the bank maintained adequate risk management around the new tools. In 2022, FinCEN reiterated this position and specifically called out the potential for AI to improve the quality of SAR filings.
The Financial Action Task Force (FATF), which sets international AML standards, published guidance in 2021 on the use of new technologies for AML/CFT (countering the financing of terrorism). The guidance was broadly supportive, noting that ML-based monitoring could reduce false positives, improve detection of complex laundering schemes, and allow compliance resources to focus on genuine risks.
That said, regulators expect explainability. A model that flags a transaction as suspicious needs to produce a reason that an analyst can evaluate and document. "The model said so" isn't sufficient for a SAR narrative. This is where some of the more opaque deep learning approaches run into trouble. Gradient-boosted trees and logistic regression models, which are more interpretable, tend to be easier to validate and defend during an examination.
Model risk management is another concern. Banks subject to OCC guidance (SR 11-7 in the US) must validate ML models the same way they validate credit risk models. That means independent testing, ongoing monitoring for performance drift, and documented governance. Vendors that can support this validation process have an advantage over those that treat their models as black boxes.
What Compliance Teams Should Evaluate
For compliance officers considering ML-based monitoring tools, a few practical criteria matter more than marketing materials.
First, ask about false positive reduction on a like-for-like basis. Some vendors measure reduction relative to the alerts their own system generates, not relative to the bank's existing system. A 70% reduction from an already-refined baseline is very different from a 70% reduction from a poorly tuned legacy system.
Second, ask how the system handles new typologies. AML patterns evolve. A model trained on historical SARs may miss emerging laundering techniques, particularly those involving cryptocurrency, trade-based laundering, or real estate. The system should support ongoing retraining and ideally allow compliance teams to inject subject-matter expertise into the model's feature set.
Third, evaluate the investigation workflow. Alert quality is only half the problem. If analysts still spend 45 minutes per case navigating between six different screens to gather the information they need, the overall efficiency gain shrinks. Tools that combine detection with case management and SAR auto-drafting deliver more total value.
Fourth, understand the vendor's approach to model governance. Can they produce model validation documentation? Do they support challenger model testing? Can they demonstrate performance metrics (precision, recall, AUC) segmented by customer type and scenario?
Finally, be realistic about timelines. Deploying ML-based AML monitoring at a regulated institution takes 6 to 18 months, depending on the bank's size, data readiness, and regulatory relationships. Quick wins are possible with alert prioritization overlays, but full model deployment requires data integration, validation, and regulatory communication.
The false positive problem in AML won't be solved overnight. But the tools exist now to make meaningful reductions in wasted analyst time while improving detection of actual suspicious activity. For compliance teams drowning in alerts, that's not a buzzword. It's an operational improvement that's long overdue.