Decomposing Live Slippage

A desk reports "18 bps of slippage this month" and everyone nods and moves on. That single number is a mixture of at least three unrelated problems — the strategy took too long to turn a decision into an order, the order it sent was too aggressive for the liquidity available, and part of the order never got filled at all — and each of those has a completely different fix. Averaging them into one line is like a doctor writing "patient feels bad" instead of taking a temperature, blood pressure, and pulse separately. You can't treat a symptom you've mashed together with two other symptoms.

Think of it as a grocery receipt with one line item called "food." It's technically accurate and useless for figuring out why the bill went up — you need it split into produce, meat, and snacks before you can decide what to cut.

The four buckets, named in words before symbols

Attribution starts from four prices, each timestamped separately: the decision price (what the strategy saw when it decided to trade), the arrival price (what the market was showing when the order actually reached it), the execution price (what you actually paid, averaged over however the order was worked), and, for anything left unfilled, a closing or opportunity price used to value the part of the order that never happened.

• Delay cost is the move between decision and arrival — the tax for however long it took your system to turn a decision into a live order.
• Trading cost is the move between arrival and execution — spread crossed plus the market impact your own order caused. This is what people usually mean by "slippage" when they say it loosely.
• Opportunity cost is what you'd have made or lost on the unfilled portion, valued against where the price ended up. An order that fills 60% at a great price and leaves 40% on the table can still be a bad trade.
• Fees are commissions and exchange fees — small, but worth isolating so they don't get blamed on the market.

Putting it together, total implementation shortfall for one order of size $Q$ is

$$\text{IS} = \underbrace{(P_{\text{arrival}} - P_{\text{decision}})\,Q}_{\text{delay cost}} \;+\; \underbrace{(P_{\text{exec}} - P_{\text{arrival}})\,Q_{\text{filled}}}_{\text{trading cost}} \;+\; \underbrace{(P_{\text{close}} - P_{\text{arrival}})\,Q_{\text{unfilled}}}_{\text{opportunity cost}} \;+\; \text{fees}.$$

In words: the total gap between what the paper strategy would have made and what the account actually made is the sum of four separate leaks, each priced at the moment it happened, not lumped into one average.

Worked example 1: a single buy order

A strategy decides to buy 10,000 shares at a decision price of $100.00. The order actually reaches the market four seconds later, by which point the price has drifted to $100.05 — that drift, on the full 10,000 shares, is delay cost of $0.05 × 10,000 = $500. The order works over the next two minutes and fills 8,000 shares at an average price of $100.18, so trading cost on the filled portion is ($100.18 − $100.05) × 8,000 = $1,040. The remaining 2,000 shares are cancelled unfilled; by the time the strategy gives up, the price has moved to $100.30, so the opportunity cost is ($100.30 − $100.05) × 2,000 = $500. Add $60 in fees. Total implementation shortfall: $500 + $1,040 + $500 + $60 = $2,100, against a $1,000,000 notional decision — 21 bps.

Reported as one number, "21 bps of slippage" sounds like an execution algorithm problem. Decomposed, it's roughly 24% delay, 50% trading cost, 24% opportunity cost, 3% fees — half the leak is genuinely execution, but a quarter of it happened before the order was even sent, which no execution algorithm can fix.

Worked example 2: aggregating across a day to find the pattern

One order tells you little; a day's worth tells you where to look. Aggregate 40 orders from one day:

Bucket	Total cost	Share of slippage
Delay	$18,400	46%
Trading (spread + impact)	$14,200	35%
Opportunity	$6,100	15%
Fees	$1,600	4%

Trading cost — the part everyone assumes dominates — is actually the second-largest bucket. Delay cost, at 46%, points at the order-management pipeline: something between signal generation and order arrival is slow, probably a batching step or a risk-check queue. No amount of tuning the execution algorithm's aggressiveness touches that 46%.

Doing it properly

Timestamp every stage — decision, order-sent, first-fill, last-fill, cancel — to the millisecond, because the whole decomposition depends on having a clean arrival price distinct from the decision price. If those two prices are ever the same timestamp, the delay-cost term is silently zero by construction and every bit of pipeline lag gets mislabeled as trading cost instead. Attribute at the individual-order level and only aggregate afterward; averaging first destroys the information about which orders leaked where, and a single huge outlier order can otherwise dominate a whole month's reported number.

Track the buckets over time the same way you'd track any other live metric — see A Monitoring Stack for Live Strategies — because a pipeline that used to add 2 bps of delay cost and now adds 12 is telling you something changed in the plumbing, not in the market. It's also worth splitting the attribution by order type and venue: a strategy that routes passively to one venue and aggressively to another will show wildly different trading-cost shares depending on which one you're looking at, and blending them hides which venue is actually worth using. Finally, compare the decomposition against what the backtest assumed — see Implementation Shortfall — because a backtest that charged a flat spread cost and ignored delay entirely will always look cheaper than live trading, for reasons that have nothing to do with the strategy's edge.