STIX 2.1 is the closest the threat intelligence community has to a shared language for describing and exchanging intelligence. It is effective for modeling network intrusions, APT campaigns, and malware analysis. However, when modeling financial fraud—such as card testing, account takeovers, or money laundering schemes—the built-in objects and vocabularies are insufficient.

This situation leaves the industry with two options: develop proprietary solutions or utilize STIX’s extension mechanisms. The STIX specification is flexible and allows for extensive customization. However, each new extension adds complexity to the JSON schema that every downstream consumer must understand, adopt, and implement. Anyone who has worked with STIX data will recognize this challenge.

A quick primer on STIX:

STIX organizes threat intelligence into three object categories.

SDOs (Domain Objects) represent the nouns: Attack Pattern, Malware, Threat Actor, and Identity. These objects describe the entities being tracked.

SROs (Relationship Objects) function as the verbs—for example, “Threat Actor uses Malware” or “Indicator indicates Attack Pattern.” These objects connect the various entities into a graph.

SCOs (Cyber Observables) serve as the evidence, such as IP addresses, file hashes, domain names, and network traffic—raw technical artifacts.

The SDOs were designed to accommodate the workflows of cyber intelligence analysts operating within traditional enterprise environments, focusing on networks and system layers.

When an organization needs to extend beyond what is built in, such as describing fraud techniques, STIX provides two main options: define a new object type or add properties to an existing one. It is possible to define custom kill chains, create new observable types, and attach detection metadata to an attack pattern. The specification allows for these extension mechanisms, enabling STIX to be adapted for domains outside its original scope, such as fraud.

Card Testing (FT030): A Case Study in Schema Friction

Card testing is a perfect use case. A fraud actor runs credit card authorizations against an endpoint, often across multiple merchants, to avoid fraud model detections. Cards that return valid authorizations get annotated as ‘good’ and used for later fraudulent activity. Declined cards get tossed.

Card testing involves identifying patterns of high-volume authorization attempts, correlated by device or devices, spread across multiple merchant accounts, within a specific time window.

STIX can express “something happened (X) times in (Y) time period with the qualifiers: REPEATS and WITHIN.

However, these capabilities are limited to STIX-native SCOs, which focus on network- or system-level IOC types. STIX does not natively support observables for identifiers related to payment infrastructure, such as merchant accounts, payment transaction details, or device fingerprints. Here’s a native STIX adaptation example:

json
{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--d81f86b9-975b-4c0b-875e-810c5ad45a4f",
  "created": "2025-06-01T00:00:00.000Z",
  "modified": "2025-06-01T00:00:00.000Z",
  "name": "Card Testing Detection",
  "indicator_types": ["malicious-activity"],
  "pattern": "[network-traffic:dst_ref.type = 'ipv4-addr' AND network-traffic:dst_port = 443] REPEATS 20 TIMES WITHIN 300 SECONDS",
  "pattern_type": "stix",
  "valid_from": "2025-06-01T00:00:00.000Z"
}

This pattern is better suited for modeling Denial-of-Service (DoS) attacks than for card testing.

The Extension Trap: Why Custom SCOs Aren’t Enough

If we apply a custom STIX schema extension, we can more accurately describe card testing.

json
{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--8a3e4c21-b7f2-4e91-a5d3-9c1b7f2e8d4a",
  "created": "2025-06-01T00:00:00.000Z",
  "modified": "2025-06-01T00:00:00.000Z",
  "name": "Card Testing Detection",
  "indicator_types": ["malicious-activity"],
  "pattern": "[x-transaction:amount < 5.00 AND x-transaction:device_fingerprint = 'X'] REPEATS 15 TIMES WITHIN 600 SECONDS",
  "pattern_type": "stix",
  "valid_from": "2025-06-01T00:00:00.000Z"
}

But that also requires the STIX scheme extension definition.

json
{
  "type": "extension-definition",
  "spec_version": "2.1",
  "id": "extension-definition--a1b2c3d4-5e6f-7890-abcd-ef1234567890",
  "created_by_ref": "identity--b3bca3c2-1f3d-4b54-b44f-bea949dc2560",
  "created": "2025-06-01T00:00:00.000Z",
  "modified": "2025-06-01T00:00:00.000Z",
  "name": "FT3 Transaction Observable",
  "description": "Defines an x-transaction SCO for modeling payment authorization events in fraud intelligence.",
  "schema": "https://github.com/stripe/ft3/schemas/scos/x-transaction.json",
  "version": "1.0",
  "extension_types": ["new-sco"]
}

Introducing a custom SCO pattern requires the organization to take on additional responsibilities, including:

  • A full JSON schema defining every property on x-transaction — amount, device_fingerprint, merchant_id, card_bin, currency, timestamp — with types, required fields, and validation rules
  • The extension-definition object that points to that schema (which has to ship in every bundle or be hosted somewhere consumers can resolve it)
  • Documentation so that downstream consumers understand what each property type means and how it maps to their own data.
  • Versioning, often at the object level, because the moment you add, rename, or deprecate a property, every consumer’s integration breaks unless they update
  • Ensuring that every platform in the chain—including the Threat Intelligence Platform (TIP), TAXII server, and data ingestion pipelines—can recognize, parse, and index new, unfamiliar data types.

Including a single x-transaction in a pattern field represents only the visible portion of a much larger, more complex challenge. The primary difficulty is not technical but rather adoption-related. Even a flawless extension schema loses value if another organization models the same fraud technique using different property names, kill chain phases, or relationship types.

This challenge is industry-wide. Multiple entities will inevitably define card testing in different ways, each employing unique property names, relationship types, and object structures. STIX provided the grammar to describe threats, but did not deliver a sustainable method for extending that grammar without risking interoperability.

Will AI make this easier?

Technically, yes. Organizitionally, no.

Every new STIX extension scheme introduced requires consumers to update parsers, rebuild data pipelines, and modify validation logic. AI agents can analyze schema differences and generate these updates far more quickly than manual efforts, reducing the adoption cycle from “maybe next quarter” to a timeline much closer to real time.

But agents won’t solve the core problem—the industry’s politics. AI can’t reconcile multiple organizations that describe the same fraud technique.

AI can accelerate translation, but translation isn’t interoperability—it’s just a faster workaround.

The most effective solution, though slower and less glamorous, is the establishment of an open, shared language collaboratively managed across the industry, designed to connect rather than compete with different frameworks.

AI can accelerate technical implementation, but cannot resolve the need for human consensus.