The most dangerous timing bug in a backtest can survive a perfect timestamp audit. Two events may both say 10:00:00.000 and still have happened in an order your simulator guessed.
That matters whenever a strategy reacts to more than completed bars: a quote update, a trade, a funding notice, an exchange status change, or its own order acknowledgement. A timestamp tells you when an event is labeled. It may not tell you when your strategy could act on it.
What does event ordering change?
Imagine a strategy that buys when the best ask falls below $100.00. At the same millisecond, the feed records an ask update to $99.99 and a trade at $99.99. If your backtest processes the trade first, then the quote, the strategy sees the new ask and submits an order. If it processes the quote first, that may be fine too, provided the event was actually available. But if the trade consumed the displayed liquidity before the order arrived, a fill at $99.99 is fiction.
Sorting rows by timestamp alone leaves the simulator to choose a sequence for tied events. File order, symbol order, or a database query plan can become an accidental execution rule. The equity curve may change even though the underlying data did not.
There’s a good way to see how arbitrary this can get: sort equal-time events by symbol name instead of arrival sequence. A multi-asset strategy can then behave differently simply because one ticker sorts before another.
Which clocks should a backtest keep?
Market data and order handling often involve several distinct times. Keep the fields your source provides, and name their meanings precisely. For many feeds, the exchange timestamp and local receive timestamp are both useful; neither is a universal truth about what every participant saw.
| Clock | What it records | What it cannot prove by itself |
|---|---|---|
| Exchange event time | When the venue says an event occurred | The order another feed or your process observed it |
| Receive time | When your collector received the message | When your strategy finished processing it |
| Decision time | When your code evaluated the signal | That the quoted price remained available |
| Order arrival time | When the venue could act on the order | A fill, unless the matching rules and liquidity support one |
For historical data without receive times, say what you assume. A backtest might process exchange events in sequence and impose a fixed 5 ms delay from decision to order arrival. That is a model, not recovered history. If you have no sequence numbers for tied exchange timestamps, your tie-breaking rule is also an assumption.
How do I model tied events?
First, preserve source sequence numbers where they exist. A sequence number gives a stronger ordering within its feed than a timestamp does, though sequence spaces may be separate across channels or products.
Then make the simulator's processing rule explicit. For each event, decide whether it can update the strategy's information, change available liquidity, trigger an order, or acknowledge an order. These are different actions; collapsing them into “process row” is how impossible fills sneak in.
- Apply only market information that has arrived by the strategy's decision time.
- Generate the order, then advance it to its modeled venue arrival time.
- Allow execution only against eligible liquidity after arrival, under the fill assumptions for that order type.
- Record the inputs, event ordering, and delay used for every simulated fill.
For a bar-based strategy, this may be more machinery than the question requires. If the signal uses completed 1-minute bars and orders fill at the next bar's open with a conservative cost model, sub-millisecond ordering likely won't change the research conclusion. The point is to match the timing detail to the claim the backtest makes.
Can I trust a backtest without arrival-time data?
You can still use it, but keep the boundary visible. If the strategy trades slowly and has wide risk limits, a few milliseconds may be immaterial. If it reacts to fleeting quotes, competes for queue position, or depends on a cross-venue lead-lag signal, missing arrival times can be central to the result.
Critics are right that precise event timing can turn into false precision. Historical feeds are incomplete, clocks drift, and venue timestamps don't reveal every network hop. A simulator with nanosecond fields can still make a crude fill assumption.
So test sensitivity instead of claiming certainty: replay with plausible event tie-breaks and order delays, then compare trade count, fill price, and which signals survive. If the result hinges on a sequence the data cannot establish, that dependence belongs in the research report. A backtest can be useful with an imperfect clock. It just needs to admit what time it actually knows.
← All posts
