How DRR works

Digital Regulatory Reporting (DRR) works by turning complex regulatory requirements into structured, machine‑readable logic that can be reused, tested, and executed consistently across jurisdictions. Instead of firms implementing their own interpretation of regulatory requirements, DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. presents an industry-led interpretation and understanding in a shared model that defines what needs to be reported and how the rules should be applied.

DRR workflow

The DRR workflow aims to translate regulatory text into machine-executable logic to produce standardised reporting outputs across jurisdictions.

1: Industry-led interpretation

The DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. project brings together different firms, large and small, to convert the often ambiguous and inconsistent language of regulatory text into logical code that is traceable and human-readable.

Working groups meet to discuss the reporting requirements for each regime, determining the required output for each field. Any ambiguous or unclear requirements are determined by group consensus, and if there is still an impasse then the group can go to the regulators directly.

Regulatory text may include:

• CFTC Part 43/45
• EMIR RTS/ITS
• ASIC DTR
• MAS reporting rules
• JFSA OTC reporting
• MiFID/MiFIR

2: Collaborative implementation effort

Following working group consensus on how fields should be reported, the interpretation is translated into DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. rules to build reports for the necessary jurisdictions. Because DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. is open access, the implementation effort can be spread across different industry participants meaning the workload and barrier to entry is significantly reduced for those seeking to adopt it.

Rune DSLRune DSL The domain-specific language built on Java that DRR uses for its logic. (the domain-specific language designed for DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data.) and DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. itself, are designed to be readable by professionals with domain knowledge (e.g. regulatory analysts), regardless of their programming competence or experience. This means that reporting logic can be written by any team member who understands the requirements and the regulation.

Working groups continue to meet regularly to discuss new or proposed changes to the model.

3: Scalable report design

DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. is designed to reduce duplication where possible while reusing components and logic across jurisdictions. Critical Data Elements set by the Committee on Payments and Market Infrastructures (CPMICPMI Committee on Payments and Market Infrastructures. The global standard‑setting body for payment systems, clearing, settlement, and other financial market infrastructure. It's made up of central banks from around the world.) and the International Organization of Securities Commissions (IOSCO), and common reporting fields act as the foundation for every regime, each leveraging the core components on a transcation report and further extending it to support their own reporting requirements. Logic only needs to be written once and it can be reused multiple times, making implementation of new jurisdictions faster.

type CommonTransactionReport extends cde.CriticalDataElement: <"Common Transaction Report represents common attributes">

4: Built-in testing and validation

Each report output in DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. is evaluated against a set of mandated data validation rules. These conditions and validations verify the data is correct syntactically, logically, and in accordance with allowable values set by the regulators.

This example shows a commonised validation rule that checks that counterparty1 must not be the same as counterparty2.

    condition DTCC_ASIC_BR_1006_01: <"Counterparty 1">
        [docReference ASIC DTCC_Specs table "1" dataElement "6" validationRule "Transaction"
        provision "when [Action Type] = NEWT, MODI, CORR, REVI, TERM, PRTO, ERROR, MARU, VALU then [Counterparty 1] must NOT = [Counterparty 2] if [Counterparty 2 identifier type] is = LEI"]
        common.party.Counterparty_Validation(
                actionType,
                counterparty2IdentifierType,
                counterparty1,
                counterparty2
            )

Synthetic data samples for each step’s inputs and output are captured in a 'Test Pack' that allows users to validate any implementation against those tests. Users can also test against their own proprietary data with their own anonymised samples.