Field note / applied ML

XGBoost for 15-minute NIFTY options.

The interesting part is not choosing XGBoost. It is making sure the model only sees what would have been available at the decision timestamp.

Short answer: a credible short-horizon options experiment needs time-ordered data, leakage checks, walk-forward validation and costs in the evaluation. A high backtest score without those boundaries is only a hypothesis.

Start with a data contract

Write down the decision time, prediction horizon, instrument, exchange session and label before training. For a 15-minute NIFTY experiment, every feature must have a timestamp that is at or before the candle on which the signal is made. The label can use a future return or barrier, but the feature table cannot borrow from that future window.

This sounds obvious. It is where many experiments quietly fail. A daily summary joined to intraday rows, a final end-of-day option-chain snapshot, or an indicator calculated after the target window can leak future information without any model code looking suspicious.

Why random cross-validation is the wrong default

Financial observations are ordered and often dependent. Randomly mixing later rows into a training fold lets the model learn a market regime that would not have been known at the time of the earlier prediction. Use chronological train, validation and test periods, then walk the training window forward.

Each walk-forward fold should record the period, the features available, the model configuration, the threshold and the costs applied. This creates an audit trail rather than one impressive number. It also makes regime changes visible instead of averaging them away.

Features should carry their own timestamp story

Potential features may include price and volume behaviour, option-chain fields, open interest, put-call ratio, implied volatility and Greeks. The feature name is less important than its availability rule. Ask: when was this value observed, how was it joined, and would it have been stable before the order decision?

Evaluate the decision, not only the classifier

Accuracy can be useful for debugging, but it is not a trading outcome. Also examine class balance, precision and recall at the chosen threshold, calibration, turnover, drawdown, hit rate after costs and the number of decisions. A model that is slightly less accurate but more stable and cheaper to operate may be the more useful research result.

Apply brokerage, slippage and other stated costs consistently. Show a no-trade threshold or abstention rule where appropriate. Report the result by time period so a good aggregate number cannot hide one fragile regime.

What the public project is for

The NIFTY XGBoost 15-minute research repository is a place to document feature engineering, walk-forward validation, signal stickiness, gate ablations and live-desk replay studies. The point is inspectability: a reader should be able to understand what was tested, what changed and what remains unproven.

The wider project map connects this research to an options platform, real-time analytics and other experiments. The projects are related, but they should not be treated as a single performance claim.

Limits matter

Market data changes, liquidity is uneven, and a backtest cannot reproduce every operational detail of live execution. A research page should therefore say what it does not establish. This note does not promise returns, a live edge or investment advice. It describes a way to make an experiment more honest.

Educational disclaimer: This material is for research and education only. It is not investment advice, a recommendation or a guarantee of future performance.

Continue the thread

Read the Option Trading with AI research project, inspect the GitHub work, or return to the research shelf for related notes on leakage, option chains and local AI.