A few years back, I made an attempt to define and classify financial products from a data modelling perspective. I wrote about this in one of my earlier blog posts, Buy-Side Financial Data Models (2) – Financial Instruments.

At that time, I organised financial instruments using a framework based on asset classes, derivative types, and embedded features. For example, a product could be classified by whether it belonged to equity, fixed income, FX, rates, credit, or commodities. It could also be classified by whether it was a cash product, a forward, a swap, an option, or a more structured derivative. On top of that, we could add embedded features such as callability, putability, convertibility, barriers, amortisation, inflation linkage, or credit event dependency.

This approach was practical. There is nothing inherently wrong with it. Product labels, asset classes, and derivative categories are useful. Many people use this approach. They help people search, report, group, govern, and manage instruments.

However, over time, I kept hitting the limitations of this framework. For example, FICC products are often highly specific and idiosyncratic. Many of them are not clean members of a single product family. They combine ideas from multiple areas. A swaption is a simple example. Is it a swap? Is it an option? From a classification perspective, the answer is awkward because it has both swap and option characteristics. It is an option whose underlying economic result is entering into a swap. If the modelling framework forces us to choose only one category, we lose part of the product’s nature.

In addition, the number of possible product variations is difficult to exhaustively enumerate. In equities, many instruments can be organised reasonably well around security definition with standard structure. In FICC, the situation is more compositional. A product may combine a notional schedule, a floating rate index, a spread, a reset rule, a payment calendar, a business day convention, a settlement method, optionality, barriers, credit events, collateral terms, and many other features. Once these features start to combine, the number of product labels grows quickly.

The third and most important limitation is that classification does not necessarily explain the inherent characteristics of a financial product. A label tells us what something is commonly called. It does not always tell us what economic obligations exist, who pays whom, what is observed, what is scheduled, what is conditional, and what may be delivered or settled.

That is why, in this article, I want to make another attempt. Instead of starting from product labels, I want to explore what financial products are at a more fundamental level.

The approach I will use is simple in this blog article: I will walk through several representative financial products and look for the economic concepts that repeatedly appear across them.

Starting with the Simplest Case: Spot Equity

Let us begin with one of the simplest examples: a spot equity trade, before moving into the more exciting FICC world.

First, there are shares that represent ownership interests in an organisation. One party wants to transfer those pieces of ownership to another party. Economically, the structure is straightforward:

The buyer pays an agreed amount of cash.
The seller delivers the shares.

At first glance, this seems almost too simple to analyse. A buyer buys shares from a seller. The buyer pays cash, and the seller delivers shares. This is probably the most intuitive financial transaction most people can imagine.

However, even this simple example already reveals several important modelling concepts. There are parties involved in the arrangement. One party acts as the buyer, and the other party acts as the seller. There is an asset being delivered: the equity shares. There is also cash being paid. There is a quantity of shares, a price per share, and a cash amount derived from the price and quantity. Finally, there is settlement: the process by which the cash and shares are actually transferred.

So even before we touch any complex derivatives, we can already see that a financial product is not just a static object sitting in a product master table. It is connected to an agreement between parties. It involves economic value moving from one party to another.

At this stage,

The financial product appears to be an agreement to transfer an asset between parties.

This definition works for spot equity, but it is still too narrow.

Fixed Rate Bond: When Future Cashflow Obligations Appear

Now consider a fixed rate bond. A bond may look simple from the outside. An investor provides cash to an issuer. In return, the issuer promises to pay periodic coupons and repay principal at maturity.

Compared with spot equity, something fundamentally new appears.

The transaction is no longer just an immediate exchange of value. When the investor buys the bond, the investor may pay cash upfront. But the issuer’s side of the arrangement does not finish immediately. The issuer is expected to make coupon payments over time and repay principal at maturity.

These future payments are not random. They are defined by contractual terms such as coupon rate, notional amount, payment frequency, day count convention, business day convention, maturity date, and payment calendar.

This means a bond is more than an asset class. It is a legal and economic structure that gives one party the right to receive future payments and gives another party the obligation to make those payments. The economic nature of a bond is represented by a schedule of future cashflows agreed by the parties and described through those contractual terms.

So the modelling insight from a fixed rate bond is not simply that there is a future obligation. More precisely, it is that a financial product may define a structured schedule of future cashflow obligations.

Apart from a fixed rate bond, other examples of scheduled cashflows also appear in swaps, loans, CDS premium legs, structured notes, and many other FICC products.

At this stage, the definition of a financial product needs to expand:

A financial product is not only an agreement to transfer an asset. It may also define future cashflow rights and obligations between parties.

FX Forward: When Agreement and Settlement Are Separated

Now consider an FX forward. An FX forward is still relatively simple. Two parties agree to exchange two currencies. For example, one party agrees to deliver GBP and receive USD, while the other party agrees to deliver USD and receive GBP.

However, the key difference is time. The parties agree the economic terms today, but the actual currency exchange happens at a future settlement date. The exchange rate, currency amounts, and settlement date are agreed upfront, even though the cash movements occur later.

