Latency and slippage are different problems

A firm measuring poor execution has a diagnostic problem before it has an engineering one. The cost is visible; its cause is not. Latency reduction is expensive, highly visible, and frequently the wrong remedy, because the observed cost was spread or impact and would have been the same at any speed.

What latency actually is

Latency is elapsed time between two points, and the points have to be named or the number means nothing. The intervals that matter are different for different strategies.

The full path runs from the market event, to its arrival at the strategy, through decision and order construction, out through the network to the venue gateway, into the matching engine, and back again as an acknowledgement and a fill. Each segment has its own distribution. Wire time is nearly constant. Decision time depends on the code path taken, which means it is worst precisely when the market is busiest and the branch is unusual. Gateway and matching queues lengthen under load, which is again correlated with the moments that matter.

The mean of that distribution is close to useless. What determines outcomes is the tail, because the events worth reacting to are the ones where everyone else is also reacting, and that is exactly when queues are longest. A system with a good median and a heavy tail performs badly in a way that average-case measurement will not reveal.

How delay becomes cost

Delay is not itself a cost. It becomes one through two distinct mechanisms.

For aggressive orders, through movement. The price that was available when the decision was made may not be available on arrival. The loss is the distance the price travelled during the delay. Critically, this is not symmetric. When the price moves away, the order arrives and pays more. When the price moves favourably, the order arrives and the resting liquidity has often already been taken by someone faster. The distribution of outcomes conditional on being slow is skewed against the slow participant, which is adverse selection in its plainest form.

For passive orders, through queue position. A resting order's place in the queue is determined by when it arrived relative to everyone else's. Queue position determines fill probability, and fill probability conditional on the price moving through the level is what determines whether the fills received are the good ones or only the bad ones. An order late in the queue fills mainly when there is enough volume to exhaust everything ahead of it, which is disproportionately when the price is about to continue through. The fills a slow passive participant receives are selected for being the ones that hurt.

This is the same selection effect described in what a backtest gets wrong about fills, seen from the latency side rather than the modelling side.

Why the two get conflated

Both produce the same observable: a fill worse than the reference price. Slippage is the measurement; latency is one of several possible causes. The others are the spread, which is paid regardless of speed, and market impact, which is caused by the order's own size and described in slippage and market impact.

Attributing a slippage number to latency without evidence is common and expensive. The distinguishing test is whether the cost varies with delay. If execution quality is measured against arrival price and binned by measured latency, a latency-driven cost shows a gradient across the bins. A spread or impact cost does not: it is flat in delay and varies instead with participation rate and quoted spread. Running that decomposition first is cheap. Reducing latency without it is not.

When latency genuinely dominates

The honest answer is: in a narrower set of cases than the attention it receives suggests.

Latency dominates when the strategy competes for a queue position that others also want, when it reacts to a public event that many participants observe simultaneously, or when it depends on a relationship between venues that others are also arbitraging. In those cases the opportunity is contested and the outcome is close to winner-take-all, so relative speed is the entire game.

It does not dominate when the holding period is long enough that the entry price is a small fraction of the expected move, when the strategy provides liquidity at a price others are not competing for, or when the binding constraint is size rather than speed. A strategy holding for hours or days that attributes its underperformance to milliseconds has misdiagnosed itself, and the real cause is almost always impact, spread, or a signal that was weaker than the backtest suggested.

Measurement before optimisation

The measurement discipline is the same discipline as anywhere else: instrument first, then decide.

• Timestamp at every boundary. Market data receipt, strategy decision, order submission, venue acknowledgement, fill. Software timestamps at each of these are sufficient to identify which segment is slow. Hardware timestamping and PTP synchronisation matter when the differences being measured approach the accuracy of the clock, and not before.
• Report distributions, not averages. Median, high percentiles, and maximum, segmented by market condition. A single mean latency figure conceals exactly the behaviour that causes losses.
• Attribute cost to delay explicitly. Bin realised execution cost by measured latency. If the gradient is flat, the cost is not latency and no amount of network engineering will change it.

In the backtest

A backtest that executes at the timestamp of the signal has assumed zero latency, which is never true and is worst in exactly the situations the strategy cares about. The correction is not to add a constant.

Model the delay as a distribution with a realistic tail, and re-evaluate the signal at the delayed timestamp rather than applying a penalty to the original price. Those are different operations: a penalty assumes the opportunity still exists and merely costs more, whereas re-evaluation allows the opportunity to have disappeared, which is what actually happens. Then sweep the delay parameter. A strategy whose performance degrades gracefully across a plausible range of latencies is robust to this dimension. One that collapses somewhere inside that range has told you what it is: a latency strategy, whether or not it was intended as one, and it should be evaluated as such.