FT3 2.0: A Multi Dimensional Fraud Taxonomy

When a framework collapses complex behaviors into a single cell, as seen in FT3 1.0, MITRE F3, or the Payment Fraud Kill Chain, critical nuances are inevitably lost or overlooked.

A legitimate credential redirects a payment beyond its intended scope. Is this account compromise, authorization abuse, or payment fraud?

All three descriptions may apply, but a flat taxonomy still requires the analyst to select only one.

This choice has significant consequences. It affects which detection covers the behavior, which control is deemed relevant, how incidents are mapped to other frameworks, and what machines can later infer. When one label must represent multiple independent facts, some information is lost.

FT3 2.0 restructures the model, representing fraud behavior through three distinct coordinates:

• the behavior's position in the fraud lifecycle;
• the actor or entity authorized to act; and
• the object, system, instrument, or authority that was abused.

What FT3 1.0 Proved#

When I built FT3 1.0, I anchored it in design principles established by the Cyber Kill Chain and MITRE ATT&CK. That was the right starting point. Kill-chain thinking gave defenders a way to reason across an adversary lifecycle. ATT&CK supplied the tactics-and-techniques discipline: tactics describe why an adversary acts; techniques describe how.^[2][1]

FT3 applied that rigor to fraud. The public catalog represented 137 technique records across 12 tactics and gave fraud, cybersecurity, threat-intelligence, detection-engineering, and attacker-engineering teams a common behavioral language.^[3]

FT3 1.0 began to explain the path and revealed where the inherited structure no longer fit the problem.

Seven inherited fields were unused across all 137 technique records. While one empty field could suggest incomplete enrichment, seven consistently empty fields indicate a structural issue: fraud is not organized around host access, operating-system privilege, or a single technical objective. Instead, it moves through identities, accounts, sessions, authorizations, payment instruments, platforms, business processes, human decisions, and value-transfer systems.

FT3 1.0 was designed primarily for analysts. FT3 2.0 must serve both analysts and agents. While people can infer missing context from prose, machines can only process what the model explicitly records.

One Cell Was Carrying Too Much Meaning#

Return to the redirected payment.

Its position in the fraud lifecycle is one fact. Whether the actor was unauthorized, the legitimate user was deceived, or a software agent exceeded its authority is another. Whether the behavior targeted an account, payment instrument, business process, human decision, or delegated mandate is a third.

Those facts are related. They are not interchangeable.

In a flat model, the analyst faces two poor options: split the same underlying behavior into several near-duplicates to accommodate each context, or collapse distinct contexts into one broad technique and rely on prose to capture differences. The first approach inflates the catalog; the second inflates confidence.

A control that stops an unauthorized actor may not prevent a deceived user from initiating the same payment. A rule that detects instrument theft may overlook a valid agent exceeding its mandate. If both events are mapped to one cell, a coverage dashboard may appear complete while the authorization boundary remains untested.

The matrix didn't disappear. It became a view#

FT3 2.0 distinguishes the properties that FT3 1.0 previously combined. The first coordinate is the tactic, indicating where the behavior occurs in the campaign lifecycle. The second is authorization state, identifying who or what was authorized to act. The third is abuse family, specifying the object, system, instrument, or authority that was abused.

Each coordinate can change without forcing the others to change. The same behavior can retain its lifecycle position while its authorization state differs. The same authorization state can appear throughout multiple abuse families. The model keeps the combination, rather than inventing a new technique for every product, channel, or situation.

FT3 2.0 is the first of its kind: an industry-available, multidimensional fraud framework that combines lifecycle position, authorization state, and abuse family as independently assignable coordinates within a machine-readable operating model connecting behavior to data, analytics, detection strategies, and controls.^[4]

While legacy structures incorporated fragments of this design, a review of discoverable public and industry-available models found no earlier taxonomy that resolved fraud on these three axes.^[4]

Delivered as a STIX 2.1 bundle comprising 3,787 objects, the community release spans 14 tactics containing 215 techniques and sub-techniques (261 records, 46 revoked). Every technique maps across seven abuse families and five authorization states. STIX is fundamental here because it formats intelligence into structured objects with explicit linkages, moving beyond static pages that require human reinterpretation.^[5]

The FT3 2.0 release includes 119 analytics, 105 detection strategies, 81 data components, and 69 controls, all interconnected through 3,113 explicit relationships.

The technique is no longer an isolated record. A defender can move from behavior to the data required to observe it, the analytic that evaluates it, the detection strategy that organizes coverage, and the control that can interrupt it. That is the difference between a catalog and an operating layer.

The familiar matrix can still be generated from the model. It is now a view over the knowledge, not the container for it.

Authorization Becomes Part of the Behavior#

Fraud models have often treated authorization as binary: the action was authorized or it was not.

That was already incomplete. A victim can be deceived into initiating a payment. A legitimate user can abuse granted access. A synthetic identity can accumulate apparently valid authority. Agentic systems make the gap impossible to ignore.

