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.

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.

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!

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.

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.

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.

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?

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.

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).

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!)

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