Why not just use Claude for financial crime investigations?

‍

I get this question a lot. Some version of: I can go into Claude, create my own agent, point it at my alerts, and skip the vendor entirely. Why wouldn't I?

‍

Before I answer it, I want to concede more of it than you might expect.

‍

I think the future of software is the agent interface. The user interface is not going to be a UI for much longer. I notice this in my own working day already. Instead of opening my Gmail client, I go to Claude to check my email. Instead of opening Slack, I go to Claude to read certain messages. Instead of opening my analytics tools, I ask Claude to do the analysis. I am writing this in August 2026, and it is entirely possible that a year from now this prediction looks either obvious or wrong. But that is how I work today, and it applies to Unit21 as much as anything else. If the interface is where you think our value sits, then yes, that value is going away, and we are building toward that future ourselves.

‍

So the question deserves a real answer rather than a defensive one. If the interface is not the thing, what is left to build?

‍

Five things. Consider how each of them would look if you sat down to do it yourself.

‍

A note on scope before I start. This is about the AI question specifically. If what you are actually weighing is whether to build or buy compliance software in general, we wrote up a decision framework for build versus buy that covers the staffing and cost side of it, and that is the better place to start. And if your objection is really about platform migration rather than capability, the short answer is that you can use our agents through the API without moving anything else. I come back to that at the end.

‍

‍

First, the knowledge inside the agent

Claude is not built for anti-money laundering or risk operations. Neither is any other general-purpose model. That is not a criticism of them. They are built to be good at a very wide range of tasks, and they are.

‍

They show up in the detail of the work: what a structuring pattern looks like across rails, which typologies your examiner cares about, what a transaction monitoring rule has to produce for an alert to be worth an analyst's time. What we have done is build a lot of financial crime knowledge into our agents, along with FinCEN guidance, other regulatory guidance, and past enforcement actions. The result is an agent that is more intelligent about financial crime and risk than a raw model, because it knows the shape of the work before you ask it anything.

‍

Can you do this yourself? Yes. This is the part of the list that is genuinely buildable. You would be assembling and maintaining a body of regulatory and typology knowledge, keeping it current as guidance changes, and getting it into the agent in a form it can actually use. Notice what kind of project this actually is. It is mostly subject matter expertise with some engineering attached, and the people who can do it well are usually the same people you need investigating cases.

‍

Second, eval sets, which is where most build plans end

This is the part I would push hardest on, because it is the part people discover eighteen months in.

‍

An eval set is a way to prove the quality of what you have built. In practice it is a set of records where each one says: this is the prompt I gave, this is the response I got, and this is the response I expected. Then you judge them. This one, correct? Yes. Next one, correct? No. Next one, correct? Yes. You score the whole set, and you end up with a number. Seventy percent on the AML eval. Ninety percent. Fifty percent. Whatever it turns out to be.

‍

That number is the only honest answer to "does it work." Without it you have a demo and a feeling.

‍

So, practically speaking, if you are using a general-purpose model to do this, do you have your own eval set? Perhaps you do. Perhaps you have gathered and curated a set of data from your own institution over time, and you are testing every single skill in your agent against it before it touches a real case. I can tell you that most people do not do this. And it is understandable, because it is hard to do.

‍

But there is a second problem underneath the first one, and it is the more serious of the two. Your institution's data may simply not be sufficient to build an eval set from. You have your own history, your own product, your own customers, your own rails. That is a narrow slice. It tells you how your team handled the cases your team happened to see.

‍

This is where having built software for human investigators for the last eight years turns out to matter in a way we did not fully plan for. We have collected a great deal of data on what actual human investigations look like, across different processes and different industries. So our evaluation sets can be quite robust. Whatever process you run, whatever industry you are in, whatever rails you are looking at, we can quality test against them.

‍

Notice that this advantage came from years of watching people work, and not from anything we engineered. Advantages of that kind cannot be closed by hiring well.

‍

Third, the model you pick is not the model you keep

