Backtest Parity, Time-Stamping at Ingest and Honest Replay
Pull-quote: “A backtest does not test the strategy. It tests the strategy plus every lie in the data. Parity work is the removal of the lies.”
Why this matters
Every backtest makes the same claim: had this logic run in the past, here is what it would have seen and done. The claim fails quietly in one specific way. The data the simulator reads is not the data production would have had, because it was stamped, revised, aggregated, or cleaned after the fact. The strategy then trades on information it could not have possessed, and the research result is fiction with error bars. Backtest parity is the engineering discipline that closes this gap: the simulator must see exactly what the live system saw, in the order it saw it, and nothing more.
Two clocks, one honest record
Every market event has two times: when it happened at the venue and when your system actually knew about it. Strategies live on the second clock. Backtests that use the first clock quietly grant the strategy foresight equal to the gap between the two, which is precisely the latency that hurts in production.
venue event ──► feed ──► [ INGEST: stamp arrival time ] ──► raw store
│ │ (append-only,
event time knowledge time microstructure
(theirs) (yours: the only preserved as
clock a backtest received)
may use)
│
▼
replay ──► same code, same
sequence, no revisionsThe rule that follows: stamp everything at ingest, keep the record as received, and replay from that record. Corrections that arrive later are new records with their own arrival stamps, not edits to history. The store itself is append-only for the same reason the audit log is: the value of the record comes from nobody being able to improve it afterward.
Where parity breaks
| Parity break | What it smuggles in | The fix |
|---|---|---|
| Using venue or vendor timestamps | Foresight equal to your real latency | Stamp at ingest; backtest on arrival time |
| Backfilled or revised history | Corrections the live system never saw | Append revisions as new records, replay as received |
| Bars and aggregates only | Intrabar sequence, spread, and queue reality | Preserve microstructure and replay from it |
| Cleaned data | Absence of the bad ticks production must survive | Keep the raw record; clean inside the replayed path |
| Survivorship-filtered universes | Knowledge of which instruments made it | Freeze the universe as of each historical date |
Each row is the same failure in a different costume: the simulation knowing something the desk did not.
Why microstructure, specifically
Bar data answers what the price did. It cannot answer whether your order would have participated: where the spread sat, what depth was displayed, in what sequence quotes and trades arrived. Any strategy whose economics depend on execution needs those answers, and they only exist if the microstructure was preserved at ingest. This is also what makes cost assumptions checkable rather than asserted: replaying against the recorded book is how fee, slippage, and fill models get validated against something other than optimism.
In practice, this is the foundation of the whole research stack: normalized feeds, time-stamped at ingest, with microstructure preserved for replay and backtest parity. The same discipline that makes backtests honest also makes incidents reviewable. When a session needs explaining, the desk replays what the system actually received, in the order it received it, instead of debating recollections.
Closing
Parity is not a data-quality nicety. It is the property that makes research transferable to production at all. Stamp at ingest, preserve the microstructure, replay as received, and treat every revision as a new fact rather than a corrected one. A backtest built this way is still only a model of the past. But it is a model of the past you actually inhabited, which is the only past worth testing against.