A software agent may be legitimate. Its credential may be valid. Its authority may still be limited due to purpose, amount, merchant, workflow, duration, or user intent. The resulting action can pass authentication and still exceed the mandate that made the action permissible.

The question is no longer only, “Was the action authorized?” It is: “Who or what was authorized, what authority was granted, and did the action remain within that authority?”

Lifecycle position cannot answer that question. Neither can the abuse family. Authorization must remain a first-class property of the behavior.

I described the protocol-level version of this problem in Agentic Commerce Changes the Object of Fraud: delegated authority is now a concrete, attackable object, not a hypothetical future concern.^[6] FT3 2.0 does not bolt agentic support onto a legacy matrix. Its structure can distinguish a compromised human account, an abused session, a manipulated mandate, an over-scoped delegation, and an action that was technically authorized but behaviorally abusive.

A Taxonomy Must Measure Itself#

Before the FT3 2.0 axes were finalized, each was tested independently for repeatability and boundary clarity. The tactic model held up under adversarial evaluation, with similar or stronger results for the authorization and abuse-family dimensions.

The point was not to eliminate disagreement. Any method describing adversarial behavior will encounter incomplete evidence and ambiguous boundaries. The point was to determine whether independent evaluators could apply the same definitions to the same evidence and reach consistent conclusions.

If they could not, the taxonomy—not the evaluator—might be wrong.

A classification system should not dismiss every disagreement as user error. Its categories may overlap, the definitions may be unclear, or the evidence may not support the requested precision. A model intended for agentic workflows must explain not only why a classification fits, but why competing classifications do not.

Translation Without False Equivalence#

The fraud-framework landscape has grown quickly. MITRE F3, FS-ISAC’s Cyber Fraud Prevention Framework, the Fraud Kill Chain, the Federal Reserve’s FraudClassifier model, and industry-specific taxonomies observe overlapping parts of the same problem. I documented that development history and the provenance concerns around it separately.^[7]

One framework may describe a high-level lifecycle. Another may record detailed adversary behavior. Another may classify who initiated a payment. Similar words can operate at different levels of abstraction, while different words can describe the same observable action.

FT3 2.0 therefore maintains versioned crosswalks that record supported relationships and assessed gaps. An approximate mapping is not promoted to equivalence to improve coverage. An assessed absence is not treated as unfinished work merely because a cell is empty.

A Taxonomy Must Remember Change#

Fraud taxonomies cannot be static. Payment models change. Adversaries recombine old behaviors. Authorization moves from people to agents and automated workflows. Broad techniques split as evidence improves; apparently separate techniques converge when their underlying operation becomes clear.

FT3’s tactic axis shows that change. The 12 tactics in FT3 1.0 became 14 in FT3 2.0—not by appending two names to a list, but through merges, splits, renumbering, and genuinely new coverage.

Two tactics that had begun to describe the same behavior were merged. The former Monetization & Cash-Out stage split into Monetization & Cash-Out and Laundering & Proceeds Obfuscation. Moving value and obscuring its origin are distinct operations, exposing different signals and requiring different controls.

Trust & Social Manipulation and Recovery & Recourse Manipulation are net-new. The latter represents abuse of disputes, chargebacks, remediation, and recovery processes after the initial loss—behavior the earlier structure did not express cleanly.

Identifiers outlive the release that created them. Detections, controls, cases, intelligence reports, attacker-engineering exercises, and enforcement packages may reference an identifier years later. FT3 2.0 preserves explicit mappings from legacy references to their successors, along with the type of change. Releases are immutable and verifiable, so participants can resolve an old reference without rewriting history.

The System Behind the Release#

FT3 2.0 is supported by Acheron, a private, intelligence-assisted curation environment that turns raw fraud intelligence into governed, versioned knowledge whilst preserving provenance.

Acheron’s architecture, decision logic, placement rules, quality controls, and operating procedures remain restricted to closed trust environments.

FT3 1.0’s open release proved the category and made a shared fraud language available. It also made the work easy to absorb without reciprocal contribution. The wider history is already documented; this release does not repeat it.^[8][7]

FT3 2.0 is available to qualified practitioners through vetted TLP trust groups and by direct request. It is not being distributed through an unrestricted public repository.

If your work touches the fraud path and you can contribute intelligence, operational validation, or subject-matter expertise, contact me at ft3@vincentpassaro.com or connect with me on LinkedIn. Please tell me who you are, what you work on, and what you carry into the room. The rest works the way trust has always worked.

The Structure Now Fits the Problem#

FT3 2.0’s contribution is not that it makes fraud machine-readable. Others have done that. It is not that it applies an adversary matrix to fraud. Others have done that too.

The change is more fundamental: lifecycle position, authorization state, and abuse family are no longer collapsed into a single label. They remain separate properties of the behavior. That makes the model capable of representing fraud across payment systems, identity infrastructure, business processes, AI systems, and delegated authority without inventing a new taxonomy every time the underlying technology changes.

This public record explains the design.

Trusted communities receive the operational system.