LearnThe Trade Lifecycle01
0/7

Lesson 01 · 5 min

The Event Loop

One loop runs the whole lifecycle: before state in, instruction applied, after states out, name derived.

The book starts moving

By now Pershing Square has a full book: a swap, a swaption, a CDS, an equity swap, a commodity hedge. All of them snapshots. But this morning the swap's floating rate fixed, and a snapshot has no place to put that fact. This module is about what happens next: in the CDM, every change to a trade is a BusinessEvent, a piece of data that consumes the old state and produces the new one. Nothing is ever edited. The trade you booked stays exactly as booked, forever, and everything that happens to it lands on a line of events beside it.

02born03resets04amended05spawns06closeda new tradeTradeStatebeforeBusinessEventinstruction in, state outTradeStateafterevery pin on the line is one of these loops07the ledger: every pin above, recorded and replayable
Key ideas

  • States are snapshots; events are the verbs

    A BusinessEvent carries instructions, each pairing a before reference to a TradeState with what to do to it, and after, the list of states that result. Before in, after out, the input untouched.

  • Thirteen verbs cover the lifecycle

    PrimitiveInstruction is the full menu: execution, contractFormation, quantityChange, reset, exercise, partyChange, split, termsChange, transfer, observation, valuation, indexTransition, stockSplit. All optional, freely combined.

  • Intent is declared; the name is derived

    intent is what the submitter says they meant. eventQualifier is what the data shows, computed by qualification functions from the instructions and the before/after diff. The same split that derived product names earlier.

  • TradeState is the trade plus its memory

    TradeState holds the trade, its state, and four history lists: resetHistory, transferHistory, observationHistory, valuationHistory. The lifecycle accretes here.

One event, on the wire

{} businessEvent, a partial unwind, trimmed to the skeleton
{  "eventDate": "2026-10-15",  "effectiveDate": "2026-10-17",  "instruction": [    {      "before": "… the swap's TradeState, by reference …",      "primitiveInstruction": {        "quantityChange": "…"      }    }  ],  "after": [    "… the swap's new TradeState …"  ],  "eventQualifier": "PartialTermination"}
This exact event is the partial unwind, a few lessons on. Every lesson in the module is this same skeleton with a different verb inside primitiveInstruction and a different name derived at the end.

Declared intent, derived name

The model's own documentation is strict about intent: it exists for the cases where the data alone is ambiguous. A notional reduction could be a partial termination, a trade correction, or a portfolio rebalancing, and only the parties know which. Everything else is the qualifier's job. There are 39 event qualification functions in cdm.event.qualification, and each one inspects a candidate event the way Qualify_InterestRate_IRSwap_FixedFloat inspected a product: read the parts, derive the name. If the instructions and the diff say a quantity decreased and something remains, the event is a PartialTermination, whatever anyone calls it.

Try itOpen BusinessEvent in the explorer and walk instruction into primitiveInstruction. Count the verbs. Each one is a stop on this module's route.
◆ Checkpoint

01Where does eventQualifier come from?

1 / 3