FRAML: Unify Fraud and AML Without Blurring Accountability

Last updated: September 2026

Fraud and AML teams look at the same customers, the same accounts and the same transactions, and for most of the last decade they did it from separate rooms with separate tooling. Closing that gap is one of the clearer wins available to a financial crime function. But "unified" is doing a lot of work in most conversations about it, and the version that goes wrong is the version nobody defined.

The short answer: unify the signal layer, not the accountability.

TL;DR

• FRAML means treating fraud and anti-money laundering as one problem space — but the term covers three different things, and they are not one decision.

• Fraud and AML share the customer, the behaviour and the underlying signals, so the case for a shared data layer is strong.

• They do not share the obligation, the supervisory expectation, the timeline or the standard of proof.

• Unify data. Largely unify detection, with separate labels and separate validation. Do not merge decisions and accountability.

• The failure mode is a merged queue: compliance work ends up managed on fraud's throughput metrics, because that is what the dashboard shows.

• Stage it data first, detection second, operating model last — and only ever for a reason beyond efficiency.

What is FRAML?

FRAML is the practice of treating fraud and anti-money laundering as one problem space rather than two, on the grounds that both track illegitimate activity moving through the same customers and the same transactions. In practice the term covers three different things: shared data, shared detection, or a merged team.

Those three are not the same decision, and the rest of this piece depends on holding them apart.

Why fraud and AML are converging now

The convergence is not a vendor coinage. It is an industry-wide push, and it has two concrete drivers.

The first is that the typologies have merged in practice. A mule account is a fraud problem and a laundering problem at the same time, in the same transaction — the funds are obtained by deceiving someone and then moved to obscure where they came from. Treating those as two investigations of two different things means two teams reconstructing the same story from half the evidence each.

The second is timing. Real-time payments compressed the window. A review that used to happen comfortably after settlement now has to happen at the point of transaction or not at all. In a conversation about exactly this, a global bank described the movement as combining fraud and AML screening at the same point in time — the point of transaction — rather than as two sequential reviews. That simultaneity is the mechanism. Once both questions have to be answered in the same moment, two separate views of the customer stop being an inefficiency and start being a constraint.

This is also a live programme category rather than an aspiration. Institutions refer to their own FRAML efforts as named internal programmes with budgets and trajectories, and reorganise their financial crime functions around them.

What fraud and AML genuinely share

It is worth being plain about how strong the case for convergence is, because the caution later in this piece is not an argument against it.

They share the subject. The same customer, the same account, the same behaviour, observed by two functions that historically could not see each other's view of it.

They share the raw material. Device, identity, network, velocity, counterparty — the signals that tell a fraud model something useful are largely the signals that tell a monitoring system something useful, and neither function generates them separately. The same evidence base sits under screening a payment in real time and under deciding whether that payment belongs in a pattern worth reporting.

And they share the analytical problem: separating unusual from illegitimate. That is why detection techniques genuinely transfer between the two domains, and why a team that has built good feature infrastructure on one side is rarely starting from zero on the other.

So the case for a shared data layer is not a compromise position. It is the strongest argument in the whole debate, and most of the value in a FRAML programme is sitting in it.

What they do not share

Here is the part the enthusiasm tends to skip.

The obligation is different in kind. A fraud loss is the institution's own money, and the institution decides how much of it to accept. Money laundering detection is a reporting duty — an obligation owed outward, about someone else's conduct, discharged by telling an authority what you saw. One is a commercial decision about your own balance sheet. The other is an accountability to a third party.

The examination is different. Different supervisory expectations attach to each, so the record a reviewer will ask for looks different too.

The timeline is different. A fraud decision is made in milliseconds, at machine speed, and is usually reversible — you can release a held transaction or reverse a block. A filing decision runs on a slower clock and is not reversible in the same way.

The standard of proof is different. Fraud decisioning acts on probability and deliberately accepts error in both directions, because the cost of each error is known and can be tuned. A filing decision is a considered judgement that has to carry a documented rationale a person can stand behind later.

Notice that the consequence of confusing the two runs in one direction. An AML-grade standard applied to fraud decisioning is slow and expensive. A fraud process quietly absorbing a filing decision is a control failure, not an efficiency.

The three layers people mean by "unified"

Buyers arrive at this already half-aware of the ambiguity. In one recent evaluation, a consumer financial services firm framed its own process as a three-way question — were they looking at an AML solution, a fraud solution or a FRAML solution — and then immediately asked a sharper one: to what extent did they actually want to combine the reviews being processed on each side?

The second question is the real one, and it resolves into three layers.

Layer one, data. Unify it. There is no good argument for two views of the same customer. Most of the value is here, the governance risk is close to zero, and the move is reversible.

Layer two, models and detection. Largely unify. Shared features and shared signals genuinely transfer, with one caveat that has to be handled rather than assumed away: the label populations are different. A model trained on confirmed fraud outcomes is not automatically a monitoring model, because "confirmed fraud" and "filed as suspicious" are not the same event, and the second is far rarer and far more human-mediated. Shared infrastructure, yes. Shared labels, no.

