What is look-ahead bias in backtesting?

Look-ahead bias occurs when a backtest uses data that would not have been available at the moment a trade decision was made. For example, computing a signal on the current bar's closing price and entering the trade at that same bar's close — you cannot fill at the close if you don't know the close until the bar ends. It produces inflated results that collapse immediately in live trading.

What is the difference between look-ahead bias and overfitting?

Look-ahead bias uses future data in a past signal — the rules are mechanically broken. Overfitting tunes rules to historical noise — the rules are mechanically valid but statistically overspecified. Both inflate backtests, but look-ahead bias is a coding error; overfitting is a methodology error. Fix look-ahead bias first; it is binary and detectable. Then address overfitting through out-of-sample validation.

Is using today's closing price for today's entry always look-ahead bias?

Yes, for most strategies. If your entry signal is based on a calculation that includes today's close (e.g. a moving average that uses today's close), you cannot know that value until the bar closes — so you cannot fill at that price in live trading. The correct approach is to signal on the close and enter at the next bar's open, which is what zipline and most rigorous backtesting frameworks enforce by default.

Can look-ahead bias occur in indicators computed over the whole dataset?

Yes — this is one of the most subtle forms. If you compute a z-score, percentage rank, or normalisation factor using the full dataset (including future bars) and then reference it at past points in time, every signal uses future information. Always compute rolling statistics using only data available up to the current bar.

Does backtester.run prevent look-ahead bias automatically?

backtester.run runs strategies on zipline, which enforces bar-by-bar execution with a strict data boundary at the current bar's close. Signals fire at bar close; fills execute at the next bar's open. This eliminates the most common class of look-ahead bias by design.

← Backtesting guide

Look-Ahead Bias

Look-ahead bias occurs when a backtest uses data that would not have been available at the exact moment a trade decision was made. It is one of the most insidious bugs in backtesting: the results look spectacular, the equity curve is suspiciously smooth, and none of it reflects what would have happened in live trading. Unlike overfitting, look-ahead bias is a coding error — and it can be fully eliminated.

Definition

Look-ahead bias (also called future leak or data snooping) — a backtest error in which a signal or indicator uses information from the current bar's close, a future bar, or a dataset statistic computed over the full history. The strategy effectively "knows the future" at each decision point, making its simulated performance mechanically impossible to replicate in live trading.

Why is look-ahead bias so dangerous?

Most bugs in a strategy reduce performance. Look-ahead bias inflates it. The strategy appears to have an edge that vanishes the moment you trade it live — because the edge depended on information you cannot have in real time. The performance collapse is immediate and total: a strategy with a 2.5 Sharpe in backtest can go to breakeven or negative on day one of live trading.

It is also difficult to spot visually. A biased backtest looks like a very good strategy, not a broken one. The only reliable detection method is auditing every data reference in the code.

Common sources of look-ahead bias

Source	Example	Fix
Fill at bar close after signal on close	Signal fires on RSI(close) at bar close; trade fills at same close	Enter at next bar's open after signal fires on current close
Full-dataset normalisation	Z-score computed across all 2,000 bars and referenced at bar 100	Use expanding or rolling window — only data up to bar 100 at bar 100
High/low snooping	Stop placed at the bar's low — known only when the bar closes	Use prior bar's low, or enter on next bar's open with a market order
Corporate action hindsight	Backtest uses split-adjusted prices computed retroactively	Use point-in-time prices; apply adjustments only from the event date forward
Parameter selection on full data	Optimise RSI period over full 5-year history, then backtest on same data	Use walk-forward analysis; optimise only on past data at each step
Future-bar indicator reference	Signal at bar[t] uses bar[t+1] open to decide direction	Audit all indicator lookups — every reference must be bar[t] or earlier

How to detect look-ahead bias in a backtest

The warning signs are distinctive:

