Point-in-time market data: as-of dates, restatements, and adjustments

Point-in-time (PIT) market data records, for every value, the dates during which that value was the one the market could see. An ordinary historical table keeps one row per company per date, holding the latest figure. A point-in-time table keeps one row per version of the figure, so the same question returns different answers depending on the date you ask it as of. Ordinary history answers "what do we know now about that day?" Point-in-time data answers "what was known on that day?" A backtest may only ask the second question, because a trader on that day had nothing else.

Two dates for every fact

Every fact in a financial database has two dates, and they are not interchangeable.

The effective date is the period the fact is about. A 4-for-1 stock split takes effect on 2021-06-30. A company's fiscal year 2020 runs from January to December 2020.

The knowledge date, also called the as-of date, is when the fact became public. The split was announced on 2021-05-20. The annual report was filed on 2021-02-10.

A point-in-time query filters on both: give me the value that applied to date D, as it was known on date K. Drop the second condition and you get today's version of the past, which is the version nobody had at the time.

Why a copy of today's table is not history

Copying today's production tables into a warehouse and calling the result history fails for five reasons with the same shape.

• Corrections overwrite. The old figure is destroyed, so the table forgets that a wrong number was once the only public one.
• Adjustments are baked in. Prices are stored already adjusted for splits and dividends that happened later, so a 2015 price level carries knowledge of a 2021 event.
• Tickers are reused. A symbol that named one company in 2015 can name an unrelated one in 2019, and a join on the ticker splices them together.
• New coverage is backfilled. When a feed adds a company, it loads years of history in one go, and that history looks as if it had always been available.
• The universe is today's. The list of companies is the list that exists now, minus every company that stopped trading.

In each case the store knows something on date K that the market did not know on date K. Nightly snapshots help only from the day you start capturing them.

The survivorship bias, delisted stocks and look-ahead bias pages take each failure in turn.

Restatements

A restatement publishes a new value for a period that already had one: an accounting correction, a vendor's changed normalization, a reconciliation re-run with better inputs. If earnings of 2.00 per share were reported on 2021-02-10 and restated to 1.40 on 2021-08-05, anyone ranking stocks in March 2021 saw 2.00. A backtest that sees 1.40 in March is using August's information, even though 1.40 is the truer number.

The fix is a store that only appends: each version carries its own known-from and known-to dates, nothing is deleted, and any past state of the table can be rebuilt.

Backfilled history is the awkward case. When a vendor adds a company and loads ten years of its filings, stamping each row with the filing's original date records when the fact was public, not when this feed could have served it. Those are different facts, and a store that keeps only one has to say which.

Corporate actions and adjusted prices

Adjustment is where point-in-time discipline is most often lost, because the standard workflow rewrites history on purpose. An adjusted close is the raw close multiplied by the combined effect of every split and dividend that came after it, so the stored number depends on events the row predates.

What this breaks is any test on an absolute price level. Take a 4-for-1 split announced on 2021-05-20 and executed on 2021-06-30. A screen for "stocks closing above $150", run as of 2021-05-03, sees that day's close of 400. The same screen run today on split-adjusted prices sees 100 and excludes the stock. Returns are different: a consistently adjusted series removes the mechanical jump on the split date, and a return computed across it is the return a shareholder earned.

The clean design stores raw prices and dated events, and computes the adjustment at query time from the as-of date.

What the served Quantverse API does, and does not, do

The Quantverse databank API is documented in its README, and this lesson should be read against what it serves today rather than against a full bitemporal store.

• Identity. GET /v1/securities/{ticker}?as_of=D answers one question: which security did this ticker name on date D? It uses the SEC's recorded ticker tenures, so META as of 2022-06-01 resolves to the fund that held the symbol until 2022-06-08, and as of today to Meta Platforms. It returns identity and listing details, not history.
• Prices. GET /v1/securities/{ticker}/prices serves one security's daily bars across its whole symbol lineage, so META as of today includes the pre-2022 FB era. That lineage is served as currently known; it does not reconstruct what was knowable about a rename on a past date. Adjustment is off by default (adjustment=none); when splits or splits_dividends is requested, only splits executed on or before as_of are applied and the series is capped at that date, so a series requested as of 2021-05-03 is not divided by the June split. Bars are current-state: a corrected bar is served with its corrected values whatever the pin.
• Events. Share splits and cash dividends are likewise served across a security's lineage and take a separate known_as_of pin that controls which events are visible, not their values: a restated event is served with its current-best figures. For history loaded before the service went live in September 2026, the knowledge date is approximated by the execution date for splits and by the declaration date, or failing that the ex-date, for dividends. The catalog entry for the resolution layer is CIK, CUSIP and FIGI mappings.

A worked example: one number, two answers

Figures are illustrative. A company reports fiscal 2020 earnings of 2.00 per share on 2021-02-10 and amends the figure to 1.40 on 2021-08-05. The point-in-time table holds two rows.

Ask for fiscal 2020 earnings as of 2021-03-01 and the answer is 2.00. Ask as of 2026-01-01 and the answer is 1.40.

Now suppose a strategy ranks the 500 largest US companies by earnings yield, meaning earnings per share divided by price, from highest to lowest, and buys the top fifty. At the March 2021 price, 2.00 puts this company 38th, inside the buy list. The amended 1.40 lowers the yield and would put it 240th, outside. A backtest built on today's table therefore skips a stock the live strategy would have bought and held into the August restatement.

Four questions to ask a data vendor

1. Ask for a known revision under two as-of dates. Pick a filing you know was restated and check that the earlier as-of returns the original figure. Unchanged values on a random row prove nothing either way.
2. Ask whether raw prices and adjustment factors are kept alongside any adjusted series.
3. Ask for the vintage coverage and retention policy. From which date are versions kept, and are superseded rows ever purged?
4. Ask for a delisted company in the universe as of a past date. If it is missing, the listing table has been filtered by the present.

The catalog lists a point-in-time screener, marked coming soon, designed to replay a filter against the universe and features as they stood on the query date. Package tiers are on the pricing page.