Why is Digital Regulatory Reporting (DRR) in CDM important?

• “Regulatory Reporting is a done deal”, 
• “We are not going to change our Regulatory Reporting implementation. It’s a cost center for us and we don’t really focus on it. It’s not the core of our business”, 
• “We have a reactive approach to Regulatory Reporting. Everytime a new regulation comes up, we create a new team and project to interpret and implement the new regulation.” 

We’ve heard these and similar statements in the capital markets industry over the past few years. Since the initial drafting of Dodd-Frank, billions of dollars are being spent on regulatory projects every year all over the world. However, are we done? Is Regulatory Reporting working? According to the recent penalties and fines given to major financial institutions, the answer is clearly NO.

What are the issues? Why are banks getting fined?

1. The data integration nightmare
1. In order to be able to report data to a regulator, a firm needs to aggregate, convert, and enrich the data from multiple systems, internal and external.  Regulatory reporting is just the tip of the iceberg. It requires a massive data integration effort.
2. Inconsistent product representations, business processes, and events
1. Different firms and systems represent the same products and business events in a different way. This implies the need for data transformation in order to represent products and events how the regulators want them. It requires a massive mapping effort.
3. Regulatory rules open to interpretation
1. Regulations are far from being crystal clear. They require interpretation from subject matter experts. Sometimes this is not enough and further clarification from the regulator is required.
2. Each financial institution needs to implement the regulatory project based on their own interpretation of the regulation. 

All these issues provide the framework for what regulatory projects are: really complex and costly projects involving data integration, aggregation, and deep business domain knowledge. 

What is CDM?

The ISDA Common Domain Model (CDM) is a standardized, machine-readable and machine-executable blueprint for how financial products are traded and managed across the transaction lifecycle. The product scope of the CDM includes OTC derivatives, cash securities, securities financing, and commodities. Detailed documentation on CDM is available here.

What is Digital Regulatory Reporting (DRR)?

DRR is the coding of regulatory rules in CDM. Yes, the rules are coded and the functional logic of each rule is implemented and distributed in multiple programming languages in an open source license.

ISDA and its members are currently developing a DRR implementation for CFTC rewrite and the new EMIR/Refit rules. The project started in 2021 and is continuing in 2022. More jurisdictions are expected to be included. TradeHeader is actively involved in the project implementing and testing all the rules.

An Example: CDS index attachment point

Let’s take a look at a specific CFTC field, #83 CDS index attachment point. Each field is modeled in CDM as a reporting rule with a reference to the regulation:

reporting rule CDSIndexAttachmentPoint <"CDS Index Attachment Point">

[regulatoryReference CFTC Part45 appendix "1" dataElement "83" field "CDS Index Attachment Point"

provision "Defined lower point at which the level of losses in the underlying portfolio reduces the notional of a tranche. For example, the notional in a tranche with an attachment point of 3% will be reduced after 3% of losses in the portfolio have occurred. This data element is not applicable if the transaction is not a CDS tranche transaction (index or custom basket)."]

The CFTC CDSIndexAttachmentPoint calls the reporting rule CDECDSIndexAttachmentPoint. CDS Index Attachment Point is a Critical Data Element (CDE) so the implementation of the rule can be reused across jurisdictions:

CDECDSIndexAttachmentPoint

as "83 CDS Index Attachment Point"

reporting rule CDECDSIndexAttachmentPoint <"CDS Index Attachment Point">

[regulatoryReference CPMI_IOSCO CDE section "2" field "81"

provision Same as above]

TradeForEvent

then extract Trade -> tradableProduct -> product -> contractualProduct -> economicTerms -> payout -> creditDefaultPayout -> generalTerms

then extract

The extraction logic for the credit index tranche product is:

if GeneralTerms -> indexReferenceInformation -> tranche exists

then GeneralTerms -> indexReferenceInformation -> tranche -> attachmentPoint

The extraction logic for the credit basket tranche product is:

else if GeneralTerms -> basketReferenceInformation -> tranche exists

then GeneralTerms -> basketReferenceInformation -> tranche -> attachmentPoint

as "2.81 CDS Index Attachment Point"

Conclusion: What are the benefits of DRR?

1. Provides a common industry interpretation of the rules in a free open-source implementation.
2. Each regulatory rule is implemented in a transparent functional testable logic.
3. Each rule implementation is tested against an open set of available test samples. There is traceability between modeling of the rules and testing.
4. The implementations of the rules that are the same in different jurisdictions (e.g. CDE rules) are reused, resulting in more efficiency.
5. The end product is code that can be used within firms in different phases of their regulatory projects: development, testing, and or production.
6. The distribution of the code is in multiple languages: Java, Scala, Kotlin,... so it can fit in existing technology architectures.
7. The same approach can be applied across jurisdictions.
8. The mutualization of the effort reduces costs and time to market.

We are in the process of standardizing a piece of the regulatory reporting via commoditized tooling that can be used across jurisdictions. We are following the path to having common and consistent implementable regulatory standards.