Consider what happens after you choose a model. You have that one model, and you are more or less locked into it. Perhaps you switch every now and then. If you are working in something like Cursor you can move between models fairly freely. But every model has its own qualities, and there are public benchmarks that tell you how good a given model is at a given type of task.

‍

For example. Earlier this year we were using Claude Sonnet, one of the earlier 4-point-something releases, for our document analysis task. It was working well. Then Mistral, a French company, released a new model that was considerably better on the benchmarks that matter for document analysis, optical character recognition in particular. So we swapped it out in the background. Nobody using the product had to do anything.

‍

You can run everything on a single model. But then you are not optimizing for quality per task, and you are not optimizing for cost either. What we have built underneath is a multi-model architecture that routes each task to the best model for that task, while we monitor the benchmarks as new models come out.

‍

If you build this yourself, that monitoring and re-testing is your job, permanently. Every time a provider retires a model, and they do, it lands on your roadmap. This is the line item I never see in a build plan.

‍

And the objection underneath all of this

Everything above assumes you get past a more basic problem, which is that language models are probabilistic and financial crime decisions have to be defensible. An investigator can be asked to explain a decision two years later. A model that produces a slightly different answer each time you run it is not much use in that conversation.

‍

This is worth being precise about, because it is where the engineering actually goes.

‍

We run our agents at temperature zero, so the same inputs produce the same output. We ask for structured outputs rather than free text, so a decision comes back in fields we can check rather than a paragraph someone has to interpret. And where a number matters, the agent does not read raw data and estimate. It generates code, and the code fetches the figure. The model does the reasoning, and the code does the arithmetic. That single split removes an entire category of error, and it is the thing I would point to first if someone asked how any of this is defensible.

‍

It is also worth saying what is not happening. There are no machine learning models here and no model risk scores. There is a rules engine and there are agents powered by language models. We do not train models on customer data.

‍

The exam is the real specification

Consider what an examiner actually asks for. Not the decision. The reasoning behind the decision.

‍

That distinction is easy to miss when you scope a build, because a system that records outcomes looks finished. You have the alert, the disposition, the timestamp, the analyst. It reads like a complete record right up until someone asks why. A work log that captures how a conclusion was reached, in a form an examiner will accept, is a different piece of software from a log that captures what was concluded.

‍

And narratives have to come out in the format your examiner expects, which is not the format that reads best internally.

‍

One thing I want to be straightforward about, because it cuts against my own argument: accountability does not transfer to a vendor. If you buy this from us, you are still the one in the examination. What you are buying is a system built so that conversation goes well. Our rule internally is that if something is not defensible to a regulator, we do not ship it. But the person in the room is always you.

‍

When building actually makes sense

I want to be fair about this, because the honest answer is not always "buy."

‍

If you have a real AI or machine learning team, and your workflow is genuinely unusual in a way that no vendor is going to serve well, then building some of this yourself can be the right call. That is a real situation and I have seen it.

‍

What I would ask before you commit:

• Where is your eval set coming from, specifically? I do not mean the plan to build one, I mean the data it will be built from.
• Who owns keeping the regulatory knowledge current, and is that person already fully booked investigating cases?
• What happens when your model provider deprecates the model you built on?
• Can you show an examiner how a decision was reached, not just what the decision was?

‍

If those four have real answers, build it.

‍

And if the reason you were considering building was that you did not want to move your whole stack onto someone else's platform, that is a fair objection with an easier answer than building. You can call our agents directly through the API and leave the rest of your stack exactly where it is. Your case management, your rules, your queues, all of it stays put.

‍

If you want to test any of this

The four questions above work as well on us as they do on an internal build, and I would rather you ask them.

‍

So bring your own alerts. Ask what the eval score is on the process you actually run, ask to see the work log behind a decision, and ask what happens when the underlying model gets deprecated. If the answers are vague, that tells you something, whoever you are asking.

‍

Book a demo and we will run it against your queue.

‍