• Insight
  • Thursday 9th December 2021

CDM myth #1: it’s a new standard

This post is the first in a series where we’re going to discuss the Common Domain Model (CDM). The series is targeted at any industry participant with interest in the CDM, ranging anywhere on the spectrum from newcomer to expert. You may work at a financial institution, a technology provider or a professional services firm, and from across functional units – not just engineering or data architecture.

One of the biggest misunderstanding about the CDM is that it is neither a storage nor a messaging format

We intend to be thought-provoking and running against received wisdom. Much has been written already to present the CDM, its capabilities and benefits for the financial industry. Instead, we want to try and uncover some fundamental truths by dispelling some myths about the CDM.

But first… Where is our CDM vantage point coming from?

REGnosys is acting as the technology partner to the industry’s trade associations who have been developing the CDM. The journey started in 2018 with ISDA, who released an initial version (CDM 2.0) in open-source in 2019 for the Derivatives market. More recently, ISLA and ICMA have added extensions for Securities Lending and the Bond and Repo markets, respectively.

From a technical perspective, the CDM is being developed, tested and released using REGnosys’ domain-modelling platform (Rosetta) where it is expressed in the Rosetta Domain-Specific Language (DSL).

In sum, when it comes to the CDM, we sit at the reactor’s core!

What do we mean by “standard”?

The capital markets’ industry is replete with electronic standards. These standards provide a mission-critical mechanism for market participants to capture information about transactions or other types of activity electronically: either to store it (database format) or exchange it (messaging format). In its simplest form, such a standard defines the schema under which data are represented, as in an XML or JSON Schema Definition.

Each standard fulfils a well⁠-⁠defined mission, supporting technology solutions that address specific requirements in the transaction lifecycle

To illustrate how such standards proliferate, let’s consider a practical front-to-back example. Under the regulatory push to provide more transparency about trading activity, a derivative transaction may be initiated, quoted and executed on an electronic trading venue using the FIX protocol, then matched and confirmed based on an FpML payload, and eventually reported to a trade repository using an ISO 20022 message.

Each such standard fulfils a well-defined mission, supporting technology solutions that address specific requirements in the transaction lifecycle, whether for electronic trading, matching or reporting. In turn, solutions which are supported by such open standards can attract a critical mass of market participants and perform a utility-like function.

Why is the CDM not a standard?

By contrast, the CDM does not purport to provide either a storage or a messaging format. It does not look to replace any of the existing standards already in use. And crucially, it does not look to displace any of the technology solutions already widely adopted by the market – although it may facilitate the emergence of competing alternatives.

Wait… What?

Yes, you read correctly: the CDM is not a data format, for either storage or messaging.

To this day, not one of REGnosys’ clients has had to re⁠-⁠engineer their source systems to take advantage of CDM

This is one of the biggest misunderstanding about the CDM. As a logical model, its underlying entity-relationship structure can be automatically converted into a data format to “visualise” CDM objects (say in JSON or XML, via a process known as serialisation) and even present them graphically. But this “human-readable” representation is just that, i.e. a convenient tool allowing users to examine the content of a CDM transaction – it isn’t the CDM itself.

This serialised representation does not, and probably should not, directly support any database implementation of the CDM – a proposition that will probably sound obvious to any database engineer looking at how deep the logical model is.

What about messaging?

Now, surely, this serialised representation could support a messaging system communicating CDM-based information about transactions?

FpML and other data formats can absolutely be the vector of CDM⁠-⁠based information and support CDM⁠-⁠based solutions

Yes, of course, it could… But should it? The response here will depend on the use case. Where existing formats are already well established and supporting robust solutions, better to ensure that the CDM can map to and from those formats.

For example, so long as FpML can be mapped to CDM, FpML can absolutely be the vector of CDM-based transaction information and support a CDM-based matching and confirmation solution. There is no contradiction here: as a logical model, the CDM exists independently of its physical transport mechanism.

In other cases, format is mandated by regulatory fiat, such as ISO 20022 for reporting. Again that’s no problem: to support a reporting solution, the CDM must be able to be mapped into the ISO format – but it does not claim to supersede any such format.

What is the CDM, then?

