FRAML: Why Fraud and AML Convergence Stalled Before, and What Changed

FRAML: Why Fraud and AML Convergence Stalled Before, and What Changed

FRAML: Why Fraud and AML Convergence Stalled Before, and What Changed

FRAML is the practice of running fraud prevention and anti-money laundering as one function rather than two: shared data, shared investigators, and one decision on the same customer.

Author

Team Bureau

KYC AML regulations part two cover
KYC AML regulations part two cover
blank

See how Bureau has helped industry leaders defend against networked Industrial-scale frauds →

Schedule a Demo

TABLE OF CONTENTS

See Less

Most of the case for FRAML is settled. Criminals do not respect org charts, duplicate infrastructure is expensive, and regulators have asked for coordination for years. What that case usually leaves out is that institutions already tried this. Fraud and AML integration programs ran in the early 2000s and largely did not deliver.

Our founder and CEO, Ranjan Reddy, was asked about convergence on Liminal's Friday Five, a five-question format for people building in identity and risk. His answer covered two things the standard FRAML pitch skips. The merge is wider than two functions, and the reason the earlier attempts failed was the method rather than the idea.

FRAML Describes a Two-Way Merge. Buyers Are Facing a Four-Way One.

Financial services has organized risk into compliance, credit, and fraud. Security has usually sat outside that arrangement, with its own budget, its own leadership, and a separate conversation.

That separation is ending. Security and fraud are merging first, and once that line goes, the others follow: compliance and fraud, fraud and credit, credit and security. Underneath the org chart, all four are asking one question about identity and transaction trust.

Regulators described this shape a decade ago. FinCEN's 2016 advisory on email compromise fraud asked institutions to promote communication among their internal AML, business, fraud prevention, and cybersecurity units. Four corners, in one sentence, from the regulator.

The practical version is simpler. A synthetic identity created at onboarding is a compliance problem, a fraud problem, a credit problem, and increasingly a security problem. It is the same identity in all four cases, and most institutions will open four separate cases on it.

Why the Earlier Attempts Failed

The early programs tried to converge the stack. One system for fraud and AML meant replacing tools that already worked, running multi-year migrations, and absorbing a change-management load large enough to end the program before it produced results.

Converging the decision layer is a different exercise. The stack stays where it is. What changes is the layer above it, the one that makes and edits the decision using signals from every system underneath.

What converges

What stays in place

The decision on the customer

Core banking, payment, and ledger systems

Identity, device, and network signals across fraud, AML, credit, and security

Existing case management and monitoring tools

Investigation context and the reason behind each flag

Team structures, until the institution chooses otherwise

That distinction is the difference between a program with a path to value and a program that spends its first 18 months on migration.

The Precondition Nobody Mentions

Merging teams and dashboards inside one institution does not create new information. It reorganizes what that institution already sees, which is one slice of a customer who exists across dozens of institutions.

A mule account looks unremarkable at the bank where it opens. It looks obvious against the ten other accounts sharing its device.

That is why FRAML needs a signal layer that spans institutions. Bureau's Graph Identity Network links users across devices, emails, phone numbers, and IP addresses over a network of encrypted identities, so a decision at one institution can draw on patterns observed everywhere else.

Without that, convergence produces a shared dashboard rather than shared intelligence.

Related read: How to Detect Mule Accounts and Prevent Fraud in Real Time

The Question Worth Asking a Vendor

When a vendor says they integrate fraud and compliance, the useful question is narrow. What has to be removed for that claim to be true?

If the answer involves replacing something the team just finished implementing, that is a migration with a convergence story attached. If the answer is nothing, ask the follow-up: where does the signal come from, and does it extend past this institution's own data?

Bureau runs identity, fraud, compliance, and security decisions on one layer across the digital customer journey, on top of the systems already in place. Schedule a demo to see how it maps to your stack.

FAQs

1. What does FRAML stand for?

FRAML combines fraud and anti-money laundering into a single financial crime function, using shared data, shared investigation, and one risk decision per customer instead of two parallel programs.

2. Why did earlier fraud and AML convergence programs fail?

Most tried to converge the technology stack itself. That meant replacing working systems, running multi-year migrations, and managing organizational change on a scale that consumed the program before it delivered detection improvements.

3. Does FRAML require replacing existing fraud and AML systems?

No. Converging the decision layer leaves core systems, case management, and monitoring tools in place. What changes is the layer that assembles signals from those systems and makes the decision.

4. Where does security fit into FRAML?

FRAML as commonly defined covers fraud and AML only. In practice, account takeover, credential abuse, and synthetic identity creation cross into security, and FinCEN has asked institutions to coordinate cybersecurity units alongside AML and fraud since 2016.

