Why Point-in-Time Databases Are Hard to Build

A point-in-time database is one that can answer the question “what did we know about this company on this exact past date,” not just “what are this company’s numbers.” It is hard to build because a company’s own reported history does not sit still. Numbers that were correct when first filed get restated, reclassified, and redrawn later, and corporate actions like splits and demergers rewrite the past on top of that. Storing today’s answer is easy. Remembering every version of the answer, and the date each one became knowable, is the genuinely difficult part.

The reason this matters to an investor is simple. If you cannot reconstruct what was actually visible on a past date, then any research or backtest you run on that history is quietly borrowing information from the future. The difficulty of building the database is exactly why so much financial data silently fails this test.

The number is not a fact, it is a version

Most people picture a financial figure as a fixed fact. Reliance earned this much revenue in that quarter, full stop. In reality, the figure you can look up today is only the latest version of that fact, and it may differ from what was on the tape when the quarter was first reported.

The same reported period can carry several versions over time:

• The figure as first filed. What the company actually published when it reported the quarter.
• The figure after a restatement. A year later, the company reports the same period again as a comparative, sometimes on a changed basis.
• The figure after a reclassification. Two years later, a line that used to sit under “other income” is moved into revenue, or an expense is regrouped, and the historical number shifts again.
• The figure after a corporate action. A stock split, bonus issue, or demerger forces per-share and segment figures to be recast so the series stays continuous.

A point-in-time database has to keep all of these versions, each stamped with the date it became known. The everyday database most tools are built on keeps only the last one. That single design choice, keep the latest versus keep every version, is the whole difficulty in miniature. One is a lookup table. The other is a full history of a history.

Restatements: the past keeps getting rewritten

The biggest source of difficulty is that companies routinely restate their own prior periods, and they do it for entirely legitimate reasons. When an accounting standard on leases or revenue recognition changes, prior years get recast onto the new basis. When a business is demerged into a separate listed company, the parent’s earlier revenue and profit are restated to exclude it. When a division is sold or wound down, its results are pulled out of continuing operations, including in the prior-year column. When management reorganizes how it reports, the historical segment split gets redrawn.

None of this is wrong. A serious analyst wants comparable periods, and restatement is how you get them. The engineering problem is that each restatement produces a new version of a period that already had a version, and both are true, just as of different dates. A database that overwrites the old figure with the restated one throws away the very information a point-in-time system exists to preserve. The gap between the first-filed number and the restated number is often the most interesting thing in the file, and the naive design deletes it.

There is a subtler trap here too. A restatement is not the same as a correction. A correction fixes an error. A restatement recasts a correct figure onto a new basis. If a system treats them the same way, it loses the ability to say whether a number changed because it was wrong or because the shape of the business changed. Telling those two apart is a judgment call that lives in the notes and the management discussion, not in the number itself.

Vintages, and the cost of remembering everything

The clean way to think about this is in terms of vintages. A vintage is a snapshot of the data as it stood on a given date. The March quarter has a March-vintage, a next-year vintage after the first restatement, and later vintages after each reclassification or corporate action. To answer “what did we know two years ago,” you need the vintage that was current two years ago, not the one that is current now.

Keeping vintages is expensive in ways that are easy to underestimate. Instead of one row per company per period, you now need a record of every version of every line, with the date each became knowable and the reason it changed. Queries get harder, because “give me the last ten years” now has to mean “as of which date.” Storage grows. And the logic that decides which vintage answers a given question has to be correct every time, because a single wrong vintage reintroduces exactly the lookahead bias the whole exercise was meant to remove.

This is why the naive version is so tempting and so common. Overwriting is cheap, small, and fast. It gives a tidy, restated, future-informed history that looks better than the real one. The disciplined version is bigger, slower, and less glamorous, and it is the only one that tells the truth about what was knowable when.

Corporate actions: the past has to stay continuous

Restatements change the meaning of a line. Corporate actions change the units the line is measured in, and that is a different kind of hard.

When a company does a stock split or a bonus issue, every historical per-share figure has to be recast so the series does not jump. When a company demerges, the parent’s history has to be split so you are comparing like with like across the event. When two companies merge, two separate histories have to be stitched into one. Each of these is a rule that rewrites the past to keep it continuous, and each one interacts with the restatement problem. You can have a per-share figure that was restated for an accounting change and then adjusted again for a split, and a point-in-time system has to know the order in which those happened and reproduce the value that was actually visible at each stage.

Get the order or the factor wrong and the series looks smooth but is quietly false. This is the same class of problem that makes comparing a company across ten years of filings genuinely difficult: the filings themselves are not measured on a single consistent basis, and making them consistent means understanding every event that sat between them.

Why the hard version is the honest version

There is a reason this is worth the trouble. The clean, latest, fully restated series is genuinely useful for one thing: seeing a fair long-run trend. It is dangerous for a different thing: judging what was knowable at a past moment. A system that can only produce the clean series cannot tell the difference, so it silently uses future information whenever it looks backward.

The honest version can produce both. It can hand you the restated series when you want a comparable trend, and reconstruct the as-first-reported view when you want to know what was actually on the tape. The point is not that one is right and the other wrong. The point is that you can tell them apart and choose deliberately, and that choice is only possible if the database remembered both.

This is also why, in financial AI, the data problem sits upstream of the model problem. As we have argued in data quality beats model quality, the cleverest model in the world is only as honest as the history it is trained and tested on. Feed it the polished, future-informed version and it will grade itself on an exam it has already seen. No amount of model sophistication recovers information the data layer threw away.

What to take away

You do not need to build one of these to benefit from understanding why they are hard. The lesson is a habit of suspicion about tidy history.

• A number is a version, not a fact. Before comparing a company to its own past, ask whether a restatement, reclassification, or corporate action sits between the two dates.
• Overwriting is the enemy. Any data source that keeps only the latest figure has quietly deleted the past you might need.
• Clean is not the same as correct. A smooth ten-year series can be smooth precisely because it was recast with information that did not exist along the way.
• Ask “as of when.” The most important question about any historical number is not what it is, but on what date it became knowable.

Building a database that respects all of this is unglamorous, expensive, and easy to skip, which is exactly why so much financial data quietly fails at it. The difficulty is not a detail. It is the reason point-in-time data is rare, and the reason research built on it can be defended while research built on tidied-up history often cannot.

This article is educational. Altys Labs is not a registered research analyst or investment adviser, and nothing here is investment advice or a recommendation to buy, sell, or hold any security.