Lesson 05 · 6 min

Rules as Code

The DRR: one agreed interpretation, written in Rune on top of the CDM, run by everyone.

You have already run rules as code

Think back to the event qualifiers. Qualify_Novation is not a paragraph describing a novation. It is an executable test: shape in, verdict out, the same verdict for everyone who runs it. You ran those tests yourself in the Playground, 39 of them. Now imagine the same move applied not to event names but to an entire reporting rulebook: every field of the report written as a function instead of a sentence.

That is the Digital Regulatory Reporting programme, DRR, led by ISDA. The mechanics: for each regime, working groups of lawyers, operations staff, and engineers from member firms argue out what every field means, once, in the open. The agreed reading is written in Rune, the same language the CDM itself is written in, on top of the CDM types you have spent three modules learning. The code is published for anyone to read and run, and it is versioned, so when the regulator moves, the rules move as a release.

BEFOREevery firm rewritesevery regime, aloneAFTERindustry working grouplawyers and engineers, one readingthe rules, as codewritten once, run by alldealerfundvendordisagreements surface before go-live, not after
Key ideas
  • Interpretation happens once, in public

    The working-group argument replaces hundreds of private readings. Disagreements surface before go-live, as comments on a draft rule, instead of after, as breaks at a repository.

  • The best-practice document executes

    Industry guidance used to be one more PDF interpreting the others. DRR is guidance that runs: if you follow it, you follow it by executing it, and so does everyone else. Regulators can read it too.

  • It works because the input is shared

    A common rule can only read common data. DRR's rules are written against the CDM: the trades, payouts, and events this course has built. Without that shared shape there is nothing for shared logic to run on.

  • Qualifiers were the rehearsal

    Deriving an event name from shape and deriving a report field from shape are the same idea at different scales. If Qualify_PartialTermination made sense to you, DRR already does.

What a regime looks like in code

</> a report, declared (trimmed)
report ESMA EMIRRefit in T+1    from ReportableEvent    when IsReportableTransaction    with type EMIRTransactionReport
Trimmed, but true to form: Rune's report declaration names the authority, the deadline, the input type, the eligibility gate, and the report type. The input, ReportableEvent, wraps the workflow step and business event you already know, plus reporting context such as which side is reporting.

Where it runs

The first regime covered end to end was the CFTC Rewrite, in production use since its December 2022 go-live. The EU and UK EMIR Refits followed, then Japan's JFSA, Singapore's MAS, Australia's ASIC, Hong Kong's HKMA, and Canada's CSA rewrite, each built by the same process. When a regime amends its rules now, the change lands as a new DRR release, and a firm's upgrade starts with reading a diff rather than three hundred pages.

Be precise about what DRR is not. It is not a reporting service: nobody submits on your behalf. You still own connectivity to repositories, reference data, enrichment, and the quality of your own books. What it removes is the private-interpretation layer, the one that made lessons 2 and 3 expensive. The judgment moves into the open; the plumbing stays yours.

Try itRe-run Qualify_PartialTermination in the Playground and read it with this lesson's eyes: a tiny reporting rule. Shape in, verdict out, no analyst in the loop.
◆ Checkpoint

01Which layer of the reporting problem does DRR mutualize?

1 / 3