5. What makes cross-institution signal necessary for FRAML?

A single institution sees one fragment of a customer's activity. Fraud rings operate across many institutions at once, so patterns such as shared devices or reused contact details only become visible when identity signals are linked beyond one organization's own data.

Most of the case for FRAML is settled. Criminals do not respect org charts, duplicate infrastructure is expensive, and regulators have asked for coordination for years. What that case usually leaves out is that institutions already tried this. Fraud and AML integration programs ran in the early 2000s and largely did not deliver.

Our founder and CEO, Ranjan Reddy, was asked about convergence on Liminal's Friday Five, a five-question format for people building in identity and risk. His answer covered two things the standard FRAML pitch skips. The merge is wider than two functions, and the reason the earlier attempts failed was the method rather than the idea.

FRAML Describes a Two-Way Merge. Buyers Are Facing a Four-Way One.

Financial services has organized risk into compliance, credit, and fraud. Security has usually sat outside that arrangement, with its own budget, its own leadership, and a separate conversation.

That separation is ending. Security and fraud are merging first, and once that line goes, the others follow: compliance and fraud, fraud and credit, credit and security. Underneath the org chart, all four are asking one question about identity and transaction trust.

Regulators described this shape a decade ago. FinCEN's 2016 advisory on email compromise fraud asked institutions to promote communication among their internal AML, business, fraud prevention, and cybersecurity units. Four corners, in one sentence, from the regulator.

The practical version is simpler. A synthetic identity created at onboarding is a compliance problem, a fraud problem, a credit problem, and increasingly a security problem. It is the same identity in all four cases, and most institutions will open four separate cases on it.

Why the Earlier Attempts Failed

The early programs tried to converge the stack. One system for fraud and AML meant replacing tools that already worked, running multi-year migrations, and absorbing a change-management load large enough to end the program before it produced results.

Converging the decision layer is a different exercise. The stack stays where it is. What changes is the layer above it, the one that makes and edits the decision using signals from every system underneath.

What converges

What stays in place

The decision on the customer

Core banking, payment, and ledger systems

Identity, device, and network signals across fraud, AML, credit, and security

Existing case management and monitoring tools

Investigation context and the reason behind each flag

Team structures, until the institution chooses otherwise

That distinction is the difference between a program with a path to value and a program that spends its first 18 months on migration.

The Precondition Nobody Mentions

Merging teams and dashboards inside one institution does not create new information. It reorganizes what that institution already sees, which is one slice of a customer who exists across dozens of institutions.

A mule account looks unremarkable at the bank where it opens. It looks obvious against the ten other accounts sharing its device.

That is why FRAML needs a signal layer that spans institutions. Bureau's Graph Identity Network links users across devices, emails, phone numbers, and IP addresses over a network of encrypted identities, so a decision at one institution can draw on patterns observed everywhere else.

Without that, convergence produces a shared dashboard rather than shared intelligence.

Related read: How to Detect Mule Accounts and Prevent Fraud in Real Time

The Question Worth Asking a Vendor

When a vendor says they integrate fraud and compliance, the useful question is narrow. What has to be removed for that claim to be true?

If the answer involves replacing something the team just finished implementing, that is a migration with a convergence story attached. If the answer is nothing, ask the follow-up: where does the signal come from, and does it extend past this institution's own data?

Bureau runs identity, fraud, compliance, and security decisions on one layer across the digital customer journey, on top of the systems already in place. Schedule a demo to see how it maps to your stack.

FAQs

1. What does FRAML stand for?

FRAML combines fraud and anti-money laundering into a single financial crime function, using shared data, shared investigation, and one risk decision per customer instead of two parallel programs.

2. Why did earlier fraud and AML convergence programs fail?

Most tried to converge the technology stack itself. That meant replacing working systems, running multi-year migrations, and managing organizational change on a scale that consumed the program before it delivered detection improvements.

3. Does FRAML require replacing existing fraud and AML systems?

No. Converging the decision layer leaves core systems, case management, and monitoring tools in place. What changes is the layer that assembles signals from those systems and makes the decision.

4. Where does security fit into FRAML?

FRAML as commonly defined covers fraud and AML only. In practice, account takeover, credential abuse, and synthetic identity creation cross into security, and FinCEN has asked institutions to coordinate cybersecurity units alongside AML and fraud since 2016.

5. What makes cross-institution signal necessary for FRAML?

A single institution sees one fragment of a customer's activity. Fraud rings operate across many institutions at once, so patterns such as shared devices or reused contact details only become visible when identity signals are linked beyond one organization's own data.

TABLE OF CONTENTS

See More

Recommended Blogs

Landing Page.

Simple, bold.

Sign Up

Download