Before getting into the CDM stuff, I want to take full credit for the suspiciously nice diagram in this post. It was hand-crafted by me (not AI)! In fact, not only for this article, I plan to create diagrams to visualise example products, ISDA CDM details, and eventually the knowledge graph around the semantic layer.

This is time-consuming. The hard part is not only drawing the diagram, but also looking into the details and making sure the structure is accurate enough to be useful. However, I am keen to do this exercise for two reasons.

The first reason is obvious: diagrams make the blog more attractive :-).

The second reason is more personal. Creating detailed diagrams helps me build my own mental model of the financial data foundation at a detailed level. FICC content is massive. When we also consider semantic layers and knowledge graphs, the knowledge space becomes even larger. I need a more efficient storage format to save these ideas into my own brain.

Now, back to the main story.

In the previous article, AI-Native Financial Data Foundation (3) — What Is a Financial Product at All?, I discussed a simple but important question:

What is a financial product?

My conclusion was that a financial product should not be understood only as a product label, such as IRS, bond, FX forward, CDS, or option. At a deeper level, a financial product is an arrangement of:

• rights
• obligations
• transfers
• timing
• conditions

This sounds abstract. So in this article, I want to make it more concrete.

Instead of discussing the ISDA Common Domain Model only from a theoretical perspective, I will use one simple product as the running example: a vanilla USD fixed-float interest rate swap.

The goal of this article is to show how the abstract nature of a financial product starts to appear in a real CDM-style product structure.

The Product We Will Use

The example is a vanilla USD fixed-float interest rate swap.

It has two interest rate legs:

In plain language, this swap says:

Party1 pays a floating interest amount based on 3-month USD LIBOR. Party2 pays a fixed interest amount at 2.53%. Both sides calculate interest on a USD 10 million notional over a five-year period.

No principal is exchanged. The notional exists to calculate the interest payments. This is one of the first important points about swaps: the notional is economically important, but it is not necessarily transferred.

ISDA CDM Product Model

The ISDA Common Domain Model provides a standardised way to represent financial products, trades, lifecycle events, and processes. For this article, I only focus on the product side.

At a high level, the CDM product model separates several important ideas:

• product qualification
• the economic product
• trade-specific price and quantity
• parties and counterparties
• payout structure
• schedules and dates

This separation is important. In many traditional systems, a product is often represented by a product type and a large number of fields attached to that type. This is easy to understand, but it has a limitation: it treats the product as a flat collection of attributes.

The CDM approach is different. It represents the product as a structured economic object. The product is built from reusable components such as payouts, quantities, rates, schedules, observables, and settlement terms.

If we model financial products mainly by product labels, every new product becomes a new exception. We start with IRS, bond, FX forward, and option. Then we add callable bond, convertible bond, swaption, cross-currency swap, total return swap, and so on. Eventually, the taxonomy becomes larger and larger. Even worse, there is more and more semantic duplication across products.

But if we model products by their reusable economic components, products become compositional.

A callable bond becomes:

bond + optionality

A swaption becomes:

swap + option

A cross-currency swap becomes:

interest rate payouts + principal exchanges

The complexity does not disappear, but it becomes more structured.

From Product Nature to CDM Structure

As discussed in the previous article, a financial product can be understood through five fundamental concepts:

rights + obligations + transfers + timing + conditions

In the CDM, each of these concepts is not represented by one single object. Instead, the nature of the product is distributed across multiple CDM components.

A rough mapping looks like this:

This mapping is not always one-to-one, and it should not be. For example, an obligation is mainly represented by a payout. But the full meaning of that obligation also depends on payer and receiver, notional, rate, schedule, calculation rules, and settlement terms.

This is why CDM can feel complex at first. It is not simply storing product attributes. It is describing the economic machinery of the product.

The Top Level: TradableProduct

In CDM, several key concepts are used to represent products.

A Product describes the economic object. It can be a TransferableProduct, such as a bond or security, or a NonTransferableProduct, such as many OTC derivatives.

For our IRS example, the product is a NonTransferableProduct, because the swap is a bilateral contractual arrangement between two parties. It is not a transferable asset like a listed equity or bond.

However, I personally think one of the main contributions of CDM is the TradableProduct concept. It offers a practical answer to one of the main dilemmas in FICC product modelling.

For listed equities, the answer is relatively simple. The product already exists independently. Apple shares are Apple shares. A trade only needs to reference the security and record the price, quantity, buyer, seller, and settlement information.

For many FICC products, especially OTC derivatives, the answer is harder. The “product” is often defined by the trade terms themselves. An interest rate swap does not exist as a fully standardised object before the parties agree its notional, currency, fixed rate, floating index, schedules, reset rules, day count conventions, business centres, and settlement terms.

So if we separate product and trade too much, we lose the economic meaning. But if we merge everything into one flat trade record, we lose structure and reusability.

The TradableProduct concept is a practical answer to this problem. It keeps the economic product structure, while also connecting it to trade-related elements such as price, quantity, and counterparties.

For our IRS example, this is exactly what we need. The swap is not just a reusable label called “IRS”, but it is also not just an unstructured trade record. It is a structured economic product made tradeable through price, quantity, and counterparty information.

The Core: EconomicTerms and Payouts

The most important part of the product is EconomicTerms. This is where the economic content of the product lives.

But within EconomicTerms, the core of the core is the payout structure.

As discussed earlier, the essence of a financial product is an arrangement of economic rights and obligations between parties, together with the rules that define how those rights and obligations are calculated, triggered, transferred, and settled.

In CDM, this is mainly the responsibility of payouts.

For our vanilla IRS, there are two economic legs:

