Look-ahead bias in backtesting: check when data was known

Look-ahead bias occurs when a historical decision uses information that was not available at that time. Sorting rows by their observation date does not prevent it. You also need to know when each value became usable.

A report can describe January 12 and arrive after that day's decision. A later revision can replace the original number. Both may appear under the same observation date in a current download.

A worked release-time example

Suppose a simulated strategy makes a decision at 15:00 UTC on January 12. These records are invented to illustrate the timing rule; they are not observations from a market or economic series.

At 15:00 on January 12, the latest available value is 97. At 21:00 that day it is 101. Using the revised value of 99 at either earlier time would use future information. Joining on the observation date alone can make that mistake without an obvious error message.

For this single-series example, select the last record whose availability time is no later than the decision. The following Python uses only the standard library and can be copied into a file and run.

from datetime import datetime

def utc(text):
    return datetime.fromisoformat(text.replace("Z", "+00:00"))

rows = [
    (utc("2026-01-12T14:00:00Z"), 97),
    (utc("2026-01-12T20:05:00Z"), 101),
    (utc("2026-01-13T13:00:00Z"), 99),
]

def latest_available(records, decision):
    known = [row for row in records if row[0] <= decision]
    return max(known, key=lambda row: row[0])[1] if known else None

early = utc("2026-01-12T15:00:00Z")
later = utc("2026-01-12T21:00:00Z")
assert latest_available(rows, early) == 97
assert latest_available(rows, later) == 101
assert latest_available(rows, utc("2026-01-12T13:00:00Z")) is None

# A changed future revision must not change the earlier input.
changed = rows[:2] + [(rows[2][0], 999)]
assert latest_available(changed, early) == 97
assert latest_available(changed, later) == 101
print("Timing checks passed")

This deliberately small function assumes unique availability times and one series. Real data needs security or series identifiers, observation periods, revision ordering, and a rule for simultaneous releases. It also needs a distinction between public release time and the time your system could receive and process the data. A timestamp check cannot recover missing historical vintages.

Training can leak future information too

The scikit-learn guide to data leakage explains why preprocessing must be learned from training data. For example, computing a scaling average across the full history lets the test period influence earlier model inputs. Fit the transformation on the training portion, then apply that fitted transformation to the later evaluation portion.

TimeSeriesSplit supports chronological training and evaluation with a configurable gap. The gap counts samples, not elapsed time. Its documentation also requires equally spaced samples for comparable test durations. It does not inspect when a financial label becomes known or whether a vendor revised an input.

For example, a training row dated January 10 whose target is a five-session future return needs prices from later sessions. If those prices arrive after the model's training cutoff, that row's target is unavailable at the cutoff. Exclude it or move the cutoff. Choose any gap from the label's actual time span and availability, rather than assuming one row is enough.

A small audit before interpreting performance

• For one simulated decision, print each input's observation time, release time, and assumed usable time. Reject unavailable values instead of filling them from a later record.
• Change or remove records after the cutoff and rerun the earlier input calculation. Earlier inputs should stay the same.
• Check preprocessing and model selection inside each training window. Keep the final evaluation period out of parameter choices.
• Inspect universe membership and corporate actions as they were known then. A correct timestamp on the wrong security still produces a wrong input.

These checks expose specific timing errors; passing them does not prove a strategy is profitable or free of every bias. Our security-identity note covers a separate input failure, and the adjusted-price guide explains why today's price history needs an explicit convention.