Your operations lead forwards a spreadsheet on Wednesday morning with eleven rows on it, each one a trade that should have settled on Tuesday and did not. Nine are the same cause. The system that booked those trades reported every one of them as complete, because by its own definition they were, and nothing in your product told anybody otherwise for two days.
The trade lifecycle is the sequence a trade moves through from order to final settlement and reporting, across the front, middle and back office. Every explanation of it draws the same left-to-right diagram of stages. That diagram describes the trade that works, and the trade that works is not the one your product exists to handle.
What follows assumes you already know the stage names. It is about what the stages hide: the breaks, the disagreements between systems, and the exception paths that end up carrying most of your support cost.
What the trade lifecycle diagram leaves out
The trade lifecycle diagram leaves out every path that is not straight through. It shows one lane running from order capture to settlement, with each stage handing cleanly to the next. In production, a meaningful minority of trades leave that lane at some point, and the work of handling them is where your product either helps or disappears.
Notice what the diagram implies about ownership. Each stage sits in a box belonging to a different team, which makes it look as though a trade is passed along like a parcel. A trade is not passed between systems; it is copied into each of them, and from that moment the copies can disagree. Nothing in the standard diagram represents that, so nothing in a specification built from the diagram handles it.
The second omission is time. The diagram is drawn as a sequence with no durations, which conceals the only thing that matters operationally: the gap between when something breaks and when a human finds out. A trade that fails matching at four in the afternoon and surfaces on a report the next morning has already consumed the window in which it could have been repaired cheaply.
Four systems hold a version of the same trade
A single trade exists simultaneously in your order management system, your counterparty's, the venue or matching platform, and the custodian or central securities depository. Each holds its own record with its own status field, updated on its own schedule. The product problem is not moving a trade through stages; it is reconciling four versions of one event.
This is why a single status field on your trade record is a design error you will pay for repeatedly. "Settled" according to whom, and as at when? A trade can be affirmed on the matching platform, unmatched at the depository, and shown as complete in your own database, all at the same moment, and every one of those statements is locally true.
Model it as one trade with a state per participant, each carrying a source, a timestamp and the message that produced it. That is more work than a status column and it is the difference between a product that can answer where a trade is and one that can only say what your own system last thought. It is the same modelling discipline that collateral agreements need for their eligibility terms, applied to a faster-moving object.
The tell that a system was built without this is the support question your team cannot answer: "where is my trade?" If answering it requires someone to open a custodian portal in another tab, your product has modelled the happy path and outsourced the rest to a human with credentials.
[ASHISH: add a real example of two systems disagreeing about the same trade, how long the disagreement went unnoticed, and what it took to reconcile]
Where trades break, and how each break reaches your product
Trades break at predictable points, and each break has a characteristic delay before anyone sees it. Allocation and enrichment failures surface within hours. Matching failures surface the same day. Settlement failures surface on intended settlement date, by which point the repair options are narrow and the cost is running.
| Stage | What breaks | How it fails in your product |
|---|---|---|
| Allocation | The client sends allocations late, or in a shape your system will not accept | The interface accepts the allocation after the downstream cut-off has passed and confirms it cheerfully, so the user believes the trade is fine until it is not. |
| Enrichment | Standing settlement instructions are missing, stale, or wrong for that market | The trade books cleanly and fails three days later. The defect was present at entry and nothing in the booking journey could have surfaced it. |
| Confirmation and affirmation | Counterparty's record differs on price, quantity, place of trading or settlement date | The mismatch lives in a third-party matching platform your product does not read, so your users learn about it by email and resolve it outside every system you own. |
| Clearing and margin | Your position calculation and the clearing house's do not agree | Two numbers exist and no view compares them, so a margin dispute becomes a phone call and the resolution is recorded nowhere. |
| Settlement | The counterparty does not deliver, or delivers part of the quantity | Partial settlement is available at the depository but not enabled in your instruction, so the entire amount fails and penalties accrue on the full value rather than the shortfall. |
| Post-settlement | A corporate action falls over the record date of an unsettled trade | A market claim arrives as a separate transaction with no link back to the original trade, so your client sees two unexplained entries and your support team reconstructs the chain by hand. |
Read the enrichment row as the most expensive one. A stale settlement instruction is cheap to prevent, invisible at the moment it causes harm, and detected only when money does not move. The cost of a break scales with the delay before detection, not with the difficulty of the fix.
How to specify a trade lifecycle exception path
Specifying an exception path starts with your own fails data rather than with a process diagram. The fails report tells you which breaks actually occur in your business, in what proportion, and that ranking is a better requirements backlog than any workshop will produce. Work through it in this order, and write the exception behaviour before the happy path.
- Export the last quarter of settlement fails and unmatched items, sorted by cause code. That distribution is your prioritisation, already weighted by frequency.
- For each cause, record which system detected it, which system holds the authoritative record, and the elapsed time between the break occurring and a human seeing it.
- Model the trade as one record with a state per participant — source, timestamp, originating message — rather than a single status field.
- Write the exception path for each stage before the happy path: who is notified, what they may change, what is immutable, and where the decision is recorded.
- Make partial settlement and hold-and-release explicit product decisions with a stated default, not configuration inherited from whoever ran the implementation.
- Hold every cut-off as data — market, custodian, internal — and display the earliest applicable one at the point of instruction, not in a help page.
- Instrument time-to-detect per break type and report it monthly. It is the only measure that tells you whether the exception handling is improving.
Step four is the one that gets deferred, and deferring it is how the exception queue becomes an inbox. Write the notification, the permitted amendments and the audit record into the acceptance criteria on the story itself rather than raising a follow-up ticket called "error handling", which is a ticket that never reaches the top of a backlog.
A specification that cannot say who repairs a break, within what window, and where that repair is recorded has not specified the product; it has specified a demo. The repair capability is the part operations judges you on, and it is almost always the part written last.
What settlement discipline does to your requirements
Settlement discipline turns operational failure into a direct, calculable cost, which changes how a product team argues for investment in exception handling. Under the Central Securities Depositories Regulation, cash penalties for late or failed settlement have applied in the European Union since February 2022, accruing daily against the failing participant until the instruction settles.
The trajectory is worth knowing before you cite it. European Securities and Markets Authority (ESMA) data reported fails peaking at roughly twelve per cent of settlement instructions in mid-2021, falling to around five per cent by April 2023 as penalties took effect. In its final technical advice on the penalty mechanism, published in 2024, ESMA proposed keeping the existing design with a moderate increase in rates rather than a redesign.
There is a caveat practitioners raise and vendor content omits. The International Capital Market Association argued in its 2024 briefing on the same consultation that penalty rates had become less material than prevailing interest rates, which impose their own cost on a failing party. Build the business case on the operational cost of a fail — the manual repair, the client call, the funding — rather than on the penalty alone, because the penalty is the smallest number in the set.
Infrastructure fails too, and your requirements should assume it. When a TARGET Services incident disrupted settlement across two days in February 2025, ESMA clarified that national authorities did not expect penalties to be applied for those dates. If your system cannot mark a set of fails as attributable to an infrastructure event and exclude them from your own reporting, somebody will do it in a spreadsheet.
Dated obligations are arriving on top of this. The move to a shorter settlement cycle in the United Kingdom, the European Union and Switzerland is set for October 2027, with allocation and confirmation requirements phased in ahead of it. Those are fixed dates with no value score, which is exactly the class of work that should be subtracted from capacity rather than ranked against features.
[VERIFY: the phased application dates for the revised CSDR settlement discipline requirements, checked against the Official Journal or ESMA's published text rather than a consultancy summary]
Terms worth agreeing once
Trade processing vocabulary is precise, and teams routinely use three of these terms interchangeably while meaning different things. Agree them with operations before refinement starts, because a disagreement about whether a trade is "confirmed" is usually a disagreement about which system is being described.
- Trade lifecycle — the sequence a trade moves through from order creation to settlement, reconciliation and reporting.
- Standing settlement instruction (SSI) — the stored account and delivery details for a counterparty in a given market and currency, used to route settlement.
- Affirmation — the buy side agreeing the details of a trade the sell side has confirmed, distinct from the confirmation itself.
- Matching — the comparison of both parties' settlement instructions at the depository, which can succeed or fail independently of confirmation.
- Partial settlement — settling the available quantity and leaving the remainder outstanding, rather than failing the whole instruction.
- Settlement fail — an instruction that does not settle on its intended settlement date, whether through lack of securities, lack of cash, or an unmatched instruction.
[ASHISH: add a real example of a fails pattern that turned out to have a single upstream cause, and how long it took to trace]
Who owns the trade lifecycle inside a product organisation
No single product manager owns the trade lifecycle end to end, and pretending otherwise produces specifications that stop at a team boundary. Order capture usually sits with a front-office product owner, enrichment and confirmation with a middle-office one, settlement with operations technology. The breaks happen at the seams between them.
The practical consequence is that the most valuable requirements work available to you is usually outside your own remit. A stale settlement instruction causes a settlement fail, but the fix belongs in a reference data screen owned by another team, and the business case lives in an operational cost your team does not carry. Nobody funds it, so it recurs quarterly.
Take the fails report to whoever owns the reference data with a number attached: this cause, this many fails last quarter, this many hours of repair. A cross-team defect only gets funded when somebody converts it from an operational annoyance into a cost with an owner's name against it. That conversation is the same shape as any other where the constraint sits outside your team, and it goes better when you have already established which rule or policy is genuinely fixed and which is habit.
The forward problem arrives with the shorter settlement cycle. The exception window that used to span a full business day compresses to hours, and the manual repairs your operations team performs by hand stop fitting inside it. At that point the question is no longer how to handle breaks, but which repairs get automated first — and answering it needs a cost per fail by cause, which is a number most firms have never calculated.
Frequently asked questions
What are the stages of the trade lifecycle?
Order creation, execution, capture and booking, enrichment, confirmation and affirmation, clearing, settlement, and post-trade reconciliation and reporting. The stage names vary between firms and asset classes. What matters operationally is not the list but the exception path attached to each stage, since that is where most of the processing effort and support cost actually sits.
What is the difference between confirmation and affirmation?
Confirmation is one party stating the agreed terms of the trade; affirmation is the other party agreeing that those terms are correct. Both are distinct from matching, which compares settlement instructions at the depository. A trade can be affirmed and still fail to match, because the two processes check different data at different points.
Why do trades fail to settle?
Most fails trace to a small number of causes: securities not available for delivery, insufficient cash, unmatched instructions from a data discrepancy, or missing and incorrect standing settlement instructions. Fails from stale reference data are the most preventable and the least visible, because the trade books cleanly and only fails days later.
What does a product manager own in the trade lifecycle?
The decisions the diagram does not show: how the trade is modelled across systems, what happens on each exception path, which cut-off is displayed to the user, whether partial settlement is enabled, and how quickly a break is detected. Stage processing is usually vendor or infrastructure behaviour. Exception handling is product.
How does a shorter settlement cycle change the trade lifecycle?
It compresses every post-trade step into the same day as execution. Allocation, confirmation and instruction all move earlier, and the window for manual repair of a break shrinks from a day to hours. The processing stages stay the same; the tolerance for anything requiring a human disappears.
What is a standing settlement instruction?
A standing settlement instruction is the stored set of account and delivery details used to settle trades with a counterparty in a given market and currency. It is reference data rather than trade data, maintained by a separate team in most firms, and it is a leading cause of settlement fails when it goes stale.