The CDM is a standard for use when trades need to be represented in a common way, such as in system design, reconciling trade data between firms, and preparing data for regulatory reporting.

Why it was built

The CDM was built to replace the different ways each firm and system represents a trade with one standard. According to the documentation of FINOS (the Fintech Open Source Foundation), when firms record the events in a trade's lifecycle in different ways, those differences create the need for reconciliation1. The aim of a standard representation is to reduce the burden of building a separate connection between each pair of systems or firms, and to lay the groundwork for straight-through processing (STP), which runs a process from start to finish with less manual work2.

The documentation names three goals1.

  • Make it easier to exchange data between firms, solutions and platforms, and advance STP.
  • Let regulators and market participants view trade data in the same representation, which makes regulatory reporting more consistent.
  • Provide a common foundation for applying technologies such as distributed ledgers, smart contracts, the cloud and artificial intelligence to financial markets.

The CDM covers over-the-counter derivatives, cash securities, securities financing such as securities lending and borrowing, and commodities3.

What the model consists of

The CDM is defined along five dimensions: product, event, legal agreement, process and reference data4.

Group What it represents Main components named in the documentation
Product The contract or product that transfers financial risk between two parties Asset, Payout, EconomicTerms
Event What happens during a trade's lifecycle, and the trade's state at that point TradeState, BusinessEvent, workflow
Legal agreement The content of the contract that governs the whole relationship between the parties to a trade Master agreement schedules, credit support documents
Process Processes and calculations used across the industry Processes written as functions
Reference data Entities that the other four groups refer to, such as parties, legal entities and floating rate indices Party, legal entity

In the product group, the model first represents cash, commodities, digital assets and financial instruments (listed derivatives, loans and securities) as assets. It then builds promises of future asset transfers as components (Payout) and expresses the economic terms of the whole product5. Every kind of asset has an identifier field, and the type of identifier (such as ISIN) can be given with it5.

The legal agreement group represents the text of a contract as structured data, not as prose that a person reads and interprets. This makes it possible to implement processes that act on the arrangements in a contract, such as the terms for delivering collateral in collateral management, directly from the data6. In the CDM, one trade can be linked to one master agreement, and one master agreement can be linked to multiple trades6. The scope includes a generic representation of master agreement schedules and the types of credit support documents of the International Swaps and Derivatives Association (ISDA)6.

A trade state created with each event

The event group represents a trade's lifecycle as a series of state transitions. A lifecycle event is defined as the move of a trade from one state to the next, caused by an instruction from the parties, the terms of the contract or an external factor7. The CDM sets out the following principles for this representation7.

  • The state of the trade must differ before and after an event.
  • The logic that moves the state is built by combining small components.
  • The history of states can be reproduced at any point in the trade's lifecycle.
  • The definition of the product that the trade is based on does not change.
  • A state is held per trade, not per product. If there are several trades in the same product, each trade has its own state.

Consider these principles with an interest rate swap. Execution is the first event, and its result is the state of the executed trade. Because execution is an event that creates a new trade, there is no previous state. Afterward, an automatic event such as a floating rate reset does not change the product definition. It links the reset information to the trade state and adds it to the reset history7.

Consider a hypothetical example in which an interest rate swap goes through execution, a floating rate reset and an amendment of terms. The state numbers are labels added for explanation and are not CDM fields.

State Event that occurred Previous state referred to How the state is created
State 1 Execution None The state of a new trade is created
State 2 Floating rate reset State 1 The product definition stays the same, and the reset information is added to the reset history
State 3 Parties agree to amend the terms State 2 The economic terms change, and a new product or trade data is created

For an event that has a previous state, as after execution, the new state is created by reference to the previous state. This chain of references is called lineage in the CDM8. When the parties agree to amend the terms, the economic terms of the trade change, so a new product or trade data is created as a result of that event7.

The CDM represents event data with the following four components7.

Component Role
TradeState The trade's current state, from execution through settlement to maturity. It has fields for the trade, the state, the reset history and the transfer history9
Primitive operator The smallest component that changes a state from the previous one to the next
Business event A lifecycle event that involves one or more trades, built by combining primitive operators
Workflow The set of steps needed to bring about a business event. Parties other than the trade's parties may take part, and automatic and manual steps may be mixed10

