Nifty Bank F&O: When Your Data Sources Disagree

Pull up three different pages on Nifty Bank F&O right now and you can walk away with three different answers about when the contract expires.

The NSE products page for Bank Nifty derivatives, in the version currently live, specifies that BANKNIFTY futures contracts expire on the last Tuesday of the expiry period, with a fallback to the previous trading day if that Tuesday is a holiday, referencing circular NSE/FAOP/68747. A popular third-party option chain page labels the same index "Weekly Wednesday expiry" with a lot size of 15. An options education page says Bank Nifty "now expires monthly — last Wednesday of each month" following SEBI's October 2024 expiry rationalisation.

For a discretionary trader, this is a minor annoyance. You look at your broker terminal, see the contract, and trade it.

For anyone running an algo, this is a live production bug waiting to fire. Expiry day is not trivia. It is a parameter that silently feeds your square-off scheduler, your days-to-expiry calculation, your theta assumptions, your roll logic, and every backtest you have ever run on this index.

This post is not about which source is right. It is about building a workflow where you do not have to guess — and about what the rest of the late-October 2026 context means for how you prepare, not predict.

What the exchange page actually pins down

Strip away the commentary and the exchange contract specification gives you a small set of hard facts worth encoding:

• Trading cycle. BANKNIFTY futures carry a maximum three-month trading cycle: near month, next month, far month. A new contract is introduced on the trading day following the expiry of the near month contract.
• Options strike introduction. On expiry of the near month contract, new contracts are introduced at new strike prices for both calls and puts, on the trading day following expiry.
• Underlying. The index is Nifty Bank, a single-sector index. The exchange defines the underlying, market lot, and maturity date — meaning all three are exchange-set variables, not constants you own.
• Expiry day rule with a holiday fallback. Whatever the day-of-week rule is, it is conditional. A trading holiday shifts it backwards.

That last point is the one most retail algos get wrong. People hardcode a weekday. The actual rule is "this weekday, unless the exchange is closed, in which case the previous trading day." A single hardcoded weekday plus no holiday calendar equals an order that fires into a closed market or a position that never gets squared off.

The off-by-one that is easy to see this month

Take October 2026 as a concrete example. The last Tuesday of the month is the 27th. The last Wednesday is the 28th. Both candidate expiry rules you will find across sources point into the same final week — one day apart.

One day apart is the worst possible kind of wrong. It is not obviously broken. Your backtest still runs. Your scheduler still fires. You just end up holding a near-zero-theta position for an extra session, or squaring off a day early and eating the spread for nothing. Nothing crashes, so nothing gets caught.

Verify the exact date against the exchange contract note and the exchange holiday list for the series before you let a scheduler act on it. Not against a blog post. Not against a cached config file from last quarter.

Why spec drift is an algo problem, not a documentation problem

The reason conflicting sources matter so much here is that expiry assumptions do not live in one place in your system. They leak.

The four places expiry leaks into

Your backtest calendar. If your historical engine assumes the wrong expiry weekday, every expiry-day trade in your sample is misdated. Expiry-day behaviour is not like any other session — gamma behaves differently, premium decay is non-linear, and liquidity concentrates. Misdating those sessions does not add noise evenly. It systematically corrupts the exact days your edge is supposed to come from.

Your DTE and theta logic. Any rule phrased as "enter when days to expiry is 2" or "stop adding on expiry day" is a direct function of the expiry date. Off by one day, off by one rule.

Your square-off scheduler. Intraday systems usually have a hard time-based exit. Expiry-day systems usually have a separate, earlier one. If the system does not know today is expiry, it applies the wrong exit profile.

Your roll and strike-selection logic. The exchange introduces new strikes the trading day after expiry, not on expiry day. An algo that tries to select a next-series strike too early finds nothing, or finds an illiquid stub, and either errors out or fills badly.

Fix one of these and leave three stale, and you have not fixed anything. This is the standard blast-radius problem: a config value that looks local is actually read by four subsystems.

Lot size is the same class of risk

One third-party source lists the Bank Nifty lot size as 15. Treat that as a number to verify, not a number to trust, because lot size is exchange-revisable and it sits directly in your position sizing path.

