How Errors Propagate Through the Trade Lifecycle

One of the most instructive ways to understand how a markets business works is to trace what happens when something goes wrong. Error propagation — the way a single mistake at one stage of the trade lifecycle ripples through every subsequent system and process — reveals both the interconnectedness of the front-to-back architecture and the critical importance of catching errors as early as possible.

The further downstream an error propagates before it is caught, the more expensive and disruptive it becomes to fix. A booking error caught within minutes of execution costs almost nothing to correct. The same error caught a week later — after it has corrupted P&L reports, generated incorrect margin calls, caused a mismatch with the counterparty's records, and fed erroneous data into regulatory reports — can take days or weeks to fully remediate.

Consider a concrete example. A trader agrees a five-year GBP interest rate swap with a pension fund: the bank pays fixed at 4.25% and receives SONIA, on a notional of £50 million. The trader — or the Trade Support analyst entering the trade — makes an error: the notional is booked as £500 million instead of £50 million. A simple factor-of-ten mistake.

At this stage, the error is still simple to fix. If the Trade Support team checks the trade against the voice recording or the electronic execution record within the hour, the error is identified, corrected, and the corrected trade is confirmed to the counterparty. Total impact: near zero. This is why most banks require Trade Support to check all new trades against execution records within a defined period — typically two hours of the trade being done.

If the error is not caught during trade capture review, it is fed into the position management system. The trading book's position now shows a DV01 ten times larger than it should be. On a £500 million notional five-year swap versus the correct £50 million, the DV01 difference is approximately £40,000 per basis point — a significant unintended risk position.

The trader's risk monitor — the screen showing their real-time risk — shows an inflated position. If the trader does not notice this discrepancy (perhaps because they are busy with other trades, or because the position monitor is not sufficiently detailed to reveal the error), the wrong position persists. The trader may even take hedging trades based on the wrong position — selling DV01 to reduce what they believe is an overlarge exposure. Those hedging trades create further positions that will need to be unwound when the error is eventually discovered.

At end of day, the P&L attribution system calculates the day's profit and loss based on the position in the book — which includes the erroneously large swap. If interest rates moved during the day, the P&L on the wrong position is nine times larger than it should be. If rates fell 2 basis points, the correct P&L on a pay-fixed swap would be approximately -£8,000 (a loss because rates moved against the position). With the ten-times error, the reported P&L is approximately -£80,000.

This inflated P&L is reported to senior management, included in the desk's daily P&L flash, and potentially used to calculate trader bonuses (on a mark-to-market basis). Product Control will attempt to reconcile the desk's own P&L against their independent calculation — but if the error is in the system that both are using as the trade population, the reconciliation will not reveal the discrepancy.

The overnight risk batch uses the wrong position to calculate market risk metrics: VaR (Value at Risk), Stressed VaR, and regulatory capital requirements. The risk report produced the following morning shows an inflated interest rate exposure. If the inflated position is large enough to breach a risk limit, it may trigger an automatic risk limit breach notification — requiring the trader to explain to risk management why they have taken on an unexpectedly large position.

If the limit breach triggers a regulatory capital calculation, the RWAs (risk-weighted assets) for the trading book may be overstated. This feeds into the bank's regulatory capital ratios — potentially affecting reported capital adequacy.

The inflated swap must be reported to LCH SwapClear as part of the daily margin cycle. LCH calculates initial margin and variation margin based on the portfolio of swaps submitted by each clearing member. With a £500 million swap instead of £50 million, the initial margin requirement is approximately ten times larger than it should be.

LCH issues a margin call for the inflated amount. The bank's treasury function allocates collateral to meet this call — posting ten times more cash or bonds than necessary to LCH. This is an unnecessary use of the bank's funding, reducing available liquidity for other purposes. If the bank is managing its liquidity tightly on that day, the unexpected large margin call could cause a liquidity stress that cascades into other decisions.

Under EMIR, the trade must be reported to the trade repository with the correct economic terms — including the correct notional of £50 million. But if the booking error has not been caught before the regulatory reporting runs (typically overnight), the report is submitted with £500 million. This is a regulatory reporting error.

Correcting a regulatory report requires cancelling the original report and submitting a corrected one. Depending on the timeline, this may require explanation to the regulator as to why an incorrect report was initially submitted. Persistent reporting errors attract regulatory scrutiny and, ultimately, enforcement action.

The industry's primary defence against error propagation is the four-eyes principle — requiring that any significant action or decision be reviewed by a second person before it takes effect. In trade capture, this means Trade Support reviewing every trade booking against the execution record before it is confirmed to the counterparty. In payments, it means a second approver is required for any payment above a defined threshold.

Corrections and audit trails. When an error is identified and corrected, the correction must be traceable. The original erroneous booking must be cancelled (not deleted) in the system, with a record of when it was cancelled and by whom. The correct trade must then be booked as a new transaction. This creates a complete audit trail — essential for regulatory examination and for understanding what happened during an error investigation.

Root cause analysis. After any significant error, the operations or risk function should conduct a root cause analysis (RCA) — a structured investigation into why the error occurred and what systemic change can prevent recurrence. RCA findings may lead to changes in workflow, additional system validations, training, or staffing adjustments. Without RCA, the same errors tend to recur.

The lesson is simple but important: operational controls in a markets business are not bureaucratic overhead — they are the mechanism by which a bank ensures that its risk, P&L, and regulatory positions accurately reflect the trades it has actually done. Every control that catches an error early prevents a cascade that grows more expensive with every stage it is allowed to propagate through.