The operational flow is covered on the Lifecycle Event Processing page.

What it means to represent a model as code

The CDM is distributed not as a specification written in diagrams and prose, but as a combination of model definitions written in a dedicated language and code built from them. The model is written in a language called Rune DSL and organized into files divided by namespace11. The code is generated automatically from the model definitions by a code generation mechanism. Rune DSL includes code generation to Java as standard, and users can write and share code generators for other languages11. The Java distribution also includes a default implementation written by hand11.

CDM distributionAdopting firmDefine the modelin Rune DSLGenerate codefrom the definitionsInclude a defaultimplementation inthe Java distributionChoose to use orextend the defaultimplementation
Figure 1From the CDM definitions to using the code
Figure description

The figure shows the order from the model definitions to the code, up to the adopting firm choosing whether to use or extend the default implementation. Distributions in other languages may include only part of the model.

The CDM's Process Model converts the technical standards that support industry processes into a standardized form. That form is "machine-readable" and "machine-executable"12. These two properties are described as essential for eliminating divergent implementations among market participants and advancing the interconnection of technologies12. A process can be a function that defines all of the required outputs, or one that defines only some of them13.

The following day count calculation is an example of what "machine-executable" means. The CDM has function components that perform day count calculations14. One day count rule, 30E/360, counts each month as 30 days and replaces the 31st of a month with the 30th15. Consider a hypothetical example in which two periods with different start and end dates are calculated under 30E/360. The outputs are values derived from the rule, not output of the CDM itself.

Start date End date Rule Output (the fraction of a year the period represents)
January 15, 2026 July 15, 2026 30E/360 0.5 (6 months × 30 days ÷ 360 days)
January 31, 2026 February 28, 2026 30E/360 About 0.0778 (28 days ÷ 360 days, because the start date is replaced with the 30th)

Instead of having each firm implement this kind of calculation separately, the CDM provides it as a definition from which code can be generated15. For a period that includes the last day of February, as in the second row, a different rule that also counts each month as 30 days can give a different value15.

The processes the model currently covers are the post-trade processes for securities, contractual products and foreign exchange trades. They include execution and confirmation, clearing, allocation, settlement, option exercise, margin calculation and regulatory reporting16. For regulatory reporting, ISDA's Digital Regulatory Reporting (DRR) is described as turning industry-agreed interpretations of new or amended reporting rules into CDM code17.

The distribution has the following three parts11.

Part Content
Model definitions The set of definitions that describe products, events, legal agreements, processes and reference data
Generated code Code generated automatically from the definitions. The Java distribution includes the whole model and the default implementation
Default implementation Code written by hand in Java. Together with the generated code, it makes a complete implementation

Distributions in other languages may include only part of the model. For example, the TypeScript distribution has the data model only and does not include executable code for functions11. The default implementation is bundled so that financial institutions can use the distribution to build and test an implementation11. Each adopter chooses whether to use the default implementation, disable it or extend it.

A public specification managed by FINOS

The CDM is a standard that FINOS develops under an open governance mechanism (the Community Specification). The underlying code assets are published under the Community Specification License 1.018. In September 2022, ISDA, ISLA and ICMA announced that they had selected FINOS after a request for quotation (RFQ) process. On February 16, 2023, FINOS announced the open-source release of the CDM19.

The documentation is published by version. The documentation checked on October 2, 2026 was for version 7.0.0. Documentation for older versions (such as 6.0.0) also remains available18. Because versions of the specification keep being updated, adopters need to check which version they use and its change history.

The CDM has working groups on derivatives, collateral, technical architecture, tokenized assets and other topics18.

Use in financial institutions' systems

Within the scope the FINOS documentation shows, financial institutions can use the CDM in the following ways.

  • Embed the distributed Java code with Maven20.
  • Generate code in another language from the distributed definitions11.
  • Use a CDM-based application offered by a software vendor. Some are open source and some have commercial terms. FINOS does not recommend any particular application21.
  • Refer to the example use cases in the documentation. They include the representation of eligible collateral, repurchase agreements, securities lending and pre-trade processing22.

