Point in Time Data and Why Vendors Get It Wrong

Point in time data records what was known on each historical date, and most commercial datasets fail this test in ways that are easy to miss.

Point in time data records, for every historical date, exactly the values that were known and published as of that date, rather than the current, final, or latest amended value applied retroactively across history. Most commercial financial datasets fail this standard in at least one field, and the failure is easy to miss because the data still looks correct, it is simply correct for the wrong date.

The most common failure mode is a database schema that stores a single value per company per metric and simply overwrites it whenever a new figure arrives. A company's quarterly revenue figure reported in January might be revised in a later filing, and a database that overwrites the January value with the revision has silently erased the record of what was actually known in January. A backtest querying that database for the January date receives the revised figure, not the one that existed at the time, and any signal built from that field is unknowingly using information from the future relative to the date it is dated with.

This is not a rare edge case confined to obscure data providers. It is the default behavior of a great many fundamental and economic datasets, because storing only the current value is cheaper and simpler than storing the full history of every revision alongside the date each revision was published, and many vendors built their systems before point in time correctness was a widely understood requirement.

Earnings figures are restated for accounting errors, changes in accounting standards, and discovered irregularities with some regularity across the corporate universe. A backtest that appears to find a profitable relationship between an accounting ratio and subsequent stock returns, when that accounting ratio was computed using restated figures rather than the figures originally reported, has not discovered a market inefficiency. It has been shown the correction before predicting the correction, which is a direct instance of the look ahead bias described in Look Ahead Bias and the Ways It Enters a Backtest.

Even a dataset that correctly avoids overwriting values can still introduce bias if the backtest does not account for the lag between the end of a reporting period and the date the figure was actually made public. Quarterly earnings are not published the day the quarter ends, they are published weeks later, and a backtest that applies a quarter's earnings figure starting on the quarter's final day, rather than on the actual announcement date, is again using information before it existed. Economic data carries the same issue: a monthly employment report covering January is not released until several weeks into February, and using the January date rather than the release date understates how…