Choosing the Signal Lag
The gap between when data becomes known and when a trade based on it can actually execute is not a backtest technicality — get the lag wrong and the whole result is fiction, often a very convincing one.
Prerequisites: Point-in-Time Data
Every backtest implicitly assumes some amount of time passes between when a piece of information is known and when a trade based on it hits the market. Get that assumption wrong in the optimistic direction and the backtest is not measuring a strategy — it is measuring how good the strategy looks when it is allowed to trade slightly before the information exists.
What "lag" actually means
The lag is the delay, in trading days or hours, between the timestamp of the data used to compute a signal and the timestamp of the trade that acts on it. A quarterly earnings figure is not tradeable the instant the quarter ends — it is tradeable once it is reported, weeks later, and even then only after whatever delay a real execution pipeline needs to receive the data, compute the signal, and route an order. A backtest that uses the quarter-end date instead of the report date, or that assumes same-bar execution on data that in reality takes a day to reach the desk, has built in a small amount of look-ahead that will not survive live trading.
The correct lag is not one universal number — it depends on the data source. A price-based signal computed from yesterday's close can often trade at today's open with only an overnight lag. A fundamental data field is only valid from its filing timestamp forward, which in point-in-time terms can be days or weeks after the period it describes. An alternative dataset (satellite imagery, credit-card panels) has its own vendor-specific delivery lag on top of the underlying data's own delay.
The two failure directions
Lag too short — effectively zero, or shorter than data actually becomes available — inflates backtested performance by letting the strategy "see" information before a real trader could have. This is the more dangerous direction because the backtest looks better, not worse, and a researcher has no natural prompt to go looking for the bug.
Lag too long is the safer mistake: it understates how good the strategy could be, because it forces the strategy to wait longer than necessary before acting. It costs opportunity, not credibility, and errs toward being caught rather than hidden.
| Lag choice | Effect on backtest | Danger |
|---|---|---|
| Too short (look-ahead) | Inflated performance | High — the bug hides inside a good-looking result |
| Correct | Realistic performance | — |
| Too long | Understated performance | Low — costs an opportunity, not credibility |
The classic version of this mistake: using a data field's "as of" date (the date the number describes) instead of its "reported" or "available" date (the date it actually became public). The two dates coincide for prices; for almost everything else — fundamentals, revisions, ratings — they differ by days to months, and using the wrong one is silent look-ahead bias.
The lag should always be set to the longest, most realistic delay a live pipeline would actually face — not the delay that makes the backtest look best. If shortening the lag by a day materially changes the result, that sensitivity is telling you the strategy's edge lives inside a window a real execution pipeline may not have.
Practice in interviews
Further reading
- Lopez de Prado, Advances in Financial Machine Learning