This introduces a different modelling concept from the bond.

A fixed rate bond introduces a schedule of future cashflows. An FX forward introduces a deferred exchange: the economic commitment is made today, but the settlement happens later. The structure is therefore not a long stream of recurring payments. It is a future exchange of two currency amounts.

The modelling insight is:

A financial product may separate the agreement date from the settlement date.

This is important because the product creates economic exposure before settlement happens. Between trade date and settlement date, market rates may move, but the agreed forward terms remain fixed.

So the financial product is not only about what is exchanged. It is also about when the exchange is agreed and when it is settled.

Deferred settlement also appears in forwards, futures, physically settled options, and many derivative contracts.

Interest Rate Swap: When the Product Is Not an Asset

Now consider a vanilla fixed-float interest rate swap. At first, people often describe it in a very simple way:

One party pays fixed.
The other party pays floating.

This sounds simple, but it introduces a very important modelling shift. Unlike spot equity, there is no share being delivered. Unlike a bond, there is no issuer borrowing principal and promising coupons to an investor. Unlike an FX forward, there may be no exchange of principal amounts at all. In many interest rate swaps, the notional amount is not exchanged. It is used mainly as a calculation basis for determining payment amounts.

This is where it becomes clear that a financial product does not have to be an asset.

Instead, an interest rate swap is actually a structured exchange of payment obligations. One payment stream is calculated using a fixed rate. The other payment stream is calculated using a floating rate, usually based on an interest rate observable.

So the modelling focus changes again.

For spot equity, the key concept was asset transfer.
For a bond, the key concept was scheduled cashflow obligations.
For an FX forward, the key concept was deferred settlement.
For an interest rate swap, the key concept is payout structure.

A vanilla fixed-float IRS contains two interest rate payout streams: fixed leg and floating leg.

Each stream needs its own modelling elements:

Modelling Element	Why It Matters
Payer / receiver	Defines who pays and who receives
Notional	Provides the calculation basis
Rate	Determines how the payment amount is calculated
Schedule	Defines accrual periods and payment dates
Observable	Required for the floating rate
Settlement terms	Defines how payments are settled

The floating leg is especially important because its cashflows may not be fully known at trade inception. The product does not store all future cashflow amounts directly. Instead, it defines how those cashflows should be calculated when the relevant interest rate observations become available.

This is an important modelling insight:

A financial product may define a calculation structure for future payouts, rather than a direct transfer of an asset.

This is why an interest rate swap is such an important example for product modelling. It shows that the core modelling unit is no longer the asset. The core modelling unit becomes the payout.

In other words, the product label should be the result of the economic structure, not the starting point of the model.

Other examples of payout-stream structures also appear in cross-currency swaps, inflation swaps, CDS, equity swaps, and structured products.

Credit Default Swap: When Obligations Become Conditional

Finally, consider a credit default swap. A CDS introduces another important concept: conditionality. In a simplified CDS, the protection buyer pays a periodic premium to the protection seller. In return, the protection seller makes a protection payment if a defined credit event occurs on a reference entity.

This is different from the previous examples. The premium payments may be scheduled, similar to other recurring cashflow structures. But the protection seller’s major obligation is contingent. It may never happen. It only becomes active if a defined credit event occurs.

So the modelling insight from a CDS is not merely that there are future payments. We have already seen future payments in bonds and swaps. The new insight is that some obligations are conditional on external events.

This makes a CDS a useful example because it shows that a financial product may contain obligations that are not guaranteed to occur. The obligation exists as part of the product structure, but whether it becomes an actual payment depends on a defined event.

The modelling insight is:

A financial product may contain contingent obligations that are triggered only under specified conditions.

At this point, the definition of a financial product needs to expand again.

It is not only an agreement to transfer assets.
It is not only a schedule of future cashflows.
It is not only a deferred exchange.
It is not only a payout calculation structure.
It may also contain conditional rights and obligations triggered by future events.

What do These Products Have in Common?

After walking through these examples, let’s summarise any pattern we can identify.

Spot equity, fixed rate bonds, FX forwards, interest rate swaps, CDS all look different at the product-label level. They belong to different asset classes. They are managed by different desks. They may be stored in different systems. They may even be governed by different operational processes.

But underneath the labels, the same economic concepts keep appearing.

Economic Concept	Spot Equity	Bond	FX Forward	IRS	CDS
Parties	✓	✓	✓	✓	✓
Asset or value transfer	✓	✓	✓
Exchange	✓		✓	✓
Future obligations		✓	✓	✓	✓
Scheduled cashflows		✓		✓	✓
Payer / receiver roles	✓	✓	✓	✓	✓
Quantity / notional	✓	✓	✓	✓	✓
Price / rate	✓	✓	✓	✓	✓
Observable dependency	Market price	Sometimes	FX rate	Interest rate	Credit / spread
Conditionality		Sometimes		Sometimes	✓
Exercise right		Sometimes		Sometimes
Settlement	✓	✓	✓	✓	✓

The important point is not whether this table is perfect. The important point is that product labels are not the deepest layer of the model.