A lot size revision changes notional exposure per lot, margin blocked per lot, and therefore how many lots fit inside a given risk budget. If your sizing code holds a cached lot size and the exchange has moved it, you are not making a rounding error — you are taking a materially different position size than your risk management rules authorised. The strategy still looks like the backtested strategy. The exposure is not.

Building a single source of truth for contract specs

The practical fix is unglamorous and it works: your algo should not hold opinions about contract specs. It should read them.

A workable daily sequence:

1. Pull the broker instrument master at session start. Most broker APIs publish a daily contract master with symbol, expiry date, lot size, tick size, and strike list. That is machine-readable truth for today, straight from the execution venue you will actually trade through. This is the kind of thing a broker API integration should be doing before the first order of the day, not as an afterthought.
2. Derive expiry, never assume it. Resolve the active expiry from the instrument master, not from a weekday rule in your code. Weekday rules are a sanity check on the derived value, not a source for it.
3. Reconcile against the exchange contract note at least once per series. When the near month rolls and new strikes get introduced, that is the natural checkpoint. Confirm expiry convention, lot size, and strike interval.
4. Treat mismatches as a halt condition, not a warning. If the master says one expiry and your config says another, the correct behaviour is to stop placing new orders and alert — not to pick one and carry on. A system that silently resolves contract-spec conflicts is a system that will trade the wrong contract quietly.
5. Log what you used. Every order record should carry the expiry and lot size the system believed at the time. Without that, post-mortems on a bad series are guesswork.

Point 4 is where most retail setups fall down. Broker session and contract-master failures tend to be silent — the algo keeps running on stale data and nobody notices until the P&L is strange. Stale-config detection deserves the same seriousness as a broken order endpoint.

Late-October 2026: the context worth preparing for

With a month-end expiry window landing in the last week of October, a few structural features of this index are worth having in front of you. None of this is a forecast. It is a list of things that change how much room for error you have.

Bank Nifty is a single-sector, concentrated index. It tracks roughly a dozen large-cap banking stocks on NSE — names like HDFC Bank, ICICI Bank, SBI, Kotak Mahindra Bank, Axis Bank, Bank of Baroda, PNB, IndusInd Bank, Federal Bank, IDFC First Bank and AU Small Finance Bank typically feature, with composition reviewed periodically by the index provider. Nifty 50 spreads across many sectors. Bank Nifty does not. That concentration is why it is generally more volatile than Nifty, and why a single large constituent's results or a single sector headline can move the whole index hard.

It is structurally sensitive to a known list of inputs. RBI policy and rate decisions, credit growth data, quarterly asset-quality and NPA disclosures, system liquidity, and global rate moves all transmit into this index with unusual directness. Research on the index notes that an unexpected RBI rate cut can move Bank Nifty two to four percent in minutes.

October sits inside the Q2 results window for Indian banks. Constituent earnings dates are published and knowable in advance. That makes them avoidable, which makes failing to avoid them a process choice rather than bad luck.

Monthly expiry concentrates what weekly expiry used to spread out. If the series convention is monthly, you get roughly twelve index expiry events a year instead of fifty-plus. Each one carries more positioning into a single session, and your strategy gets far fewer independent samples per year to learn from.

Turning that into rules your system can execute

Context only helps if it becomes a condition in code. Some filters that express the above without predicting anything:

• Event-day blocks. Maintain a dated calendar of RBI policy dates and constituent results dates. Rule: no new entries on blocked dates, or reduced size with wider stops. The rule is the deliverable, not the opinion about what will happen.
• Expiry-window exposure caps. Scale down maximum lots as days-to-expiry drops. On expiry day itself, many retail systems are better served by a flat-only or reduce-only mode than by their normal sizing.
• Volatility-state gating. Define what regime your strategy was built for in measurable terms — an India VIX band, an IV percentile range, a realised-range threshold — and refuse entries outside it. A premium-selling logic built in a calm tape should not be deploying unchanged into an event week.
• Basket-level stops, not just leg-level. Multi-leg structures need a combined loss limit. Individual leg stops on a spread can leave you accidentally naked at the worst moment.
• A hard daily loss limit above everything. One number, enforced by the system, that no override touches.

Encode these in a BANKNIFTY strategy builder workflow where the filter is part of the strategy definition, rather than something you remember to check manually at 9:14 am.

