Prevent Lookahead Bias in Pine Script MTF Strategies with request.security

The core MTF question is when the value became knowable

The final close, high, low or indicator value of a higher-timeframe bar is not confirmed until that bar closes. At 09:00 on a 15-minute chart, code cannot know the final close of the 09:00–10:00 hourly bar. If a historical plot makes that completed value visible from 09:00, audit for future leakage.

Save symbol, requested timeframe, expression, gaps, lookahead, offset and historical/realtime behavior as one request contract. “Uses the hourly timeframe” is incomplete; state which hourly bar, confirmed or open, and from which lower-timeframe bar it becomes eligible.

In this guide, HTF means that the requested timeframe is strictly greater than the chart timeframe. A 60-minute request on a 60-minute chart, or a 15-minute request on a 60-minute chart, is outside this confirmed-HTF pattern. Convert both to seconds and stop with a runtime error unless requested > chart.

Map the HTF close boundary onto lower-timeframe bars

In a simple four-to-one mapping, the final value of the 09:00–10:00 hourly bar becomes confirmed at 10:00. Before that boundary, realtime high, low and close are fluid. A confirmed-only design holds the previous completed HTF value through the hour and switches after 10:00.

Provider revisions and session differences can remain, so “usually consistent” is not an identity guarantee.

The arithmetic 60/15=4 does not prove that four market bars exist at the relevant boundary.

Build separate cases for four aligned bars on an ordinary session, a shortened-session endpoint and the first bar after a holiday. Record the HTF start/end plus the adjacent lower-timeframe bars, then reconcile the first appearance of the completed value in both the plot and timestamped log. Never invent a missing chart bar to make the ratio fit.

The offset changes what lookahead_on means

`barmerge.lookahead_on` is not universally safe or unsafe in isolation. Requesting the current HTF `close` can distribute a completed historical value from the start of its period. Requesting `close[1]` in the HTF context and aligning it with lookahead_on is a representative way to receive the prior confirmed HTF value consistently.

Same-timeframe and lower-timeframe requests have different semantics; validate that this is truly an HTF request.

Adding `barstate.isconfirmed` to the lower-timeframe strategy does not remove a future value already leaked by the request expression. Chart-context confirmation and requested-context confirmation are separate states.

Freeze symbol, timeframe, gaps and session together

A requested symbol can differ through session, adjustment, currency or ticker construction even when its visible name looks similar. `gaps_off` can carry a previous value while `gaps_on` exposes `na`. Holidays, extended hours, weekends and daylight-saving transitions can alter the practical alignment.

• Save the full syminfo.tickerid or explicitly constructed ticker ID.
• Reject a requested timeframe that is not truly above the chart timeframe.
• Record expression length and every history offset.
• State gaps and lookahead explicitly with a comment explaining the intent.
• Hand-check sample timestamps around a session and HTF boundary.

Similar final values or matching plot colors do not prove an identical request contract.

Exercise a requested extended session, a gaps_on case that returns na, and a symbol switch that changes exchange timezone. Before counting signals, prove which series was available on which bar and whether carried-forward data was mistaken for a newly confirmed value.

Request the previous confirmed HTF expression explicitly

The Pine v6 sample requires a timeframe above the chart, evaluates `close[1]` and `ta.ema(close, 20)[1]` in the requested context, and aligns them with lookahead_on. The cross is only a timing demonstration. Confirmed data is intentionally later than the still-forming HTF value.

//@version=6
strategy("Confirmed HTF audit demo", overlay = true)

string higherTf = input.timeframe("60", "Higher timeframe")
int chartSeconds = timeframe.in_seconds()
int higherSeconds = timeframe.in_seconds(higherTf)

if higherSeconds <= chartSeconds
    runtime.error("Choose a timeframe higher than the chart timeframe")

float confirmedHtfClose = request.security(
    syminfo.tickerid,
    higherTf,
    close[1],
    lookahead = barmerge.lookahead_on
)
float confirmedHtfEma = request.security(
    syminfo.tickerid,
    higherTf,
    ta.ema(close, 20)[1],
    lookahead = barmerge.lookahead_on
)

bool longCondition = ta.crossover(confirmedHtfClose, confirmedHtfEma) and barstate.isconfirmed
bool exitCondition = ta.crossunder(confirmedHtfClose, confirmedHtfEma) and barstate.isconfirmed

if longCondition
    strategy.entry("L", strategy.long)
if exitCondition
    strategy.close("L")

plot(confirmedHtfClose, "Confirmed HTF close", color.teal)
plot(confirmedHtfEma, "Confirmed HTF EMA", color.orange)

The EMA is calculated in the HTF context and then offset. That differs from repeating an hourly close across 15-minute bars and computing a chart-context EMA. Also review current request-count and execution limits.

Compare historical, realtime and reload states on the same boundary

1. 01Choose a known boundary

   Select lower-timeframe bars immediately before and after one HTF close.

2. 02Record historical state

   Save values, signals and markers immediately after reload.

3. 03Observe realtime state

   Timestamp whether the requested value stays fixed or changes while the HTF is open.

4. 04Observe HTF close

   Identify the first chart bar receiving the new confirmed value.

5. 05Reload again

   Diff the same bars and classify every change instead of calling all of them repainting.

Run a known unsafe and confirmed pattern over the same window, then compare first availability, signal count and trade timestamps—not only performance. Unlike BT07 overfitting, the defect here is a data-availability bug rather than parameter selection.

Freeze every setting except the expression offset and lookahead between the two versions.

Reproduce this with three evidence sets: save the historical bars and values, observe timestamped changes while that HTF bar forms, then reload after confirmation. Bind the tables with ticker ID, version ID, timezone and session. Rows that cannot distinguish data revision, session mismatch or code change remain unresolved and are excluded from release.

The release ledger keeps each LTF open and close, its HTF open and close, the predicted first-availability time and the observed switch time in separate columns. Equal values do not pass when timing is early. Holidays, shortened trading, extended sessions and different gaps settings receive distinct case IDs rather than being merged into one population.

Include an unsafe lookahead_on request without the offset as a negative control. If the audit does not flag its completed value appearing too early, the test has no detection power. The confirmed version must hold the prior value before HTF close, switch only on the first eligible bar afterward and retain that mapping after reload before its CSV can enter downstream analysis.

Send only leak-free strategy results into downstream analysis

Prove at a known boundary—and again after reload—that future data no longer enters the decision, then import the corrected Strategy Tester CSV/XLSX into the Backtest & Robustness Lab. Compare the leaking and corrected versions across performance metrics, drawdown, stress, OOS and parameter stability to isolate results created by the leak. Paid version management is appropriate when that before-and-after evidence must be retained.

When a free indicator uses MTF data, its plot is still not a strategy export. Review source visibility, requested timeframe, confirmation and alert timing; strategy conversion adds a new order and fill contract.