Lesson 01 · 5 min

What is the CDM?

One machine-readable model for trades, instead of every firm reinventing the same swap.

The problem it solves

Walk one interest rate swap through a bank and count its representations. The front office books it in the trading system's format. Risk rebuilds it in theirs. Operations holds a third copy for settlement, and regulatory reporting flattens it into a fourth. Every copy describes the same economic reality. And yet every firm pays, over and over, to translate between its own copies, then to reconcile them with every counterparty's copies.

Front officeswap_v2.xmlRiskIRS objectOps / settlementtrade rowReg reportingCFTC fieldsCDMone shared shapereconcile oncereport onceautomate oncesame trade, four different shapeseveryone speaks this

The Common Domain Model (CDM) is the industry's answer: a single, machine-readable definition of how trades, products, and lifecycle events are represented. Two firms (or two systems in one firm) describing the same trade produce the same data.

Key ideas
  • One model, machine-readable

    A standard data model for financial products, trades, and their lifecycle, designed to be executed by software rather than interpreted off a page.

  • Open source and community-governed

    Developed by ISDA and the community under FINOS, the Fintech Open Source Foundation. Anyone can read it, use it, and propose changes.

  • Executable, not a PDF

    The CDM ships types, validation conditions, and functions. “Is this a vanilla equity option?” is answered by running a function, not by a human reading a document.

  • Build once, agree everywhere

    A shared shape means cheaper reconciliation, consistent regulatory reporting (the DRR programme builds directly on CDM), and lifecycle automation that survives between firms.

What "a model" actually means here

Concretely, the CDM is a set of typed building blocks. Each type declares its fields, each field has a type and a cardinality (how many values it can hold), and conditions constrain what a valid instance looks like. Small pieces compose into big ones: a price becomes part of a payout, payouts become a product, a product becomes a trade.

Here is one of the small pieces, a fixed rate expressed as a CDM price:

{} Price, a 4.25% fixed rate
{  "value": 0.0425,  "unit": {    "currency": "USD"  },  "perUnitOf": {    "currency": "USD"  },  "priceType": "InterestRate"}
Even a rate carries its semantics with it: the priceType says this number is an interest rate, and the units say it's USD per USD. No more guessing what 0.0425 means from a column name.
Try itEverything in this course links into the live model and opens in a new tab, so you never lose your place. When a lesson mentions a type, click through: the schema, its conditions, and a runnable playground are one tab away.
◆ Checkpoint

01What makes the CDM different from a documentation standard like a rulebook or message spec?

1 / 3