What is Point-in-Time Data? (And Why Most Backtests Ignore It)

If you've ever run a backtest that looked great on paper and then failed immediately in live trading, there's a good chance you know the feeling — even if you don't know the cause.

One of the most common causes is a data problem that most traders never think to check: the backtest used information that wasn't actually available on the dates being tested.

That's what point-in-time compliance is designed to prevent.

The Problem: Look-Ahead Bias

Every stock database contains historical records — earnings, revenue, P/E ratios, outstanding shares, analyst estimates. The problem is that most of these numbers get revised after the fact.

A company reports earnings on February 15. The initial report shows EPS of $1.12. Three months later, an accounting restatement revises it to $1.04. Most financial databases store the revised number against the original date — not the number that was actually reported at the time.

If your backtest uses that database, it's making decisions on February 15 using a number that didn't exist until May. Your model is looking into the future without knowing it. This is called look-ahead bias, and it makes strategies appear far more profitable than they actually are.

The Other Problem: Survivorship Bias

Related but distinct: most financial databases only contain stocks that still exist today.

If you backtest a strategy over "the last 20 years" using today's list of S&P 500 companies, you're testing against survivors. The companies that went bankrupt, got acquired, or were delisted — all the ones that would have been in the universe during your test period — aren't in the data. Your strategy never had to deal with them.

This inflates backtest performance significantly. In any real historical period, a meaningful percentage of stocks in a given universe declined sharply or went to zero. A survivorship-biased backtest never encounters these stocks — it only tests against the ones that made it through.

What Point-in-Time Compliance Means

A point-in-time compliant database solves both problems.

For each date in history, it stores only the data that was actually available on that date. The earnings reported on February 15 are stored as $1.12 — not the restated number from May. Stocks that were delisted or went bankrupt are included in the historical universe for the periods when they existed. Nothing looks forward. Nothing gets retroactively corrected.

When your model trains on this data, it's learning from what a real trader would have actually seen on each day. When it backtests on this data, the results reflect what would have actually happened — not a version of the past that was cleaned up after the fact.

Why This Changes Backtest Results

The difference between a survivorship-biased, non-point-in-time database and a clean one can be enormous.

Strategies that look like they return 30%+ annually on dirty data often look like 12–15% strategies on clean data. Not because the strategy is bad — because the first number was fiction. The strategy was never going to encounter the stocks that went down, and it was always going to use the best available version of the fundamentals, not the version that existed in real time.

A backtest on clean data is a realistic estimate of forward performance. A backtest on dirty data is a number that makes you feel good until you go live.

How Quant-Builder Handles This

Quant-Builder's dataset includes 30 years of point-in-time compliant data across 600+ features per stock — updated every night after market close. Every training run and every backtest uses data that reflects only what was actually known on each historical date.

Delisted stocks, bankrupt companies, acquired names — they're all in the historical universe for the periods when they existed. Restated fundamentals are stored with the restatement date, not retroactively applied to prior periods.

This is one of the things that separates institutional-grade quant research from retail backtesting tools. Most retail tools use whatever data their provider gives them, with no guarantee of point-in-time integrity. Building on clean data doesn't guarantee your model works — but it guarantees your backtest results mean something.

The Simple Rule

Before trusting any backtest result, ask one question: does this database only show me information that was available on each date being tested?

If the answer is no — or if you don't know — the results are unreliable. You're looking at what the strategy could have done if it could see the future. That's not a strategy. That's fiction.