Timestamp Provenance: Exchange Versus Vendor
Every market data record has more than one candidate timestamp — when the exchange matched the trade, when it was disseminated, when a vendor received or recorded it — and conflating them can introduce look-ahead bias or misjudge execution latency in a backtest.
A single trade event can end up with several different timestamps depending on where in the data pipeline you look: the moment the exchange's matching engine actually executed the trade, the moment the exchange disseminated that trade over its market data feed, and the moment a data vendor's system received, processed, and recorded it in the database you're querying. These can differ by anywhere from microseconds to, in poorly maintained historical datasets, minutes — and which one a backtest uses matters enormously for anything sensitive to execution timing.
The idea
"Timestamp provenance" just means knowing which of these candidate timestamps a given data field actually represents, since a vendor's database column labeled simply "time" doesn't tell you whether it's exchange match time or vendor receipt time. For strategies operating on daily or even hourly bars this distinction is mostly irrelevant, but for anything reacting to specific events — a news release, an order book change, a cross-exchange price discrepancy — using the wrong timestamp can either introduce look-ahead bias (assuming information was available earlier than it actually was disseminated) or misjudge how much of an observed price move was still capturable after accounting for real dissemination and processing latency.
Worked example
A strategy backtests reacting to a large trade printed on Exchange A by trading a correlated instrument on Exchange B, using the trade's timestamp from a vendor's consolidated feed. If that timestamp reflects the vendor's receipt time rather than the exchange's dissemination time, and the vendor's processing added, say, 50 milliseconds of latency inconsistently across records, the backtest may be silently assuming the strategy could react to information before it was actually available on Exchange B's own feed, or conversely underestimate how much of the price move on Exchange B was already reflected by the time a real system could have reacted.
What this means in practice
For any daily-or-longer strategy this level of care is unnecessary — the distinctions are lost in the noise. But for anything execution-timing sensitive, intraday, or event-driven, a research team needs to know explicitly which timestamp field a vendor is providing and confirm it against the exchange's own published specification, rather than assuming "the timestamp" means what it appears to mean.
Market data can carry several different timestamps for the same event — exchange match time, dissemination time, vendor receipt time — and a backtest sensitive to timing needs to know explicitly which one it's using, since conflating them can introduce look-ahead bias or misjudge realistic execution latency.
Further reading
- O'Hara, Market Microstructure Theory, ch. 1