Introductory Context
"This topic covers the methodology for rigorous options strategy backtesting -- the data requirements, the implementation choices that determine whether the backtest is meaningful or misleading, the statistical measures that assess the simulated performance, and the practical tools available to Indian options traders for conducting backtests without requiring institutional data infrastructure. "
Data Requirements for Options Backtesting
Valid options backtesting requires end-of-day (EOD) option chain data: the full set of available strikes and expiries with closing bid, ask, and last-traded prices for every trading day in the observation period. For Nifty options: this means approximately 30-50 strikes × 3-5 expiries = 150-250 option price observations per day. For a 5-year backtest: approximately 1,250 trading days × 200 options = 250,000 individual data points. Sources for Indian options historical data: (1) NSE's Bhavcopy files (free daily download, available back to 2008). (2) OPSTRA and Sensibull historical data (subscription-based, pre-processed, more convenient than Bhavcopy). (3) NSEpy Python library (programmatic access to NSE historical data). (4) iCharts and other data vendors for cleaned, structured options data.
Common data quality issues that corrupt backtests: stale prices (options that didn't trade today show the prior day's last-traded price, which may be far from fair value), wide bid-ask spreads that make mid-price execution unrealistic, missing data for illiquid strikes, and settlement price discrepancies (the official NSE settlement price for expiry-day options may differ from the last-traded price). Addressing these issues: use bid-ask midpoints rather than last-traded prices where available, filter out options with OI below a minimum threshold (illiquid strikes), and use the official NSE settlement prices for all expiry-day valuations.
Backtesting Biases - The Cardinal Sins
Lookahead bias (the most common and most damaging error): using information that was not available at the time of the simulated trade decision. Examples: setting the entry IV based on the day's closing IV when the simulated entry should use the opening IV; using the 'best' day to enter each week (which requires knowing future prices to identify); applying the exit condition using the exact low price of the day rather than a realistic order execution price. Lookahead bias makes backtests appear significantly more profitable than any real execution could achieve.
Selection bias (survivorship bias): testing the strategy only on securities that survived (still exist) rather than all securities that existed at the start of the backtest period. For Nifty options: Nifty itself has survived, so this is less relevant. For individual stock options: companies that went bankrupt are excluded from the current universe, making strategies that were short their options appear more profitable than they would have been when those stocks were still viable trading targets.
Overfitting (curve fitting): optimising strategy parameters (VIX thresholds, OTM percentages, profit targets) on the full historical dataset until the backtest results are maximised. The optimised parameters fit the specific historical path perfectly but are unlikely to perform well on out-of-sample data. Topic 25.4 (walk-forward testing) specifically addresses this bias.
Backtesting Quality Checklist
✓ EOD option chain data with bid/ask prices (not just last-traded). ✓ Minimum 3 years of data including at least one stress period. ✓ Entry prices at realistic levels (mid or slightly above mid for buys; mid or slightly below for sells). ✓ Exit prices at realistic levels (accounting for bid-ask spread). ✓ Transaction costs included (brokerage + exchange fees + impact cost). ✓ No lookahead bias (decisions based only on data available at the simulated trade time). ✓ Out-of-sample validation period (test period not used for parameter optimisation). ✓ Slippage model for entries and exits. ✓ Correct handling of dividend adjustments if using individual stocks. ✓ Correct expiry mechanics and settlement prices.
Backtesting Tools for Indian Options Traders
Python ecosystem (recommended for serious backtesting): pandas and numpy for data manipulation, scipy for statistical analysis, matplotlib for visualisation. NSEpy for NSE data access. Backtrader or Zipline for systematic strategy backtesting frameworks. A custom options backtesting engine can be built in 200-500 lines of Python, handling the options-specific complexity (option chain storage, Greeks calculation, expiry management) that general-purpose backtesting frameworks don't support natively. OPSTRA.in: a web-based Indian options backtesting platform with pre-built strategy templates and historical data. Suitable for testing standard strategies (iron condors, straddles) without coding. Limited customisation for non-standard strategies. Sensibull (PRO subscription): offers basic strategy scanning and performance analysis. Not a full backtesting engine but useful for visual inspection of historical strategy performance.
Backtesting is not a tool for finding strategies that worked -- it is a tool for testing whether a strategy is likely to continue working. The difference is subtle but profound: a backtest optimised to maximise historical returns is finding the strategy that happened to fit the historical path, which is not the strategy that will perform best going forward. A proper backtest tests a specific hypothesis (the strategy has a structural edge) on historical data (which may or may not validate the hypothesis) with appropriate out-of-sample validation (which provides forward-looking evidence). The honest backtest is uncomfortable: it will often show that the strategy's edge is smaller or less consistent than hoped. This uncomfortable honesty is its value.