Point in time is not a lag
Three datasets can carry the same column name and tell three different stories about the past. Restatement lags and index membership are where the difference hides.
· 7 min · point in time
2 / 4
“Seventy eight percent of companies restated audited annual revenue within 400 days. If the top line moves that often, imagine the items beneath it.”
Ask three researchers what point in time means and you will get “the data as of that date” three times, in agreement, and then watch them build three different things. One pulls the final numbers and uses them as of period end. One pulls the final numbers and shifts them forward 90 days to be safe. One does the thing the phrase describes. Only the third has a backtest. The first two have a story about a backtest.
Three columns, one name
Take a single figure: a company’s annual revenue for fiscal 2019. It has more than one value.
The first value is the one filed in early 2020. The second is the one in the 2020 annual report a year later, when 2019 became the comparative column and got adjusted. The third might appear in 2021 after an accounting change or a divestiture restated the history. Each of these was, for a while, the current number. A database that keeps only the latest one is called “as last reported” or “final”. It is what most vendors ship by default, and every value in it knows the future.
A point in time database keeps all of them, each stamped with the date it became public. Those successive versions are called vintages. Ask the database what 2019 revenue was on 15 March 2020 and it returns the first filing. Ask on 15 March 2021 and it returns the adjusted one. It reproduces what was knowable, and only what was knowable, on the date you name.
The gap between the first filing and a later revision is the restatement lag. That lag isn’t a rounding error. An S&P Capital IQ Quantamental Research note from August 2015 found that 78 percent of companies restated their audited annual total revenues at least once within the following 400 days. Revenue. Audited. Seventy eight percent. If the top line moves that often, imagine what happens to the items beneath it.
| 2019 revenue, asked on 15 March 2020 | final | lagged 90 days | point in time |
|---|---|---|---|
| value a backtest would have seen | the restated figure | the restated figure, later | the originally filed figure |
Why a fixed lag does not fix it
The second researcher, the one who shifted everything forward 90 days, is trying to solve this with a rule. The instinct is sound. The tool isn’t.
A lag says: assume every figure became known exactly N days after period end, and assume it never changed afterwards. The first assumption is wrong in both directions. Some filings arrive in 30 days and some in 120, so a fixed lag both leaks early filers and delays late ones. The second assumption is the real problem. A lag applied to final data still uses the final number. It just uses it later, and later isn’t the same as unknown. The restatement that happened in year two is sitting inside the fit window pretending to be year one information, and the lag did nothing to stop it.
The same S&P note measured what that costs. Cumulative return differences between point in time and lagged backtests reached up to 39 percent in emerging markets. Its conclusion was blunt: static lagging mechanisms are not capable of replicating the results a point in time model produces. You can’t approximate knowledge dates with a constant.
This is what the trial log means when it prints “killed 17, look ahead: restated fundamentals inside the fit window”. Seventeen of 48 specifications in the canonical run had learned something from a number that did not exist yet. They weren’t bad ideas. They were ideas that had been shown the answer.
The second leak: who was in the index
Restatements get the attention because they are about numbers. The quieter leak is about names.
Every backtest runs on a universe. Large cap, all cap, the constituents of an index, the top thousand by volume. The question is: constituents as of when? If you take today’s list and run it back twenty years, every company that failed, was acquired or shrank out of the index is missing from your history, and every company that grew into it is present before it earned its place. That is survivorship, and it is a look ahead bias in a different coat. Your universe knows who won.
Point in time membership means reconstructing the list on every date. Who was in on 3 June 2009, at the weights of that day, including the names that would be gone by December. The canonical run’s second log line, “rebuild point in time: restatement lag applied; index membership reconstructed”, is two separate jobs, and the second is usually the one nobody budgeted for.
What the agent stores
The agent treats this as an engineering job, not a discipline to be remembered. When it onboards a dataset it maps the vendor’s entities to a stable identifier, backfills the history, and stores every figure as vintages indexed by the date each became public. In the canonical run that was 4,118 entities mapped and 2004 to 2026 backfilled overnight, with two licence flags raised for a human to read in the morning.
Then, for every specification in the sweep, it serves each date only the vintages and only the universe that existed on that date. There is no lag parameter to tune, because there is nothing to approximate.
Why this gate comes first
The four gates run in a fixed order and point in time is the first. That is deliberate. A specification that has seen the future will clear walk forward, because its test window is also contaminated. It will clear costs, because its edge looks large. It will report a generous capacity. Every later gate would pass it and every later number would be wrong. Killing it first means the 31 that reached walk forward were at least tested on honest data, whatever else was wrong with them.
Seventeen died at this gate in the canonical run. That isn’t a failure of the run. It is the run doing the job a lag pretends to do.
Illustrative output. Backtested, modelled and simulated results are hypothetical. They do not represent actual trading, they carry the benefit of hindsight, and they may differ materially from any result achieved in the market. Past performance, real or simulated, does not indicate future results.
No output of the Services is a recommendation, an offer, a solicitation, or advice about any security, strategy or account. Every investment decision is made by the customer and the customer's own investment professionals.