Unrealistically smooth equity curve — very few losing months, drawdowns rarely exceed 5%
Sharpe ratio above 3–4 — genuine strategies almost never sustain this over multi-year periods
Performance collapses on paper trading — the strategy worked perfectly in backtest but goes flat or negative immediately in live simulation
Win rate above 80% on trend-following signals — statistically implausible without future information

The definitive test: shift all signals forward by one bar (enter at bar +2 instead of bar +1) and re-run the backtest. If performance collapses, the strategy was relying on bar-close information it should not have had. A valid strategy will degrade only slightly from the additional slippage; a biased one will lose most of its edge.

How to eliminate look-ahead bias

Signal on the close, fill on the next open. Your signal fires when the bar closes. Your fill executes at the next bar's open. Never fill at the same bar's close.
Use only expanding or rolling windows for statistics. Any normalisation, z-score, or rank must be computed using only data available up to the current bar — never the full dataset.
Reference only bar[t] or earlier in every indicator. Audit every array index and lookback in your code. bar[t+1] is always wrong.
Use a framework that enforces the data boundary. Event-driven frameworks like zipline process one bar at a time and make future data structurally inaccessible. Vectorised frameworks (pandas, numpy) require disciplined coding — it is easy to make mistakes.
Apply point-in-time data for corporate actions and fundamentals. Use prices and ratios as they were known at the time, not as retroactively adjusted.

Look-ahead bias vs overfitting: a comparison

Issue	Type	Detection	Fix
Look-ahead bias	Coding error	Bar-shift test; code audit; impossible Sharpe	Fix data references; use event-driven engine
Overfitting	Methodology error	OOS performance drop; low WFA efficiency ratio	Fewer parameters; walk-forward analysis

Backtest without worrying about look-ahead bias

backtester.run runs strategies on zipline, which enforces strict bar-by-bar execution. Signals fire at bar close; fills execute at the next open. The most common class of look-ahead bias is eliminated by design — not by discipline.

Start free →

Frequently Asked Questions

What is look-ahead bias in backtesting?: Look-ahead bias occurs when a backtest uses data that would not have been available at the moment a trade decision was made. For example, computing a signal on the current bar's closing price and entering the trade at that same bar's close — you cannot fill at the close if you don't know the close until the bar ends. It produces inflated results that collapse immediately in live trading.
How do you detect look-ahead bias in a backtest?: The clearest signs are an unrealistically smooth equity curve, near-zero drawdowns, or a Sharpe ratio above 3–4. To confirm, check every indicator calculation: does it use any value from the current bar's close, a future bar, or a dataset statistic computed over the full history? If yes, look-ahead bias is present. Shifting all signals forward by one bar and re-running the test will cause the performance to collapse if bias was the source.
What is the difference between look-ahead bias and overfitting?: Look-ahead bias uses future data in a past signal — the rules are mechanically broken. Overfitting tunes rules to historical noise — the rules are mechanically valid but statistically overspecified. Both inflate backtests, but look-ahead bias is a coding error; overfitting is a methodology error. Fix look-ahead bias first; it is binary and detectable. Then address overfitting through out-of-sample validation.
Is using today's closing price for today's entry always look-ahead bias?: Yes, for most strategies. If your entry signal is based on a calculation that includes today's close (e.g. a moving average that uses today's close), you cannot know that value until the bar closes — so you cannot fill at that price in live trading. The correct approach is to signal on the close and enter at the next bar's open, which is what zipline and most rigorous backtesting frameworks enforce by default.
Can look-ahead bias occur in indicators computed over the whole dataset?: Yes — this is one of the most subtle forms. If you compute a z-score, percentage rank, or normalisation factor using the full dataset (including future bars) and then reference it at past points in time, every signal uses future information. Always compute rolling statistics using only data available up to the current bar.
Does backtester.run prevent look-ahead bias automatically?: backtester.run runs strategies on zipline, which enforces bar-by-bar execution with a strict data boundary at the current bar's close. Signals fire at bar close; fills execute at the next bar's open. This eliminates the most common class of look-ahead bias by design.