Why usFeaturesTemplatesBlogGlossary

Point in Time Data: Knowing What You Knew That Day

A backtest that rebalances on 1 April and ranks the Nifty 500 on March-quarter earnings is reading numbers that, for most of that universe, had not been filed yet.

Regulation 33 of SEBI’s Listing Obligations and Disclosure Requirements gives a listed entity forty-five days from the end of a quarter to submit its financial results, and sixty days from the end of the financial year for the audited annual numbers (SEBI FAQs on LODR Regulations, April 2025). The March quarter falls under the annual timeline. So a screen run on 1 April 2024 using March-quarter figures is using data that in many cases arrived somewhere in May.

The backtest is not slightly early. It is ranking a universe on information that did not exist on the day it claims to have traded.

Two dates attach to every fact

The habit worth building is to stop thinking of a data point as having one date.

Every fact in a financial database has at least two. There is the date it became true, which for a quarterly earnings figure is the quarter end. And there is the date it became public, which is the filing date. A price has both dates on the same day, which is why price-based strategies rarely trip on this. A fundamental has them weeks apart. A macro release can have them months apart.

Point-in-time data means the database can answer a specific question: what was knowable on this date? Not what is true about this date, which is a different and much easier question. A regular database stores the current best value keyed to the period it describes. A point-in-time store keeps the publication date alongside it, so a query can be constrained to facts that had already been published at the moment the strategy was deciding.

The distinction sounds academic until you notice how many strategies are ranked entirely on quarterly fundamentals.

The publication lag, in Indian terms

The filing deadline is a ceiling, not a schedule. Companies file across the whole window, and the spread within a single quarter is wide. Some large caps report within three weeks of quarter end; plenty of smaller names file in the final days before the deadline.

That gives you three ways to handle the lag, in increasing order of honesty and effort.

The first is to ignore it, which is what a naive backtest does by default and what makes results look good.

The second is to shift every fundamental field forward by a fixed lag, using the regulatory maximum. A March-quarter figure becomes visible sixty days after 31 March. A June-quarter figure becomes visible forty-five days after 30 June. This is conservative, it is simple to implement, and it is defensible because no rule built on it can ever read something early. It costs you the genuine signal that exists between an early filer’s actual report date and the deadline.

The third is to use the actual filing date per company per quarter, which is the correct answer and requires your data source to have recorded it.

The choice is per field, not global. Applying a sixty-day lag to close, volume or an exchange announcement would be wrong in the other direction, throwing away information that genuinely was available the same day. Price and volume are same-day. Quarterly fundamentals are lagged. Most macro series are lagged by a release calendar of their own. A backtest that treats them all identically is wrong somewhere regardless of which way it errs.

Restatements: today’s number is not the number that was reported

The second failure is quieter, and no amount of date discipline fixes it on its own.

Financial data gets revised. A company restates a prior period after an audit qualification, a change in accounting treatment, a reclassification between segments, or a regulatory finding. Most commercial databases handle this by overwriting the old value with the corrected one. The row keeps the same period label and quietly changes its contents.

Which means your backtest, running over 2018, reads a 2018 figure that was published in 2021.

The direction of that error is what makes it expensive. Restatements are not distributed randomly across a universe. They cluster in companies with weak controls, aggressive revenue recognition, or governance problems. A backtest using restated data reads the cleaned-up number and quietly declines to buy exactly the names that would have hurt a real investor holding the original, flattering figure. It sidesteps the trap and reports the return of someone who never saw it.

A point-in-time store solves this by keeping every vintage of every value rather than one current best. That is expensive, and honesty about whether your data has it matters more than pretending it does. If your source only stores current values, the correct response is to treat fundamental-driven results as an upper bound and to weight the strategy’s plausibility accordingly.

Index membership is a time series, not a list

The third failure is the easiest to demonstrate and the most common in practice.

“Backtest this on Nifty 50 stocks” is an ambiguous instruction. There is today’s list of fifty names, and there is the list that existed on any given date in the past. They are not the same list, and using the first one to test the second period is look-ahead bias in a form that looks completely innocent.

The Nifty 50 is reviewed semi-annually on data for the six months ending January and July, with changes taking effect at the end of March and September, and four weeks’ prior notice given to market participants (NSE Indices methodology document for equity indices). Zomato and Jio Financial Services entered the index in the March 2025 review, replacing BPCL and Britannia Industries (Business Standard, February 2025).

Run a 2020-to-2025 backtest on today’s Nifty 50 and you have bought Zomato from its listing onward, several years before it qualified for the index. You did not buy it because your rule found it. You bought it because it eventually became large enough to be in the list you started from, and the process that put it there is the same process your rule was trying to anticipate. That is the entire selection effect, handed to your strategy for free.

