FT3 created the shared fraud taxonomy.
FT3 2.0 sets it in motion.

FT3 provides a shared language that connects communities, research, detection, and operational decision-making.

Fraud does not hold still. FT3 2.0 gives practitioners and agents a machine-readable model of attacker behavior they can query, compare, and challenge. Techniques connect to the information needed to investigate them and to relevant analytics, detections, and controls. As new intelligence arrives, agents surface gaps and candidate changes; practitioners decide what the evidence supports.

See how it worksRequest access
Fig. 1 · A flat matrix, resolved into a connected model

01 · Agentic commerce

Built for commerce where software acts on someone’s behalf

Commerce actions can pass from an actor through automation into a payment API. FT3 2.0 records who directed the activity, what software acted, which surface it touched, and what evidence supports each claim. In this card-testing example, automation is established, AI involvement is suspected, and no named protocol is established. Defensive agents can work through that record without treating a suspicion as an observed fact.

Fig. 2 · Card testing, recorded with its automation context

  1. 01 ADVERSARY

    DIRECTS THE ACTIVITY

    • EXAMPLE CARD TESTING

    ↓ OPERATES

  2. 02 AUTOMATION

    SCRIPTS OR BOTS

    • AI INVOLVEMENT SUSPECTED
    • EVIDENCE BASIS NARRATIVE ONLY

    ↓ ACTS ON

  3. 03 PAYMENT SURFACE

    PAYMENT APIS

    • ACTION PERFORMED INITIATING A TRANSACTION
    • NAMED PROTOCOL NOT ESTABLISHED

The pattern is clear. The attribution is earned.

Repeated payment attempts establish automation. FT3 2.0 keeps the next questions open: was an AI agent involved, and did it use a named commerce protocol? In this case, AI involvement is suspected; the protocol is not established. That gives investigative agents a precise record to work from and a way to strengthen it as evidence arrives.

Same attempts, three claims

PAYMENT ATTEMPTS · UNIFORM INTERVAL

  • AUTOMATED ESTABLISHED
  • AI AGENT SUSPECTED
  • NAMED PROTOCOL NOT ESTABLISHED

02 · What changed

From a flat matrix to a multidimensional map

Start with a technique. See it across tactic, authorization state, and abuse family. FT3 2.0 keeps the connections visible as practitioners and agents move through the taxonomy.

Fig. 3 · One cell in FT3 1.0 becomes a connected record in FT3 2.0
FT3 1.0
FT008 · TACTIC
FT3 2.0
FT008 → TACTIC · AUTHORIZATION STATE · ABUSE FAMILY

One behavior.
Three ways to understand it.

Each technique is classified by the role it plays in the fraud, how authority is involved, and what is being abused. Card testing, for example:

  • Role in the fraud

    Fraud Execution / Fraud Event

    What role the behavior plays

  • Authorization status

    Unauthorized

    How authority is involved in the action

  • What is abused

    Payment & value transfer

    What the behavior exploits

03 · What it enables

A description that leads to defense

FT3 connects each technique to the information worth examining, the patterns to look for, investigation approaches, and controls to consider, including where those controls fall short.

Fig. 4 · Card testing, connected to what a team needs to investigate it

Technique · Card testing

  1. 01 INFORMATION TO EXAMINE

    • PAYMENT ATTEMPTS
    • AUTHORIZATION OUTCOMES
    • CLIENT OR API REQUEST CONTEXT
    • Optional corroboration
    • CHARGEBACK OR DISPUTE RECORDS

  2. 02 PATTERNS TO LOOK FOR

    • REPEATED LOW-VALUE AUTHORIZATION ATTEMPTS

  3. 03 INVESTIGATION APPROACH

    • CARD-TESTING PAYMENT AUTHORIZATION PATTERN

  4. 04 WAYS TO REDUCE RISK

    • PAYMENT-ATTEMPT RATE LIMITING
    • BOT CHALLENGES

FT3 1.0 records Card Testing as a single technique; FT3 2.0 keeps that technique and connects it to a detection strategy, an analytic, data components, and controls.

