Look-ahead bias in backtesting occurs when a simulated decision uses information that was unavailable at the decision time. Examples include an unfinished hour's final close and a pivot identified by later bars. Survivorship bias excludes instruments that disappeared from the sample. Both distort the historical test, while data snooping and selective reporting distort how a strategy is chosen or judged.
Backtest biases at a glance
Scroll horizontally to read every column.
| Problem | What enters or leaves the test | Evidence to inspect |
|---|---|---|
| Look-ahead bias | Information enters before it was available. | Input availability time versus decision time. |
| Survivorship bias | Only instruments or records that survived remain. | Historical membership, removals and missing histories. |
| Data snooping | Repeated searches shape the selected rule. | All tried rules, parameters, markets and date ranges. |
| Selective reporting | Unfavourable trials disappear from the account of the research. | The experiment register beside the published selection. |
| Repainting | Historical and realtime calculations or plots differ. | Saved realtime values versus values after recalculation. |
TradingView defines lookahead bias as future information leaking into historical evaluation. Its selection-bias guidance covers cherry-picking instruments, timeframes and testing ranges.[1] Brown, Goetzmann, Ibbotson and Ross's Survivorship Bias in Performance Studies shows how a sample truncated by survival can distort performance inference, using mutual fund managers as its case.[4]
Use these checks within the backtesting process. Increasing the history length does not remove a systematic information leak.
How do you check whether an input was available?
Required timing condition: input availability time ≤ decision time
The condition is a practical audit rule, not a performance metric. Input availability time means when the value used by the rule could actually be known. Decision time means when the simulation evaluates the instruction. A timestamp printed under a candle or drawing is not necessarily its availability time.
For a completed-bar rule, the final high, low and close become known at the bar's close. A developing value can be observed earlier, but it is a different input. TradingView documents that realtime high, low and close values can change while a bar remains open.[2]
Apply the check separately to every dependency. A five-minute bar can be confirmed while the hour containing it is still developing. Likewise, a price pivot plotted on an earlier bar can require later bars before the script identifies it.[2]
Worked example: an hourly close used 45 minutes early
Illustrative times and prices, not a recommendation or a strategy result. Assume continuous five-minute bars, an hourly bar from 10:00 to 11:00 UTC, and a rule evaluated at 10:15 UTC. The rule compares the latest completed hourly close with 100.
| Observation | Value | Available at 10:15? |
|---|---|---|
| Previous hour's final close, at 10:00 | 99 | Yes. The completed-close comparison is false. |
| Current hour's developing price, at 10:15 | 101 | Yes, but it is not the completed hourly close. |
| Current hour's eventual final close, at 11:00 | 102 | No. Using it at 10:15 leaks future information. |
The leaked value arrives 11:00 − 10:15 = 45 minutes too early. At five minutes per bar, that is 45 ÷ 5 = nine bar intervals. Waiting for the 10:15 five-minute close does not confirm the hourly close.
Using 101 would avoid pretending to know the eventual 102, but would change the rule to one using a developing hourly value. The distinction must appear in the specification and historical model. Replacing unavailable data with a different observable value is a rule change.
How do higher-timeframe requests and pivots leak information?
As of 25 September 2026, TradingView's Pine Script v6 documentation identifies an important higher-timeframe trap: using barmerge.lookahead_on with an unoffset expression in request.security(). Historical bars can receive the higher-timeframe bar's final value before that value was actually available.[3]
For a rule that needs the previous confirmed higher-timeframe value, TradingView documents an expression offset of at least one requested bar, combined with barmerge.lookahead_on. The offset belongs inside the requested expression. The request.security and lookahead guide explains the pattern and its higher-timeframe scope.[3]
Removing lookahead_on alone does not establish identical historical and realtime behaviour. A request can still return a developing higher-timeframe value during realtime execution and a confirmed value after reloading. Check the intended input and when it becomes final.[2]
Pivots create a different visual trap. If confirmation needs later bars, moving the marker back to the pivot bar does not move the discovery time back. Record the confirmation event as the decision input. The pivot confirmation guide distinguishes the plotted location from the usable signal.[2]
Is every repainting indicator biased?
No. TradingView defines repainting broadly as historical and realtime calculations or plots behaving differently. An indicator updating with an open bar is not necessarily reading the future. The problem arises when the historical evaluation presents information or decisions that could not have existed at the stated time.[2]
Save the values used when a realtime event occurs, then compare them with the recalculated history. A difference is a diagnostic lead, not a complete diagnosis: revised data and a changed history starting point can also change calculations. A matching observation does not prove every other input is valid.
Bar-close order assumptions need a separate check. TradingView documents that process_orders_on_close can let the emulator fill an order on the same closing tick that created it. An external order triggered after that close does not thereby receive the same price or trading opportunity.[1]
A simulated same-close fill is not automatically a future-data leak. It is an execution assumption. Conversely, recalculation after historical fills can expose a bar's final values before the simulated decision should know them. Audit information timing and fill timing separately.[1]
What is survivorship bias in stock and index tests?
Survivorship bias arises when the retained sample depends on surviving until a later date. A stock-selection test restricted to today's surviving listings can omit securities that were available earlier but later delisted. Testing past index membership using today's constituents introduces a related future-informed selection problem. Both apply the survival-conditioning mechanism analysed for fund samples by Brown and co-authors.[4]
For a constituent-selection test, reconstruct the eligible universe at each decision date. Keep entry and removal dates, identifier changes and the treatment of missing or terminated histories. Do not silently remove a security's earlier observations because its history ends before the test does.
Illustrative coverage example: a historical universe contains 100 securities, but a current-only dataset retains 80. The missing count is 100 − 80 = 20, or 20 ÷ 100 = 20% of the original universe. That percentage measures missing coverage, not the size or direction of a return distortion.
Distinguish a rule selecting individual index constituents from a rule trading an index instrument's historical price series. The first needs historical membership. The second needs the relevant instrument's data and specifications; substituting today's constituent list is a different test.
For a fixed set of major FX pairs, this stock-listing form of survivorship bias is less directly relevant. The test is not selecting surviving companies. That narrower observation does not excuse choosing pairs, feeds or dates after inspecting their results, which remains a selection problem.[1]
How do data snooping and selection bias differ?
Data snooping means repeatedly using the same observations to discover or choose rules, then treating the chosen result as independent evidence. The search may span parameters, entry definitions, instruments or dates. TradingView's overfitting guidance describes the underlying problem: tailoring a strategy to the data used to assess it.[1]
Selective reporting concerns what is retained or shown. A research process can test many variants but present only the chosen one, concealing how strongly the choice depended on the sample. The finished rule's simplicity does not reveal the size of the search that produced it.
Preserve discarded trials and define the evaluation criteria before examining reserved results. The overfitting guide covers search history; the out-of-sample testing guide explains when a holdout stops being independent. Choosing between unchanged candidates using a holdout still uses that holdout for selection.
Which checks belong before an alert reaches MT5?
- Freeze the question: record the rule version, market universe, dates and evaluation criteria before inspecting the reserved test.
- Audit the clock: list each input, its source and its availability time. Include higher-timeframe values and pivot confirmation.
- Inspect calculation settings: distinguish bar-close, intrabar and after-fill evaluation. Verify the data available at each simulated decision.
- Audit membership: identify missing instruments and why they are absent. Preserve the intended historical eligibility rule.
- Retain the search: save rejected candidates and unfavourable windows instead of presenting only the final selection.
- Compare realtime records: preserve actual signal values and alert times, then inspect differences from recalculated history.
- Verify execution separately: match the alert to processing and the intended broker outcome on demo.
PineConnector's recommendations explicitly separate backtest and repaint checks from observing realtime demo behaviour. Historical markers are not replayed as newly sent alerts.[5]
Follow the evidence through each stage: condition true, alert triggered, webhook delivered, PineConnector processing and EA order request. Then distinguish broker acceptance, executed deal and resulting position. PineConnector's setup test requires checking the broker trade after processing.[6] MT5 defines orders, deals and positions separately.[7]
What can these bias checks still miss?
A clean information timeline does not validate transaction costs, fill assumptions or future market conditions. An untouched holdout can repeat the same coding or data error as the development sample. Likewise, a successful demo order verifies an observed execution path, not the historical research design.
The useful stopping question is specific: which claim did this check test, and what evidence would contradict it? A timestamp audit tests availability. A membership audit tests sample coverage. Neither establishes what a future trading period will produce.
Frequently asked questions
What is look-ahead bias in backtesting?
Look-ahead bias occurs when a simulated trading decision uses information unavailable at that decision time. Examples include using an hourly bar's final close before the hour ends or treating a later-confirmed pivot as known at its plotted location. Audit each input's availability time separately from the chart timestamp and simulated fill time.
What is survivorship bias?
Survivorship bias occurs when a sample retains only instruments or records that survive to a later date. In a historical stock-selection test, using only current listings can omit securities that later delisted. Reconstruct historical eligibility and retain removal histories. Missing coverage alone does not quantify how much the reported result was distorted.
Does waiting for bar close remove backtest biases?
Waiting for a chart bar to close can remove uncertainty in that bar's final price values. It does not confirm a still-open higher-timeframe bar, repair future-informed instrument selection or undo repeated tuning on the same sample. Simulated fills at the close also need separate scrutiny because an external broker request occurs afterwards.
What is data snooping in trading research?
Data snooping is repeated use of the same observations to discover or select trading rules, followed by treating the selected result as independent evidence. Searches across parameters, markets and testing dates all matter. Keep an experiment register and reserve evaluation data that did not influence the final choice.
Reviewed 25 September 2026. Facts were checked against the linked sources on that date. Nothing in this article was tested on a trading account and no code was compiled.
Related reading
- How to backtest a trading strategy
- Higher-timeframe data and request.security lookahead
- Overfitting and curve fitting in trading
- Out-of-sample testing and honest holdouts
Sources
- TradingView – Strategies: lookahead bias, selection bias, overfitting and order timing, accessed 25 September 2026.
- TradingView – Repainting, accessed 25 September 2026.
- TradingView – Other timeframes and data: avoiding higher-timeframe repainting, accessed 25 September 2026.
- Brown, Goetzmann, Ibbotson and Ross – Survivorship Bias in Performance Studies, The Review of Financial Studies 5(4), 1992 (hosted PDF), accessed 25 September 2026.
- PineConnector – Recommendations: backtests and repaints, accessed 25 September 2026.
- PineConnector – Test your setup, accessed 25 September 2026.
- MetaQuotes – Basic Principles: orders, deals and positions, accessed 25 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
