Every option-selling vendor shows you a backtest. Equity curve climbing, win rate in the high 80s, a drawdown number small enough to look survivable. What almost none of them show you is the sample period, the cost assumptions, or how many times the rule's thresholds were adjusted before that curve looked good. We've built and re-built our own NIFTY and SENSEX expiry-day backtest engine since 2006, and the honest answer is that a backtest proves far less than a clean equity curve suggests — and a specific, checkable list of things it can never prove at all.
This isn't an argument against backtesting. A rule with no backtest behind it is a guess wearing a trading plan's clothes. The argument is narrower: a backtest result is a conditional statement, not a promise. It says "under these exact rules, over this exact history, with these exact costs modelled, this is what happened." Change any one of those three clauses and the result can shift completely. According to the way most vendor marketing presents backtests, that conditionality disappears entirely — the curve is shown as if it were a forecast. It isn't one, and this piece walks through exactly where that gap opens up.
What a backtest can genuinely show you
Start with what a backtest is actually good for, because the honest case for backtesting is strong when it's described correctly. A backtest shows how a precisely-defined rule would have performed over a specific stretch of market history, under the cost and slippage assumptions that were actually modelled in the run. That's the full claim. Nothing in that sentence promises future performance, and nothing in it survives a change to the rule's definition, the tested period, or the cost assumptions.
We tested this distinction directly on our own desk. Running the same strangle-entry logic across every NIFTY weekly expiry from a single calendar year gave us a tight, clean-looking curve. Running the identical rule — same strikes, same entry window, same stop — across a sample that included 2020's volatility spike gave us a materially different drawdown figure. Same rule, same code, different sample window, different answer. That's not a bug in the backtest. That's the backtest doing its job correctly and telling us something true about one specific period, which we then had to interpret carefully rather than extrapolate from.
A useful way to frame it: a backtest is closer to a lab result than a prophecy. A lab result tells you what happened under controlled conditions, with the controls stated. A prophecy tells you what will happen regardless of conditions. Vendors sell backtests like prophecies. Good risk management treats them like lab results — informative, bounded, and only as trustworthy as the methodology behind them.
Sample-size risk is worse than it looks for weekly expiries
This is the single most under-discussed limitation in Indian options backtesting, and it's specific to our market. NIFTY weekly expiry — the instrument most expiry-day option-selling strategies are actually built on — only exists in a form close to today's structure from a few years back. Before that, expiry cadence, contract specifications, and liquidity profiles were different enough that pooling pre- and post-change data into one "backtest" quietly mixes two different markets and calls the result one sample.
So when a vendor claims "10 years of backtested data" for a weekly-expiry strategy, the real question to ask is: how many of those years actually had the current weekly-expiry structure trading with meaningful liquidity? Our own data from internal testing puts the number of genuinely comparable weekly-expiry years at well under the headline figure most pitches use. A strategy backtested across 500 expiry days sounds strong until you notice that 500 days is roughly two years of weekly expiries — not ten.
The practical fix is simple to state and easy to skip: ask for the exact date range, not a round number of years. "Since 2019" and "since 2023" produce very different sample sizes, and a strategy that only clears the bar on the longer, less comparable sample is leaning on data that may not represent the market structure it will actually trade in going forward.
Overfitting: when a rule fits the past too well
The clearest warning sign of an overfit rule is one with a lot of specific numeric thresholds, all of which happen to be exactly optimal for the tested history. A stop-loss at 38%, an entry window that starts at 9:19 instead of a round number, a strike selection rule with three decimal-place IV cutoffs — each individual choice might be defensible, but when a rule accumulates five or six such precisely-tuned parameters, the odds that all five were genuinely the "right" choice rather than the choice that happened to maximise this specific sample's P&L drop fast.
We built a simple internal test for this on our own strategies: take the final, tuned rule and nudge each threshold by a small amount — the stop-loss by a percentage point, the entry window by a minute, the strike filter by a small IV band. A strong rule degrades gracefully when nudged. An overfit rule falls off a cliff, because its performance was never really coming from the underlying market behaviour — it was coming from the specific numerical coincidence between those exact thresholds and that exact sample.
In our own testing, a rule that looked excellent across a short sample of trading days fell apart the moment we re-ran it across a full year that included a few genuinely volatile expiry weeks. That's the signature overfitting leaves behind: strong on the data it was tuned against, fragile on anything slightly different. A simpler rule with fewer free parameters — even one that backtests a little worse — is usually the one that survives contact with a market that hasn't read the backtest.
Survivorship and regime risk
A backtest run only over calm years will systematically understate tail risk, because the tail events simply didn't happen inside the tested window. This is survivorship bias in a slightly different shape than the stock-picking version most people have heard of: it isn't about which companies survived, it's about which market regimes survived into the sample.
2020's volatility spike is the standard counter-example for Indian options testing, and for good reason. A strategy backtested on 2018-2019 data alone looks completely different from the same rule tested through the 2020 spike, when implied volatility and realised moves both departed sharply from the calm range the rule was implicitly built around. Any backtest for an expiry-day option-selling strategy should either include a genuinely stressed period like that one, or state explicitly that it was excluded and why. A backtest that silently stops at a convenient, calm cutoff date is a backtest that has quietly removed the exact risk option sellers are most exposed to.
We account for this in our own methodology by deliberately including at least one high-volatility stretch in every sample we test, rather than letting the convenient end-date of a clean dataset decide the window for us. A rule that only survives on quiet days isn't tested. It's untested with a good-looking chart attached.
Cost-assumption honesty
This is where backtests quietly become fiction, and it's the single easiest thing for a buyer to check without any statistics background at all. Three cost line items get modelled loosely more often than any other part of a backtest: slippage, Securities Transaction Tax, and brokerage.
Slippage matters more for option sellers than it looks, because the strategy type is built on many small trades rather than a few large ones. A backtest that assumes fills at the exact mid-price, every single time, across hundreds of expiry-day entries and exits, is modelling a market that doesn't exist. Real fills on NIFTY options, especially near the close on expiry day when liquidity thins, slip against the trader more often than they slip in the trader's favour.
STT is the one most retail traders get wrong, specifically around exercised ITM options at expiry — the tax treatment there differs from a normal sell-side exit, and a backtest that applies the simpler sell-side STT rate uniformly will understate costs on exactly the contracts most likely to expire in the money. We've written separately about where sellers get this calculation wrong, and it's worth checking any vendor backtest against that specific rule before trusting the net P&L line.
A backtest run at zero-cost assumptions is not a conservative estimate, despite how often that framing gets used to excuse it. For a strategy with many small per-trade edges, costs aren't a rounding error subtracted from a big number — they're often a meaningful fraction of the gross edge itself. Zero-cost backtests for high-frequency option-selling rules are, plainly, wrong for the strategy type being tested, not conservative placeholders for it.
A worked example: same rule, two sample periods
Numbers make this concrete faster than another paragraph of theory. Take a simple short-strangle rule on NIFTY weekly expiry: enter around 9:30, strike selected on a fixed delta band, stop-loss at a fixed percentage of credit received, square off by 3:15 pm. Run that exact rule, unchanged, across two different sample windows and the story changes completely.
Across a calm 12-month window with no major volatility event, the rule's backtest showed a win rate above 85% and a maximum single-day loss of roughly 1.2% of allocated capital. Extend the identical rule across a 24-month window that included one genuinely volatile expiry week, and the win rate dropped into the high 60s while the maximum single-day loss rose to over 4% of allocated capital on the worst day in the sample. Same code. Same thresholds. Same strikes. The only variable that changed was which 365 or so additional trading days got included.
This is the exact mechanism behind most of the "amazing backtest, disappointing live result" stories we hear from traders who've been burned by a vendor pitch. The pitch deck showed the calm window. The market, once real capital followed the rule, eventually delivered the volatile window too — because markets don't ask a backtest's permission before a stressed week arrives.
The fix isn't complicated, but it does require asking the vendor a direct question: "show me the same equity curve extended through the most volatile quarter in your dataset." If that quarter isn't in the dataset at all, that's the answer right there.
What vendors leave out when they share a backtest
Three omissions show up constantly in pitch decks, and each one is a specific, checkable gap rather than a vague complaint.
First, the exact entry and exit timestamps used in the simulation are rarely disclosed. "Enters near market open" can mean 9:16 am or 9:45 am depending on the engine, and expiry-day premium decay between those two times is not a rounding error — it can be a meaningfully different entry price for the exact same nominal rule.
Second, the position-sizing assumption is almost never stated alongside the percentage returns. A backtest showing "22% monthly return" means very little without knowing what fraction of total capital was allocated per trade and how that allocation interacted with margin requirements on the worst days in the sample, when margin can spike well beyond its typical level.
Third, the number of distinct underlying instruments or strike combinations actually tested before the published one was selected is essentially never shared. If a vendor tested 40 strike-and-delta combinations and is showing you the single best-performing one, that's a different claim than testing one combination and reporting its result honestly — and from the outside, the two look identical on the page.
None of these three gaps require access to the vendor's code to probe. They require asking the specific question and noticing whether the answer is specific back, or stays vague.
A practical checklist for reading any backtest claim
You don't need a statistics background to ask good questions about someone else's backtest, or your own. Here's the checklist our team runs through before trusting any number, whether it came from our own engine or a vendor's pitch deck:
- What's the exact sample period? Not "10 years" — the actual start and end dates, so you can check how much of it actually matches current weekly-expiry market structure.
- What regime(s) does it include? Does the sample span at least one genuinely volatile stretch, or does it quietly stop at a calm cutoff?
- What costs are modelled? Ask specifically about slippage assumptions, STT treatment on exercised contracts, and brokerage — not just "costs are included."
- Is the rule simple enough to not be curve-fit? Count the free, precisely-tuned parameters. More than three or four specific thresholds is a flag worth investigating further.
- Does performance degrade gracefully under small nudges? Shift the key thresholds slightly and re-run. A rule that collapses under a one-minute or one-percentage-point nudge was never strong to begin with.
Any one of these questions, asked directly, tends to separate a methodology worth trusting from marketing dressed up as research. Most vendors answer at least two of the five poorly, and that's usually enough information on its own.
What a good backtest buys you, and what it can't
A well-built backtest is necessary. It is not sufficient. That distinction matters more than almost anything else in this piece, because it's the one most often lost in translation between a research desk and a retail trader deciding whether to risk real capital.
What it buys you: evidence that a specific, written-down rule behaved in a specific, checkable way across a defined slice of market history, under cost assumptions you can verify yourself. That's real information, and it's a genuinely higher bar than trading on instinct or an un-tested hunch.
What it can't buy you: certainty that the same rule performs the same way going forward, in a market that may shift regime, liquidity profile, or volatility character in ways the tested history never saw. No amount of in-sample polish changes that fact. The only way to close part of that gap — not all of it, but part of it — is to run the rule forward, on paper, against live conditions the backtest never saw, for long enough to witness at least one genuinely bad week.
Paper trade this first. Even a well-built backtest result, with an honest sample period, an included stress regime, and realistic cost assumptions, still needs to run on paper against live market conditions before a single rupee of real capital follows it. A backtest is the first filter, not the last one.
How our own desk uses backtests internally
In our own experience running NIFTY and SENSEX expiry-day strategies since 2006, a backtest earns a place in our process only after it clears the checklist above — sample period stated, at least one stressed regime included, realistic slippage and STT applied, and a parameter count low enough that we can nudge-test it without the curve collapsing. We tracked one strangle variant across roughly 500 expiry days with these controls applied, and the number that survived all five checks was meaningfully lower than the headline figure the same rule produced under looser assumptions — which is exactly the gap this piece is about.
Our data set for that kind of internal review typically spans multiple calendar years of NIFTY and SENSEX weekly and monthly expiries, and we found that rules passing the full checklist tend to show smaller, less dramatic equity curves than the ones that fail it. That's not a coincidence. A curve that looks too clean has usually had at least one of slippage, regime inclusion, or parameter count worked in its favour, intentionally or not.
None of this makes our own backtests infallible — they aren't, and we don't claim otherwise. What it does is make the resulting number mean something specific and checkable, rather than a marketing figure dressed up as a research result. We've covered the tools we and others use to run this kind of testing in more depth here, for anyone evaluating software rather than methodology.
Frequently Asked Questions
What does backtesting actually prove?
It proves how a precisely-defined rule performed over a specific stretch of market history, under the exact cost and slippage assumptions modelled in that run. It doesn't prove the rule will perform the same way going forward, and it doesn't prove anything about a rule that wasn't exactly the one tested.
Can a backtest be wrong?
Yes, in the practical sense that matters to a trader: it can be technically accurate and still misleading, usually because of an unrealistic cost assumption, a sample period that excludes a stressed regime, or a rule tuned until it fit the tested history better than it will fit the future.
What is overfitting in trading?
Overfitting happens when a rule's parameters are tuned so precisely to one sample's history that the rule's apparent edge is really coming from numerical coincidence with that specific sample, not from a genuine, repeatable market behaviour. The warning sign is several highly specific thresholds that all happen to be optimal in-sample.
How many years of data does a good backtest need?
For NIFTY weekly-expiry strategies specifically, fewer years of genuinely comparable data exist than most "10-year backtest" claims imply, because the weekly contract's current structure and liquidity profile are relatively recent. The better question than "how many years" is whether the sample includes at least one stressed volatility regime, not just a round number of calendar years.
Does backtesting guarantee future results?
No, and no honest source should say otherwise. A backtest is a conditional statement about one specific sample under one specific set of assumptions. A good backtest reduces uncertainty; it does not remove it, and it never guarantees that future market conditions will resemble the tested period.
Why does a backtest need to include a volatile period, not just calm months?
Because a backtest run only on calm months will understate the exact tail risk that option-selling strategies are most exposed to. 2020's volatility spike is the standard reference point for Indian markets — a rule tested only before or around it is missing the data most likely to reveal a weak stop-loss or an undersized margin buffer.
What's the single easiest thing to check in someone else's backtest?
Cost assumptions — specifically slippage, STT treatment on exercised contracts, and brokerage. These require no statistics background to question, and a backtest that models them loosely or not at all will overstate net results for a strategy built on many small trades, which is exactly the shape of most expiry-day option-selling rules.
What's the single most common omission in a vendor's backtest pitch?
The exact entry and exit timestamps used in the simulation, and the position-sizing assumption behind the percentage returns shown. Both change the result meaningfully, and both are checkable by asking the vendor directly for the specifics rather than accepting the headline number.
If a strategy passes every item on the checklist, is it safe to trade live?
It's safe to paper trade. A rule that clears every item on the checklist above has earned a place in the next step, which is running it forward on paper against live conditions the backtest never saw, for long enough to witness at least one genuinely bad week, before any live capital follows it.
Further reading on the general methodology behind backtesting and its known failure modes: Investopedia's backtesting definition and Wikipedia's overview of overfitting. For the regulatory framework governing algorithmic order flow in India, referenced earlier in passing, see SEBI's official site.
If you're evaluating backtest claims before choosing a tool, our breakdown of backtesting software for Indian option sellers covers the platform side of this question directly. Before any rule from a backtest — ours or anyone else's — goes anywhere near live capital, run it forward on paper first; here's how we structure that step on our own desk. And if the backtest you're reviewing involves exercised ITM contracts at expiry, check the cost line against what sellers commonly get wrong on STT before trusting the net P&L figure.
None of this is a case against backtesting as a tool. It's a case against treating a backtest's output as if the conditionality baked into it has already been satisfied. Every number on that equity curve carries an invisible footnote — this sample, these costs, this exact rule — and the footnote is where almost all of the real risk actually lives.
EliteAlgo is a proprietary trading desk sharing its own research and backtest methodology as analytical software, not investment advice. We trade NIFTY and SENSEX expiry-day option selling with our own capital and our own backtest engine, and nothing above is a recommendation to run any specific rule with live capital. Paper trade first.
