Contribute to DRR

DRR is an open-access project built by the industry, for the industry. Anyone can potentially contribute – whether you’re fixing a bug, improving a rule, updating documentation, or helping with release notes. This guide explains, in simple terms, how you can get involved and why your contributions matter.

Benefits of contributing

1. Improve the industry standard: DRR is used across banks, vendors and regulators. Your contribution helps improve the shared logic everyone relies on.

2. Build your expertise: Working on DRR gives you hands on experience with:

The CDM
Regulatory reporting logic
Open-access governance
Real-world financial data models

This is valuable experience for any developer or modeller working in finance or regtech.

3. Help others understand the rules: Clear release notes, examples and documentation make DRR easier for everyone – especially new contributors.

4. Shape the future of regulatory reporting: DRR is becoming the industry’s shared source of truth. Contributing means you’re helping to define how reporting works across jurisdictions.

1. How to contribute (step by step)

If you’re comfortable reading DRR logic, you can help improve:

Reporting rules
Validation rules
Mapping logic
Example datasets

Your contribution might include:

Fixing an incorrect rule
Updating logic to match new regulatory guidance
Improving examples so they’re easier to understand

When describing rule changes, be explicit about:

What changed
Which examples were affected
What the new expected output is

1.1 Make your change

Before making your change, please see additional details for editing DRR Further details on design-principles for changes made can be found here You can request changes using the pull request system in the GitHub repository. Changes might include:

Editing a Markdown file
Updating a rule
Fixing an example
Writing release notes

1.2 Explain your change

Every contribution should include:

What changed
Why it changed
Where the change appears (e.g. file, rule, example)

Further information around change-control-guidelines

1.3 Submit your contribution

You can contribute through the normal workflow in the GitHub repository:

Fork the repository
Make your changes
Submit a pull request

A reviewer will look at your update, ask questions if needed, and help you get it merged.

Details on the how contributions are discussed and approved can be found here

2. Pull request (PR) standards

All contributions to DRR must be submitted via a pull request (PR) that meets the required standards.

2.1 Title

PR titles must be clear, specific, and descriptive. A reviewer should be able to understand the nature and scope of the change without opening the PR.

Do

Clearly state what is changing and where.
Reference the affected regime, common type, or architectural layer where applicable.

Do not

Use vague titles such as “Updates”, “Fixes”, or “Changes”.

Example

Add EMIR refit fields to CommonTransactionReport
Refactor ASIC margin mapping to use DRR base abstractions

2.2 Background and context

Each PR must include sufficient background to explain why the change is required.

Do

Describe the regulatory, architectural, or functional motivation.
Reference external specifications, tickets or regulatory texts where applicable.
Explain why the chosen approach is appropriate within the DRR architecture

2.3 Explanation and justification of changes

All non-trivial changes must be explicitly explained and justified in the PR description.

Do

Where possible, include references to supporting documentation or primary regulatory sources directly within the model using appropriate doc Reference or regulatory Reference annotations.
Clearly describe the behavioural or structural changes introduced.
Call out any deviations from existing patterns or common implementations.
Justify any relaxation or tightening of type constraints.

Where changes affect existing behaviour, the PR must clearly state:

What behaviour has changed.
Why the change is necessary.
Which jurisdictions or reports are impacted.

2.4 Review standards

PRs must demonstrate compliance with DRR 7 architectural boundaries. Further information on review standards can be found here

Do

Confirm that all CDM interactions occur exclusively via the DRR base layer.
Confirm that all changes have valid doc references or regulatory references.

Do not

Use duplicate or poor quality code.
Introduce direct CDM usage outside of base.
Add expectation diffs (differences) without explanations

2.5 Reviewer expectations

PRs that lack sufficient explanation, justification or architectural alignment may be returned for rework, even if the implementation is technically correct.

3. Architectural overview

All interactions between DRR and CDM must be implemented on the DRR base layer. Direct references to CDM types or semantics outside of base are not permitted.

This means that all regimes report against shared common report types:

CommonTransactionReport
CommonMarginReport
CommonValuationReport

Each common report type extends a corresponding CriticalDataElement (CDE), enabling consistent modelling of shared regulatory concepts and significantly reducing duplication across regimes.

3.1 Namespace dependency rules

This structure enforces a strict hierarchy governing allowable dependencies:

Regime namespaces may import from common and cde
Common namespaces may import from cde
CDE namespaces may only import from base

4. Contribution guidelines

4.1 Type structuring and metadata

Rune DSL allows regulatory metadata to be attached directly to both simple and complex types.

Do

Attach label, regulatoryReference, and ruleReference metadata directly to types.
Follow the standard annotation order:
1. label
2. regulatoryReference
3. ruleReference

Do not

Use empty ruleReference declarations to capture regulatory metadata.
Rely on rule source (deprecated).

Examples

override attribute boolean (0..1)
    [label "Test Label"]
    [regulatoryReference Jurisdiction table "1" dataElement "13" field "Attribute"
        provision "Example Provision"]
    [ruleReference AttributeRule]

override attribute Type (0..1)
    [ruleReference empty]

override attribute ComplexType (0..1)
    [label for nestedAttribute "Test Label"]
    [regulatoryReference for nestedAttribute Jurisdiction table "2" dataElement "55" field "Nested Attribute"
        provision "Example Provision"]
    [ruleReference for nestedAttribute NestedAttributeRule]

4.2 Jurisdiction-specific mappings

All new jurisdiction-specific mappings must be implemented using CommonTransactionReport and the appropriate CriticalDataElement types.

Do

Add attributes to CommonTransactionReport when required by more than one jurisdiction
Relax type constraints at the Common or CDE level if required, then reapply stricter constraints at the regime level
Reuse existing ruleReference’s defined in Common or CDE namespaces

Do not

Duplicate logic that already exists in CommonTransactionReport or CriticalDataElement.

When adding jurisdiction-specific rules for existing attributes:

Do

Prefer existing common rule references.
Make jurisdictional divergences explicit and easy to identify.

Do not

Create new rule logic where a suitable common rule already exists.

Example

reporting rule JurisdictionSpecificRule from TransactionReportInstruction: <"Cleared">
    filter IsAllowableAction
    then extract
        if common.CommonRule = value
        then extract jurisdiction
        else common.CommonRule

4.3 Validations

New validations must be assessed against existing validations across jurisdictions before introducing new logic.

Do

Reuse existing common validations where applicable
Promote validations to the common namespace when shared across jurisdictions

Do not

Implement new validations from scratch before confirming there is no existing equivalent.

5. Adding a new jurisdiction

The introduction of a new jurisdiction must follow a consistent and repeatable process:

5.1 Analyse reportable attributes

Identify all reportable fields required for the jurisdiction-specific report.

5.2 Classify attributes

Determine whether each attribute is:

Already present in CommonTransactionReport
Present in Common but not reportable (override with ruleReference empty)
Unique to the jurisdiction
Shared with one or more existing jurisdictions (promote to Common)

5.3 Document common attributes

Record new or reused common attributes in DRR tracking artefacts (e.g. Airtable) to ensure consistency and visibility.

5.4 Compare mappings and rule references

Assess differences between jurisdiction-specific mappings and existing common rules, promoting logic where appropriate.

5.5 Compare validations

Reuse existing common validations where possible. If validations are shared across jurisdictions, promote them to the common layer.

6. Release notes

Release notes explain what changed in each DRR release. They help users understand updates quickly and track how the model evolves. You can contribute by:

Writing clear summaries of changes.
Describing updates to rules, mappings, or documentation.
Showing before/after examples when something changes.
Explaining why a change was made.

Release notes are written in Markdown (.md), a simple formatting language. If you know how to write # headings and - bullets, you’re ready. If you’re not sure, take a look at this Markdown cheat sheet.

If you’re offering contributions via Rosetta, you can download this DRR Release Notes Template.

For additional background on governance and contribution processes you can also refer to the CDM Development Guidelines.

6.1 Tips for writing release notes

When you write release notes in Markdown, include:

A short headline e.g. # DRR EMIR Refit – Clearing threshold update.
A clear explanation of what changed.
Before/after examples if relevant.
A short justification (why the change was needed).
Directions for reviewers (where to look in the development environment e.g. Rosetta).

More tips

Use:

Correct grammar (e.g. complete sentences with full stops)
Consistent terminology (e.g. if you define ‘agreement specification details’ do not refer later to ‘agreement content’)
Bullets for lists
Third-person terminology (e.g. ‘the CDM model provides…’, not ‘we provide…’)

Markdown basics you’ll use:

