Point-in-Time Data

Ask your database what Acme's earnings per share were in Q2 2021 and it will give you a number. That is the wrong question. The question a backtest needs answered is: what did the database say Acme's Q2 2021 EPS was, on the morning of 4 August 2022?

Those are different questions with different answers, and a normal database can only answer the first one. It stores the current best value for every historical fact. Every time a company restates, every time a statistical agency revises, every time a vendor backfills a correction, the past silently changes underneath your research. A point-in-time (or bitemporal, or vintage) database keeps the old answers too, so you can reconstruct what a screen would have shown on any given day.

Two dates on every row

The fix is structural, not clever. Every fact gets two timestamps:

• Valid time — the period the number describes. "Q2 2021." "The week ending 12 March."
• Knowledge time — when this version of the number became available to you.

A query then always carries an as of date and returns the latest version whose knowledge time is before it. This is the as-of join, and it is the single most important join in quantitative research. See Vintage Databases and As-Of Joins.

Note the difference from Decision Time Versus Data Timestamp, which is about lag: the Q2 number does not exist until roughly six weeks after the quarter ends. Point-in-time is about the value: even at the correct date, the number sitting in your file today may not be the number that was published then.

What a vintage table looks like

The same fact, as three different databases would report it:

You ask on	As-reported EPS, Q2 2021	What happened
5 Aug 2021	1.42	First release
12 Nov 2021	1.42	Unchanged through Q3 filing
3 Mar 2023	1.11	Restated after a revenue-recognition correction
Today, non-PIT database	1.11	The 2021 rows were overwritten in place

A backtest run on the last row believes that in August 2021 it knew about an accounting problem that surfaced eighteen months later.

Worked example: an accounting-risk screen that could not lose

A screen designed to short accounting risk: rank 900 US names quarterly on aggregate accruals and a handful of earnings-quality flags, short the worst decile, hold three months.

Run on the current, restated fundamentals file, the short leg returns 11.8% a year with a Sharpe near 1.1 over twenty years, and the equity curve has an unmistakable shape — flat, flat, flat, then a cluster of enormous winners.

Those clusters are the frauds. And that is the tell. The reason the screen flagged those names in the quarter before they collapsed is that the numbers in the file for that quarter are the restated ones, filed years afterwards by the auditors who cleaned up the mess. The original filings looked healthy. That is the entire point of a fraud.

Re-run the identical rule against the as-reported vintages — the numbers as they stood on each rebalance date — and the short leg returns 1.9% a year, Sharpe about 0.2, which after borrow costs on hard-to-short small caps is a loss.

Verdict: the screen has no forecasting ability at all. It was reading the answer key. The nine points a year came entirely from restatements arriving in the file before the events that caused them.

The same problem in macro

Macro data is revised harder than corporate data. US GDP for Q4 2008 was first published on 30 January 2009 at an annualised −3.8%. Successive revisions took it to −6.2%, then −6.3%, and later comprehensive revisions put it near −8.9%. A regime rule fitted on the final series is fitted on a recession whose depth was not visible for years. It will look prescient and be untradeable. Real-time macro vintages exist precisely for this reason.

The universe is a point-in-time fact too. Index membership, sector codes, share counts and even a company's country of domicile all change and all get overwritten. Screening "S&P 500 members" using today's list is Survivorship Bias wearing a different hat — see Point-in-Time Universe Construction.