FT3 1.0 FT030 Card Testing Standalone technique. No linked records.FT3 2.0 1 technique · 1 detection strategy · 1 analytic · 4 data components · 2 controls See the full Card Testing record

Fraud ExecutionFraud EventCard Testing

Card Testing

Active

Adversaries make small transactions with stolen card data to test which cards are valid before using them for higher-value fraud.

FT3-TEC-0030Fraud Execution / Fraud Event · Unauthorized · Payment & value transfer · card rail

Created May 26, 2026 · Last reviewed Jun 24, 2026 · ft3-v2.0.0

Copy IDView sourceOpen in matrix

Lifecycle position

Phase 10 / 14

Where this technique sits in the fraud lifecycle. The highlighted phase is the one this record uses.

  1. 5 Credential, Session & Data Capture
  2. 6 Command, Control & Orchestration
  3. 7 Positioning & Account/Payment Preparation
  4. 8 Authorization & Approval Subversion
  5. 9 Detection, Risk & Investigation Evasion
  6. 10 Fraud Execution / Fraud EventThis technique
  7. 11 Monetization & Cash-Out
  8. 12 Laundering & Proceeds Obfuscation
  9. 13 Recovery & Recourse Manipulation
  10. 14 Impact & Disruption

Overview

Card testing is a fraudulent activity where criminals test the validity of stolen credit card information. This is often done by making small online transactions or donations through payment processing platforms. If a small transaction succeeds without triggering fraud detection mechanisms, the attackers gain confidence that the card can be used for larger, more lucrative purchases or fraudulent transactions.

Execution: Attackers often use automated scripts or bots to perform card testing, submitting numerous small transactions across various websites including e-commerce stores, donation forms, and subscription services. On platforms with extensive payment-processing APIs, such scripts may hit the API directly. These micro-charges are small enough to go unnoticed by cardholders but in aggregate can confirm the validity of thousands of stolen card numbers.

Signals — data components Added in 2.0

3 required · 1 corroborating

Evidence surface — which telemetry each component comes from.

ComponentPayment eventAccess surfaceCase record
Payment authorization attempt FT3-DC-0008Payment event, RequiredAccess surface, noneCase record, none
Authorization outcome event FT3-DC-0009Payment event, RequiredAccess surface, noneCase record, none
Client or API request context FT3-DC-0010Payment event, noneAccess surface, RequiredCase record, none
Chargeback or dispute record FT3-DC-0011Payment event, noneAccess surface, noneCase record, Corroboration

Solid bar = required signal. Dashed bar = corroborating evidence.

ComponentWhy it is neededExample sources
Payment authorization attempt FT3-DC-0008 RequiredAn attempted card authorization, capture, donation, subscription charge, or similar payment action, including repeated low-value attempts characteristic of validation behavior.payment authorization logs, payment processor events, merchant checkout events
Authorization outcome event FT3-DC-0009 RequiredThe result of a payment authorization attempt — approval, decline, reversal, issuer response code, or later chargeback context — used to read success/failure mix across attempts.authorization response logs, decline reason records, issuer response feeds
Client or API request context FT3-DC-0010 RequiredRequest context for the client, integration, script, bot, API caller, IP, device signal, or session that submitted an action, used to separate the behavior from the surface it came from.API gateway logs, web request logs, device or browser signals, session records
Chargeback or dispute record FT3-DC-0011 CorroborationA chargeback, dispute, or representment case tied to a transaction, with reason code, timing, and customer-history context, used to detect recourse abuse and post-fraud signals.chargeback/dispute case records, issuer dispute feeds, representment records

Analytics & detection strategy Added in 2.0

FT3-DS-0003

Detection pipeline — FT3-DS-0003

  • Payment authorization attempt FT3-DC-0008
  • Authorization outcome event FT3-DC-0009
  • Client or API request context FT3-DC-0010
  • Chargeback or dispute record FT3-DC-0011
Low-value authorization burstFT3-AN-0003
Card-testing payment authorization patternFT3-DS-0003

Detection pipeline for FT3-TEC-0030 Card Testing

FT3-DS-0003

Card-testing payment authorization pattern

