Latency Modeling in Backtests
A constant latency assumption misses the part that actually matters, that latency is a distribution with a fat right tail, and the tail hits hardest exactly when the market is moving fastest and the opportunity is best.
Prerequisites: Signal-to-Execution Lag
A common shortcut is to give every order a fixed latency — say 50 milliseconds — between decision and fill, and move on. On a quiet day that's a fine approximation: network paths are stable, the exchange matching engine isn't backed up, and 50ms is close to whatever the true number was. The problem is that latency isn't a constant, it's a distribution with a long right tail, and that tail is correlated with volatility — the same order surges and matching-engine queueing that widen spreads also slow down the path your order takes to get there. The moments a strategy most wants to trade fast are the moments it's most likely to be slow.
Worked example: the constant that's right on average and wrong when it counts
A short-horizon signal is backtested with a flat 50ms latency: signal fires, price is captured 50ms later, done. Live logging of the actual production system over the same period shows a different picture.
| Regime | Share of order volume | Latency (median) | Latency (99th pctile) |
|---|---|---|---|
| Calm | 80% | 45ms | 90ms |
| Elevated | 15% | 60ms | 350ms |
| Burst (news, open/close) | 5% | 90ms | 1,400ms |
The volume-weighted average latency across the sample is close to 55ms — not far from the 50ms flat assumption, so a naive check ("is my average latency roughly right?") passes. But the strategy's edge is concentrated precisely in the burst regime, where fast reaction to a fresh signal captures most of the alpha before it decays. During bursts, real latency is 1,400ms at the tail instead of 50ms — by the time the order lands, the price it was aimed at is long gone, and the fill happens well after the opportunity has been arbitraged by faster participants.
Modeling latency as a single number backtests a strategy that doesn't exist. Modeling it as a distribution conditioned on regime — sampling from the calm bucket 80% of the time and the burst bucket during genuinely volatile windows — reallocates realized edge away from exactly the trades that were never actually capturable.
Latency should be sampled from a distribution conditioned on market regime, not applied as a constant — the average latency can look calibrated while the tail, which lands during the exact bursts a fast strategy is built to exploit, is off by an order of magnitude.
A flat-latency backtest is biased in favor of the strategy specifically when the strategy's edge is concentrated in fast-moving regimes, because that's where real latency diverges most from the average. The better the backtested Sharpe on burst-driven signals, the more suspicious a constant-latency assumption should look.
Where production logs of real latency exist, use them directly, bucketed by realized volatility or spread; where they don't yet exist, treat the flat-latency Sharpe as an upper bound, not an estimate.
Practice in interviews
Further reading
- Kissell, The Science of Algorithmic Trading and Portfolio Management (ch. 4)