Point-in-time data

Point-in-time data preserve history as it could have been observed at each moment. The date to which a value refers is not enough: one must record when it was published, when it became available to the system, which version was then valid and how long that version remained valid. A database that is correct and fully updated today can describe the past perfectly while being unsuitable for simulating a past decision.

Four dates not to confuse

The availability timestamp is the operational one. A release published at 16:05 New York time cannot generate an order at the 16:00 close. If the system acquires the file at 16:08, the first admissible decision must also respect that latency. For daily data without a reliable time, a prudent approach is to state an explicit convention—such as “usable from the next session”—and document it.

Macroeconomic data illustrate the revision vintage problem. Output, employment and growth figures may be corrected many times. The latest series answers “what is today's best estimate of the past?” A point-in-time test asks “which estimate was public on that date?” These are different questions.

Universe, identifiers and membership

A current list of securities, funds or contracts cannot be projected backwards. The universe must be a temporal table with validity intervals:

A ticker is a label, not a stable identity: it can change or be reused. Linking prices, financial statements and corporate actions requires persistent identifiers and a mapping with temporal validity. Sector classification or country membership can change too; applying today's classification to 2010 introduces retrospective information.

Corporate actions and delistings

Splits, dividends, spin-offs, mergers, offers, conversions and symbol changes involve several dates: announcement, ex-date, record date, payment and effectiveness. An adjusted-close series recalculated today is convenient for returns, but does not replace a causal event register. The adjustment factor must suit the purpose: comparing total returns is not the same as simulating observable limits, quantities and orders before an event.

A delisting does not justify deleting the last observation. The reason, date, any delisting return, distribution or recovery value, and the rule used when data are missing must be retained. A loss erased from the database makes the sample healthier than it was and connects directly to survivorship bias.

Point-in-time protocol

1. Fix decision time. Define the time zone, calendar, cutoff and frequency of every strategy.
2. Separate event and availability. Preserve event_time, published_at, available_at and ingested_at where available.
3. Archive vintages. Do not overwrite a revision; add a new version with validity start and end.
4. Use persistent identities. Map tickers and descriptions to stable identifiers with temporal intervals.
5. Reconstruct the universe. Store membership, eligibility, announcements and effective dates; do not start from today's survivors.
6. Treat corporate actions as events. Preserve terms, dates and sources, then generate the adjustments needed for the stated purpose.
7. Keep failures and absences. Delistings, suspensions, closed funds and missing values are part of history.
8. Model latency. Add vendor and processing delay and the next tradable window.
9. Make the query repeatable. “Show what was known at 10:00 on date X” must always return the same snapshot.
10. Freeze the test dataset. Store version, checksum, transformations and code with the out-of-sample results.

Quick checks

Limitations

A point-in-time database reduces look-ahead bias, but it does not certify a strategy. Late data may be wrong; a source may have selective coverage; the pipeline may apply future transformations; the universe may remain incomplete. Point-in-time data also do not model orders, liquidity, capacity or transaction costs in backtests. Every result remains conditional on documented sources, conventions and availability.

Sources

• Federal Reserve Bank of St. Louis, ALFRED® and Real-Time Periods — storage of originally released values, revisions and information-validity periods.
• U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces — filing history, metadata and updates to disseminated information.
• Center for Research in Security Prices, CRSP Survivor-Bias-Free US Mutual Fund Database Guide — historical structure including both active and terminated funds.
• Tyler Shumway, The Delisting Bias in CRSP Data, The Journal of Finance, 1997 — consequences of omitting delisting returns.
• S&P Dow Jones Indices, Equity Indices Policies & Practices — announcements, effective dates, rebalances and treatment of composition corrections.

Links

• Systematic trading
• Backtest
• Out-of-sample
• Data leakage and look-ahead bias
• Survivorship bias
• Transaction costs in backtests