Core modelling components of DRR

A 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 is structured around three main modelling components:

• Types – define how data is represented in the model.
• Reporting rules – define regulatory logic attached to those data structures.
• Functions – define reusable logic used by rules and calculations.

Together, these components define how regulatory reports are produced from 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..

Types

A type defines the structure of a data object. Types represent domain concepts used 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., such as PartyInformation. A type describes the fields that belong to the object and the relationships between them.

This example shows the complex type PartyInformation.

type PartyInformation: <"Specifies party specific information required for reporting of the transaction.">
    partyReference Party (1..1) <"Specifies the party that is associated with the enriched information.">
        [metadata reference]
    relatedPerson NaturalPersonRole (0..*) <"The role(s) that natural person(s) may have in relation to the transaction.">
    relatedParty RelatedParty (0..*) <"Specifies one or more parties that perform a role within the transaction. The related party performs the role with respect to the party identified by the 'partyReference'.">

In this example:

• PartyInformation is the type.
• The type contains the attributes partyReference, relatedPerson, and relatedParty.
• Each field specifies 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. and a cardinalityCardinality The number of elements in a set or other grouping, as a property of that grouping..

Types form the foundation of 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. Reporting rules and functions operate on the data defined within these structures.

Reporting rules

Reporting rules define regulatory logic used to populate individual reporting fields.

A reporting rule is attached to a specific input type. The rule evaluates functional logic that extracts or derives a value from that type.

This example shows the reporting rule Counterparty2.

reporting rule Counterparty2 from TransactionReportInstruction: <"Counterparty 2">
    if cde.party.Counterparty2IdentifierTypeIndicator = True
        then cde.party.Counterparty2
    else reportingSide -> reportingCounterparty -> partyId -> identifier first

In this example:

• Counterparty2 is the rule name.
• TransactionReportInstruction is the input type.
• The rule evaluates logic to determine which value should be returned by calling reporting rules cde.party.Counterparty2IdentifierTypeIndicator and cde.party.Counterparty2 or extracting the identifier directly from reportingSide -> reportingCounterparty -> partyId.

Functions

Functions define reusable logic that can be used across the model.

A function accepts one or more inputs, performs a set of operations, and produces an output. Functions are typically used to encapsulate logic that may be required by multiple reporting rules.

The following example shows the function CounterpartyRoleFromLEI.

func CounterpartyRoleFromLEI:
    inputs:
        counterparties Counterparty (2..2)
        partyLei LEIIdentifier (0..1)
    output:
        reportingParty CounterpartyRoleEnum (0..1)
    alias party1: ExtractCounterpartyByRole(counterparties, Party1)
    alias party2: ExtractCounterpartyByRole(counterparties, Party2)

    set reportingParty:
        if partyLei = PartyLei(party1 -> partyReference -> partyId)
        then Party1
        else if partyLei = PartyLei(party2 -> partyReference -> partyId)
        then Party2

In this example:

• CounterpartyRoleFromLEI is the function name.
• Counterparty and LEIIdentifier are the input types.
• CounterpartyRoleEnum is the output type.
• party1 and party2 are temporary variables defined using alias.
• The functional logic that takes the inputs and returns the output variable reportingParty is defined after the keyword set.

Modelling components using Rune DSL

The Rune DSLRune DSL The domain-specific language built on Java that DRR uses for its logic. 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. additional modelling components that support more advanced modelling patterns, such as enumerations, conditions, metadata, mappings and other reusable constructs. You can find out more about these modelling and their syntax in Rune DSL modelling components.