Reading the option chain without reading a prediction into it

Before an algo acts on an index option, there is a short list of chain-level checks worth making. The standard columns do real work: OI (total open contracts), OI change (today's new positioning), volume (today's activity), IV (higher means more uncertainty priced in), and LTP.

What you can legitimately get from that:

• Liquidity confirmation. Is the strike you are about to trade actually traded? Thin OI and thin volume mean your backtested fill price is fiction.
• Spread sanity. Wide bid-ask on an illiquid strike can quietly consume a meaningful share of a small premium edge.
• IV context. Is current IV high or low relative to this instrument's own recent range? That is a position-sizing input and a structure-selection input.
• Where positioning is heaviest. Large OI concentrations on specific call and put strikes are frequently described as resistance and support.

Here is the discipline point. Market commentary routinely converts "largest call OI at strike X, largest put OI at strike Y" into "implied range for the upcoming expiry." Max-OI strikes describe where open positions currently sit. They are not a committed boundary, they shift as positions change, and they say nothing about what happens on an event day. Use them as a liquidity and context map. Do not let them become an unstated forecast inside your strategy.

In a workspace like Anadi's options view, this is why the chain, OI analysis, IV and theta, basket preview, and margin estimate sit in the same flow — the chain is the inspection step between a signal and an order, and margin and risk should appear before execution, not after. The same logic applies to stock F&O setups routed through a scanner: index and sector context first, then structure, then risk, then route.

Backtest hygiene when the spec itself has changed

If the expiry convention for this index genuinely changed in the recent past, your historical data has a seam in it. That seam matters more than most people assume.

Do not pool pre-change and post-change expiry-day data. Expiry-day dynamics under a weekly regime and under a monthly regime are different data-generating processes. Averaging them produces a result that describes neither.

Recount your sample size honestly. A strategy with three years of history and a monthly expiry event has roughly three dozen expiry observations. That is a small sample for anything with sharp tail behaviour. Walk-forward testing and out-of-sample holdouts matter more here, not less.

Re-check your assumed expiry dates across the whole historical window. If your engine applied a single weekday rule to the entire history, part of that history is mislabelled. Careful options backtesting means verifying the contract calendar your engine used, not just the strategy logic running on top of it.

Model costs and slippage as regime-dependent. Expiry-session slippage on an index option is not the same as a mid-series Tuesday. Flat per-trade cost assumptions flatter expiry strategies specifically.

If you want to pressure-test this kind of workflow — contract-spec reconciliation, event-day blocks, expiry-window sizing, basket stops — on your own rules before putting capital behind them, request early access and build the filters into the strategy definition rather than keeping them in your head. Pairing it with a weekly market outlook habit is useful for the same reason: context should prepare your rules, not generate trade calls.

Checklist: before your algo trades Bank Nifty F&O again

Run this once per series, and the spec-drift half of it at session start:

1. Expiry date resolved from the broker instrument master for the active contract, not from a hardcoded weekday.
2. Holiday fallback implemented — expiry shifts to the previous trading day if the scheduled day is a holiday, verified against the exchange holiday list.
3. Lot size read live from the contract master and flowing into position sizing; no cached copy anywhere.
4. Strike availability checked after roll, since new strikes arrive the trading day after near-month expiry.
5. Mismatch halt in place: config versus master disagreement stops new orders and alerts, rather than auto-resolving.
6. Event calendar loaded with RBI policy dates and constituent results dates, wired to an entry-block or size-reduction rule.
7. Expiry-window sizing ladder defined by days-to-expiry, with an explicit expiry-day mode.
8. Volatility gate stated numerically, so the system can refuse a regime it was not built for.
9. Basket-level stop on every multi-leg structure, plus a system-enforced daily loss limit.
10. Liquidity pre-check on OI, volume and spread for the exact strike before the order goes out.
11. Backtest seam handled: pre-change and post-change expiry data kept separate, sample size counted honestly.
12. Order-level logging of the expiry and lot size the system believed at execution time.

Three sources disagreeing about an expiry day is not a reason to distrust the market. It is a reason to stop treating contract specifications as background knowledge. The exchange owns the underlying, the market lot, and the maturity date. Your algo's job is to read all three fresh, reconcile them, and refuse to trade when they do not line up.