Reconstitution also happens off-cycle, and Yes Bank is the clean example. The February 2020 semi-annual announcement scheduled its removal from the Nifty 50 for 27 March 2020, with Shree Cement taking its place. After the Gazette notification of the Yes Bank Limited Reconstruction Scheme, 2020, the Index Maintenance Sub-Committee accelerated the removal to 19 March 2020 (NSE Indices press release, 16 March 2020). A membership series that only models the scheduled March and September changes has YESBANK in the Nifty 50 for eight days it was not there, during one of the most violent stretches in that stock’s history.

The four-week notice cuts the other way, and it is worth knowing. Because changes are announced before they take effect, a rule that acts on an announced-but-not-yet-effective membership change is using public information and is legitimate. Point-in-time discipline is not “use less information”. It is “use exactly the information that was public”.

Delisted companies and the universe that flatters you

Build a universe from the list of companies trading today and every backtest you run over the last fifteen years inherits a guarantee no investor had: everything you can buy still exists.

DHFL was a Nifty 500 constituent and a widely held housing finance name. Trading in its shares was suspended from 14 June 2021 after NCLT approved Piramal’s resolution plan, under which the existing equity was extinguished through capital reduction with nothing paid to shareholders (Business Standard, June 2021). JETAIRWAYS followed a longer path to the same place: the Supreme Court ordered liquidation on 7 November 2024 after the resolution applicant failed to implement its plan five years after approval, and trading was suspended the following day (Business Standard, November 2024).

Neither company appears in a list of stocks trading today. So a backtest over 2015 to 2024 built from today’s list never buys either, never rides them down, and never takes the loss. Every metric improves. CAGR rises, max drawdown shrinks, Sharpe improves, and none of it is real. This is survivorship bias, and it is the single largest source of inflated Indian backtest results because so much freely available historical data is assembled from currently-listed names.

Two details make it worse than it first looks. Losers are removed disproportionately, since the failure modes that end in delisting are exactly the ones you wanted your risk rules to catch. And a strategy that screens on distress-adjacent characteristics, deep value being the obvious case, is precisely the strategy whose real-world holdings would have included the highest share of names that later stopped trading.

Testing whether your backtest has the problem

Four checks, in order of how quickly they settle the question.

Count the delisted names in your trade log. If a fifteen-year backtest over a broad Indian universe holds zero companies that stopped trading, your universe is a list of survivors and the result is not a measurement of anything.

Check whether your index membership changes over time at all. Print the constituent list at three widely spaced historical rebalance dates. If they are identical, you are testing today’s index against yesterday’s prices.

Delay the rebalance. Shift every fundamental-driven rebalance date forward by the regulatory lag and re-run. If most of the edge disappears, the edge was the lag.

Ask whether any field you use is revised after publication. If the answer is yes and your source stores one value per period, you cannot separate the strategy’s skill from the benefit of hindsight.

Risks and failure modes

Over-correcting is a real cost. Applying a filing lag to same-day fields discards genuine signal. The lag belongs to the field, not to the backtest.

The filing date is itself an event, and lagging to the deadline hides it. A strategy built around the market’s reaction to results is trading the announcement. Push everything to the sixty-day boundary and the announcement has been over for weeks by the time your rule sees it. Event-driven and cross-sectional strategies need different treatments of the same underlying field.

A survivorship-free universe still needs a modelled exit. A stock that stops trading has to be liquidated in the backtest at some defensible price, at the last traded price or at zero in a resolution that extinguished the equity. A name that silently disappears from the panel while the portfolio still holds it produces a different and equally wrong answer.

Point-in-time data does not make a strategy good. It makes the number in front of you trustworthy. A carefully constructed backtest that shows a 9% CAGR against a benchmark doing 12% is a useful, honest result, and the temptation to relax one of these constraints until the number improves is the actual danger. That temptation is a well-documented pattern rather than a personal failing, and it is worth reading about in cognitive biases that destroy algo trading strategies.

Data availability is not the same as tradeability. A signal can be perfectly point-in-time and still untradeable, either because the dataset has since been discontinued or because the stock was under a surveillance measure at the time. Knowing something on the day is necessary, not sufficient.

How saral.money handles it

Historical universes retain delisted stocks, so a backtest over the last fifteen years can hold a company that later stopped trading and takes the loss the way a real portfolio would have. Corporate actions applied to prices are splits and bonus issues. Dividends are not accrued into returns, which means an equity curve is a price-return figure and a comparison against a total-return benchmark will understate the strategy by roughly the dividend yield. That limit is worth stating plainly rather than discovering later. The data catalog, which shows what each field is and where it comes from, sits inside the Explore section and is in preview behind a per-user flag rather than generally available. The engine’s data and execution contracts are summarised on the features page.

What to try next

Take the last backtest you were pleased with and run the delisted-names check on its trade log. It takes a minute and it is the fastest way to find out whether you were measuring a strategy or measuring a universe. Then pick a fundamentals-driven strategy template, move its rebalance dates past the filing deadline, and see how much of the result is still standing.

Further reading