Investigates whether repeated low-value payment attempts reflect card testing rather than normal merchant activity, customer retries, or integration testing.

Analytic

Low-value authorization burst FT3-AN-0003

Identifies bursts of low-value payment authorization attempts that resemble validation of stolen or enumerated/generated card data before higher-value fraud.

Evidence consumed
  • Payment authorization attempt FT3-DC-0008
  • Authorization outcome event FT3-DC-0009
  • Client or API request context FT3-DC-0010
  • Chargeback or dispute record FT3-DC-0011

Decision & controls Added in 2.0

2 preventive

FT3-CTL-0005 Preventive Payment

Payment attempt rate limiting

Limits repeated payment attempts across customer, card, merchant, client, API, network, or session context to disrupt automated card testing while preserving legitimate retries.

FT3-CTL-0006 Preventive Payment

Bot friction challenge

Adds adaptive friction (challenge, proof-of-work, or verification) to submission flows when automation-like request context indicates elevated risk, raising the cost of scripted abuse.

Reference · FT030 · Legacy FT3 v1 technique (stripe/ft3, MIT).

Acheron proposes where the framework should grow

Acheron turns fraud intelligence into proposed additions to FT3. Agents identify the techniques described in incoming intelligence and prepare evidence-backed proposals; FT3 maintainers decide what is added.

Fig. 5 · From fraud intelligence to proposed FT3 techniques

  1. Intelligence sources

    SOURCE 01 · SOURCE 02 · SOURCE 03

  2. 01 IDENTIFY TECHNIQUES

    Agents

  3. 02 PREPARE PROPOSALS

    Agents

  4. FT3

04 · The project

FT3

Created by
Vincent Passaro
Framework
FT3 2.0
Catalog version
2.1.0
Format
STIX 2.1

I created FT3 to give fraud teams a consistent way to describe behavior, compare cases, and connect what happened to the knowledge needed to investigate it.

FT3 2.0 is the framework generation. The current catalog is version 2.1.0, published as STIX 2.1. I share FT3 2.x through practitioner trust groups and direct requests.

The public source repository covers FT3 1.0. Access to 2.x is separate.

View the FT3 1.0 project

FT3c extends this shared language across other fraud and security frameworks, connecting concepts through reviewed mappings and graph-based crosswalks.

Explore FT3c

Precedence record

  1. FT3 / DARKSHEERFT3 authored by Vincent Passaro internally at Stripe
  2. FT3 / DARKSHEERFT3 presentation submitted to FS-ISAC for Spring Summit, 2025
  3. FS-ISACFS-ISAC declines the FT3 presentation
  4. FS-ISACFS-ISAC launches their own fraud framework — Cyber Fraud Prevention Framework (CFPF)
  5. FT3 / DARKSHEERFT3 is made public on GitHub (STIX, CSV)
  6. RH-ISAC + TARGETRetail ISAC creates their own fraud taxonomy
  7. MITRE CTIDMITRE publishes F3 STIX 2.1 bundle
  8. MITRE CTIDMITRE CTID launches F3, drawing on FT3.
  9. FT3 / DARKSHEERVincent Passaro ships Acheron, the intelligence-sourced agentic framework behind FT3
  10. FT3 / DARKSHEERFT3 2.0 ships as an intelligence-sourced, agent-authored, machine-readable framework that names delegated-authority abuse

§4.1.2 of MITRE’s F3 Design Principles and Methodology (opens in a new tab), in Sources of Information, lists “Stripe Fraud Tools Tactics and Techniques (FT3)” among four prior fraud models whose activities “were analyzed through empirical use examples and fused.” It describes FT3 as a “Framework to enhance understanding of the tactics, techniques, and procedures (TTPs) used by actors in fraudulent activities.”

Want access to FT3 2.x?

Email me with the subject “FT3 access request”. Include who you are, what you work on, and how you could contribute.

Request access

05 · How teams use it

How a fraud or attacker engineering team uses FT3

A fraud or attacker engineering team uses FT3 by mapping observed behavior to an FT3 technique, then to the detections and controls connected to that technique.

