IndianOps: algorithms and paper trading for index options
Published
IndianOps is a suite of algorithms and paper-trading tools for Indian index options. Built from the GreekLab research work, it connects broker data, market-regime classification, strategy selection, and simulated positions in one inspectable workflow.
My role: Creator & Quant Researcher, spanning data ingestion, research logic, paper execution, and the operations dashboard. Core stack: Python, FastAPI, React, and PostgreSQL.
Make data quality part of the decision
The research problem starts before a strategy runs. Broker feeds can have missing candles or stale quotes, and historical options coverage varies across providers. A strategy result is difficult to interpret if its inputs are not reliable enough to explain the decision.
I built the pipeline around four sources: Zerodha Kite, Dhan, Upstox, and Breeze. They provide a mix of live data, instrument references, historical coverage, and cross-checks. A reconciliation service detects candle gaps and attempts repair from historical data.
PostgreSQL holds positions, decisions, and regime state. The architecture also allows ClickHouse for higher-volume market-data tables. These serve different needs: inspecting a decision requires its associated state, while market-data research may require scanning many bars or snapshots.
Multiple providers improve coverage but introduce reconciliation work. Two sources disagreeing is a data-quality question to investigate, rather than a reason to silently choose whichever value makes a strategy look better.
Use an explicit admission step
The research flow is organized around a market-regime decision before strategy selection:
Broker data → quality checks → regime classification
→ strategy eligibility → simulated execution
→ positions, costs, and decision history
The regime engine uses signals such as opening-range position, the relationship to volume-weighted average price, and measures of realized and implied volatility. It records the classification with its input signals and reason.
The states describe how the system is allowed to proceed:
- RANGE: consider the configured strategies for range-bound conditions.
- TREND_UP / TREND_DOWN: consider directional strategy families.
- VOL_SHOCK: restrict eligibility under elevated volatility conditions.
- NO_TRADE: admit no strategy when the market is closed, inputs fail quality checks, or confidence is insufficient.
NO_TRADE is a useful part of the interface between data and execution. It
represents a decision with a reason, rather than leaving the absence of a
position unexplained. A strategy matching a regime is a research hypothesis;
it does not establish that the strategy has positive expected value.
Share the workflow across strategy families
The suite covers volatility structures such as iron condors and iron flies, directional approaches, calendar and diagonal spreads, short-duration research, and expiry-based structures. The common engineering requirement is an explainable path from inputs to eligibility, simulated entry, and exit.
That makes the decision history as important as the position history. A position shows what the simulator did. The associated regime and reason help explain why it did it, and whether a later change in data quality affected the result.
This structure supports comparisons between algorithms while preserving their different entry conditions. Aggregating all outcomes into one total would hide whether a result came from a particular strategy, market regime, or data issue.
Paper execution is an integration test
Paper trading runs the workflow against arriving data without committing real capital. Positions include costs and decision reasons so results can be reviewed in context.
The paper period exposed operational problems that a backtest over cleaned historical bars would not necessarily reveal. Positions were voided because of data issues, and some were closed shortly after admission when quote quality degraded. These events are useful evidence about the system even when they make the performance summary less tidy.
They also limit what can be concluded. A simulated fill does not demonstrate that a live order would execute at the same price. A small sample of outcomes cannot establish a durable edge or explain a loss by itself. Entry rules, execution assumptions, market conditions, and data quality all remain possible contributors.
Expose the reasoning in the dashboard
The FastAPI backend supports a React operations dashboard showing regimes, open paper positions, recent decisions, and data-quality indicators. The read-only view helps distinguish a quiet system from a broken one.
For example, if no strategy is admitted while the market is active, the operator can inspect quote freshness, candle coverage, and the recorded classification reason. That turns “nothing happened” into a diagnosable state.
The market-data quality view, captured in October 2026. The displayed workflow is paper-only. Select the image to enlarge it.
What the project demonstrates
IndianOps brings ingestion, quality checks, strategy evaluation, simulated execution, and operational review into a working research suite. The dashboard provides a view into that process. This article describes paper trading, not a live-money execution result.
The design I would carry forward is the explicit connection between an input, a decision, and an outcome. It makes failures easier to investigate and gives future algorithm changes a clearer basis for comparison. The next research question is whether a change improves results under comparable conditions, not simply whether it produces more simulated trades.