Why Latency Arbitrage Backtests Don’t Survive in Production: The Execution Time Gap

The execution time gap, in one paragraph

This article quantifies the gap, breaks down where the milliseconds actually go, and explains how to model execution time inside a backtest so the numbers you ship match the numbers you’ll see on a live account.

What “execution time” actually means in latency arbitrage

In a latency arbitrage system, the strategy compares two price feeds — a fast feed (typically a tier-1 aggregator or LP feed) and a slow feed (the broker you’re trading against). When the fast feed leads the slow one by more than the spread plus a configured threshold, the strategy fires an order on the slow side, expecting the slow price to converge.

The opportunity exists only while the two prices are misaligned. The moment the broker’s quote engine catches up — usually within 50 to 200 milliseconds — the edge disappears. Your order has to be in the market before that happens.

“Execution time” in this context is not a single number. It is a stack of latencies, each contributing some milliseconds:

• Strategy decision latency — how long your code takes to detect the discrepancy and emit an order (typically <1ms in a tight loop, but can be 5–20ms in a high-level scripting language)
• Network latency to the broker — round-trip time over the public internet or co-located link (1ms co-located, 30–80ms across continents)
• Broker matching engine latency — how long the broker’s order management system takes to accept, route, and match the order against liquidity (5–100ms depending on broker)
• Fill confirmation latency — the round-trip back so you know the order is in (mirrors the network leg)

For a strategy running on a standard VPS in a different data center than the broker, the realistic round-trip is rarely below 80–100ms. For a strategy running co-located with the broker over a cross-connect, it can drop to 1–5ms. That order-of-magnitude difference is the entire ballgame.

The 50–200ms window: why milliseconds decide everything

Imagine a clean signal: the fast feed jumps 1.5 pips. The slow broker hasn’t updated yet. You have, on average, somewhere between 80 and 150 milliseconds before the slow broker’s quote engine reflects the new price. Inside that window, two things happen simultaneously:

1. Other latency arbitrageurs (and any market makers running similar logic on the broker) are also racing to fill
2. The broker’s quote feed is converging toward the fast feed continuously, not in one jump — so the edge bleeds linearly across the window

If your round-trip eats 50ms, you arrive when the discrepancy is still ~70% intact and you capture most of it. If your round-trip eats 150ms, you arrive when the discrepancy has already collapsed to ~10% — and after spread + slippage you’re likely losing.

Four execution-time scenarios — with concrete numbers

Here is the same theoretical 1.5-pip-edge latency arb signal, simulated at four different round-trip execution latencies. The numbers below are typical of what you’ll see on EUR/USD during a London session with normal liquidity and a 0.6–0.9 pip spread.

Notice the pattern: from 5ms to 50ms, profitability drops modestly. From 50ms to 120ms, it falls off a cliff. Beyond 150ms, the strategy is a coin-flip with negative expectancy after costs. This cliff is invisible to a backtester that assumes instant fills.

Why standard backtesters assume zero-latency fills

Standard retail backtesters were built for trend-following and indicator-based systems — strategies where holding periods are minutes to days, and a few seconds of execution slippage is rounding error. Their architecture reflects that:

• They replay bar data (M1, M5, H1) and apply the strategy to bar opens or closes
• Orders are matched at the displayed price the instant the strategy emits them, with no time advancing between signal and fill
• Spread is typically a single fixed number, applied identically to every fill
• There’s no concept of a network round-trip, broker matching engine, or fill confirmation

For a strategy that holds positions for hours, this is fine — the cost of these simplifications is well under 1% of the PnL. For a latency arbitrage strategy that earns 1–3 pips per trade and lives or dies inside a 100ms window, every one of those simplifications is fatal:

The four latency components a real backtest must model

To produce a backtest that survives contact with a live broker, the simulator has to model each leg of the round-trip explicitly. Here’s the breakdown a serious latency-arb backtest needs:

