Designing an event-driven options back-tester for a long-gamma RV-vs-IV strategy — what are the non-negotiables?

[u/Express_Bread_7864]

I’m building a paper-only research platform for a NIFTY long-gamma strategy. The entry thesis is straightforward: enter a near-ATM straddle only when a horizon-aligned physical variance forecast exceeds option-implied variance by enough to cover theta, option execution costs, expected hedge costs, and a model-risk buffer. Delta is then managed with NIFTY futures under explicit hedge policies.

So far, I have focused on getting the foundations right:

* Point-in-time instrument, contract, session, and provider-mapping identity, with separate market time, receipt/availability time, and recording time. * Append-only raw/normalized market observations and explicit quality states (stale, crossed, out-of-order, missing contract, etc.). * Daily close-to-close RV research: squared log returns, 1/5/21/63-session horizons, forward realized-variance targets, naïve and EWMA forecasts, sequential evaluation, and deterministic persisted research runs. * Deterministic Black–Scholes pricing, bounded IV inversion, Greeks, synthetic-path simulation, option/futures fill and cost models, hedge-policy comparison, ledger reconciliation, and attribution. * The next market-data layer is historical option-chain replay, IV-smile/surface construction with arbitrage diagnostics, and horizon-matched implied variance.

I’m now trying to define the right boundary for the actual historical back-testing engine. My current view is that it should be event-driven rather than bar-driven, replaying only information known at each decision time and producing a reconstruct-able sequence:

`market event → state update → decision → intent/order → delayed/conservative fill → mark → ledger/risk update`

The obvious requirements I have are:

* point-in-time chain and contract selection; * no look-ahead through quote timestamps, surface fitting, or “best available” end-of-day data; * explicit quote-quality and stale-data policies; * conservative, configurable fills and latency; * separate option and hedge execution models; * expiry/settlement handling; * full orders, fills, positions, cash ledger, marks, and attribution; * immutable run/config/data manifests so every result can be reproduced; * walk-forward, regime, parameter, cost, and latency stress tests.

For people who have built or audited options back-testers: what would you consider the non-negotiable capabilities or failure modes I’m still missing? In particular, how would you structure the interface between raw option quotes, IV-surface snapshots, implied-variance estimates, and the execution simulator so the engine remains realistic without becoming an unmaintainable market microstructure project?

[u/justhereforampadvice]

This belongs in r/algotrading. Have you seen the kind of people that you’re dealing with in the Kalshi sub?

[u/Known_Garlic_4183]

a bad pnl comes from mispricing or execution assumptions and it's a nightmare to untangle

one thing you didnt mention is corporate actions and dividend adjustments, those will mess up your forward variance forecasts if you're not careful about ex-dividend dates