Analysis & metrics

Look-ahead bias

By Jarosław Wasiński • Published: Mar 24, 2026 • Updated: Oct 11, 2026

Future information leaking into a historical decision, such as a bar’s final close before the bar finishes, a later macro-data revision, or a swing before confirmation. It distorts the test relative to information actually available at the time; it does not necessarily improve every result. A developing bar’s current reading can legitimately be used when simulation respects its real availability. Check publication, confirmation, decision and fill times, repainting and other-timeframe requests such as Pine Script request.security(). Not every changed marking or lookahead setting is automatically the same error.

Example. An illustrative hourly bar spans 10:00–11:00 UTC. At 10:15, the latest available price is 1.1020, but its final 11:00 close is 1.1050. A backtest buying at 10:15 because the final hourly close exceeds 1.1040 uses future information. A rule can legitimately use a developing bar’s current price if it is actually known and handled consistently in the test.

Availability time is what matters

Distinguish the observation’s reference period, publication time, retrieval time and subsequent revision. Data for a previous month were not available throughout that month. A revised series downloaded today can contain information absent at the decision. See St. Louis Fed: FRED/ALFRED real-time periods for historical vintages. Use explicit timezones and data delays.

A hindsight chart can look different

A swing confirmed by two later bars was not known at the extreme itself. ZigZag or another tool changing historical markings must be evaluated using what it showed at the decision. Repainting is not always the same error, and reading a partial bar is not categorically prohibited. Information availability and consistency between simulation and real-time behaviour are the relevant conditions.

Errors in other-timeframe data

In Pine Script, unoffset higher-timeframe data with lookahead_on can reveal a final value prematurely on historical bars. For appropriate HTF requests, using the preceding confirmed value with the correct configuration defines a separate delayed-information model. Changing a single flag does not solve every error. See the method and limitations in TradingView’s official documentation.

Signal and fill occur at different times

If a condition requires the final close, the calculation becomes available only after the relevant close and data update. Do not automatically assume a fill at that price without modelling order acceptance, bid/ask side and latency. Waiting for confirmation can change entry. The test should reproduce this sequence rather than move profitable signals backwards onto the bar whose outcome has just become known.

Practical checks

For selected signals, record inputs, availability time, decision time and fill time. Replay history step by step, including session boundaries and revisions. Fitting scaling or features on the entire history can also leak information into a test. In the course: backtesting and forward testing. Sources checked on 11 October 2026.

FAQ

Is delaying every signal by one bar sufficient?

No. Required delay depends on the data, confirmation rules and actual publication time.

Must look-ahead always inflate performance?

No. It distorts the information model; examine its effect rather than assume a direction.

← Back to the full glossary