# for headings
- for bullets
** ** for bold (use sparingly)
` ` back tick 'code quotes' for rule names, attributes, or functions

Example: Release note for EMIR refit

# **DRR EMIR refit - Rule model updates**

_Background_

The existing implementation for the EMIR Refit rules that are fully or partially aligned with the CDE and CFTC jurisdictions has been reviewed and updated to match the latest CFTC version using common functions.

_What is being released?_

This second release fixes various issues identified in the EMIR Refit rules listed below:

1. EMIR 2.1 - `UTI`:
  -    Replaced the filter based on the deprecated FpML's coding scheme unique-transaction-identifier by the CDM `identifierType`.
  -    Removed the filter to the last UTI version.

2. EMIR 1.2 - `Report Submitting Entity ID`:
  - Changed the `SupervisoryBodyEnum` value to `ESMA`.

_Review directions_

In Rosetta, select the Textual View and search for the released rules.

In Rosetta, open the reports tab, select the report `ESMA / EMIR Refit` and the dataset `Credit` and review the expectations for the field `2.1 - UTI` in the sample Credit-Swaption-Single-Name-ex01.

In Rosetta, open the reports tab, select the report `ESMA / EMIR Refit` and the dataset `Rates` and review the expectations for the field `1.2 - Report Submitting Entity ID` in the sample IR-Option-Swaption-ex01-Bermuda.

Example: Code snippets

Code snippets should be preceded by the string: .. code-block:: Language (where the Language could be any of Haskell, Java, JSON, etc), followed by a line spacing before the snippet itself.

So a code snippet that reads:

.. code-block:: Haskell

 type Party:
   [metadata key]
   partyId PartyIdentifier (1..*)
   name string (0..1)
     [metadata scheme]
   businessUnit BusinessUnit (0..*)
   person NaturalPerson (0..*)
   personRole NaturalPersonRole (0..*)
   account Account (0..1)
   contactInformation ContactInformation (0..1)

Will be rendered as:

type Party:
  [metadata key]
  partyId PartyIdentifier (1..*)
  name string (0..1)
    [metadata scheme]
  businessUnit BusinessUnit (0..*)
  person NaturalPerson (0..*)
  personRole NaturalPersonRole (0..*)
  account Account (0..1)
  contactInformation ContactInformation (0..1)

Note: Code snippets that appear in the user documentation are being compared against actual CDM components and any mismatch will trigger an error in the build. This ensures that the user documentation is kept in sync with the model in production before any release.

Benefits of contributing​

1. How to contribute (step by step)​

1.1 Make your change​

1.2 Explain your change​

1.3 Submit your contribution​

2. Pull request (PR) standards​

2.1 Title​

Do​

Do not​

Example​

2.2 Background and context​

Do​

2.3 Explanation and justification of changes​

Do​

2.4 Review standards​

Do​

Do not​

2.5 Reviewer expectations​

3. Architectural overview​

3.1 Namespace dependency rules​

4. Contribution guidelines​

4.1 Type structuring and metadata​

Do​

Do not​

Examples​

4.2 Jurisdiction-specific mappings​

Do​

Do not​

Do​

Do not​

Example​

4.3 Validations​

Do​

Do not​

5. Adding a new jurisdiction​

5.1 Analyse reportable attributes​

5.2 Classify attributes​

5.3 Document common attributes​

5.4 Compare mappings and rule references​

5.5 Compare validations​

6. Release notes​

6.1 Tips for writing release notes​

Benefits of contributing

1. How to contribute (step by step)

1.1 Make your change

1.2 Explain your change

1.3 Submit your contribution

2. Pull request (PR) standards

2.1 Title

Do

Do not

Example

2.2 Background and context

Do

2.3 Explanation and justification of changes

Do

2.4 Review standards

Do

Do not

2.5 Reviewer expectations

3. Architectural overview

3.1 Namespace dependency rules

4. Contribution guidelines

4.1 Type structuring and metadata

Do

Do not

Examples

4.2 Jurisdiction-specific mappings

Do

Do not

Do

Do not

Example

4.3 Validations

Do

Do not

5. Adding a new jurisdiction

5.1 Analyse reportable attributes

5.2 Classify attributes

5.3 Document common attributes

5.4 Compare mappings and rule references

5.5 Compare validations

6. Release notes

6.1 Tips for writing release notes