A market data row can be perfectly accurate and still be unusable evidence for a backtest. The trade happened, the price is right, and the timestamp is valid; but the feed may have delivered it late, a vendor may have corrected it later, or the quoted market may not have been one your strategy could access.
To know whether historical data was tradable, audit more than its event timestamp. You need to know what the row describes, when it became available to the system, which venue or instrument it represents, and whether the quote or trade could plausibly support your order.
Is a correct historical price enough for a backtest?
No. Accuracy answers, “What price did the source eventually record?” A backtest also needs to answer, “What could my strategy have known at decision time?” and “What could it have executed?” Those are separate questions.
Imagine a crypto trade prints at 12:00:00.120, but your data vendor’s stream delivers it to your process at 12:00:00.480. A strategy deciding at .200 cannot use that trade, even though the event timestamp precedes its decision. If the historical file preserves only event time, the backtest can quietly grant the strategy information its live process would not yet have received.
| Time or field | What it tells you | Backtest failure if missing |
|---|---|---|
| Event time | When the exchange says the event occurred | Confusing market time with strategy availability |
| Receive time | When your collector got the message | Using delayed data as if it arrived instantly |
| Sequence or update ID | Where the event belongs in the feed order | Applying updates out of order or silently skipping them |
| Revision time | When a corrected historical value became known | Backtesting with a value that did not exist in the original feed |
When your archive lacks receive times, be honest about the gap. You can test a latency assumption, or restrict the claim to event-time research. You cannot reconstruct the exact information set from timestamps that were never saved.
How do I tell whether a quote was executable?
Start with the market your order would have reached. A consolidated best bid and offer can summarize several venues; it does not prove that your account had access to the displayed size, that the quote was still present when your order arrived, or that the venue would accept your order type.
For a market order, a midpoint fill is usually a fiction. A more useful estimate walks the visible book against the order size, then adds fees and a latency or impact assumption. If you have only top-of-book data, cap the claim: you can estimate the first level, but you cannot infer depth that was never recorded.
For a limit order, a price touch does not mean a fill. Orders ahead of yours may consume the available quantity first. Queue position is usually unknowable from ordinary snapshots, so a touch-based fill rule should be treated as an optimistic scenario, not a fact about what happened.
A one-minute bar can tell you that the low crossed your limit. It cannot tell you whether your resting order reached the venue before the low, how much traded there, or how much queue sat ahead of you.
What should I check before trusting a market data archive?
I check the mundane properties first. They catch more bad research than a sophisticated execution model bolted onto a broken feed.
- Coverage: Are there missing intervals, duplicate events, sequence gaps, or unexplained bursts of zero volume?
- Market identity: Does the symbol map to the same exchange, contract, quote currency, and instrument specifications through time?
- Availability: Are event and receive times both preserved? If not, what delay assumption bounds the result?
- Corrections: Can you distinguish the original message from later vendor backfills or revisions?
- Units: Are prices, quantities, contract multipliers, and timestamps interpreted consistently?
That last check sounds almost too basic. I once spent a morning chasing an apparent volatility regime change that turned out to be a quantity field switching units after a feed migration. The chart was beautiful; the unit was wrong.
How can I test whether data availability changes the result?
Run a small sensitivity test around the strategy’s decision boundary. Shift usable data by realistic delays, discard updates with broken sequence continuity, and compare fills using the actual venue book where you have it. Report both the original and the degraded result. If a tiny delay erases the effect, the strategy may depend on an information advantage your collection setup cannot reliably supply.
For a concrete example, suppose a signal fires when the best bid rises by one tick. Replay it once with exchange event time and once with the collector’s receive time. If the event-time version trades 40 times and the receive-time version trades 27, that difference is part of the strategy’s evidence. So is the performance under each replay. Do not bury the weaker replay because its data looks less elegant.
Paper trading is a useful next check because it exposes feed delays, stale quotes, symbol mapping mistakes, and venue filters in the same operating path your research system uses. It still will not reproduce every live queue or market impact. Keep that boundary visible.
What does “tradable data” mean in practice?
It means the backtest can explain when an observation occurred, when the strategy could consume it, what market it came from, and what execution evidence supports the assumed fill. A clean price series is a starting point. The research becomes credible when its timing, access, and fill assumptions survive inspection—and when the result still makes sense after you weaken them.
← All posts
