Event Model

Join us for this 24 hours Event

The TDB event model provides data structures to represent the lifecycle events of financial transactions. A lifecycle event occurs when a transaction goes through a state transition initiated either by one or both trading parties, by contractual terms, or by external factors. For example, the execution of a trade is the initial event which results in the state of an executed trade. Subsequently, one party might initiate an allocation, both parties might initiate an amendment to a contractual agreement, or a default by an underlying entity on a Credit Default Swap would trigger a settlement according to defined protection terms.

Examples of lifecycle events supported by the CDM Event Model include the following:

Trade execution and confirmation

Clearing

Allocation

Settlement (including any future contingent cashflow payment)

Exercise of options

The representation of lifecycle events in the CDM is based on the following design principles:

A lifecycle event describes a state transition. There must be different before/after trade states based on that lifecycle event.

State transitions are functional and composable. The CDM specifies the entire functional logic to transition from one state to another. The state transition logic of all in-scope events is obtained by composition from a small set of functional building blocks.

The history of the trade state can be reconstructed at any point in the trade lifecycle. The CDM implements a lineage between states as the trade goes through state transitions.

The product underlying the transaction remains immutable. Automated events, for instance resets or cashflow payments, do not alter the product definition. Lifecycle events negotiated between the parties that give rise to a change in the trade economics generate a new instance of the product or trade as part of that specific event.

The state is trade-specific, not product-specific (i.e. the CDM is not an asset-servicing model). The same product may be associated to infinitely many trades, each with its own specific state, between any two parties.

To represent a state transition, the event model is organised around four main components:

Trade state represents the state in the lifecycle that the trade is in, from execution to settlement and maturity.

Primitive operator is the functional building block that is used to compose business events. Each operator describes a fundamental change to the state of a trade going from a before state to an after state and is parameterised by a primitive instruction input.

Business event represents a lifecycle event affecting one or more trades as a composite of primitive instructions. A business event can comprise several instructions, each consisting of a set of primitive instructions applied to a single trade state (before). The resulting trade state (after) can be multiple.

Workflow represents a set of actions or steps that are required to trigger a business event.

The below diagram illustrates the relationship between these components. Each of them is described in the next four sections.