Wire-to-Wire Latency Decomposition

A market-making desk's backtest assumes a flat 200-microsecond tick-to-trade latency and projects a queue-position win rate of 62% on a liquid futures contract. Live, the win rate comes in at 41%. Average measured latency, checked once, is 210 microseconds — close enough to the assumption that latency looks cleared as a suspect. It isn't. The average is nearly right and the distribution is nowhere close: most updates process in 150 microseconds, but a tail tied to one pipeline stage takes 800 microseconds or more, and it's precisely during those slow ones — often triggered by the same volatility burst that makes the trade worth winning — that the strategy loses the race.

The stages, and why they don't average together honestly

Wire-to-wire latency is a chain, and a chain is exactly as slow as its slowest link on any given event, not as slow as the average link:

$$L_{\text{total}} = L_{\text{wire-in}} + L_{\text{parse}} + L_{\text{strategy}} + L_{\text{risk-check}} + L_{\text{wire-out}}.$$

In words: time for the market data packet to arrive at the network card, time to parse and normalize it, time for the strategy logic to decide, time for the risk/compliance check to clear the order, and time for the order packet to leave and reach the exchange. Each stage has its own distribution — parsing is usually tight and deterministic, the strategy stage can spike under load, a risk check can occasionally block on a lock. The sum's tail is dominated by whichever stage has the fattest tail on that particular event, and it's rarely the same stage twice.

Worked example: finding the culprit

Measured stage latencies over 50,000 quote-update events (medians and 99th percentiles, in microseconds):

Stage	Median	p99
Wire-in	12	18
Parse	12	15
Strategy	40	95
Risk check	15	520
Wire-out	20	30
Total	~110	not additive — see below

Summing medians gives 99 microseconds — close to the reported average once queueing effects are added. But summing p99s (668) badly overstates the tail, because slow events at each stage don't all land on the same messages. The honest approach: look at total latency for only the slowest 1% of round trips and ask which stage was slow on those specific events. Here, 91% of the slowest 1% have their time concentrated in the risk-check stage — a lock contention issue that only bites when order volume spikes, exactly when the strategy most wants to trade. Fixing that lock, not micro-optimizing the parser, is what actually moves the win rate.

Worked example: the queue-race arithmetic

Being 200 microseconds faster than a competing market maker on a repriced quote is worth roughly 3 percentage points of fill-rate advantage per 100 microseconds saved, for this instrument. The desk's median latency (110 μs) beats a typical competitor's assumed 180 μs by 70 μs — a modest edge, worth about 2 points of fill rate. But on the 1% of events where risk-check spikes to 520 μs, the desk is now 340 μs slower than that competitor — a swing worth roughly −10 points of fill rate on exactly the volatile, high-value events where being first matters most. The flat-latency backtest never sees this asymmetry, because it never models a tail at all.

Widen the standard deviation above and picture the right tail stretching far past the mean — that stretch is what a single "average latency" number deletes, and it's exactly where fill probability is decided.

What this means in practice

Instrument every stage boundary with a timestamp, log the full distribution per stage — not just mean and p99 — and pull the stage breakdown for your slowest 1% of round trips whenever fill rate degrades. Feed the measured per-stage distributions into the simulator, as in Modelling Latency In Backtests, instead of one flat number.