For a typical retail latency arb deployment from a generic VPS through a standard MT-style broker, the four components add up to roughly 80–180ms — squarely inside the danger zone where signal capture drops below 50%. For a co-located deployment through a fast ECN broker, the same components add up to 5–20ms — well below the cliff.

Every honest backtest of a latency arbitrage strategy should let the trader configure these latencies and see the impact. SharpTrader Optimizer models execution latency as a single configurable parameter (in milliseconds) that gets applied to each order at simulation time, on top of real historical tick data.

How to model execution time correctly in a backtest

Three things have to be in place. Each is necessary; none is sufficient on its own.

1. Real historical ticks — not bar interpolation

Standard retail backtesters fill in “tick” data by interpolating between bar OHLC values. The synthetic ticks they produce hit the bar high and low at random points in the bar, smoothly between the open and close. Real markets don’t move that way — they jump. The 1.5-pip latency arb signal you’re trying to catch is a jump that interpolated tick data smooths into nonexistence.

A serious backtest replays actual recorded bid/ask ticks from the broker’s matching engine (or a clean reference feed like London-source institutional data). Every tick has a timestamp, a bid, and an ask. The strategy sees them in the same order, with the same timing, that a live deployment would see.

2. Configurable execution time — applied per order

The trader configures the round-trip execution time T (in milliseconds) that they expect to see live. When the strategy emits an order, the simulator advances the clock by the request-leg portion — typically T/2, since only the time between signal and broker-side matching affects the fill price (the response leg only tells the strategy what already happened). If T = 80ms, the simulator looks at the tick stream 40ms after the signal and uses that tick’s bid/ask — not the tick that triggered the signal — as the fill price.

This single change — advancing the clock between signal and fill — reproduces the cliff at realistic latencies. It also makes the backtest deterministic: the same strategy at T = 50ms vs T = 150ms on the same tick stream produces measurably different results, and the trader can see exactly where the strategy stops working.

The realized slippage on each fill is whatever the tick walk produced — it is an output of the simulation, not a number the trader has to guess. Some fills land favorably (positive slippage), some land worse (negative), and the magnitude tracks actual tick volatility during those milliseconds. This is the realistic distribution that’s missing from every standard retail backtester.

3. Tick-resolved slippage on both legs — entry and exit

Latency arb closes as fast as it opens. The exit happens 200–800ms after entry, into a converging price. If the simulator applies the same fixed spread to entry and exit, it misses two things: (1) entry slippage from the latency window, and (2) exit slippage from the price drifting back during the close-side round-trip. A real model lets you configure execution time independently on open and close — reflecting real broker behavior where exits often go through a slower routing path — and resolves the slippage on each leg from the tick stream automatically.

Worked example: same strategy, three latency configurations

Here is a representative result from a SharpTrader latency arbitrage strategy backtested over 30 days of EUR/USD tick data, with the same parameters but three different execution-latency configurations. The numbers are typical of what we see in BJF Feed (London / Tokyo / NY) backtests.

The 0ms column is the “backtest fantasy” that standard tools produce. The 50ms column is what a well-deployed latency arb strategy actually looks like. The 150ms column is what most retail traders accidentally run when they spin up a strategy on a generic VPS and trade through a standard broker without realizing where their round-trip falls on the cliff.

The same strategy can be wildly profitable, marginally profitable, or a guaranteed loss — depending only on a number that no standard backtester models.

Why execution time, variable spread, and walk-forward go together

Execution latency is the most under-modeled variable in retail latency-arbitrage backtests, but it isn’t the only one. A trustworthy backtest combines three things, and each amplifies the others:

When all four are in place, the backtest stops being a marketing tool and becomes a forecasting tool. The numbers it produces stop diverging by 50–200% from live results and start landing within 10–20% — close enough that risk sizing, capital allocation, and broker selection decisions can actually be made on the backtest.

Frequently asked questions