In a real scanner observation, annualised implied volatility was 19.8%, while the displayed historical volatility was 10.7%. The scanner reported an IV/HV ratio of 1.85, yet its “IV rank” was only 6. Another observation showed IV of 21.2%, HV of 13.5%, a ratio of 1.57 and a rank of 69. Neither combination is a contradiction. The two statistics answer different questions.

For this article we fetched the public scanner output and matched all 53 reported ATM-IV values, percentile readings and available IV/HV ratios against its saved JSON output. The examples below explain the measurements without identifying securities, quoting executable contracts or interpreting the scan as a trading opportunity. The observation time is fixed: this is an examination of a recorded calculation, not a continuously updated market view.

Three measurements, three denominators

Implied volatility is the volatility input that makes an option-pricing model reproduce an observed option price. It is conditional on the model, the price supplied, the remaining maturity and other assumptions. It is neither a forecast guaranteed to occur nor an estimate of the probability that an option seller will profit.

This scanner chooses the earliest available expiry with at least three calendar days remaining, when such an expiry exists. It estimates a forward price from put–call parity, solves Black-76 implied volatility by bisection, averages usable call and put estimates around the forward, and interpolates between the bracketing strikes. Its fixed interest-rate assumption is 6.6%. A parity estimate more than 4% away from the available underlying reference is replaced with that reference. These choices help produce a number; they also make the number model-dependent.

Historical volatility looks backward. The intended HV20 calculation takes 20 log returns from 21 closing-price observations, computes their population standard deviation and multiplies by the square root of 252. Both IV and HV are displayed as annualised percentages, but one reflects option prices and the other a particular sample of realised moves. A ratio above one only says the former exceeds the latter under those conventions.

The scanner’s “IV rank” makes a third comparison: current ATM IV against its own stored IV observations. Its exact formula is:

IV percentile = round(100 × count(previous IV < current IV) / count(previous IV))

The lookback is 100 calendar days and the calculation requires at least eight observations. Equal readings do not count as “below”. The usual high–low range measure sometimes also called IV rank—current IV’s position between the historical minimum and maximum—is a different formula. The label alone cannot tell a reader which one a tool implements.

Rebuilding the arithmetic from the stored observations

The first percentile is 100 × 1/16 = 6.25, rounded to 6. Its earlier IV range was 19.7%–23.0%. A high–low range calculation would instead give 100 × (19.8 − 19.7)/(23.0 − 19.7), or approximately 3.0. For the second observation, 11/16 becomes 68.75, rounded to 69; using its 17.9%–25.3% range would produce approximately 44.6. Neither alternative is the number displayed by this scanner.

This explains the apparent puzzle. An option-implied volatility can exceed a recent realised-volatility estimate while remaining near the bottom of its own historical IV distribution. One comparison uses realised returns; the other uses past implied estimates. Interchanging them changes the meaning of the statement.

The scanner calculates IV/HV before rounding the displayed volatility inputs, so manually dividing its one-decimal percentages can give a slightly different ratio. We also excluded each current scan observation when rebuilding its percentile: the software computes the percentile first and only then appends that observation to history.

A three-month span is not three months of daily evidence

The backfill code is designed to read roughly three months of NSE F&O bhavcopies. The actual database snapshot contains 900 IV rows across 53 underlyings, covering only ten distinct dates. Eight dates have the backfill timestamp of 16:00: 8–12 June and 7–9 September 2026. The remaining observations come from repeated live scans on 10 and 11 September. There are no July or August observations in this snapshot.

That is why the worked examples have only 16 previous observations despite a 100-day lookback. Each additional below-current observation changes a fixed 16-observation percentile by 6.25 points. The rounding makes the display look tidy; it does not make the estimate precise. Eight observations are the software’s availability threshold, not evidence of statistical reliability.

Repeated scans also give some dates more weight than others. The percentile describes stored readings, not the percentage of historical trading days with lower IV. A series that mixes one daily backfill reading with several intraday readings will change its effective weighting as the scanner operates. Equal weighting of daily observations would be a separate methodology.

The backfill and live calculations differ as well. Backfill uses closing option prices at the nearest strike and treats the reported underlying price as an approximate forward. Live calculation uses the parity estimate and interpolation around it, with quoted midpoints where available. Expiries roll through time; this is not a constant-maturity volatility series. These differences can affect the percentile even without a meaningful change in underlying risk.

The HV denominator needs its own data audit

We reproduced the three examples’ historical-volatility values from the local closing-price database and the scanner’s additional end-of-day records. The unrounded calculations were 10.7439%, 13.4871% and 14.5690%, consistent with the displayed 10.7%, 13.5% and 14.6%.

However, the source price histories for those examples end on 2 September, and the next appended close available before the scan is dated 10 September. The code concatenates closing values without aligning their dates. It therefore treats that multi-session gap as one of the nominal daily returns. The arithmetic is reproducible, but the resulting measure is not a clean volatility estimate from 20 consecutive trading sessions. The bias need not always point in the same direction.

The median of the 52 available displayed ratios is 0.975. These counts describe the scanner’s output, including its data limitations. They do not establish that options were broadly cheap or expensive, and a zero percentile does not mean zero volatility or zero risk.

Liquidity and events are checks, not proofs of safety

The code checks combined ATM call-and-put open interest against thresholds of 300 for stocks and 2,000 for indices, using the feed’s reported units. It also limits the wider ATM bid–ask spread to 12% of midpoint. All 53 analysed rows passed those implemented checks in this snapshot. That says little about depth at more distant strikes, simultaneous execution of several legs, or the slippage associated with an actual order.

The quote parser can fall back to the last traded price when two-sided quotes are unavailable. The existence of a calculated IV should therefore not be confused with proof that its input was an executable midpoint. Similarly, the scanner’s straddle-cost-to-forward ratio is a price-derived scale, not a statistically guaranteed range or confidence interval.

The event filter checks local corporate actions and the NSE event calendar up to expiry. Results, splits, bonuses, buybacks and specified restructuring events are classified as hard exclusions from the candidate pool; dividends and fund-raising events receive softer flags. The snapshot’s skipped list is empty. That establishes what the software reported, not that every relevant event was captured or that unexpected news cannot occur.

A meaningful investigation of option risk would need aligned and complete historical inputs, comparable maturity conventions, verified quotes, subsequent realised outcomes and trading costs. This scan provides no tested probability of profit or evidence that a premium-selling rule has positive expected returns. Its most useful educational contribution is showing why a volatility number needs a clearly defined comparison set before it can be interpreted.

curl -L --fail https://silver-pnf.h2c5h62gdr.workers.dev/options \
  -o /tmp/options_live.html

SELECT substr(ts, 1, 10) AS observation_date, COUNT(*)
FROM iv_history GROUP BY observation_date ORDER BY observation_date;

SELECT COUNT(*) AS n, SUM(atm_iv < :current_iv) AS below,
       MIN(atm_iv), MAX(atm_iv)
FROM iv_history
WHERE symbol = :underlying
  AND ts >= '2026-06-03'
  AND ts < :that_underlying_current_scan_timestamp;