Point-in-Time Data

What is Point-in-Time Data?

Most financial databases are built to answer the question "what are this company's numbers?" as accurately as possible today. Point-in-time data answers a different and harder question: "what did we know about this company on a given date in the past?" It stores not just the values but the timing, so that for any historical day you can reconstruct the information set an investor actually had, no more and no less.

Two properties make data point-in-time. First, every figure carries the date it became public, so a fiscal quarter that ended in December but was not filed until the following March is treated as unknown until March. Second, the record keeps the value as it was originally reported rather than replacing it with a later revision. If a company reported one number in its first filing and a corrected number two years later, a point-in-time dataset remembers both and knows which one was visible on which date.

The clearest way to picture it is as a series of snapshots, or vintages, of the same fact. Economic data works this way by design: agencies that publish figures such as GDP release an initial estimate and then revise it repeatedly over months and years, and archives of these vintages let researchers see exactly what the number looked like at each moment. Company fundamentals have the same structure, even though many databases quietly collapse it by keeping only the latest version. Preserving the vintages is what makes the data honest for backtesting.

Why Point-in-Time Data Matters in Backtesting

A backtest is only as trustworthy as the data it reads on each date. If the underlying database has been scrubbed to today's best values, then every historical decision the simulation makes is quietly informed by the future, and the result is contaminated by look-ahead bias. Point-in-time data is the direct fix: it is the thing that lets a backtest be run under the constraint that it can only see the past.

The gap between the two kinds of data is not academic hair-splitting. Standard fundamental databases were assembled to describe companies well, not to preserve reporting lags and original filings, so they tend to align numbers with the period they cover and to overwrite restated values. Studies that compared strategies tested on this convenient data against the same strategies tested on data frozen as it stood at the time have found the convenient version can materially overstate performance. That overstatement is exactly the edge that evaporates when a strategy goes live.

The decision point-in-time data informs is the most important one in the whole process: whether to trust the backtest enough to act on it. A result generated on point-in-time data is a fair estimate of what the strategy would have delivered to a real investor. A result generated on restated, period-aligned data is a description of a world that never existed. The failure mode of skipping this is subtle and expensive, because the flawed backtest looks just as clean as the honest one right up until real money is on the line.

How SledgeKey Implements Point-in-Time Data

SledgeKey stores each company's fundamentals against the date the underlying filing became public, not the fiscal period it describes. When a backtest evaluates a company on a historical date, it draws on the most recent set of financials that had already been released by that date, which means the reporting lag between a period ending and its results being filed is preserved rather than assumed away. A full year of earnings only becomes usable on the day it would genuinely have reached an investor.

The same principle governs prices and the trades themselves. Positions are entered and valued at prices that were available on the rebalance date, and the ranking a screen produces on that date is built only from what was public. Because the data is organized this way from the start, point-in-time behavior is the default rather than an option you have to remember to enable. There is no setting to switch it on; every backtest inherits it.

From your side, this is the difference between a number you can lean on and a number you cannot. When SledgeKey reports a return, it was earned by a strategy that saw only the information available at each step, with the filing delays intact. That is the same discipline that closes off look-ahead bias, and it is why the platform emphasizes filing dates and as-reported values over the hindsight-cleaned snapshots that most convenient datasets provide.

Common Pitfalls

The most common mistake is assuming that any large, reputable database is point-in-time. Size and quality are not the same thing as vintage preservation. Many widely used fundamental datasets are excellent at telling you a company's history as it reads today, yet they carry restated figures and align data to period-end dates, which is precisely the combination that breaks a backtest. The question is never how good the data is now; it is whether it remembers what it looked like then.

A related pitfall is trusting restated financials without realizing they are restated. Revisions can be large, especially around mergers, discontinued operations, or accounting changes, and a strategy that screens on a restated balance sheet is screening on information that did not exist in that form at the time. The original filing, however messy, is what the market actually traded on. Point-in-time discipline means preferring the as-reported value for the historical date even when a cleaner number is available in hindsight.

A third pitfall is treating point-in-time data as a substitute for a representative universe. It is not. Point-in-time data fixes the timing and the vintage of the numbers, but it does nothing about which companies are in the sample. A dataset can be perfectly point-in-time and still be riddled with survivorship bias if it only contains firms that are still listed today. The two protections are complementary, and a serious backtest needs both.

Related Concepts