Layer three, decisions and accountability. Do not merge. This is where the obligations diverge, and merging here is what produces governance confusion.

Most of the disappointment with FRAML programmes comes from treating those three as one decision, agreeing to it in principle, and finding out at layer three what was actually signed up for.

Where naive consolidation breaks

The failure has a recognisable moment. In a workshop on a unified workflow, a US payments company reached it live: because the model has fraud investigators also looking at cases from an AML point of view, the destination of the work becomes a suspicious activity report — and then nobody in the room could say what the workflow should be.

That question is the whole problem compressed into one sentence. A fraud investigator arriving at a filing decision is a governance question, not a routing question, and no amount of workflow design answers it.

Three things break specifically:

• Who owns the filing. A merged queue implies a merged owner, and the filing decision is precisely the one that has to have a named owner.

• What happens to a case that is both. A chargeback candidate that is also a filing candidate has two outcomes, and a single case object with a single resolution field forces someone to pick one.

• Whose metrics the merged team is managed on. This one is the quiet killer. Merge the queue and the compliance work will be managed on fraud's throughput metrics, because throughput is what the dashboard shows. Nobody decides this. It just happens, and it happens quietly, which is what makes it dangerous.

What unified looks like when accountability stays separate

The resolution is not "go back to two teams." It is one customer view with two decision owners.

The shared layer is what both functions see. The decision rights stay with the function that carries the obligation. A case that is genuinely both gets handled twice on purpose, with each function reaching its own conclusion on the shared evidence rather than inheriting the other's — which is the opposite of duplicated work, because the expensive part of an investigation is assembling the evidence, not reading it.

What makes that practical rather than bureaucratic is the record. A full audit trail per decision with stored reasoning, human-in-the-loop by design, designed to fit SR 11-7, lets each function see how the other reached its conclusion without being bound by it. The fraud team's reasoning becomes evidence for the compliance analyst rather than a verdict handed to them.

The tooling underneath can be entirely shared. A unified platform — real-time data fabric, device and behavior intelligence, rules, and case management in one stack, with agents native to it — is a shared signal and tooling layer. It is not a merged decision, and it should not be sold to the reader's board as one.

The practical difference between a converged programme and a blurred one comes down to this: in the first, handoffs between fraud and compliance are designed, named and recorded. In the second, they are implied.

How to stage the move

Sequence matters more than speed here, because the layers differ in how easily they can be undone.

1. Data first. Highest value, lowest governance risk, and reversible. If a programme does nothing else, this justifies it. The onboarding decision is often the cleanest place to start, because the signals gathered at account opening are the same ones both functions will want on every transaction that follows.

2. Then shared detection, with the label caveat handled explicitly rather than assumed away. Shared features and shared tooling; separate targets and separate validation.

3. Then, and only if there is a reason beyond efficiency, the operating model. Write down who owns which decision before changing anything about who sits where.

One test applies at every step. If an examiner asked who made this decision and on what basis, is the answer still a single name and a recorded rationale? While it is, you are unifying the signal layer. When it stops being, you have started merging accountability, and you should be able to say why.

If the shared-data step is the one you are planning now, it is worth working through what a consolidated detection stack actually has to do before scoping it.

A related question — how far shared context actually reduces false positives, and what it takes to get there without raising fraud loss — deserves its own treatment. So does the choice between rules and models inside layer two, which is the same argument at a lower altitude.

Frequently asked questions

What does FRAML stand for?

FRAML is a contraction of fraud and AML — anti-money laundering. It refers to treating the two as one problem space, on shared data and often shared tooling, rather than as two separate functions with separate views of the same customer.

What is the difference between fraud and AML?

Fraud is about the institution's own loss: someone takes money that is not theirs, and the institution decides how much of that risk to absorb. AML is a reporting duty owed outward, about someone else's conduct. That difference in obligation drives everything else — different supervisory expectations, different timelines, and a different standard of proof behind each decision.

Who files the suspicious activity report under a unified fraud and AML model?

Structurally, the filing stays with the function that carries the reporting obligation, whatever the shared tooling underneath looks like. Unifying data and detection does not transfer the duty, and a case surfaced by a fraud model still reaches a filing decision through the compliance function's own judgement and record. Confirm the specific requirements that apply to your institution with your compliance counsel.

Does combining fraud and AML reduce false positives?

At the data layer, usually yes — more context per decision means fewer alerts raised on behaviour that another system could already explain. Merging queues does not produce that effect and can hide it, because a combined alert count obscures which side the noise is actually coming from. The gain comes from shared signal, not shared staffing.

What should a bank unify first?

Data. One view of the customer, the account and the transaction, available to both functions. It carries most of the value, almost none of the governance risk, and it can be undone if it does not work. Everything else in a FRAML programme is easier to evaluate once both sides are looking at the same picture.