Data leakage and look-ahead bias

Who this is for — Anyone turning historical data into signals, optimising parameters, using machine learning or simulating orders. A model can be coded without errors and still “know” the future because causality was violated in a join, feature, split or execution price.

Data leakage is contamination of a research procedure by information that should not have been available at the point where it is used. Look-ahead bias is the temporal case: a decision at time t directly or indirectly incorporates data known only after t. The result is not merely optimistic; it simulates a different strategy equipped with a nonexistent information channel.

In plain terms — Sorting rows by date is not enough. Every step must respect this chain: information available → signal → order → possible fill → position → outcome.

Every arrow must point from past to future. An arrow returning to the left indicates possible information leakage.

Essential distinctions

Problem	What happens	Example
Look-ahead	a future value enters the decision	using the bar close to buy at that same close without auction mechanics or latency
Target leakage	the forecast target leaks into features	an aggregation includes the target's future period
Preprocessing leakage	estimation or selection uses train and test together	normalising with the full sample's mean and standard deviation
Cross-sample leakage	correlated observations cross the boundary	overlapping labels appear in both train and test
Revised information	the final value replaces the available vintage	a macroeconomic figure corrected months later
Non-causal simulation	the order receives an impossible price	signal on the close with a guaranteed fill at that close

Survivorship bias is distinct: it arises from observing only entities that survived or were selected after the fact. It can coexist with leakage, but correcting timestamps alone does not recreate failed instruments, closed funds or former index members.

Three clocks: signal, order and fill

A trading rule must state at least three moments:

Signal time: the latest information allowed in the calculation.
Order time: the first moment at which an order can be created and sent.
Fill time: the moment or interval in which the execution model may assign quantity and price.

If a signal uses close[t], a fill at close[t] requires mechanics genuinely available before or during the auction and data compatible with that decision. Without such evidence, a more defensible convention is to submit after the signal and model later execution. Likewise, the completed high and low of a bar cannot decide an order filled inside that same bar without an observable intrabar sequence.

For releases, filings and macroeconomic data, the relevant time is the dissemination timestamp, not the economic-period date. Point-in-time data also include vintage, vendor delay and subsequent corrections.

Where leakage hides

Features and transformations

centred averages, bidirectional filters or interpolation using future observations;
cross-sectional ranks calculated on a universe reconstructed today;
winsorisation, imputation or standardisation estimated on the whole dataset;
fundamentals aligned with quarter-end rather than filing time;
splits and dividends applied without distinguishing effective date from the date on which they became known.

Research and selection

The test set can be contaminated without any future-looking column. Repeatedly consulting its outcome to select features, thresholds or models gradually turns it into development data. Out-of-sample is not a file label; it is a role in the process. The number of alternatives attempted, rejected decisions and selection criteria must be recorded.

Orders and execution

An OHLC price does not demonstrate that an order would have filled. Stops and limits may be touched without execution; available quantity may be insufficient; queue priority may be unknown; delays and partial fills change the position. Always assigning the most favourable bar price is a form of hindsight, separate from but connected to transaction costs in backtests.

Causal protocol

Write the decision before the code. List inputs, timestamps, time zones, cutoffs, frequency and the action produced.
Version raw data. Preserve snapshots, vintages, the universe and corporate actions without overwriting history.
Compute every feature “as of”. A query at t must exclude every record with available_at > t.
Fit on train only. Imputation, scaling, feature selection and optimisation must be learned from the permitted subset and then applied forward.
Respect temporal order. Use chronological splits; where labels or positions overlap, consider purging and gaps consistent with the horizon.
Freeze the specification. Record rules, parameters, universe, benchmark and metrics before final evaluation.
Separate signal, order and fill. Apply delays, calendars, order types and genuinely observable data.
Preserve every experiment. An experiment ledger reduces invisible data snooping.
Repeat from a clean snapshot. The result must be reproducible without intermediate files built with future information.

Illustrative example — A rule buys at the open when quarterly earnings exceed expectations. The database associates the figure with quarter-end, but the release arrives six weeks later. The original test therefore buys before publication. The correction preserves the release timestamp, waits for the next tradable window and uses the vintage then available. The timing illustrates a causal check, not a recommended strategy.

Diagnostic tests

Test	What it may reveal
Shift every feature by one bar	hidden dependence on the current bar
Reconstruct the dataset as of a historical date	revised values or retrospective membership
Artificially increase latency and gaps	fragility in the causal sequence
Fit preprocessing separately in each fold	train/test contamination
Remove the bar's “perfect” price	impossible fills or favourable selection
Run a placebo with a time-shifted target	suspicious pipeline correlations

A collapse after these tests is a warning, not automatic proof of the cause. A stable result does not prove the absence of leakage either: some leaks can survive perturbations.

Limitations

Temporal splits, walk-forward procedures and cross-validation do not repair data already contaminated. Purging and embargoes must follow the structure of the labels rather than being applied as rituals. A causal dataset may still suffer measurement errors, multiple selection, regime change, low power or an incomplete universe. Validation therefore requires both statistical controls and an audit of the information path.

Sources

Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — inference when the selected outcome emerges from many explored specifications.
Robert D. Arnott, Campbell R. Harvey and Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — separation of research, selection and holdout testing under scarce financial data.
David H. Bailey, Jonathan M. Borwein, Marcos López de Prado and Qiji Jim Zhu, The Probability of Backtest Overfitting — overfitting risk arising from selection among many configurations.
Federal Reserve Bank of St. Louis, FRED® versus ALFRED® — the difference between historical information available today and the vintage known in the past.
scikit-learn, TimeSeriesSplit — time-ordered cross-validation and the gap parameter; official technical documentation.