Skip to main content

Scope and structure

Reporting regimes​

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. currently supports these trade and transaction reporting regimes:

North America​

  • CFTCCFTC Commodity Futures Trading Commission – United States regulator overseeing derivatives markets, including swaps and futures. — Commodity Futures Trading Commission (United States)
  • SECSEC Securities and Exchange Commission – United States regulator overseeing securities markets (distinct from the CFTC, which covers derivatives). — Securities and Exchange Commission (United States)
  • CSACSA Canadian Securities Administrators – an umbrella organization of Canada’s provincial and territorial securities regulators. — Canadian Securities Administrators (Canada)

Europe and United Kingdom​

  • ESMAESMA European Securities and Markets Authority – EU‑level regulator responsible for securities markets, including EMIR reporting. — European Securities and Markets Authority (European Union)
  • FCAFCA Financial Conduct Authority – United Kingdom regulator overseeing financial markets, conduct, and reporting obligations. — Financial Conduct Authority (United Kingdom)

Asia‑Pacific​

  • ASICASIC Australian Securities and Investments Commission – the financial regulator for Australia — Australian Securities and Investments Commission (Australia)
  • HKMAHKMA Hong Kong Monetary Authority – Hong Kong’s central banking institution and regulator for OTC derivatives reporting. — Hong Kong Monetary Authority (Hong Kong)
  • JFSAJFSA Japan Financial Services Agency – Japan’s national regulator for banking, securities, and derivatives markets. — Japan Financial Services Agency (Japan)
  • MASMAS Monetary Authority of Singapore – Singapore’s central bank and integrated financial regulator. — Monetary Authority of Singapore (Singapore)

For each regulation, the model defines the set of regultory references together with their issuing authority. They are represented as:

  • Body – the entity that is the author, publisher or owner of the referenced document
  • Corpus – the document set that contains the referenced information
body Authority CFTC <"Commodity Futures Trading Commission (CFTC): The Federal regulatory agency established by the Commodity Futures Trading Act of 1974 to administer the Commodity Exchange Act.">

corpus Specifications "DTCC Specs" DTCC_Specs <"Document providing the message specifications required for inbound message for DTCC for CFTC.">

corpus Regulation "CFTC 17 CFR Parts 45 Version 3.0" Part45 <"Part 45 of the CFTCs regulations specifies the Commissions swap data recordkeeping and reporting requirements, pursuant to section 2(a)(13)(G) of the Commodity Exchange Act (CEA), which states that all swaps, whether cleared or uncleared, must be reported to a Swap Data Repository (SDR)">

The same structure is used for standard-setting bodies, such as 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.–IOSCO’s Critical Data Elements (CDECDE Critical Data Element):

body Authority CPMI_IOSCO <"IOSCO and the Committee on Payments and Market Infrastructures (CPMI) work together to enhance coordination of standard and policy development and implementation, regarding clearing, settlement and reporting arrangements including financial market infrastructures (FMIs) worldwide...">

corpus TechnicalGuidance "Harmonisation of Critical Data Elements (other than UTI and UPI)" CDE <"The G20 Leaders agreed in 2009 that all over-the-counter (OTC) derivative transactions should be reported to trade repositories (TRs) to further the goals of improving transparency, mitigating systemic risk and preventing market abuse...">

Namespace​

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. model adopts the CDM’s namespace structure. 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. reporting logic sits in a dedicated regulation layer, using the below convention:

drr.regulation.<body>.<regulation>

Reporting regulations can themselves be subdivided, for instance when regulatory specifications are revised:

drr.regulation.cftc.rewrite

Reporting regulations are then further subdivided by report type:

drr.regulation.cftc.rewrite.trade
drr.regulation.cftc.rewrite.margin
drr.regulation.cfrc.rewrite.valuation

By design, the model is composable. Therefore, there are some components which are not specific to any regulation and are built to be resuable across several of them. These components can be found in the drr.regulation.common namespace.

Elements defined in other namespaces can also be reused throughout the model by importing that namespace. For example, CDECDE Critical Data Element reporting rules defined in drr.standards.iosco.cde are leveraged and reused within the CFTCCFTC Commodity Futures Trading Commission – United States regulator overseeing derivatives markets, including swaps and futures. regulation namespace:

