
Where should you actually start with AI in your AML program?
It's the question I get more than any other, and there's a number that should decide it more often than it does. A sanctions screening review takes about five minutes. An enhanced due diligence review takes a few hours. A fifty-entity fraud ring takes days.
Almost everyone starts with the five-minute one.
In practice I see teams pick one of two lanes, and the choice is usually made on comfort rather than on return.
The first lane is to start with the simplest review you have, which is nearly always sanctions screening. The logic is sound on its face. You want to prove to yourself that the technology works before you bet a real workflow on it, and sanctions is genuinely the easiest place to do that. These models are trained on text, and a sanctions check is fundamentally a question about whether two pieces of text refer to the same person, so it sits right in the sweet spot of what the technology is good at with very little configuration.
The trouble is that it will work. Whether you build it yourself, work with us, or work with practically any vendor in the market, this is the one everybody can do. And because the review only took five minutes to begin with, cutting it in half saves you two and a half minutes. An AI summary makes the review a bit faster and somewhat more defensible, which is real, and it's thin.
The value in sanctions is mostly locked behind auto-clearing obvious non-matches, and that's rarely where anyone is willing to start. Most teams want a human in the loop early on for auditor defensibility, which is a reasonable instinct, and it's worth understanding how the autonomy ladder works before you decide how far up it you're willing to go. So you end up in a lane where the meaningful return arrives in phase two or phase three, and the business case has to survive until then.
The second lane is to start with the reviews that consume the most time. Enhanced due diligence, where hours of online research is the job, and a few-hour review can come back in under an hour. Escalated L2 and L3 work. A fraud ring with fifty-plus entities where you have to investigate each one, which without AI takes days and with it can take hours.
Transaction monitoring alerts sit between the two, at roughly thirty minutes to an hour per review, at much higher volume.
Starting with the complex reviews is harder, and I'd still suggest it, for two reasons.
The first is obvious once you see the arithmetic. The handle time you remove is meaningful in a way that two and a half minutes on a sanctions alert never will be, and you can capture it with the human still in the loop, so you aren't trading defensibility for return.
The second reason is that it's a much better test of the vendor. One of our more advanced customers does this deliberately. They start with the most complicated reviews they have, on the reasoning that sanctions is easy and everyone can do it, so it tells them nothing. If a system can work a fifty-entity fraud ring accurately and at scale, everything else in the program is downhill. If it can't, they've learned that in week one rather than in month nine.
That's a good instinct to borrow, and it's worth bringing to demos alongside the other questions that separate a real agent from a chatbot. Ask to see the hardest workflow you have, on your data, rather than the cleanest one on theirs.
Here's the part that surprises people, and it has very little to do with which lane you picked.
The hardest thing about deploying AI agents is almost never the technology. It's that your process isn't written down as precisely as you believe it is.
One of my favourite phrases is that buyers are liars, and I don't mean that unkindly. It shows up everywhere, in this industry and in the rest of life, and it's rarely deliberate. People describe the process they think they follow, and the real one has drifted somewhere else.
So a team tells us to make the agent do exactly this. We help them configure it, and more importantly we make sure they can configure it themselves. Then they see the output and say, "oh, actually I meant this."
The reason is usually that someone like Steve works a case differently than someone like Jane. Both are good analysts, both close the case, and the steps in between aren't the same. Nobody noticed, because nobody had ever needed to write those steps down at that resolution. An agent needs a tight process to follow, so it surfaces the variance immediately, and what you're really looking at in that first round of output is a mirror.
I've come to think of that moment as the actual beginning of the deployment rather than a setback in it. It's also the strongest argument I know for making sure your own team can adjust the tasks. If every "actually, I meant this" costs a support ticket and a release cycle, you'll stop having the thought. If your compliance team can change it the same afternoon, the system converges on how you really work within a few iterations.
There's one more thing, and it's the one I'd most want people to take away, because almost nobody raises it on their own.
Everyone gravitates toward investigations. Given a pile of alerts, the instinct is to find a way through the pile faster. Far fewer people ask why the pile is that size to begin with.
False positive rates in AML still sit at roughly 90%. That's the number underneath everything else in this post. If nine out of every ten alerts your team works are noise, then the ceiling on investigation speed is not where your leverage is.
Tuning detection logic is where it is, and the reason it doesn't happen isn't ignorance. It's that it's genuinely hard. We shipped backtesting for transaction monitoring about eight years ago, and the premise was simple: if you know what you want to change, test it against your own historical data and show an auditor that the new rule version cuts alert volume without missing escalations. That part works.
The hard part is knowing what to tune. A mature program can have hundreds of rules running. You have to go and ask the analysts, form some theories, then backtest each one, and in practice this happens annually if it happens at all. Plenty of institutions outsource it to a firm for meaningful money.
What we've invested heavily in is doing that automatically, by learning from what people already write when they escalate or close something out. The disposition notes your analysts have been producing for years are an enormous record of why alerts were wrong, sitting in text, which is exactly the form this technology reads best. Pair that with backtesting you already trust, and rule tuning stops being an annual project.
It also changes the economics. If you only ever point AI at investigations, you're paying to process the same noise forever. Reduce the noise at the source and everything downstream gets cheaper, which is the difference between a program that scales and one that just runs faster in place.
Pick one high-handle-time workflow rather than the easiest one. Keep the human in the loop while you build an accuracy record. Expect the first round of output to reveal that your process was never as documented as you thought, and treat that as progress. Then, once investigations are working, turn the same attention upstream to the detection logic generating the queue.
The question I keep coming back to with teams is this one: are you trying to get through your alerts faster, or trying to have fewer alerts that were never worth working? Most programs only ever plan for the first.
Where should you start with AI in an AML program?
Start with a workflow where reviews take a long time, such as enhanced due diligence or escalated L2 and L3 investigations, rather than the simplest workflow you have. The handle time you remove is far larger, you can capture it with a human still reviewing every decision, and it's a more honest test of whether a system works.
Why is sanctions screening a weak place to start?
A sanctions review typically takes around five minutes, so even a large percentage improvement saves only a couple of minutes per alert. It's the easiest use case to deploy and nearly any vendor can do it, which means it proves less than teams expect. Most of the value arrives only once you're comfortable auto-clearing obvious non-matches, and that usually isn't phase one.
What's the most common reason AI deployments stall in compliance?
Undocumented process. Teams describe the workflow they believe they follow, then the agent's first output reveals that different analysts work the same case differently. An agent needs a precise process to follow, so it exposes that variance immediately. Teams that can reconfigure tasks themselves resolve it in days rather than release cycles.
How much time can AI save on a complex investigation?
It depends on the workflow. An enhanced due diligence review that takes a few hours can come back in under an hour, and a large fraud ring spanning fifty or more entities that would take days to work manually can be completed in hours, with an analyst still reviewing the result.
Should AI be used on detection as well as investigation?
Yes, and it's the step most programs skip. False positive rates in AML sit around 90%, so speeding up investigations raises the ceiling on a queue that shouldn't be that large. Using analyst disposition notes to learn which rules are misfiring, then backtesting proposed changes against historical data, reduces the alert volume at source.

Tyler Allen is the CEO of Unit21 and was the company’s first hire, writing some of the first lines of code seven years ago. He previously led Unit21’s AI team as Head of AI, then served as COO, before stepping into the CEO role. He is a driving force behind Unit21’s vision as the leader in AI risk infrastructure, having led the AI team before becoming COO. A deep technical leader, Tyler recently returned to the codebase to personally build AI agent configurations, pairing his technical expertise with seven years of experience observing how compliance teams operate.