FpML is an open-source standard, written in XML, for exchanging and processing information on trades such as over-the-counter derivatives electronically23. The CDM takes mapping to existing industry messaging formats as one of its design principles24. For example, part of the trade data adopts elements of the FpML trade confirmation view, and some components correspond to the pre-trade view25.

Notes

  1. FINOS, "Overview of the FINOS CDM", "Purpose". Differences between firms in recording lifecycle events create the need for reconciliation, and regulatory reporting becomes more consistent through a standard representation and machine-executable reporting requirements. ↩ ↩2

  2. FINOS, "Common Domain Model" home page, "What is the purpose of the CDM?" ("Enhance interoperability & straight through processing"). ↩

  3. FINOS, "Overview of the FINOS CDM", "Scope". ↩

  4. FINOS, "Overview of the FINOS CDM", "FINOS CDM Distribution" and "Model Overview". The component names in the table follow the Product Model, Event Model, Legal Agreements and Process Model documents. ↩

  5. FINOS, "Product Model", "Financial Product" (the relationship among Asset, Payout and EconomicTerms), "Asset" (cash, commodities, digital assets and financial instruments; identifier types), "Instrument" (listed derivatives, loans and securities). ↩ ↩2

  6. FINOS, "Legal Agreements", "Legal Agreements in the CDM" and "The Use of Agreements in Financial Markets", "Introduction". ↩ ↩2 ↩3

  7. FINOS, "Event Model", "Introduction to the Event Model". The definition of a lifecycle event, the principles, the examples of execution and amendment, and the four components. ↩ ↩2 ↩3 ↩4 ↩5

  8. FINOS, "Event Model", "Lineage". ↩

  9. FINOS, "Event Model", "Trade State" (the definition of TradeState; the four fields trade, state, resetHistory and transferHistory). ↩

  10. FINOS, "Event Model", the description of "Workflow" (involvement of parties other than the trade's parties, automatic and manual steps, lineage between the steps). ↩

  11. FINOS, "Overview of the FINOS CDM", "CDM Components" (the three parts of the "FINOS CDM Distribution", "Rune DSL"). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  12. FINOS, "Process Model", "What Is the Process Model" and "How Does It Work". ↩ ↩2

  13. FINOS, "Process Model", "Granularity" (whether a function's logic is "fully defined" or "partially defined"). ↩

  14. FINOS, "Process Model", the day count section ("The CDM includes a library for performing day counting calculations."). ↩

  15. FINOS, "Process Model", "Year Fraction" (the three rules in the 30/360 family, the example function for 30E/360, code generation). The values in the table are hypothetical. ↩ ↩2 ↩3 ↩4

  16. FINOS, "Process Model", "Coverage". ↩

  17. FINOS, "Overview of the FINOS CDM", the description of ISDA's Digital Regulatory Reporting (DRR) after "What is the FINOS CDM?". ↩

  18. FINOS, "Common Domain Model" home page (governance, license, list of versions, working groups). Checked on October 2, 2026; the documentation version was 7.0.0. ↩ ↩2 ↩3

  19. FINOS, "FINOS Launches Common Domain Model Project…" (February 16, 2023), third paragraph. ISLA is the International Securities Lending Association and ICMA is the International Capital Market Association. ↩

  20. FINOS, "Overview of the FINOS CDM", "Using the CDM (Java)". ↩

  21. FINOS, "Overview of the FINOS CDM", "CDM Applications". ↩

  22. FINOS, "Common Domain Model" documentation home page, the "Use Cases" list (Eligible Collateral Representation, Repurchase Agreement Representation, Securities Lending, Pre-trade Processing and others). ↩

  23. Secretariat of the TC68 Domestic Committee, "ISO 20022 の概要" (Overview of ISO 20022, our translation; in Japanese) (March 2015), page 6, footnote 13. It shows that FpML is an open-source standard developed under ISDA's sponsorship. ↩

  24. FINOS, "Overview of the FINOS CDM", "Design Principles" ("Mapping to existing industry messaging formats"). ↩

  25. FINOS, "Event Model", the note under "Trade" (the Trade and ContractDetails fields adopt elements of the FpML trade confirmation view, and TradableProduct corresponds to the pre-trade view). ↩