Look-Ahead Bias: Check When Information Became Available

Separate three timestamps

A data item can have an event time, a publication time and a time at which the system actually received it. For example, an economic value may describe a quarter that ended weeks before publication. A historical rule cannot use that value at quarter-end merely because the database labels it with the quarter's date.

QuantConnect's reconciliation documentation discusses custom-data timing and look-ahead risk. The general requirement is to ensure that the simulated decision's information set matches what could have been known then. A platform cannot correct an incorrectly timestamped custom source automatically.

Expose a same-bar mistake

Assume a hypothetical one-minute bar begins at 10:00:00 with price 100 and closes at 10:01:00 at 102. A rule that buys at 10:00:00 whenever that bar eventually closes above 101 has used a future close. Crediting a purchase at the opening price of 100 compounds the error by assuming an execution before the required information existed.

A coherent alternative evaluates the completed bar at or after 10:01:00 and then models an eligible later execution. Its price may differ from 102, and fees or spread still apply. This example identifies a timing constraint; it does not prescribe a profitable strategy.

Audit revisions and derived features

Suppose a value for January was first published on February 10 as 50 and revised on March 15 to 55. A February 20 decision should see 50 if that was the available vintage. A modern download containing only 55 cannot reproduce the historical information set without additional vintage data.

Derived statistics can leak information too. Normalizing a training period using a mean computed over the entire future dataset imports later observations. Selecting instruments based on which ones are known today to have survived introduces another form of future knowledge. The absence of an obvious “tomorrow” column does not prove the pipeline is clean.

Use a small causal replay

Choose several decision times and list every input value, its availability timestamp and the transformation that produced it. Verify that rolling windows end at the intended boundary and that joins do not pull the next published record backward. Preserve time zones and daylight-saving conventions so a one-hour shift does not become silent leakage.

For a copy-trading backtest, also distinguish source decision, source fill, message receipt and follower fill times. The follower cannot execute using a later-confirmed source price as though it were known earlier. Test uncertain or missing records explicitly rather than replacing them with a favorable later observation.

A corrected replay may reduce performance or simply change the eligible sample. Report the effect and the remaining limitations. Removing one leakage path does not prove that fill modeling, selection and repeated optimization are valid; those require their own checks.