Lookahead Bias, Explained: The Silent Killer of Stock Backtests

Lookahead bias is when a backtest uses information it could not have known at the time it claims to make a decision. It is one of the most common reasons a strategy looks brilliant on paper and then fails in live markets, and most of the time the person running the test never notices it.

A simple example

Imagine you test a rule: buy a stock the day after it reports strong quarterly results. You run it across ten years of data and the returns look excellent.

Now ask a harder question. On the date your test says it bought the stock, did the market actually have those results yet? Companies report with a lag. Results are filed, revised, and sometimes restated months later. If your dataset stamps the results against the quarter they belong to, rather than the date they were actually published, your test is buying on information that did not exist on that day. That is lookahead bias, and it silently lifts every number in your report.

Why it is so easy to get wrong

The problem is that most financial datasets are built to answer one question: what are this company’s numbers for this period. They are not built to answer the question that matters for testing a strategy: what did we know, and when did we know it.

Two failure modes dominate.

As reported versus restated. A company may report a profit figure, then revise it a year later after an audit or an accounting change. If you pull that company’s history today, you often get the revised number sitting in the slot for the old date. Any test that reads it is cheating without meaning to.

Reporting lag. Even without restatements, a result for the quarter ending in March is not public in March. It becomes public weeks later when it is filed. A dataset that ignores the filing date lets your model act on the number too early.

The fix is point in time data

The only durable fix is to store data the way it actually arrived. Every value carries the date it was first known. When you ask the dataset for a company’s numbers as of a past date, it returns only what had actually been published by then, not the version that exists today.

This is unglamorous work. It means keeping the original filing, the filing date, and every subsequent revision as separate records rather than overwriting. It means your database is bigger and your queries are more careful. But it is the difference between a test you can trust and a test that is quietly lying to you.

What to check in your own process

If you run backtests or build screens, three questions expose most lookahead problems.

• Does every financial value in your dataset have a date it was first known, separate from the period it describes?
• When a company restates a number, do you keep both versions, or does the new one overwrite the old?
• Does your test respect the reporting lag, so a decision on a given day can only see what was public by that day?

If the answer to any of these is no, your results are probably better than reality, and the gap will show up the moment you go live.

Why this matters to us

At Altys Labs we treat point in time discipline as the foundation rather than a feature. Every number is stored with the date it was known and linked back to the filing it came from, so research and testing reflect what was actually knowable at each moment. It is the least exciting part of the system and the part that decides whether anything built on top of it can be trusted.