How does the Common Domain Model standardize the back office?


  • CDM
  • Common domain model
  • Digital innovation

Leo Labeis, CEO, REGnosys

The complexity of trade processing has, for years, put market participants under considerable pressure. Navigating this landscape has proven increasingly difficult due to the number of overlapping requirements introduced over the past decade, forcing companies to constantly recalibrate their workflows.

by Leo Labeis, CEO, REGnosys

The Common Domain Model (CDM) has become one of the main technologies designed to solve this problem. The CDM is an open-source, human-readable, machine-executable data model for business products and processes. It creates a digital representation of contracts and events throughout the lifecycle of financial transactions while supporting conversion to and from existing messaging standards. This allows market participants to ensure consistency in interpreting and implementing post-trade requirements.

Although it appears to be an important tool for achieving greater cohesion in the treatment of exchanges, one of the most frequent criticisms leveled at the CDM is that it is a solution to the looking for a problem.

This criticism, however, ignores the very purpose for which the CDM was created. CDM has always been the analysis of a problem before being the outline of a solution. Not making the CDM a solution to a specific problem is precisely what allows it to tackle the inefficiencies it was meant to unlock.

The CDM is not – and should not be – a solution

Solutions exist at every stage of the transaction lifecycle, from matching to reporting to collateral management. Some of these solutions are widely adopted by the industry, and in most cases, organizations can choose from several available solutions.

The problem that persists in the post-trade landscape is not a lack of solutions, but a lack of interoperability. New mandates introduced after the 2008 global financial crisis, such as clearing, reporting or margining requirements, have resulted in a proliferation of new processes and fragmented approaches globally. ISDA she herself acknowledged that “limited industry resources are not always focused on developing and delivering common solutions”.

So, the need isn’t for another solution – the industry already has plenty of them. This is exactly why the CDM is not a solution and should never be. In this scenario – if the CDM was designed to be a solution to a specific problem in the business lifecycle – the model would be customized for that specific use case rather than promoting consistency and robustness.

The industry’s current approach to trade confirmation illustrates this pitfall. This process usually classifies products in advance. Therefore, most downstream business processes, for example clearing or declaration, are designed according to product types, even if they are not the relevant classification for these processes.

Before we knew it, the CDM would have perpetuated the very problem that current solutions suffer from – a lack of interoperability at different points in the business lifecycle.

If the CDM is not a solution, then what is?

What post-trade infrastructure needs is the development of common foundations for trading lifecycle processes, behaviors, and data elements. The CDM was created to meet this demand.

The fact that the CDM is “coded” explains why it is often confused with a solution, assuming that code equals a solution. It is more accurate to think of the CDM as a library distributed in several languages ​​and accompanied by visual representations. This code library is directly usable in solution implementations, but remains essentially independent of any particular solution or system.

Digital Regulatory Reporting (DRR) – an initiative originally championed by ISDA – provides the best illustration of this separation in action. DRR provides a standardized, coded interpretation of transaction reporting rules using MDP-based data to represent transaction inputs.

It is important to note that DRR is only one application of the CDM. It does not interfere directly with the MDP, which therefore remains free of any reporting perspective. For example, processing transaction inputs with static, often jurisdiction-specific referential data is part of RRC but not CDM.

Keeping the CDM as a true common denominator is essential to ensure its pivotal status between different business processes without being encumbered by any one in particular.

Look forward

The CDM has enormous potential to foster greater standardization in the post-trade landscape. It can operate as a complement to any other data standard – including FIX, FpML or ISO 20022 – and can be integrated into market players’ internal systems, enabling consistent data interpretation at all levels.

To realize this potential, it is vital that the industry understands that it is not by making the CDM a solution to a specific problem that it achieves this harmonization. By doing so, companies can begin to implement more innovative and strategic approaches to data management.

Previous post

Banking poverty: why a national identity database is essential for financial inclusion

Read more