According to its canonical definition, the CDM is “a standardised, digital blueprint for the processing of financial transactions through the lifecycle”.

Of course it is standardised: the CDM is meant to deliver a “common” (i.e. single) logical model for the transaction lifecycle. A great deal of toil, blood, sweat (and tears) has already been, and continues to be, invested into normalisation: that is, identifying common patterns across disparate industry processes and designing the CDM to provide a common support across those. The composable, building-block approach for the product and event model or the abstraction of the price and quantity concepts are prime examples (and will be discussed in later posts).

The CDM’s focus on logic enables interoperability between existing standards and systems

But being standardised does not imply that the CDM is a standard. This statement would wrongly suggest that:

1. It is the standard that supersedes existing ones in its surface area – otherwise, why bother creating a new one?

2. To benefit, participants first have to rip-up the road layout and re-engineer their systems to be CDM-native.

Instead, the CDM’s focus on logic enables interoperability between existing standards and systems. To take our previous derivatives front-to-back flow example: the CDM provides a single, logical layer to articulate from a FIX into an FpML and into an ISO message.

REGnosys is working with a number of clients and partners looking at implementing CDM solutions in production. To this day, not one of them has had to go the way of re-engineering their source systems to take advantage of CDM – although some technology providers have decided to be CDM-native from the start (a wise choice that we can only recommend!)

Ready to roll?

Please get in touch with REGnosys to see how we can help you benefit from the CDM.

Leo Labeis

Leo Labeis

Founder & CEO at REGnosys

Read more

Reporting Audit

First, map your data into CDM...

We have it covered it. All it takes is a +/- 2-day immersion workshop with your tech team to build your mappings.
As a by-product, you get a ready-to-use API to convert all your trade data

… And access your audit results on-line…

Once your trade data have been mapped, our reporting engine compares its output to your reports and analyses any discrepancy.
Analysis is developed within 6 weeks and results published into a web application.

… Through a powerful user interface

Forget static audit reports that end-up on a shelf.
Our reporting engine is available on-demand to reconcile your reporting process end-to-end and down to single trade flow, through a fully interactive interface.
Contact us

CDM Integration

We do the data mappings for you…

Just extract transaction data from your booking, reporting or any other systems, we handle the rest.
We build mappings in immersion with your tech team, as a packaged +/- 2-day workshop that includes valuable CDM training – and is fun (yes, really)!

… And deliver you a packaged output…

Forget data mapping spreadsheets and forget hard-coded translation buried deep into your code base.
What you get is a transparent, maintainable CDM translation dictionary, automatically packaged into an API to translate your internal trade messages.

… Which you can start using right away

Start using the API for testing right away. For production deployment, we offer a range of hosting options that adapt to your technology stack.
The application grows with you. Just edit your dictionary to connect more and more systems to CDM.
Contact us

Model-Driven Regulation

Bring-on the regulatory text…

Can be anything in your existing corpus, as long as it’s digestible and relatively self-contained.
The target is to deconstruct that text and reconstruct a model of the regulation in +/- 2 days.

… We’ll handle the rest…

Our team of regulatory and engineering experts works in immersion with you and guide the process from start to finish.
Our promise: some executable code running by the end of the workshop, delivered to you and ready for demonstration.

… And you’re ready to develop rules on your own

All it takes is a cross-functional team, ideally all-encompassing from policy to technology, who is open to a fresh (and fun!) approach.
The buck doesn’t stop there. Your team is now empowered to carry that project forward inside your organisation.
Contact us

Data Modelling

Take an existing data pipeline of any form…

Just choose among your existing business processes to experiment a model-driven approach in +/- 2 days.​
We can start from any kind of artefact, from XML messages down to Excel or even PDF documents.

… To demonstrate the model-driven approach…

Our team of data engineering experts works in immersion with you and guide the process from start to finish.​
Our promise: some executable data pipeline running based on your model by the end of the workshop.

… Which you can deploy within your organisation

All it takes is a cross-functional team of developers and non-developers, who is open to a fresh (and fun!) approach.​
The buck doesn’t stop there. That team is now empowered to carry that project forward and build model-based pipelines for your organisation.
Contact us