Modelling Latency In Backtests

A naive backtest loop looks like this: read the next market data event, check the strategy's condition, and if it fires, execute immediately, at that same timestamp, at whatever price is showing. In live trading this never happens — there is always a gap between "the market data arrives" and "your order actually reaches the exchange and does something," made up of network transit, parsing, decision time, and order transit (the same pipeline as Tick-To-Trade Latency). A backtest that skips this gap is quietly assuming your strategy has zero latency, which for a signal with any short-lived edge is the difference between a backtest that looks profitable and a live strategy that loses money, because in reality the opportunity has often already been taken — by someone else, or simply by the market moving on — before your order would actually arrive.

Where the gap bites

Consider a strategy that buys the instant a specific order book pattern appears, expecting a 3-tick bounce over the next 200 microseconds. In the backtest, "buy" happens at the same timestamp as the pattern, capturing the full 3-tick move. In reality, tick-to-trade latency of even 40 microseconds means the order doesn't reach the exchange until the pattern is already 40 microseconds old — and if the bounce plays out over 200 microseconds total, the strategy has already missed a fifth of the move before its order is even in the book, and worse, faster competitors reacting to the identical pattern may have already consumed the liquidity the strategy was counting on filling into.

Building the delay in

The fix is a two-part delay in the simulator: an inbound delay between when a market event is generated and when the strategy is allowed to "see" it, and an outbound delay between when the strategy decides to act and when that order is allowed to affect the simulated book.

$t_{\text{decision}} = t_{\text{event}} + \delta_{\text{in}} \qquad t_{\text{order live}} = t_{\text{decision}} + \delta_{\text{out}}$

In words: the strategy only gets to react to an event after the inbound delay has passed, and its order only starts competing for a place in the book after the outbound delay on top of that. Crucially, the simulated book must keep evolving with everyone else's orders during both delays — a competitor with lower latency reacting to the same event may get their order in first.

Worked example

A backtest without latency modelling shows a strategy buying at the touch the instant a book-imbalance signal crosses a threshold, capturing an average 1.5-tick gain per trade, 60% win rate.

Re-run with $\delta_{\text{in}} = 15\mu s$ and $\delta_{\text{out}} = 20\mu s$ (35 microseconds total, representative of a fast but non-FPGA setup). Now the order only reaches the simulated book 35 microseconds after the signal fired. Replaying historical order flow through that gap shows that in 22% of instances, another market participant's order — visible in the historical tape as trading during exactly that 35-microsecond window — already consumed the liquidity the strategy needed, converting what looked like a fill into a miss, or a favorable fill into one at a worse price.

Version	Win rate	Avg gain/trade
No latency	60%	1.5 ticks
35μs latency	41%	0.6 ticks

The edge doesn't vanish, but it shrinks by more than half once the strategy is honestly competing against everyone else's latency instead of trading with a time machine.

Where this matters most

The bite is worst for strategies with the shortest expected holding periods and thinnest edges per trade — market making, latency arbitrage, and pure order-book microstructure signals — since a fixed latency delay eats a larger fraction of a short-lived opportunity than a long-lived one. A strategy expecting to hold for hours can usually ignore microsecond-level latency modelling entirely; a strategy expecting to capture a 200-microsecond bounce cannot.

In interviews

If asked to critique a backtest for a fast strategy, latency is one of the first things to check for, alongside queue position and impact. The sharpest framing: ask what the backtest assumes about when your order competes with everyone else's, and if the answer is "at the same instant the signal was generated," that's the naive, optimistic version.