NRF vs FT3: Same Problem, Different Design Intent

Retail fraud now has two structured frameworks. The National Retail Federation published one, with RH-ISAC and Target.^[1] I built the other. FT3 covers fraud across industries, and retail is one place it applies.

Most people start by comparing coverage.

That misses the point. NRF’s taxonomy is built for retail.

FT3 is built for fraud, period.

The real question: what job was each framework built to do? The answers are different, and you can see it in the structural decisions.

What NRF built#

NRF released version 2.0 of the Retail Fraud Taxonomy in July. It’s an 88-page report with five tactics (Pre-Compromise, Initial Access, Defense Evasion, Control, Monetization), three channels (Analog, Digital, Social Engineering), and three schemes (Gift Card Fraud, Account Takeover, Return Fraud). The report also defines 32 mitigations and 15 detection sources.^[1]

The original report states its purpose directly: “a knowledge base of retail theft, fraud and abuse techniques derived from real-world observations, aimed at enhancing the community’s ability to define, understand, prepare for, mitigate and detect fraud.” The uses it lists are education, tabletop exercises, security assessment, gap analysis, information sharing, testing, and vendor evaluation.^[2]

In practice, teams do all of that at once.

Target built a browser viewer for it, open source under Apache 2.0. Each technique is its own JSON file: code, name, tactics, channels, schemes, description, mitigations, detections. Every mitigation and detection carries an implemented flag so a team can mark what it already has. A technique also carries hide, color, and risk_score fields.^[3]

A retail fraud manager can use the report immediately. Teams can review the taxonomy together in a workshop, identify key issues, and find gaps. This is design tailored to the user’s needs.

What FT3 built#

FT3 ships as a STIX 2.1 release. Techniques, tactics, data components, analytics, detection strategies, and controls are separate objects. Typed relationships connect them. A control mitigates a technique. A detection strategy detects it. A data component supports the detection. A consumer pins a release and its hash and knows exactly what it has.^[4]

FT3 1.0 was designed for analysts. FT3 2.0 has to serve analysts and agents. Both can interpret prose, but explicit fields let them query authorization state and abuse family without reconstructing those classifications from each technique’s description.

That’s why FT3 2.0 moved away from treating each technique as a single cell. Now, each technique is defined by three coordinates: lifecycle position, authorization source, and what was abused.^[4]

These can shift independently without affecting the others.

The same technique in both frameworks#

Wardrobing is buying something to use it, then returning it for a refund as if it had never been used.^[5]

Both frameworks record wardrobing, so we can look at what each one says about it.

NRF files Wardrobing (FT1209) under the Control tactic, in the Analog and Digital channels, in the Return Fraud scheme.^[5] It answers the questions a retail team organizes around. Which program owns it? Does it happen in-store, online, or both? Where in the attack does it sit?

FT3 treats wardrobing as a variant inside Refund Fraud (FT3-TEC-0036). Refund Fraud’s primary tactic is Recovery & Recourse Manipulation, with Fraud Execution / Fraud Event as a second. Its authorization state is Abused-legitimate: a person who genuinely held authority misused it. Its abuse family is Payment & value transfer, with Business process, claim & record as a second.^[6]

That’s what a control owner needs to know. Who allowed it? What got abused? Which control matters when a real customer steps outside the policy’s intent?

Neither record is wrong. They’re describing the same behavior, but for different jobs.

The gaps follow from that. NRF includes Authorized Account Abuse and Insider Recruitment as named entries, but it has no authorization field for grouping those behaviors with other techniques that abuse legitimate authority. FT3 has no channel and no scheme. If your question is physical versus digital, or which program owns the problem, NRF answers it directly, and FT3 doesn’t.^[7]

Granularity is a design choice too#

NRF goes deeper on retail returns than FT3 does. The Return Fraud scheme has Item Manipulation (with Harvesting and Switch Merchandise), Returns Process Exploitation (with Shipping Manipulation and Damaged Shipment), and Fraudulent Refund (with Refund to Gift Card, Double Refund, and Non-Receipted Returns). Each has its own mitigations and detection sources.^[7]

FT3 keeps one Refund Fraud technique and carries the variants in its description and detection guidance, including the return-condition evidence a wardrobing case needs. Its retail coverage also includes Unlinked Refund Fraud, Rewards & Loyalty Program Abuse, and Token Cracking for gift card and coupon codes.^[6]

For a retail team working returns, NRF’s entries are the place to start. They match how the work is divided.

NRF gives wardrobing its own entry. FT3 keeps it within Refund Fraud, with the other return-abuse variants described there.

How mitigations connect#

NRF’s report lists each technique’s mitigations and detection opportunities inside the entry and indexes them in the back by FM and FD identifiers.^[8]

The viewer data works differently. Across 52 technique files, there are 262 mitigation and detection entries. Each has a label, some detail text, and the implemented flag. None has an identifier. “Login Required” appears inside Check Gift Card Balance as an entry in that technique, and a tool asking which techniques it covers has to match on the label.^[9]

Objectively, that’s brittle.

In FT3, a control is its own object with its own identifier, and a relationship ties it to every technique it mitigates.^[4]

A team building coverage across hundreds of techniques needs to find every technique a control applies to. FT3 gives that control an identifier and links it to those techniques. NRF’s viewer matches them by name.

Tactics divide the lifecycle differently#

NRF’s five tactics follow how a retail attack runs. For example, Control includes exchanging an illicitly obtained gift card for a legitimate one. FT3 has fourteen, and the later stages are divided more finely: Monetization & Cash-Out, Laundering & Proceeds Obfuscation, and Recovery & Recourse Manipulation. FT3 also has Authorization & Approval Subversion and Trust & Social Manipulation, which have no counterpart among NRF’s tactics.^[10]

For a retail return scheme, NRF spreads the techniques across Control and Monetization. FT3 puts refund abuse in the recourse stage. That’s where the actor is working against the merchant’s dispute and return process.

Which one to use#

Both frameworks are useful, but they’re built for different eras of fraud defense.

NRF and its viewer are designed around how retail teams work today: exploring techniques, reviewing mitigations, and assessing coverage. FT3 is designed for a different operating model, where analysts and automated systems need to interrogate the same structured intelligence at scale.

FT3 takes a different bet: that structured, machine-readable relationships will become essential as fraud grows more complex and increasingly automated.

FT3 gives analysts, models, and automation a shared structure for connecting techniques, detections, analytics, controls, and the authorization boundaries that distinguish one fraud behavior from another.

The future isn't choosing between human expertise and machine reasoning. It's building fraud intelligence that both can use, without losing the distinctions that make it useful.