Guides
Look-ahead bias in backtesting — how it happens
Look-ahead bias is the use of information in a backtest that was not available at the moment the simulated decision was made. It is rarely deliberate and almost never obvious, because the resulting equity curve looks like skill rather than like a bug.
It enters through three main doors. The first is revised data: macroeconomic series and company fundamentals are updated after their initial publication, so a database holding only current values will hand a simulation numbers that did not exist on the date being tested. The second is disclosure lag — 13F holdings are filed after quarter end, fund portfolios are published after the period they describe, and the Commitments of Traders report describes a Tuesday but is released the following Friday. The third is survivorship: a universe built from securities that still trade excludes the failures, so the sample itself encodes knowledge of who would survive.
The defenses are unglamorous and specific. Store two timestamps on every observation — when it refers to and when it was published — and filter on the second. Keep first prints alongside revisions instead of overwriting. Retain delisted securities. None of this requires clever modelling; it requires a data layer that never throws away the information needed to reconstruct what was knowable.
What's covered
- Revised series: later values silently replacing the original print
- Disclosure lag: filings and reports dated before they were public
- Survivorship: universes assembled from today's listed securities
- Restatements: amended financials applied to the original period
- Index membership: constituents backfilled to before their addition
- Corporate actions: adjustments applied without preserving the raw series
Questions
How can I tell whether my backtest has look-ahead bias?
Re-run it using only data timestamped by publication date and compare. If results degrade sharply, the original was reading the future somewhere. A strategy whose edge survives that test is at least testing something that could have been traded.
Is point-in-time data always necessary?
Not for every question. Descriptive work about what actually happened is better served by revised data. It becomes necessary the moment you are evaluating a decision, because a decision can only use what was knowable when it was made.
Do agents make this worse?
They make it easier to commit and harder to notice. A model querying a database has no way to know that a value was published later than the date in question unless the data layer enforces the distinction — and it will state the number with complete confidence either way.
Sources
Related
Join the waitlist for early access.
Join the waitlist. Vote the roadmap. First in, first served.