What Is Point-in-Time Data? Look-Ahead Bias Explained

What point-in-time data actually means

Every dataset about the past sits on two clocks. The first is event time: when the thing actually happened. The second is knowledge time: when the world could first see it. Point in time data preserves both, so you can ask not only "what were this fund's holdings on December 31?" but the sharper question, "what did the public record say the holdings were, as of February 10?"

Those answers differ more often than people expect. A 13F position existed at quarter end but only became public up to 45 days later. A Form 4 insider trade executes on Monday and reaches EDGAR within two business days. And the record keeps moving after first publication: managers file amendments, issuers restate, identifiers change. A conventional database stores one answer, the current best one, and silently overwrites the path it took to get there.

That overwrite is the original sin. Once the old state is gone, you can never again reconstruct what an investor, or an AI agent, could actually have known on a given date. Quant shops learned this decades ago with fundamentals: earnings get restated, so backtesting against the corrected numbers means trading on figures nobody had at the time. The same logic applies with sharper teeth to ownership filings, because amendment is a routine part of the disclosure process rather than a rare exception. For the broader catalog of ways raw filings mislead, see how accurate is 13F data.

Look-ahead bias: the quiet backtest killer

Look-ahead bias means using information before the market could have known it. In filings data it arrives in two flavors, and both are invisible in a database that stores only current state.

The first flavor is lag bias. Disclosure runs on a delay, and each form has its own clock:

A Q1 13F can legally arrive as late as May 15 in 2026 (full deadline calendar here) while describing positions as of March 31. A backtest that rebalances on March 31 using that filing is trading on six weeks of future knowledge. Across the whole filing family the error compounds, and academic work on 13F-cloning strategies has generally found that returns measured from quarter end look better than returns measured from the realistic filing date, which is the only date you could actually have traded on.

The second flavor is revision bias, and it is nastier because it hides inside clean-looking data. When an amendment corrects or extends a filing, most pipelines merge it back into the original period. The dataset then claims the final, corrected picture was visible on day one. Your backtest knows things in November that the market learned in February. No error message, no missing value, just quietly impossible knowledge.

A concrete example: the amendment that rewrites history

A 13F amendment (form type 13F-HR/A) comes in two flavors with opposite semantics. A restatement replaces the original filing in full: the new holdings table is the truth and the old one is void. A new-holdings amendment only adds entries on top of the original. Per the SEC's 13F FAQ, a manager can also request confidential treatment for positions it is still building, omitting them from the public filing and disclosing them months later by amendment.

Walk through what that does to a naive database. A large manager files its Q3 report by the November deadline showing no position in stock X, because confidential treatment was granted while the stake was being accumulated. In February the confidential period ends and an amendment lands, adding a large position dated as of September 30. A current-state pipeline upserts the amendment into the Q3 snapshot. The position genuinely existed in September, so event time is correct, but the public record only contained it in February. Any model trained or tested on the merged snapshot now assumes everyone saw the stake months before anyone did. This is not hypothetical: Berkshire Hathaway has repeatedly used confidential treatment while building major positions, and those stakes entered the record only through later amendments. You can browse the settled Berkshire portfolio to see what the same filings look like once history has finished moving.

The opposite failure occurs too. Treat a full restatement as additive and you double-count: holdings inflate, quarters collapse into each other, and a fund appears to have bought everything twice. Handling amendments correctly means classifying which flavor each one is and storing both generations, never blending them. For the mechanics of the underlying documents, start with how to read a 13F filing.

Why as-of queries need bitemporal storage

The clean solution has a name from database research: bitemporal modeling. Every row carries two independent time axes. Valid time says when the fact was true in the world (the position existed as of September 30). Transaction time says when the fact entered the record (the amendment hit EDGAR in February, and the pipeline ingested it shortly after). Neither axis can substitute for the other.

With both axes stored, three query patterns fall out naturally. First, latest-known: "what were the Q3 holdings?" using everything known today, amendments applied. This is the right default for current research and for agents answering questions now. Second, as-of knowledge date: "what did the record say Q3 holdings were, as known on November 20?" This is the only honest input for a backtest, because it reconstructs the information set that actually existed. Third, revision diff: "what changed between the original filing and its amendment?" Revisions are themselves signal; a confidential-treatment reveal is among the more information-dense events on the filings calendar.

The storage discipline that makes all three possible is append-only writes. An amendment never overwrites the original filing's rows. It becomes a new generation linked to its predecessor, with a supersession rule deciding which generation answers which question. Each generation keeps its provenance: at Arkolith, every holding row traces to the SEC EDGAR accession number of the specific document, original or amendment, that asserted it. That matters doubly for AI agents, which will otherwise fill historical gaps with plausible inventions. A grounded answer cites the exact filing version it came from, so a wrong claim is checkable rather than merely confident.

Working with point-in-time filings data in practice

Arkolith's Q1 2026 institutional dataset spans 1,824 filers, 1.87 million long positions, and $53.7 trillion in reported value, plus 51,000+ tracked insider transactions, with every datapoint keyed to the EDGAR accession number of the document that asserted it. The REST surface is deliberately plain. Find a filer:

curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/search?q=berkshire"

Pull its holdings by CIK:

curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/funds/1067983/holdings"

Or list covered funds to build a research universe:

curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/funds"

Whatever stack you build on, four habits keep historical work honest. Timestamp every fact by its filing date, not its period date: the period tells you when a position existed, the filing date tells you when you could have known. Treat amendments as new information events with their own arrival times, never as corrections to be merged backward. Pin security identity to stable identifiers (a CUSIP, not a ticker), because a symbol change in a single-axis database looks exactly like a trade. And demand provenance: a historical claim you cannot trace to a specific document version is a claim you cannot audit, and in an agent pipeline, one you cannot trust.

If the underlying form is new to you, the SEC's investor primer on 13F reports is the right starting point. Full endpoint and credit documentation lives in the docs.

Frequently asked questions about point-in-time data

What is point-in-time data?

Point in time data is data stored so that you can reconstruct exactly what was known at any past date, not just the current corrected values. It separates when something happened (event time) from when it became knowable (knowledge time), the distinction that revisions, amendments, and reporting lags otherwise erase.

How is point-in-time data different from bitemporal data?

Bitemporal storage is the implementation; point-in-time querying is the capability it enables. A bitemporal database stores valid time (when a fact was true in the world) and transaction time (when it entered the record) as independent axes. Once both exist, an as-of query is just a filter on the second axis.

Why do 13F amendments cause look-ahead bias?

Most pipelines merge an amendment back into the quarter it describes, which stamps late-arriving information with an early date. A position disclosed by amendment in February but dated September 30 then appears to have been knowable in November. Backtests built on the merged snapshot trade on information that did not publicly exist at the simulated decision point.

How do I avoid look-ahead bias when backtesting with 13F data?

Use filing dates, never period dates, as the moment information becomes tradable; for 13Fs that can be up to 45 days after quarter end. Source data from a store that keeps original filings and amendments as separate generations, and run the simulation with as-of queries against the knowledge timeline rather than against today's corrected history.

This article explains public filings and data concepts. It is not investment advice.