Point-in-Time Data: Stop Revised History Leaking Into Your Backtest

Point-in-Time Data: Stop Revised History Leaking Into Your Backtest

বাংলায় পড়ুন

Evergreen trading tutorial: This guide uses hypothetical data to explain revision and availability bias. It is educational information, not personalised advice or a claim that any backtest will work live.

Historical databases often show the best information available today. A trader in the past had only the first economic release, the financial statement published at that time, the index members then in force and the prices delivered by the original data feed.

When a backtest gives that past trader today's corrected or revised history, it creates revision bias or a failure of point-in-time integrity. The strategy can appear to make decisions with information that did not yet exist.

Learning objective

By the end of this guide, you should be able to:

• distinguish observation date, release date and database timestamp;
• explain how economic revisions and company restatements leak future information;
• build an “as known then” dataset;
• test publication and processing delays; and
• audit a backtest for point-in-time errors.

Observation time is not availability time

An economic statistic may describe activity in January but be released in February and revised in March. A company's annual results may cover a year ending in December but become public months later. The period label does not tell the trader when the information was tradable.

A robust record needs at least:

• observation period: what time the data describe;
• publication timestamp: when the source released it;
• vendor arrival timestamp: when the system received it; and
• revision or vintage identifier: which version was available.

The trading rule can use a value only after the relevant publication and processing delay.

Worked hypothetical economic-data example

Assume a fictional inflation series has a strategy rule:

Buy a bond index when year-on-year inflation is 3.1% or lower.

The initial release on 10 February reports January inflation at 3.2%. The strategy should remain out of the market.

On 15 March, the statistical agency revises January inflation to 3.0%. A modern historical download shows 3.0% beside January without clearly retaining the first vintage.

A naive backtest reads 3.0%, triggers a buy on 10 February and captures a later rally. That trade is impossible: the 3.0% value was not known until 15 March.

The point-in-time test must use:

• 3.2% from 10 February until the revision timestamp; and
• 3.0% only from 15 March onward.

This example does not say revisions are predictable. It shows why final revised history is unsuitable for simulating real-time decisions.

Financial statements have the same problem

A company's revenue may be labelled “financial year 2025”, but traders cannot use it on 31 December 2025 if results were published later. The first filing may then be restated because of an accounting change, error or acquisition adjustment.

A point-in-time fundamentals database should retain:

• fiscal period end;
• first public filing timestamp;
• each amendment timestamp;
• the value in every filing vintage;
• units, currency and accounting basis; and
• the identifier that linked the security at that time.

Using the latest restated value for every historical date gives the model knowledge unavailable to the original market.

Other sources of point-in-time leakage

Index membership

Testing today's index constituents over 20 years removes companies that were deleted or failed and introduces firms before they joined. Use membership effective on each historical date. The survivorship-bias guide explains the broader problem.

Analyst estimates

Consensus databases are updated continuously. A historical earnings surprise needs the consensus snapshot immediately before the announcement, not the latest reconstructed estimate.

Credit ratings and classifications

Sector codes, ratings and country classifications can change. Today's label may not represent what investors knew then.

Corporate actions

Splits and dividends require adjusted price series, but the adjustment should not make a future corporate action visible before it was announced. Research and execution data may need separate raw and adjusted views.

Economic calendars

Release schedules can move, and a preliminary estimate may be replaced by a final one. Store actual timestamp and vintage rather than assuming a regular monthly date.

News and alternative data

Web pages can be edited after publication. A current page timestamp or final text may not reproduce the version available when a signal supposedly fired.

Step-by-step point-in-time pipeline

1. Define the decision timestamp

State exactly when the strategy makes a decision: market open, bar close, scheduled batch time or event arrival.

2. Timestamp source availability

Use the original publisher's release time where possible. Record timezone and convert consistently. Do not substitute the period end.

3. Retain every vintage

Append revisions rather than overwriting values. Each row should have an “effective from” timestamp and, where practical, an “effective until” timestamp.

4. Perform an as-of join

For each decision time, select only the latest data vintage whose availability timestamp is earlier than or equal to that decision.

5. Add realistic processing delay

Even public information is not instantly usable. Include vendor latency, parsing, validation and model computation. The signal-decay guide covers this timing layer.

6. Separate research and execution prices

The signal can use only data known at the decision time. The simulated fill must occur later at an executable price.

7. Preserve historical universes

Use security listings, index members and identifiers valid on that date. Map ticker changes, mergers and delistings explicitly.

8. Version the dataset and code

Record source files, checksums, transformation version and calendar rules. A rerun should explain why results changed after a vendor update.

9. Test against archived releases

Select several historical dates and compare the database with original release documents or archived files. This is often the fastest way to discover silent revision leakage.

10. Freeze and validate later data

After constructing the strategy, test on a later period collected in real time or frozen before results are known.

A practical as-of table

For one observation, a point-in-time table might look like this:

Observation	Available from	Vintage value
January	10 February 08:00	3.2%
January	15 March 08:00	3.0%
January	20 April 08:00	3.1%

A decision on 1 March sees 3.2%. A decision on 1 April sees 3.0%. A decision after 20 April sees 3.1%. The observation period is unchanged; available knowledge evolves.

Testing the damage from revisions

Run the strategy twice:

1. with final revised values; and
2. with the correct real-time vintages.

Compare trades, expectancy, drawdown and turnover. A large performance gap is evidence that revisions materially affect the strategy.

Do not “repair” the live-vintage test by optimising new thresholds on the same data. That replaces revision bias with overfitting. Our multiple-testing guide explains this risk.

Common mistakes

1. Using the observation date as the release date. The data may arrive weeks later.
2. Downloading the latest history and assuming it is original. Vendors often overwrite revisions.
3. Using restated financials before the amendment. Past traders saw the earlier filing.
4. Testing today's index members in the past. Deleted firms disappear from the sample.
5. Using final consensus estimates. The pre-announcement snapshot is required.
6. Ignoring vendor and processing latency. Public does not mean instantly tradable.
7. Joining by calendar date only. Timezone and intraday release time matter.
8. Adjusting prices without preserving raw data. Future corporate actions can contaminate interpretation.
9. Overwriting dataset versions. Silent vendor changes become impossible to audit.
10. Optimising after seeing the real-time-vintage failure. This creates a new in-sample fit.

Practical checklist

• Decision timestamps are precisely defined.
• Observation period and publication time are stored separately.
• Timezone and source are recorded.
• Preliminary, revised and final vintages are retained.
• Fundamentals use first-filing and amendment timestamps.
• Historical index membership and security identifiers are valid by date.
• Analyst estimates use pre-event snapshots.
• As-of joins exclude later vintages.
• Processing and execution delays are modelled.
• Raw and adjusted price series are both available.
• Dataset and transformation versions are reproducible.
• Final-history results are compared with real-time-vintage results.
• Later frozen data provide out-of-sample validation.

The Money Man View

A backtest should know only what a real trader could have known at each decision. Final revised history is excellent for understanding the economy today but can be invalid for simulating yesterday's trade. Preserve vintages, join data by availability time and treat a strategy that fails on real-time data as unproven, however attractive the final-history chart looks.

Educational risk disclosure: Point-in-time data can reduce specific biases but cannot guarantee accurate modelling or future returns. Sources can contain errors, timestamps can be incomplete and market execution can differ from research assumptions. The examples are hypothetical. This article was prepared with AI-assisted research and writing under The Money Man editorial process.