Why Fraud Frameworks Must Converge: The 18-Month Landscape

The Landscape Nobody Has Fully Mapped

Between 2024 and April 2026, at least five separate fraud frameworks emerged, each seeking to provide fraud, cybersecurity, risk, and intelligence teams with a shared language for describing, detecting, and disrupting financial fraud.

This development matters because it signals the need for unified action in organizing and defining fraud defense.

This indicates the problem is substantive. Fraud is a global economic drag, with some estimates totaling $4.4T per year. Across financial services, retail, payments, mobile threat intelligence, and cyber threat-informed defense, various groups reached the same conclusion: “fraud” is too broad a term to be operationally useful.

An account takeover, card testing, a mule account network, a spear-phishing campaign, a key leak, and a laundering operation may all be reported as “fraud.” But they are not the same problem. They do not follow the same attack path. They do not require the same controls. And they cannot be consistently detected, investigated, or disrupted if the industry lacks a shared behavioral model for describing what actually happened.

FT3 was developed specifically to address this gap.

The broader industry has also independently validated this gap.

The industry's central question is now clear: will it continue building parallel frameworks or move toward a unified, converged model for fraud response?

The Timeline

Before comparing these approaches, it is useful to examine their chronological sequence.

This represents a substantial volume of framework development within approximately eighteen months.

This trend reflects both fragmentation and validation: multiple institutions, sectors, and practitioner communities examined the fraud landscape and concluded that existing terminology was insufficient.

The industry, despite differing starting points, sought a common objective: transforming fraud from a generic label into a structured behavioral model.

FT3 — Stripe

FT3 was built at Stripe because the term “fraud” lacked sufficient operational detail. Security teams had MITRE ATT&CK to describe cyber intrusions with precision. Fraud teams lacked an equivalent model to consistently describe the tools, tactics, techniques, procedures, indicators, mitigations, detections, and response patterns associated with fraud activity.

FT3 adapted the ATT&CK-style matrix directly to fraud. It was designed to let analysts and engineers describe a fraud incident end-to-end, from initial research and resource development through manipulation, cash-out, laundering, impact, and evidence destruction.

FT3 was open-sourced under the MIT license, with a contributing guide, code of conduct, and an explicit invitation for community input.

Its twelve tactics are:

• Reconnaissance
• Resource Development
• Initial Access
• Execution
• Defense Evasion & Obfuscation
• Lateral Movement & Internal Proliferation
• Manipulation & Fraudulent Transactions
• Command and Control
• Collection & Exfiltration
• Financial Evasion, Laundering & Cash-Out
• Impact & Disruption
• Obfuscation and Destruction of Evidence

The comprehensive scope of FT3 is significant.

FT3 was not only a fraud-loss classification model. It was built to describe adversarial behavior across the full lifecycle of a fraud campaign. That made it useful not only for fraud analysts but also for security engineers, threat intelligence teams, detection engineers, fraud engines, and law enforcement partners.

The core premise is that as fraud becomes more technical, organized, and adversarial, fraud defense requires a behavioral framework with the same level of precision that cybersecurity teams expect from ATT&CK.

CFPF — FS-ISAC

FS-ISAC’s Cyber Fraud Prevention Framework approached the problem from a different angle.

Inside financial institutions, fraud and cybersecurity teams often see different parts of the same attack. Cybersecurity may see a phishing campaign or a credential compromise. Fraud teams may detect unauthorized transactions or account manipulation. Without a shared lifecycle, those teams can struggle to connect activity across phases.

CFPF was designed to address that coordination problem.

Its five phases are:

• Reconnaissance
• Initial Access
• Positioning
• Execution
• Monetization

This is a process-oriented model. It helps teams understand where they are in the attack lifecycle and where to look left or right across organizational boundaries. That makes it useful for large financial institutions trying to improve cross-functional investigation and response.

CFPF is less detailed than FT3 by design. It values accessibility and sequence over mapping detailed techniques.

This represents a valid design choice and illustrates the importance of convergence. A high-level lifecycle model and a detailed technique matrix are not mutually exclusive; they can be mapped to one another.

Fraud Kill Chain — ThreatFabric + Barclays

The Fraud Kill Chain approached the problem through the lens of economic crime and fraud operations.

Its creators argued that existing cyber frameworks were built primarily for network intrusion and did not sufficiently capture the full fraud lifecycle, especially the human-behavioral and post-fraud laundering stages.

The Fraud Kill Chain shows its value by emphasizing areas that are often under-modeled in cyber-first frameworks: psychological manipulation, faux communications, account access, authorization compromise, monetization, and money laundering.

It also reflects an important reality in fraud: many fraud campaigns are not simply technical compromises. They are socio-technical operations. They involve infrastructure, identity, persuasion, account control, payment rails, laundering pathways, and human behavior.

This contribution warrants recognition.

However, the Fraud Kill Chain also exposes the risk of parallel models. When groups define overlapping stages with different names, practitioners must reconcile the models.

RH-ISAC, Target, and NRF

The RH-ISAC and NRF work is the most clearly sector-specific.

