Lesson 06 · 6 min

Inside a Reporting Rule

Eligibility, extraction paths, field labels, and citations that travel with the code.

One field, end to end

Take the UTI field of the October report and dissect it. In DRR a field is a reporting rule: a function from the reportable event to a value, labeled with the regulation's own name for the field, annotated with the provision it answers. Here is the shape of the one that produces the UTI:

</> reporting rule, the UTI field (trimmed)

[regulatoryReference ESMA EMIRRefitthe citation rides with the code    provision "Unique Transaction Identifier"]reporting rule UniqueTransactionIdentifier from ReportableEvent:    extract originatingWorkflowStep -> businessEvent -> after firsta path through types you can read        -> trade -> tradeIdentifier first        -> assignedIdentifier first -> identifier    as "Unique Transaction Identifier"the regulator's own field name

Trimmed: the production rule also filters tradeIdentifier by its identifierType before taking the first, so a USI never sneaks in. But every hop in that path is a type you already know.

Key ideas

A field is a function
Same input, same output, at every firm, with no analyst in the loop. The judgment happened once, in the working group; what ships is its conclusion, executable.
Paths are model walks
trade -> tradeIdentifier -> assignedIdentifier -> identifier is ordinary CDM grammar. If you can read a payout, you can read a reporting rule; the hard part of this lesson happened three modules ago.
Labels and citations are data
as "…" names the output with the regulation's field label; the annotation names the provision. An auditor can traverse from any reported value to the exact text it answers.
Eligibility is code too
Whether a trade is in scope at all, by asset class, party classification, venue, is its own set of rules using the same machinery. Scope arguments end the same way field arguments do: executably.

A second field, for the shape of it

</> reporting rule, notional (trimmed)

reporting rule NotionalAmountLeg1 from ReportableEvent:    extract originatingWorkflowStep -> businessEvent -> after firstfields read the trade as the event left it        -> trade -> tradeLot first        -> priceQuantity first -> quantity first -> valueafter October, this reads 6,000,000    as "Notional amount of leg 1"

Note where the path starts: the after state. Reports describe the trade as it stands, which is why module 3's state discipline matters to a regulator: a sloppy after state becomes a wrong number on a legal filing.

Walk the second path yourself: trade to Trade, whose lots you met earlier, down through priceQuantity to a quantity's value. Two hundred fields sounds like a mountain until you notice every one of them is this: a short walk, a label, a citation.

Try itWalk the UTI path by hand in the explorer: TradeState to Trade to AssignedIdentifier. Every reporting rule you will ever read is a path like this one.

◆ Checkpoint

01What does the `as "…"` clause on a reporting rule do?

1 / 3