Lesson 07 · 6 min

Events & the Trade Lifecycle

TradeState in, instructions applied, TradeState out: the lifecycle as auditable data.

Trades don't sit still

Everything so far described a trade at a single instant. Real trades live for years: rates reset, notionals grow, positions terminate. Most systems scatter that history across audit tables and overwritten rows. The CDM makes the lifecycle first-class data: the TradeState snapshots, the trade plus its current state, and events that transform them.

Key ideas

BusinessEvent transforms states
An event takes before-states, applies instructions, and produces after trade states. Before in, after out, nothing edited in place.
Instructions compose from primitives
PrimitiveInstruction is the toolbox of atomic changes: execution, quantity change, reset, transfer, party change. Composite events combine several in one go.
Events are typed by what they do
The eventQualifier ("Execution", "Reset", "Increase"…) is derived by qualification functions from the instructions and the before/after delta, exactly like product qualification.
The chain is your audit trail
Each event references what it changed. Follow the thread backwards and you can replay how today's position came to be: lineage for free.

Anatomy of an event

BusinessEvent extends EventInstruction, so it carries the intent (what was meant), the instructions (what to apply, against which before-state), the event and effective dates, and then the outcome: after, a list of resulting TradeStates.

{} businessEvent, execution, heavily trimmed

{  "eventDate": "2026-06-12",  "effectiveDate": "2026-06-15",  "instruction": [    {      "primitiveInstruction": {the atomic change being applied        "execution": {          "product": {            "economicTerms": "… the swap's economic terms …"          },          "priceQuantity": [            "… the lot: quantity and price …"          ],          "counterparty": [            "Party1 = Pershing Square",            "Party2 = Goldman Sachs"          ]        }      }    }  ],  "eventQualifier": "Execution",computed, never typed in  "after": [the new snapshot(s) the event produces    {      "trade": "… the full Trade, product plus identity …",      "state": {        "positionState": "Executed"      }    }  ]}

The pattern to internalise: instruction describes the change, after holds the resulting state, and eventQualifier is computed, here by Qualify_Execution. No intent appears: executions are unambiguous, and the qualifier requires it to be absent.

One pattern, the whole lifecycle

Every lifecycle action is the same shape with different primitive instructions. A reset observes the index and records it in resetHistory. An increase adds a trade lot, the quantity-and-price unit. A novation swaps a counterparty via partyChange. A termination closes the position state. Learn the before → instructions → after pattern once, and you can read any event in the model.

Try itYou've now met all three pillars: product, lot, event. Open Create_TradeState or any Qualify_* event function in the Playground and watch the lifecycle machinery run on real payloads.

◆ Checkpoint

01How does a BusinessEvent change a trade?

1 / 3

◆ Keep learning

More modules are coming

Drop your email and be the first to know when a new module ships.

◆ Feedback