The deeper layer consists of reusable economic concepts:

• parties
• rights
• obligations
• payouts
• transfers
• quantities
• prices
• rates
• observables
• schedules
• conditions
• triggers
• settlement
• exercise
• qualification

Once I started looking at products this way, I realised that financial products are not best understood as isolated labels.

They are compositions of reusable economic concepts.

So What Is a Financial Product?

After looking at these examples, the product labels start to feel less fundamental. Spot equity, fixed rate bond, FX forward, interest rate swap, and CDS all have different market names. They belong to different product families. They may be traded by different desks and stored in different systems. But underneath those labels, the same economic concepts keep appearing.

This leads to my current working definition:

A financial product is a structured arrangement of economic rights and obligations between parties, defining what may be paid, delivered, transferred, observed, calculated, exercised, or triggered, under what conditions, and when.

This definition is more abstract than saying “bond”, “swap”, “option”, or “CDS”. But that is exactly why it is useful.

A product label is a convenient market name. It helps people communicate quickly. But from a data modelling perspective, the label is not always the deepest truth of the product.

For example, saying:

ProductType = IRS

is useful, but incomplete.

A more meaningful model should be able to explain why the product is an IRS:

It contains two interest rate payout streams. One is fixed. One is floating. The floating stream references an interest rate observable. Both streams have notional amounts, schedules, payer/receiver roles, calculation rules, and settlement terms.

This is the main distinction.

In a classification-first model, the product label is the starting point.

In a structure-first model, the product label becomes the result of the economic structure.

That is the direction I now find more useful.

From Product Nature to Modelling Elements

I think this is the point where the discussion naturally moves from product definition to product modelling. The examples above all started with familiar product labels: spot equity, fixed rate bond, FX forward, interest rate swap, and CDS. However, the more I analysed them, the less important the labels seemed to become.

What kept appearing were reusable economic concepts:

• someone participates in the arrangement
• someone pays or receives
• something may be transferred
• an amount needs a calculation basis
• a value may depend on a market observable
• things happen over time
• some obligations depend on conditions or events
• some rights may or may not be exercised

If financial products are compositions of these economic concepts, then a financial product data model should be able to represent those concepts directly.

For example:

Economic Nature	Modelling Element
Someone participates in the arrangement	Party
Someone pays or receives	Payer / Receiver
Someone has an economic obligation	Payout
Something may be transferred	Transfer / Settlement
The amount needs a basis	Quantity / Notional
The value needs a price, rate, spread, or index	Price / Rate
Some values depend on market data	Observable
Things happen over time	Schedule
Some obligations depend on events	Condition / Trigger
A right may or may not be exercised	Exercise
The product needs a market-recognised label	Qualification

This table is not intended to be a complete financial product model. It is a conceptual bridge. It shows how we can move from the economic nature of a product to the modelling elements required to represent that nature.

Instead of trying to exhaustively enumerate every possible product type, we model the reusable economic concepts from which products are composed. The product label still matters. However, the label should sit on top of the structure, not replace the structure. In other words, the product type should be a consequence of the economic structure rather than the foundation of the model.

This is very different from my earlier classification-driven approach. And it eventually led me back to the ISDA Common Domain Model.

Why This Leads Naturally to ISDA CDM

This way of thinking eventually led me back to the ISDA Common Domain Model.

The reason is not simply that CDM is an industry standard. What really attracted me is its modelling strategy. One of the core design principles of ISDA CDM is the composibility.

“To ensure re-usability across different markets, the CDM is designed as a composable model whereby financial objects can be constructed bottom-up based on building-block components.”- ISDA

CDM does not try to model every financial product as a completely separate object with its own specialised structure. Instead, it defines reusable building blocks that can be composed to represent different products. This is very close to the conclusion reached from the examples above.

A swaption should not be difficult simply because it has both swap and option characteristics. It can be understood as an exercise right over a swap-like economic structure.

A CDS should not be modelled only as a credit derivative label. It can be understood as a premium payment structure combined with a contingent protection obligation.

An IRS should not be reduced to the label InterestRateSwap. It can be understood through its underlying economic structure.

In this way, the object type is not always declared upfront as the primary modelling foundation. Instead, the product can be identified, qualified, or classified based on how its economic components are populated. It means consistency comes from structure, not naming convention..

Conclusion: From Product Nature to Concrete Modelling

The main lesson from this exploration is simple. Financial products are not best understood as labels. They are better understood as structured arrangements of economic rights and obligations between parties. Once this structure is represented explicitly, the product label becomes much easier to understand.

The product is no longer just a row in a product master table. It becomes a machine-readable representation of economic meaning. That is what attracted me to the ISDA CDM product model.

From the next article, I will start to discuss the ISDA CDM more directly. However, before jumping into each individual concept in the model, I want to first use a vanilla fixed-float interest rate swap as an overview example. The goal is not simply to explain how an IRS works. The goal is to show, at a high level, how the product nature discussed in this article can be represented in the ISDA CDM product model.

• AI-Native Financial Data Foundation