namespace drr.regulation.cftc.rewrite

import drr.standards.iosco.cde.*

This keeps the model modular, reusable, and consistent across jurisdictions. Read more about DRR namespace structure.

Reportable event​

All reporting regimes assume that reporting starts from a transaction event. 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., this is represented by the ReportableEvent data typedata type A structured model object that defines: what information exists; how that information is organised; what constraints or validations apply. It’s the basic building block used to model reporting concepts such as events, trades, parties, reports and enriched information.. The ReportableEvent type extends ReportableEventBase. This means ReportableEvent (known as a sub-type) inherits all of its behaviour and attributes from ReportableEventBase (known as super-type) and adds its own behaviour and attributes on top.

type ReportableEvent extends ReportableEventBase: <"Specifies a workflowstep with enriched information required for reporting.">
    [rootType]
    override reportableInformation ReportableInformation (1..1) <"Additional information required for a reportable transaction, including the reporting regime.">

type ReportableEventBase:
    originatingWorkflowStep WorkflowStep (1..1) <"The workflowstep that originated the reportable event.">
    reportableTrade TradeState (0..1) <"The reportable trade decomposed from the originating workflow step when required.">
    reportablePosition CounterpartyPositionState (0..1) <"The reportable position decomposed from the originating workflow step when required.">
    reportableInformation ReportableInformationBase (0..1) <"Additional information required for a reportable transaction, including the reporting regime.">

In the CDMCDM Common Domain Model. A standardised, machine-readable and machine-executable blueprint for how financial products are traded and managed across the transaction lifecycle. It is represented as a domain model and distributed in open source., the WorkflowStep data typedata type A structured model object that defines: what information exists; how that information is organised; what constraints or validations apply. It’s the basic building block used to model reporting concepts such as events, trades, parties, reports and enriched information., an attribute of ReportableEvent, is used to represent the state of a business event. While a WorkflowStep providesIDE Integrated Development Environment. A software application that brings together all the essential tools a developer needs to write, test and debug code in one unified workspace. some reportable information, a transaction will typically need to be enriched with further information that is only relevant in a reporting context.

The dedicated ReportableEvent data typedata type A structured model object that defines: what information exists; how that information is organised; what constraints or validations apply. It’s the basic building block used to model reporting concepts such as events, trades, parties, reports and enriched information. in 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. model allows us to capture this additional, enriched information, ready 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. consumption.

Report definition​

Each regulatory report is defined using three components:

  • What to report, i.e. the reportable fields
  • Whether to report – eligibility criteria.
  • When to report – timing (this is informational only, not executable).
report CFTC Part43 in T+1
    from TransactionReportInstruction
    when IsReportableEvent
  	with type CFTCPart43TransactionReport

The reportable fields are defined by specifying:

  • A body and corpus as the source of the reporting mandate - CFTC Part43
  • A timing constraint as a syntactic indication. Note this does not generate any executable code and therefore has no impact on the reporting process – T+1
  • Eligibity criteria which references a functional rule that returns a BooleanBoolean Data type with only two values (yes/no, on/off etc). – IsReportableEvent
  • The report's output as a data typedata type A structured model object that defines: what information exists; how that information is organised; what constraints or validations apply. It’s the basic building block used to model reporting concepts such as events, trades, parties, reports and enriched information. whose attributes represent the required reportable fields – CFTCPart43TransactionReport

In the report's output definition, each attribute (or reportable field) may be linked to a reporting rule through a ruleReference. A ruleReference contains the logic used to extract or compute the value to be reported for the associated attribute.

type CFTCPart43TransactionReport:
  [rootType]
  cleared string (1..1)
    [ruleReference Cleared]
  counterparty1 string (1..1)
    [ruleReference Counterparty1]

A report's output is validated using a condition. In the model, conditions are used to define the validation rules for reportable fields. Each condition evaluates to a BooleanBoolean Data type with only two values (yes/no, on/off etc). value, and if it evaluates to False, the validation fails.

condition ReportingTimestampCondition:
[regulatoryReference CFTC Part43 appendix "1" dataElement "97" validationRule "Transaction"
    provision "M, the value shall be equal to or later than the value in [Execution timestamp]"]
        reportingTimestamp = executionTimestamp or reportingTimestamp > executionTimestamp