Trade Reporting: The Case for Adopting a Unified Common Central Model

Keywords: #CDM, #DRR, #trade reporting, #regulatory reporting

"Trade reporting is simply a field mapping exercise. How hard can it be?" If the past 15 years of regulatory changes are any indicator, the answer is that it can be difficult. The good news is that it is about to get easier – hopefully.

There are at least four problems to solve: the central model, data management, legacy architecture and regulatory intelligence. In this article, we’ll focus on the first problem.

A Central Model

Motivation

Solving the impedance mismatch between models is hard, precisely because it is more than a field mapping exercise. For example, identifying a partial termination on a swap can be challenging. Some legacy systems do not fully model lifecycle events and merely show a notional reduction and freeform comments. In some cases, the identifier of the trade changes while it’s in progress.

Systems tend to be fragmented (typically by asset classes), meaning there are many internal post-trade processing models to be mapped to many reporting models for each jurisdiction.

The cost of this mapping, implementation and maintenance has increased over years of regulatory change. And the penalty for getting it wrong can be significant fines and more remediation costs.

The name of the game is to create a central model to mutualise the fields and rules where they overlap. ISDA estimated the overlap between CFTC and ESMA Emir to be around 50%, and at least 85% with specific rewrites (JFSA, FCA, ASIC, MAS, CSA, HKMA).

Critical data elements (CDE) are prime candidates to be modelled in the CDM due to the standardisation of their definition and data format. And since CDEs emerged from the BCBS 239 principles, they will overlap with market and credit risk management measures, which should provide the required data quality.

This harmonisation of the regulation should translate into simpler and more consistent reporting systems, which means faster and cheaper implementation – if we build a robust central model that supports:

• several jurisdictions
• future regulatory changes, hopefully toward ever more harmonisation
• future changes in your business, should you decide to trade new products
• new or evolving standards, such as ISO 20022

The Common Domain Model (CDM) offers exactly that. The Digital Regulatory Reporting (DRR) code can then use the CDM to provide:

• a machine-executable interpretation of the reporting requirements
• traceability back to the regulatory text
• testing and validations
• projections on data format mandated by the regulator, such as ISO 20022

Plus, this is all open-source, which guarantees transparency across the community.

ISDA has made great progress in covering 2024 changes. The DRR for CFTC, ESMA and JFSA is already available. The DRR developments for FCA, ASIC and MAS are being finalised (by April). The developments for HKMA and CSA (scheduled in 2025) will likely start as soon as there is more clarity about the requirements. The involvement of ICMA and ISLA to cover more asset classes has also reinforced the standard.

Adoption

The adoption of CDM/DRR can happen in phases, and each phase can be limited to a specific asset class:

1. Requirements: the DRR code is the unambiguous interpretation of the English regulatory text into a Domain Specific Language (DSL) that machines and humans can read. Firms can refer to the reporting rules in the DRR and compare notes with their interpretation.
2. Test pack: comparing the output of the DRR and your system (replicating the test cases provided) can be a useful addition to your testing campaign
3. Central model for reporting: this phase provides the full benefits of using the CDM for reporting, the cost being to map your internal model to the CDM.
4. Core model for trade processing: adopting CDM as the core model for trade processing will reduce further the frictions, so the reporting function becomes a simple projection of the core model.

Adoption Opportunities and Limitations

Adoption across trade processing functions could increase its benefits and accelerate adoption. The CDM represents the transaction, its associated products, lifecycle events and their processing, legal agreements and reference data (plus the mapping information to produce standard data formats such as FpML, FIX and ISO 20022).

Can the use of the CDM be extended beyond trade reporting or even beyond the trade processing scope? In theory, it can be extended to everything within the modelled domain. For example, it's already been used for collateral management. It could also help meet the operational efficient requirement of the T+1 settlement period (i.e., by simplifying reconciliation/matching and SSI selection).

Low latency or computationally intensive applications might not be suitable. However, there are also some limitations, simply because, by definition, different models are required for different domains. It would probably be unwise to use the CDM for real-time P&L and market risk, or order management. From a technical perspective, since the DSL is automatically translated into code (Java by default), there might also be limitations in the performance of the generated code. A proof of concept can assess the viability of the CDM in environments with constraints of scale, latency and throughput.

Tips and Accelerators

Data Management

The central model discussed above, whether it is the CDM or a proprietary model, lives on a platform where it is hydrated with data. Among other quality attributes, this platform must be:

• Secure: to ensure correct access control to sensitive data
• Reliable: to produce accurate and timely reports, including in periods of stress
• Flexible: to accommodate future changes
• Auditable: to explain and understand reported data
• Scalable: to support future growth, future regulatory reports, and the history of reports and associated data

This is why there should be a strong focus on robust data management, and on:

• data lineage that provides transparency with clear accountability and data ownership (as highlighted in BCBS 239 principles, applied to GSIBs/DSIBs)
• automation of policies (often based on metadata)
• monitoring and quality controls
• data dictionary and clear taxonomy

Legacy Architecture

Regulatory changes have been piling up for over 15 years since the first version of MiFID. This often results in sub-optimal infrastructure, disparate architecture and complex or poorly understood code.

Regulatory Intelligence

At the start of the regulatory reporting implementation process is "regulatory intelligence": scanning the horizon of regulatory changes, identifying what is relevant to your firm, enriching with relevant information, and managing your documentation. Third-party tools such as RegDelta excel at these tasks.

Conclusion

Faster and more cost-effective reporting is possible with a strategic approach based on robust data and metadata management and CDM/DRR.

Endava can help build robust data management foundations, modernise legacy and gradually adopt CDM.

References

FINOS website: https://cdm.finos.org/

Rosetta DSL: https://ui.rc.rosetta-technology.io

ISDA : https://www.isda.org/2023/04/04/drr-infohub/

Glossary

ASIC: The Australian Securities and Investments Commission regulates financial markets, corporations, and financial services in Australia.

CDE: Critical Data Element

CDM: Common Domain Model.

CFTC: The Commodity Futures Trading Commission regulates futures and options markets in the United States, promoting transparency and preventing fraud.

CSA: The Canadian Securities Administrators is the umbrella authority that supervise the regulation of the Canadian capital markets.

DRR: Digital Regulatory Reporting.

DSL: Domain Specific Language.

FCA: The Financial Conduct Authority is the regulatory body in the United Kingdom overseeing financial markets and firms, ensuring consumer protection and market integrity.

GSIB: Globally Systemically Important Bank. These are large banks whose failure could significantly impact the global financial system.

HKMA: The Hong Kong Monetary Authority supervises and regulates banks and financial institutions in Hong Kong, maintaining monetary stability and financial integrity.

ICMA: The International Capital Market Association supports the development of efficient and resilient capital markets globally, covering areas like bond issuance, repo markets, and sustainable finance.

ISDA: The International Swaps and Derivatives Association, a global trade association that represents participants in the derivatives market, focusing on standardizing and enhancing the industry.

ISLA: The International Securities Lending Association deals with securities lending and borrowing, promoting best practices and providing guidelines for market participants.

JFSA: The Japan Financial Services Agency supervises financial institutions, securities markets, and insurance companies in Japan.

MAS: The Monetary Authority of Singapore oversees monetary policy, financial stability, and financial services in Singapore.

MRER: Machine Readable and Executable Reporting.

SSI: Standard Settlement Instructions. These are standardized details used for settling financial transactions, including bank accounts, currencies, and intermediary information.