Current Blog
How to Model Order Latency in a Trading Backtest
A latency-aware backtest separates decision time, send time, venue receipt, execution, acknowledgment, and market-data arrival before assigning a fill.
This article was prepared with AI assistance and checked through automated editorial and source review. No named human review is recorded.
A latency-aware backtest should not place an order at the instant a strategy finishes its calculation. It should advance the simulated market until the order reaches the venue, then decide whether the price and available quantity still permit an execution. The strategy learns the result only after the acknowledgment or execution message returns.
Keep at least six timestamps: market event time, local market-data arrival, decision completion, order send, venue receipt, and local receipt of the venue response. Store every timestamp in one normalized unit while preserving the source clock and time-zone metadata.
Do not collapse distinct clocks
The SEC's 2026 Rule 605 FAQ says order receipt is assigned when an order is first captured by the relevant automated order-handling system and specifies at least millisecond precision. That regulatory definition is not a substitute for a research clock, but it shows why receipt time is a separate event rather than the strategy's decision time.
The Nasdaq OUCH 5.0 specification distinguishes an inbound Enter Order message from outbound Order Accepted, Order Executed, Order Canceled, and Rejected messages. Its Accepted message acknowledges receipt and acceptance, and the accepted values can differ from the entered values. A simulator should preserve those state transitions instead of inventing one instantaneous order event.
Advance the book to venue receipt
When the strategy sends an order, schedule its venue arrival using the outbound latency model. Process all market events whose exchange timestamps occur before that arrival. Only then apply the order to the reconstructed book and the venue's historical matching rule.
The Nasdaq TotalView-ITCH specification timestamps add, execute, cancel, delete, and replace messages in nanoseconds since midnight and associates order updates with reference numbers. Those fields support a sequenced view of the venue book. They do not reveal the strategy's own network path, so local receive times and an explicit latency model remain necessary.
Apply the same separation to the queue-position model. Quantity visible when the decision starts may execute or cancel while the order is in transit. The order joins the queue that exists at venue receipt, not the earlier queue observed by the strategy.
Worked millisecond example
Consider a synthetic buy limit order for 1,000 shares at $100.05. A quote showing 800 shares at the $100.05 ask reaches the strategy at local time 10:00:00.000. Decision work takes 0.8 milliseconds, outbound transit takes 2.2 milliseconds, and venue processing before acceptance takes 0.5 milliseconds. The venue accepts the order at 10:00:00.0035, which is 3.5 milliseconds after the observed quote reached the strategy.
At venue time 10:00:00.0026, the displayed 800 shares execute and the best ask moves to $100.07. The limit order arrives 0.9 milliseconds later, so it cannot take the vanished $100.05 liquidity. It rests at $100.05 under the applicable priority rule. The example produces no immediate fill even though the strategy's last observed quote looked executable.
Assume the acknowledgment returns 1.7 milliseconds after acceptance. The strategy learns that the order is resting at local time 10:00:00.0052. The figures are illustrative, not measurements of Nasdaq or any broker. They simply show the unit arithmetic and event ordering that the simulator must preserve.
Model cancels and replacements in flight
A cancel request also has outbound latency. Continue processing executions against the live order until the venue accepts the cancellation. A cancel acknowledgment may report only a reduction because part of the order executed first. OUCH explicitly notes that a canceled message does not always mean the whole order is dead.
A replacement needs the same treatment. Do not update price, quantity, or priority at local send time. Apply the change when the venue accepts it, using the venue rule that governs whether priority is retained or reset. Keep the original and replacement records in the data-lineage trail.
Calibrate distributions, not one constant
Latency varies by route, session, message type, congestion, and infrastructure. Store distributions by venue and order path when the evidence supports that detail. Keep decision time, outbound transit, venue processing, acknowledgment return, and market-data delivery as separate components so one slow stage does not distort every other stage.
Use point-in-time measurements from the same deployment and period as the backtest when available. Otherwise publish a base case and sensitivity bands. Label synthetic distributions and do not present them as measured production performance. A deterministic constant can still be useful for a unit test, but it is weak evidence for expected fills.
Test causality and uncertainty
Run explicit invariants against every order lifecycle.
No order is accepted before it is sent.
No fill occurs before venue receipt.
The book is advanced through every event before the simulated arrival.
The strategy cannot react to an acknowledgment or market event before local receipt.
Cancel and replace requests leave the original order active until venue acceptance.
Partial fills never exceed the quantity live at that moment.
Clock conversions, units, and sequence gaps are recorded and checked.
Also test a quote that disappears during transit, a partial fill before a cancel arrives, an acknowledgment delayed behind an execution, and a market-data gap. Reuse the price and quantity constraints from the limit-order model and the trigger separation from the stop-order model. If historical latency evidence is missing, report a range of outcomes rather than a precise fill claim.