Retail and hospitality face fraud patterns that do not always map cleanly onto banking-centric models. Gift card tampering, refund abuse, loyalty fraud, supply-chain compromise, and hybrid physical/digital fraud require their own operational language.

The Fraud Intelligence Sharing Playbook and NRF Retail Fraud Taxonomy were built to help that community collect, analyze, and share fraud intelligence more effectively.

The retail taxonomy includes four broad phases:

• Pre-compromise
• Initial Access
• Control
• Monetization

This approach works because it fits the retail fraud landscape. It reinforces a central point: every sector is solving the same underlying issue from its own perspective.

This approach is understandable. Yet, without interoperability, sector-specific clarity can lead to fragmentation at the ecosystem level.

F3 — MITRE Fight Fraud Framework

What distinguishes the Fight Fraud Framework is not the framework itself, but rather the institutional gravitas and authority MITRE brings to the effort.

It brings the authority of MITRE CTID, the familiarity of ATT&CK methodology, STIX 2.1 compatibility, and a large contributor base across financial services, cybersecurity, retail, and risk.

F3’s seven tactics are:

• Reconnaissance
• Resource Development
• Initial Access
• Defense Evasion
• Positioning
• Execution
• Monetization

The most important contribution of F3 is interoperability. By aligning fraud behaviors with ATT&CK-style methodology and machine-readable formats, F3 enables organizations already operating in ATT&CK-based environments to integrate fraud into existing intelligence, detection, and response workflows.

This interoperability is valuable.

F3 will be an important reference for groups using ATT&CK, OpenCTI, STIX/TAXII, and threat-informed defense.

But F3 also confirms the broader pattern. The industry continues to converge on the same concepts: reconnaissance, initial access, positioning or manipulation, execution, monetization, and fraud-specific adversary behavior.

No single institution created those concepts. They are emerging because practitioners across the ecosystem are observing the same reality.

The Structural Pattern

A side-by-side comparison of these frameworks reveals clear patterns.

First, the problem is broadly validated. Fraud teams, cyber teams, retailers, banks, vendors, and threat-informed defense communities all identified the same need: fraud requires a shared behavioral model.

Second, the frameworks differ in level of abstraction. Some are lifecycle models. Some are taxonomies. Some are ATT&CK-style matrices. Some are sector playbooks. These differences are not inherently bad. They reflect different operating needs.

Third, the overlap is significant. Most models include some version of reconnaissance, access, manipulation, positioning, execution, and monetization. Some go further into laundering, lateral movement, exfiltration, impact, or evidence destruction.

Now, practitioners—analysts, detection engineers, CTI teams, fraud strategists, and platform builders—must relate these models. Integration should not fall solely to them.

The industry has accomplished the first step: recognizing the gap.

The next, more challenging step is convergence.

Why Convergence Matters

Framework fragmentation has real costs.

It makes it harder to compare incidents across organizations. It complicates intelligence sharing. It slows tooling integration. It creates duplicative mapping work. It forces practitioners to translate between models that often describe similar behaviors with different names.

It is not necessary to eliminate every framework within the fraud community.

However, these frameworks need to interoperate.

A high-level financial services lifecycle can coexist with a detailed ATT&CK-style technique matrix. A retail-specific taxonomy can map to common fraud tactics. A fraud kill chain can contribute to human behavioral and money laundering details. A MITRE-aligned framework can help standardize machine-readable integration. FT3 can continue serving as an open, practitioner-built contribution surface.

The goal is not framework supremacy. The goal is operational interoperability.

That means reducing the translation burden on practitioners and making these models usable together inside the workflows where fraud defense actually happens.

The Next Phase Should Be Convergence

The subsequent phase of fraud-framework development should prioritize practical outcomes over symbolic actions.

The field does not need another framework launch simply to prove that fraud needs a shared language. That point has been made. The emergence of multiple frameworks in eighteen months is evidence that the need is real, urgent, and broadly understood.

The more important question now is whether these efforts can be more useful together than apart.

Each framework reflects a different operating need. Lifecycle models help institutions organize teams and investigations. Technique matrices help analysts, engineers, and detection teams describe behavior with precision. Sector taxonomies capture domain-specific fraud patterns that broader models may miss. Machine-readable formats help move structured intelligence into tools and workflows.

These approaches do not need to compete with one another.

A mature fraud-defense ecosystem should retain the strengths of each model while minimizing the translation burden on practitioners. Collaboration among fraud, security, intelligence, engineering, and law enforcement teams should be facilitated without necessitating debate over the authority of the framework.

FT3 plays a critical role in this context.

FT3 was built early because the gap was visible from the start. It was built openly because fraud defense needs more than static documents and branded launches. It needs models that practitioners can inspect, test, extend, and operationalize.

That does not mean FT3 should be the only framework.

However, FT3 should be included in discussions regarding convergence.

The industry has now independently validated the problem FT3 was built to solve. The responsible next step is not continued proliferation. It is a more interoperable, practitioner-centered fraud-defense ecosystem.

The objective should not be to identify a single dominant framework.

The objective should be to enhance the usability, durability, and operational relevance of these frameworks for teams actively combating fraud.

The subsequent phase should not involve further proliferation of frameworks.

The next phase should focus on convergence.