Party1 pays a floating interest amount based on 3-month USD LIBOR.
Party2 pays a fixed interest amount at 2.53%.

In normal market language, we call these the floating leg and the fixed leg. In CDM language, both sides are represented as InterestRatePayout.

Payout
    ├── InterestRatePayout  // floating side
    └── InterestRatePayout  // fixed side

An InterestRatePayout represents an interest-rate-based payment obligation. It defines who pays whom, what notional amount the interest is calculated on, what rate is used, which day count convention applies, and when the rate is observed, calculated, and paid.

For the fixed side, the payout points to a fixed rate specification. For the floating side, it points to a floating rate specification.

CDM does not necessarily create a separate object called Right. The right is implied by the receiver side of the payout. The obligation is implied by the payer side of the payout.

So for the fixed side:

Party2 has the obligation to pay fixed interest.
Party1 has the right to receive fixed interest.

For the floating side:

Party1 has the obligation to pay floating interest.
Party2 has the right to receive floating interest.

This is a good example of why CDM is semantic but not always obvious. The meaning is not stored in one label. It is distributed across the structure.

A payout also needs to define how the payment amount is calculated. For an interest rate swap, the amount depends on notional, rate, day count fraction, and calculation period.

Fixed Amount
    = Notional × Fixed Rate × Year Fraction
Floating Amount
    = Notional × Floating Rate × Year Fraction

In CDM, the economic basis for these calculations is represented through concepts such as PriceQuantity, QuantitySchedule, RateSpecification, and Observable.

This is why the floating leg is usually richer than the fixed leg.

The fixed side says:

Use this fixed rate.

The floating side says:

Observe this rate index.
Apply the reset rules.
Apply the fixing offset.
Use the day count convention.
Calculate the payment for each period.

This is where market data becomes part of the product definition.

Timing is another major part of the payout structure. From a distance, an IRS looks simple: one party pays fixed and the other pays floating. But operationally, much of the complexity lives in time.

The product needs to define when the trade starts, when it ends, what the calculation periods are, when payments are made, when the floating rate is observed, and how dates are adjusted.

In CDM, this is represented through schedule-related structures such as:

EconomicTerms
    ├── effectiveDate
    ├── terminationDate
    └── dateAdjustments
InterestRatePayout
    ├── calculationPeriodDates
    ├── paymentDates
    ├── resetDates
    └── stubPeriod

For our IRS, the fixed side has semi-annual calculation and payment periods. The floating side has quarterly calculation, reset, and payment periods.

This is one reason FICC product modelling is difficult. The hard part is not only the product label. The hard part is the structure: schedules, resets, payment rules, stubs, date adjustments, business centres, and settlement terms.

Finally, a payout must also be settled. For this IRS, settlement is cash settlement in USD. The fixed amount and floating amount are calculated, the net amount is determined, and the cash payment is settled.

There is usually no principal exchange in a vanilla single-currency IRS. The notional is referenced for calculation, but the notional itself is not exchanged.

This distinguishes an IRS from products where the principal or asset is delivered:

Bond settlement:
    cash exchanged for bond
FX spot:
    one currency exchanged for another currency
Cross-currency swap:
    principal exchanges may exist
IRS:
    notional is referenced but not exchanged

So the nature of the product is not captured by the label alone.

It is captured by the combination of payout, payer and receiver, notional, rate, observable, schedule, calculation rules, and settlement terms.

This is why payout is such an important CDM concept. The product label tells us what the market calls the trade. The payout structure tells us what the trade actually does.

Conditions, Rules, and Qualification

Conditions and rules are also part of the nature of a financial product.

For some products, this is very obvious. In a CDS, a credit event may trigger a protection payment. In an option, exercise may create a future obligation.

For a vanilla IRS, the conditions are less dramatic, but they still exist. The floating leg depends on rate observation and reset rules:

observe USD-LIBOR-BBA 3M
apply the fixing offset
use the correct business centre
calculate the floating amount
settle on the payment date

So even a simple IRS is not just static data. It contains rules that define how the product should be interpreted, calculated, validated, and processed.

Another important CDM idea is qualification.

The product label does not need to come first. CDM can first represent the economic structure, and then qualify the product from that structure.

For our example, the structure says:

two interest rate payouts
one fixed
one floating
same currency
scheduled payments
no principal exchange

From this structure, the product can be qualified as an interest rate swap, more specifically a fixed-float IRS.

This is different from the traditional approach:

ProductType = IRS

and then attaching fields to that label.

The CDM approach is closer to:

build the product from economic components
then qualify what it is

This topic deserves more detail, especially CDM product qualification and how it can support an AI-readable semantic layer. I will come back to it in later posts.

The Full Mapping

We can now map the financial product nature from the previous article to the CDM structure in this article.

This table is the bridge between the two articles.

The previous article asked:

What is a financial product?

This article asks:

How does CDM represent that nature?

The short answer is:

Nature:
    rights + obligations + transfers + timing + conditions
CDM:
    EconomicTerms + Payouts + PriceQuantity + Schedules + Settlement + Qualification

The important point is that CDM does not represent a financial product only through a product label. It represents the product through its economic structure.

For our IRS example, the label is “fixed-float interest rate swap”. But the real meaning comes from the structure underneath: two interest rate payouts, two parties, a notional amount, a fixed rate, a floating index, schedules, reset rules, and cash settlement.

What Comes Next

This article used one product, a vanilla fixed-float IRS, to show how the abstract nature of a financial product maps into CDM structure.

The next article will start from the core of the core:

payouts.

Market people often talk about “legs”. CDM uses “payouts”. They are related, but they are not exactly the same. Understanding that difference is one of the keys to understanding how CDM represents financial products.

• *AI-Native Financial Data Foundation