Lesson 02 · 5 min

Birth of a Trade

Execution creates the state, formation makes it binding. positionState tracks the handshake step by step.

The deal on the desk

2026-04-15. Pershing Square and Goldman Sachs agree the fixed-float swap over the phone: USD 10,000,000, fixed against SOFR, five years. The handshake is real the moment it happens, but the confirmation lands a day later. The CDM models that honestly, as two events. An execution brings the trade into existence, and a contractFormation makes it legally binding. Between them, one small field on the state records exactly how far along the birth is.

Key ideas

Execution is the heaviest instruction in the model
ExecutionInstruction requires a product, priceQuantity, both counterparty roles, the real parties, executionDetails, tradeDate, and a tradeIdentifier: everything needed to build a trade from nothing. It is the one verb that needs no before.
Formation carries only the paperwork
ContractFormationInstruction has exactly one field: legalAgreement. The economics were already set at execution; this step binds them to the ISDA Master and the confirmation.
positionState tracks the handshake
PositionStatusEnum has five values: Executed, Formed, Settled, Cancelled, Closed. The birth walks the first two.
Where the deal happened is data too
executionDetails is required, and its executionType is an enum: Electronic, OnVenue, or OffFacility. A phone deal and a venue deal carry different reporting duties, so the model refuses to lose the distinction.

The execution event, on the wire

{} businessEvent, execution, trimmed

{  "eventDate": "2026-04-15",  "instruction": [    {      "primitiveInstruction": {        "execution": {          "product": "… the fixed-float swap, both legs …",          "priceQuantity": [            {              "quantity": [                {                  "value": 10000000,                  "unit": {                    "currency": "USD"                  }                }              ]            }          ],          "counterparty": [            "Party1: Pershing Square",            "Party2: Goldman Sachs"          ],          "executionDetails": {            "executionType": "OffFacility"a phone deal, off facility          },          "tradeDate": "2026-04-15",          "tradeIdentifier": [            {              "assignedIdentifier": [                {                  "identifier": "W22LROWP2IHZNBB6K528RT4K7Q20PXM3",                  "version": 1                }              ],              "identifierType": "UniqueTransactionIdentifier",the UTI: Goldman's LEI plus a unique suffix              "issuer": "W22LROWP2IHZNBB6K528"            }          ]        }      }    }  ],  "after": [    {      "trade": "… built from the instruction above …",      "state": {        "positionState": "Executed"executed, not yet binding      }    }  ],  "eventQualifier": "Execution"}

No before on the instruction: there is nothing to be before. The next morning a second, far smaller event applies contractFormation with the legal agreement, and the after state reads positionState: Formed.

Two qualifiers for two steps

Qualify_Execution checks that the execution verb stands alone and that no intent was declared: an execution is never ambiguous, so a declared intent actually disqualifies it. Qualify_ContractFormation accepts the formation verb alone or riding together with an execution, because the two steps can collapse into one event when a deal executes and confirms at once. Same protocol as product naming: the qualifier reads the parts, and the name follows from what is actually there.

Try itOpen Qualify_Execution in the Playground and run its examples. Then add an intent to the True payload and watch the qualifier reject it.

◆ Checkpoint

01What does an execution event NOT need?

1 / 3