Trade Lifecycle & Instrument Modeling
A trade is not a row; it is a story that unfolds over time. This course models the full lifecycle as explicit events and states, from capture through amendment, novation, and termination, over the instrument structures that make each trade what it is.
The pipeline at the heart of this course
The lifecycle as data events
Most people picture a trade as a static record, but a trade is better understood as a sequence of events applied to an evolving state. It is captured, perhaps amended, maybe novated to a new counterparty, and eventually settled or terminated. Each of these is an event that changes the trade's state and ripples into positions, P&L, and risk. Modeling the lifecycle as events rather than as a single mutable row is what makes a trading system auditable and reconstructable.
This course makes that model explicit. You define the set of legal states a trade can occupy and the transitions between them, so that the system can never move a trade into an impossible state, a settled trade cannot be amended, an expired option cannot be exercised. The state machine is not documentation; it is enforced.
The shift from thinking in rows to thinking in events is the conceptual heart of the course, and it pays off everywhere downstream. Once a trade is a sequence of events, its history is free, its audit trail is complete, and any past state is a replay away, and the streaming and event-sourcing courses build directly on this foundation. The course spends time on this shift because it is the idea that makes the rest of the program coherent.
Instrument modeling
The lifecycle interacts with the structure of the instrument. A vanilla forward has a simple life; a swap has legs and a schedule of resets; an option has exercise and expiry; a structured trade has optionality that changes what events are even possible. This course models these instrument structures as data, so that the lifecycle engine knows, for any given trade, which events apply and what they mean.
You learn to represent forwards, futures, swaps, and options in a way that captures their cash-flow generation and their lifecycle behavior together, and to model the difference between physical and financial trades, which diverge sharply at settlement. The representation has to be rich enough for exotics but disciplined enough to query.
Instrument modeling is where the lifecycle meets financial structure, and the course refuses to hand-wave it. A forward, a swap, and an option have genuinely different lives, different events, different cash-flow mechanics, different ways of ending, and a model that pretends they are the same either loses information or becomes a mass of special cases. You learn to represent structure richly enough to be correct and disciplined enough to stay queryable.
Amendments and the audit of change
Amendments are where naive systems lose their integrity. When a trade's price or quantity is corrected, the question is not just what the new value is but what changed, when, by whom, and why, and whether every downstream number was recomputed. This course models amendment as an event that preserves the prior state, so that the full history is queryable and the audit trail is complete.
The same discipline covers novation, where a trade is assigned to a new counterparty, and termination, where it is unwound early. Each is a lifecycle event with defined effects, and each must leave the trade's history intact. The course connects this directly to the event-sourcing course, where the pattern is taken to its conclusion.
Amendments are the acid test of a lifecycle model. A system that handles capture and settlement cleanly but loses its integrity the moment a trade is corrected is a system that cannot be trusted, because corrections are routine and their history is exactly what audit asks about. The course models amendment, novation, and termination as first-class events that preserve the full before-and-after, so that the question of what changed always has a precise answer.
Fixings, resets, and schedules
Many trades are not static after capture: a floating-rate leg resets against a fixing, a schedule generates cash flows over months or years, an option accrues toward expiry. Modeling these time-driven events is essential, because they change positions and P&L without any human touching the trade. The course shows how schedules and fixings are represented and how the lifecycle engine applies them on the right dates.
This is also where idempotency first becomes critical: if a fixing event is applied twice, the trade must not double-count it. You learn to design lifecycle events so they can be safely replayed, a property that the streaming and STP courses depend on.
Time-driven events, fixings, resets, expiries, are where positions move without anyone touching a trade, and they are a common source of unexplained P&L in weaker systems. The course models these explicitly, on the dates they apply, so that the platform can always explain a position change as either a trade event or a scheduled one. This is also where idempotency first becomes essential, because a fixing applied twice must not double-count.
A queryable trade history
The course culminates in a data model where the full history of every trade is queryable: not just its current state but its state as of any past date, and the complete sequence of events that produced it. This is what lets risk reconstruct a book as it stood before a market move, and what lets audit answer exactly what happened and when.
The artifact below shows the lifecycle event model and the state machine as data. Notice that the current state is derived from events, not stored independently, so it can never disagree with the history.
The payoff of all this discipline is a genuinely queryable history, and the course makes that concrete. Not just the current state of a trade, but its state as of any past date, and the full ordered sequence of events that produced it, are available as queries rather than as forensic reconstruction. This is the capability that lets risk rebuild a book before a market move and lets audit answer exactly what happened and when.
The state machine as an enforced contract
A state machine is only useful if it is enforced, and this course is emphatic on that point. It is not enough to document that a settled trade cannot be amended; the system must make the amendment impossible, by consulting the transition table before applying any event and rejecting transitions that are not defined. This turns a whole class of business rules from wishful documentation into guarantees the data cannot violate.
The course walks through designing the transition table for real trading, including the awkward cases: a trade that is partially settled, an option that is exercised versus one that expires, a trade under dispute. Each is a state, and the legal moves out of it are edges in the machine. Getting this right means the lifecycle engine can be small and dumb, it just looks up whether a transition is allowed, while the intelligence lives in the data that defines the machine.
You also learn to version the state machine itself, because business rules change, and a trade captured under last year's rules must still be interpretable today. This connects to the bitemporal and event-sourcing ideas elsewhere in the bundle: the rules, like the data, have history.
Deriving state from events, and why it matters
The most important architectural choice in this course is to derive current state from the event history rather than storing it independently. If the current state of a trade is a stored column that is updated as events occur, then state and history are two separate things that can drift apart, and when they do, you have no way to know which is right. If instead the current state is computed from the events, the two can never disagree, because one is defined in terms of the other.
This has a cost, computing state means replaying events, and a benefit, the history is always authoritative and the state is always reconstructable, including as of any past date. The course shows how to manage the cost with derived views and, later, snapshots, while preserving the benefit. It is the same insight the event-sourcing course generalizes, met here first in the concrete setting of a single trade's life.
By the end you can build a lifecycle model where any question, what is this trade now, what was it last Tuesday, what exactly changed and when, is answered from one authoritative event history, with no possibility of the contradictions that plague systems built on mutable state.
Where this course sits, and what it unlocks
The lifecycle course is the third step, building events over the entities from the modeling course and preparing for the FpML course that feeds it representations. It also foreshadows the event-sourcing course, which generalizes the event-over-state pattern introduced here, and the STP capstone, whose flow begins with exactly this lifecycle model. Understanding the lifecycle as events is what makes the later real-time and automated courses coherent.
The applied project, modeling and implementing the full lifecycle as an enforced state machine, produces a component the capstone reuses directly. This is a recurring pattern in the bundle: each course builds a piece that the STP capstone assembles, so the sequence is not just pedagogical but constructive.
Common lifecycle failures, and how to avoid them
The most damaging lifecycle failure is storing current state independently of history, so that the two can drift apart and no one knows which is authoritative. Deriving state from events, as this course insists, eliminates that whole class of bug. A related failure is allowing illegal transitions, amending a settled trade, exercising an expired option, because the state machine is documented but not enforced; the fix is to consult the transition rules before applying any event.
A third failure is non-idempotent event handling, where replaying or re-delivering an event double-applies it, double-counting a fixing or a cash flow. Designing events to be idempotent, so applying one twice has the same effect as applying it once, is what makes the streaming and STP courses safe. The course establishes this discipline early and concretely.
By avoiding these patterns you get a lifecycle model whose state and history can never contradict each other and whose events can be safely replayed, the foundation the rest of the platform needs.
A worked example: amending a confirmed swap
Follow an amendment through the lifecycle model to see the design pay off. A confirmed swap needs its notional corrected. In a naive system, the notional column is simply overwritten, and the previous value, and the fact that it changed, are gone. In this course's model, the amendment is an event: the transition table confirms that a confirmed trade may be amended, an AMEND event is appended with the old and new values in its payload, and the trade's current state is recomputed from the events.
The result is that the trade's full history is intact: you can see exactly what the notional was before, what it became, when it changed, and, through the event payload, why. Every downstream number that depended on the notional, position, P&L, exposure, can be recomputed, and the audit trail is complete without any extra bookkeeping, because it is a natural consequence of modeling the amendment as an event rather than an overwrite.
This one amendment demonstrates the course's central claim: modeling lifecycle changes as events over an enforced state machine gives you auditability and reconstructability for free, where a mutable-state design gives you neither.
Operational realities: replay, corrections, and integrity
In production, lifecycle events arrive out of order, get re-delivered, and occasionally need correcting, and the course addresses each. Out-of-order and duplicate events are handled by idempotent design and explicit sequencing, so that applying an event twice, or applying events in the wrong order, does not corrupt the trade. Corrections are themselves events, compensating events that adjust state forward, never edits that rewrite history.
Integrity checks run continuously: does the current state derived from events match expectation, do lifecycle events reconcile against the trades they belong to, are there orphaned or contradictory events. These checks catch problems early, and because state is derived from an authoritative event history, a problem can always be diagnosed by examining the events rather than guessing at a mutated row. This operational robustness is what the streaming and STP courses build on.
Design trade-offs: mutable state versus event history
The tempting design is to store a trade as one row and update it in place as it changes, and for a simple system it works until the first time someone asks what the trade looked like last Tuesday, or who changed the price and when, or why the position moved without a new trade. At that point the mutable row has already destroyed the answer. The alternative this course teaches, modeling the lifecycle as an ordered sequence of immutable events with current state derived from them, costs more up front and pays back every time history is questioned.
The trade-off is real: event history is more storage, more query complexity, and more conceptual load than a single updatable row. But trading is a domain where the questions history answers, audit, reconstruction, dispute resolution, are not optional, and where a state that cannot explain how it arose is a liability. The course shows how to get the auditability of events without the full ceremony of a distributed event store, a middle path that suits many ETRM systems.
Carrying the lifecycle into the capstone
The lifecycle model is the spine of the STP flow. Capture, amendment, novation, and settlement are lifecycle events, and the capstone's guarantee that a trade can be followed and reprocessed through every stage depends on those events being explicit and ordered. Idempotency, which you first meet here in the context of fixings and replayed events, is what lets the capstone reprocess a trade after a failure without double-settling it.
When the event-sourcing course later makes the log the source of truth and the streaming course drives positions in real time, they are both building on the lifecycle model established here. The capstone simply connects the stages, and it can only do so cleanly because each stage agrees on what a trade event is and how it may transition.
Performance and scale considerations
An event-based lifecycle trades storage and read complexity for auditability, and this course is clear about managing that trade-off at scale. Deriving current state by folding events is more expensive than reading a row, so the course shows how snapshots and materialized current-state views keep the common query fast while the full event history stays available. The design goal is that the everyday read is cheap and only the rare historical reconstruction pays the full replay cost.
High-volume lifecycle events, fixings across large portfolios, batch amendments, scheduled cash flows, are where naive designs slow down, so the course teaches processing them in bulk and idempotently. Applying a day's fixings as a set rather than one trade at a time, and doing so in a way that is safe to retry, is what keeps the lifecycle engine fast under the load a real book generates.
Testing and validating the lifecycle
A lifecycle engine's correctness is testable in a way that ordinary CRUD is not, and the course exploits this. Because state is derived from events, you can test the engine by asserting that a given sequence of events produces the expected state, that illegal transitions are rejected, and that replaying the same events always yields the same result. Idempotency in particular is tested by applying events twice and confirming the state is unchanged.
The course also teaches reconstruction testing: take a real trade's event history, rebuild its state as of several past dates, and confirm each matches what the platform reported at the time. This is exactly the capability audit relies on, so testing it directly is how you gain confidence that the lifecycle model will answer correctly when it matters. You finish able to validate the engine's integrity rather than just hoping for it.
How it works, concretely
-- Legal states and the transitions the engine will allow
CREATE TABLE trade_state_transition (
from_state text NOT NULL,
event_type text NOT NULL,
to_state text NOT NULL,
PRIMARY KEY (from_state, event_type)
);
INSERT INTO trade_state_transition VALUES
('NEW', 'CONFIRM', 'CONFIRMED'),
('CONFIRMED', 'AMEND', 'CONFIRMED'),
('CONFIRMED', 'NOVATE', 'NOVATED'),
('CONFIRMED', 'TERMINATE', 'TERMINATED'),
('CONFIRMED', 'SETTLE', 'SETTLED');
-- No row for ('SETTLED','AMEND') => the engine refuses to amend a settled trade.
-- Immutable lifecycle events; the trade's state is a projection of these
CREATE TABLE trade_event (
event_id bigint PRIMARY KEY,
trade_id bigint NOT NULL REFERENCES trade(trade_id),
event_type text NOT NULL,
event_seq int NOT NULL, -- ordering within a trade
payload jsonb NOT NULL, -- what changed
event_time timestamptz NOT NULL,
UNIQUE (trade_id, event_seq)
);
-- Current state, derived (never written directly)
CREATE VIEW trade_current_state AS
SELECT trade_id,
(array_agg(to_state ORDER BY event_seq DESC))[1] AS state
FROM trade_event e
JOIN trade_state_transition t
ON t.event_type = e.event_type
GROUP BY trade_id;Chapters 41 to 60
Twenty sequential chapters. Within the full bundle these are chapters 41 through 60 of 240.
- 041The trade lifecycle as a sequence of data eventsSeeing a trade as a sequence of events rather than a single mutable row. Seeing the trade as events rather than a row is what makes it auditable and reconstructable.
- 042Deal capture: what is recorded and whenCapturing exactly what is recorded at deal entry and when. Capture defines the moment and the data from which the whole lifecycle unfolds.
- 043Trade states and the lifecycle state machineModeling legal states and the transitions a trade may make between them. The enforced state machine makes impossible transitions literally unrepresentable.
- 044Instrument modeling: forwards, futures, and swapsRepresenting forwards, futures, and swaps as queryable structures. Instrument structure determines which lifecycle events even apply to a given trade.
- 045Options, structures, and optionality in dataModeling options, structures, and the optionality that shapes their life. Optionality changes what events are possible, so it must be modeled explicitly.
- 046Physical vs financial trade representationDistinguishing physical from financial trades where they diverge at settlement. Physical and financial trades diverge sharply at settlement, and the model captures that.
- 047Legs, schedules, and cash-flow generationGenerating legs, schedules, and cash flows from the instrument. Schedules and legs are what generate the cash flows that valuation later consumes.
- 048Fixings, resets, and floating-price mechanicsHandling fixings, resets, and the mechanics of floating prices. Fixings and resets change positions and P&L without any human touching the trade.
- 049Amendments and the audit of what changedRecording amendments as events so what changed is always auditable. Modeling amendment as an event preserves exactly what changed, when, and by whom.
- 050Novation and assignment as data operationsModeling novation and assignment as controlled data operations. Novation is a data operation with defined effects, not an ad-hoc edit to a row.
- 051Termination, unwind, and early settlementHandling termination, unwind, and early settlement cleanly. Termination and unwind must leave the trade's full history intact for audit.
- 052Rollovers and their lifecycle impactApplying rollovers and their effect on the trade's life. Rollovers ripple into positions and P&L, so their lifecycle effect is modeled precisely.
- 053Give-ups, allocations, and block tradesModeling give-ups, allocations, and block trades. Allocations and block trades show how one captured deal becomes many booked trades.
- 054Exercise, expiry, and delivery eventsHandling exercise, expiry, and delivery as lifecycle events. Exercise, expiry, and delivery are the events that close out optionality and physical trades.
- 055Corporate actions and contract adjustmentsApplying corporate actions and contract adjustments. Corporate actions and adjustments change contracts in ways the model must absorb cleanly.
- 056Lifecycle events and downstream recalculationTriggering downstream recalculation when a lifecycle event fires. Every lifecycle event triggers the downstream recalculation that keeps numbers current.
- 057Idempotency and replaying lifecycle eventsDesigning events so replaying them is safe and idempotent. Idempotent events are what let a fixing or amendment be safely replayed without double-counting.
- 058Modeling exotic and structured tradesRepresenting exotic and structured trades without breaking the model. Exotic and structured trades stress the model and reveal whether it truly generalizes.
- 059Lifecycle integrity checks and reconciliationChecking lifecycle integrity and reconciling against expectation. Lifecycle integrity checks catch divergence between events and derived state early.
- 060A queryable trade-history data modelDelivering a data model where full trade history is queryable. You finish with a data model where any trade's state as of any date is a query.
What you'll be able to do
- Model a trade as an enforced state machine over immutable events
- Represent forwards, swaps, options, and structures as queryable data
- Handle amendments, novation, and termination with a complete audit trail
- Apply fixings, schedules, and lifecycle events idempotently
- Reconstruct any trade's state as of any past date from its event history
Audience & prerequisites
Engineers modeling how trades live and change over time, and anyone who needs a trade history that is auditable and reconstructable rather than a mutable row.
Prove the module by building it
Model the full trade lifecycle as an explicit state machine with event transitions, then implement capture, amend, novate, and terminate against your core schema with a queryable history.
This course project is one of twelve that culminate in the bundle's end-to-end capstone, a complete working ETRM data platform run as a straight-through pipeline.
Learn it your way
This course is included in the ETRM Data Engineering and Analytics bundle, available self-paced with PDF handbooks, slide decks, video explainers, and hands-on labs and a project, and deliverable as private corporate training.
Explore the full 12-course bundle and its end-to-end capstone project →
Frequently asked questions
What does the Trade Lifecycle & Instrument Modeling course cover?
How a deal moves from capture to settlement as data: events, states, amendments, and the instrument structures behind each trade. It runs to 20 sequential chapters (chapters 41 to 60 of the 240-chapter bundle).
Where does this sit in the learning path?
It is course 3 of 12 in the ETRM Data Engineering and Analytics sequence. It builds on the courses before it and prepares for those after it.
Is there a project?
Yes. Model the full trade lifecycle as an explicit state machine with event transitions, then implement capture, amend, novate, and terminate against your core schema with a queryable history.
What technologies are involved?
The course works with State machines, SQL, JSON, Python, Kafka, chosen to reflect how real ETRM data platforms are built.
Is it available self-paced?
Yes. Every course in the bundle is available self-paced with PDF handbooks, slide decks, video explainers, and hands-on labs and a project, with lifetime access.
Can my team take it as corporate training?
Yes. The whole bundle, or individual courses, can be delivered as private corporate training mapped to your stack and data. Use the contact form to scope it.
Take this course, or the whole platform
Enroll self-paced, or bring the ETRM Data Engineering bundle to your team.