How is the Common Domain Model standardising post-trade?

The complexity involved in trade processing has, for years, put market participants under considerable strain. Navigating this landscape has proved increasingly difficult due to the number of overlapping requirements introduced in the past decade, forcing firms to constantly recalibrate their workflows.

by Leo Labeis, CEO, REGnosys

The Common Domain Model (CDM) has emerged as one of the leading technologies designed to tackle this problem. The CDM is an open-source, human-readable and machine-executable data model for trade products and processes. It creates a digital representation of contracts and events across the lifecycle of financial transactions while supporting the conversion to and from existing messaging standards. This allows market participants to achieve consistency in the interpretation and implementation of post-trade requirements.

Despite emerging as an important tool in achieving greater cohesiveness in trade processing, one of the most frequently levelled criticisms against the CDM is that it is a solution looking for a problem.

This criticism, however, misunderstands the very purpose that the CDM was created to serve. The 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 designed to unlock.

The CDM is not – and shouldn’t be – a solution

Solutions exist at every point of the trade lifecycle, from matching to reporting to collateral management. Some of these solutions are widely adopted by the industry, and in most cases, organisations can choose between multiple available solutions.

The problem that persists across the post-trade landscape is not about a lack of solutions – it’s about a lack of interoperability. New mandates introduced after the 2008 global financial crisis, such as clearing, reporting or margin requirements, have led to a proliferation of new processes and fragmented approaches globally. ISDA itself has recognised that the “industry’s limited resources are not always focussed on developing and delivering common solutions.”

So, the need is not for another solution – the industry already has many of these. This is exactly why the CDM is not a solution and never should be. In this scenario – if the CDM was crafted to be a solution to a specific pain point in the trade lifecycle – the model would be customised to 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 upfront. As a result, most downstream trade processes, for instance, clearing or reporting, are engineered based on product types, even though they may not be the relevant classification for those processes.

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

If the CDM isn’t a solution, then what is it?

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

That the CDM is “coded” explains why it is often mistaken for a solution, based on the assumption that code equates to a solution. It is more accurate to think of the CDM as a library distributed in multiple languages and accompanied by visual representations. That code library is directly usable in solution implementations but critically remains independent of any particular solution or system.

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

Importantly, DRR is only an application of the CDM. It does not directly interfere with the CDM, so the latter remains free of any reporting perspective. For instance, the processing of transaction inputs with static referential data, often jurisdiction-specific, is part of DRR but not of the CDM.

Keeping the CDM as a genuine common denominator is key to ensuring its status as a pivot between different trade processes without being encumbered by any particular one.

Looking ahead

The CDM has enormous potential to foster greater standardisation across the post-trade landscape. It can work in a complementary way to any other data standards – including FIX, FpML or ISO 20022 – and can be integrated into the internal systems of market participants, enabling data to be interpreted consistently across the board.

To realise this potential, it is vital for the industry to fully understand that not making the CDM a solution to a specific problem is what allows it to achieve this harmonisation. In doing so, firms can begin to implement more innovative and strategic approaches to data management.