Techniques connect to the information needed to investigate them and to relevant analytics, detections, and controls.

The public FT3 1.0 files list the tactics and techniques; access to 2.x is separate.

06 · F3 and FT3

When to use FT3 and MITRE F3

Vincent Passaro created FT3 (Fraud Tools, Tactics, and Techniques). Use F3 as a common vocabulary when communicating about fraud with banks and other institutions; use FT3 when your team needs technique-level detection and controls across payment and platform technology.

FT3 2.0 is an ATT&CK-style matrix for fraud techniques. Catalog 2.1.0 lists 14 tactics and 215 techniques, including 72 sub-techniques, with 118 detection strategies and 80 controls.

Read the FT3 vs MITRE F3 essay

Read the work behind FT3

How the FT3 2.0 taxonomy works

The model: separate lifecycle position, authorization state, and abuse family.

How agentic commerce changes fraud

The application: delegated authority, scoped consent, and mandate abuse.

Where STIX needs more fraud context

The modeling tradeoffs: what native STIX objects leave out and what extensions cost.

07 · FAQ

Frequently asked questions

01Who created FT3?

Vincent Passaro created FT3 (Fraud Tools, Tactics, and Techniques), a fraud framework. FT3 1.0 is open source under the MIT license at https://github.com/stripe/ft3 (opens in a new tab).

02What is FT3?

FT3 (Fraud Tools, Tactics, and Techniques) is a fraud framework created by Vincent Passaro. It gives fraud teams a consistent way to describe attacker behavior, compare cases, and connect each technique to the knowledge needed to investigate it. FT3 2.0 is a machine-readable model that practitioners and AI agents can query, compare, and challenge.

03What is the difference between FT3 1.0 and FT3 2.x?

FT3 1.0, at github.com/stripe/ft3, was the first publicly available ATT&CK-style matrix for fraud on GitHub (July 2025): a flat matrix of fraud tactics and techniques. FT3 2.x, released July 2026, is the first ATT&CK-style fraud matrix designed for agentic commerce, classifying each technique by tactic, authorization state and abuse family.

04How does FT3 compare with MITRE ATT&CK and MITRE F3?

MITRE ATT&CK describes cyber intrusions; FT3 1.0 adapted its tactics-and-techniques model to fraud. §4.1.2 of MITRE’s Fight Fraud Framework (F3) methodology lists “Stripe Fraud Tools Tactics and Techniques (FT3)” among four prior fraud models “analyzed through empirical use examples and fused.” FT3 2.0 classifies each technique by tactic, authorization state, and abuse family.

Source: MITRE F3 Design Principles and Methodology, §4.1.2 (opens in a new tab)

05Can AI agents use FT3?

Yes. FT3 2.0 is designed to serve both analysts and agents: a machine-readable model, a STIX 2.1 catalog shared through practitioner trust groups, that agents can reason over. Each record separates what is established from what is only suspected, so defensive agents do not treat a suspicion as fact. Acheron uses agents to identify new techniques in incoming fraud intelligence.

06Is FT3 open source, and how do I get access to FT3 2.0?

FT3 1.0 is open source under the MIT license at github.com/stripe/ft3. FT3 2.x is not distributed through a public repository; Vincent Passaro shares it through vetted TLP trust groups and by direct request. To ask, email ft3@vincentpassaro.com with the subject “FT3 access request”, saying who you are, what you work on, and how you could contribute.

07Is FT3 an agent-ready fraud taxonomy?

Yes. FT3 2.x is a machine-readable STIX 2.1 fraud taxonomy that extends the ATT&CK-style fraud matrix to agentic commerce, classifying each technique by tactic, authorization state and abuse family. FT3 1.0 is open source at github.com/stripe/ft3; FT3 2.x is shared through practitioner trust groups.

08Is FT3 a fraud framework for agentic commerce?

FT3 2.0 is a fraud framework designed from the start for agentic commerce. It classifies every technique on three independent axes (tactic, authorization state and abuse family), so defenders can tell a compromised account from an over-scoped agent mandate. It is machine-readable: a STIX 2.1 catalog shared through practitioner trust groups.