Look-ahead bias: the five mistakes that make a backtest look perfect

Cause one: filling at the signal bar's own price

The strategy inspects a completed bar, decides to buy, and the backtest fills at that same bar's closing price. This is physically impossible. You cannot know a bar's close until the bar is closed, and by then that price is history.

The honest alternative is a fill at the next bar's open, or at a defined intrabar price with a known rule for when it would have been touched. The difference matters most on strategies that trade breakouts, because the move you are trying to catch typically begins before the bar closes.

Cause two: indicators that peek

Any statistic computed over the whole series and then used as if it were known in advance introduces the future. Normalising by the mean of the entire dataset, ranking against future values, or z-scoring with a full-sample standard deviation all do this.

The rule is simple and easy to state: every value used at bar N must be computable using only bars up to and including N. Rolling windows with a bounded lookback satisfy this. Full-sample statistics do not.

Cause three: survivorship in the instrument or the sample

If your test universe contains only instruments that still exist today, you have selected winners in advance. Delisted stocks, discontinued futures contracts and failed products are exactly the ones that would have hurt, and they are absent from the data.

The same problem appears inside strategy selection. If you chose the strategy by looking at results over a period, the backtest of that period is contaminated by your choice, no matter how carefully the code avoids future bars.

Cause four: revised or restated data

Economic releases are revised. A preliminary figure is published, then corrected weeks later. If your backtest uses the corrected value on the original date, it knows something the market did not.

The same applies to any dataset that has been cleaned, backfilled or interpolated after the fact. A price series with gaps repaired by interpolation contains information about what happened after the gap, which is the definition of peeking.

Cause five: the parameter was chosen with hindsight

Choosing a 20-period moving average because 20 produced the best result over the test period is a form of look-ahead: the parameter selection used information from the entire period, including its end. The strategy then trades the whole period with knowledge of how the period turned out.

This one is not a code bug and cannot be fixed by careful indexing. It is fixed by procedure: hold back data, choose parameters on one portion, and only then evaluate on the rest.

How to detect it

• Shift every input forward by one bar and re-run. If the result barely changes, the strategy was not relying on the current bar's information. If it collapses, investigate why.
• Compare the fill prices in the trade log against the prices that were actually available at that timestamp.
• Look at the trade timing: if entries cluster suspiciously close to the best prices of the bar, something is peeking.
• Check whether a result survives when costs and a one-bar execution delay are applied. Many look-ahead systems are profitable only under the unrealistic assumption.
• Be sceptical of performance that is far better than anything you have seen before. Exceptional smoothness is a symptom, not a discovery.

Why this matters beyond the backtest

A strategy contaminated by look-ahead bias does not merely perform worse live. It fails in a specific and demoralising way: the signals it was designed around do not appear at the prices the backtest assumed, so the trades it takes are different trades from the ones that were evaluated.

That makes the failure hard to diagnose from live results alone, which is why it is worth eliminating before a strategy reaches an account rather than after. The detection methods above are cheap and mechanical, and there is no reason not to run them.