Is there an API for IV rank?

Let me know if you find it, I haven't been able to find any references to one in the docs. With how slow the options backtests are already, a custom function for an ATM30 IV on a minutely basis would probably grind the backtest to a halt.

Hi Dat,

IV Rank is not in the API and Implied Volatility can't be accessed via a historical data request, but we have it on our to-do list and hope to implement it in the near future. To can view the status of this feature here in GitHub. In the meantime, Implied Volatility is easy to access and you can calculate the IV Rank using Rolling Windows (find out more about them here) by storing historical IV values. I've attached a backtest below demonstrating how this can be done.

Jack Simonson thanks for this code example. Can you clarify how this works a bit more to a noob? If we are calculating IV rank from current volatility, would we have the historical IVR for any given period only aftert that period has passed? So if we want to limit trades on IVR based on a period of say previous 1 year, we'd have to run the calculations for 1 year before making any trades?

Hi Jean,

I believe that code example comes from our tutorial. There are step-to-step explanation together with some basic knowledge. In fact, we have many tutorials regarding options and they are great for both getting used to our API and implementing some stretagies with algorithms.

There are modifications in OnData() method and OnSecuritiesChanged() method for purpose of calculating and storing IV rank. The process of calculation is in CalculateIVRank() method.

To access historical data, instead of setting the start date to 1 year early, we could set up a warm-up period for algorithm. If you don't want to run certain code in warm-up period, you could put following statement before those code:

Thanks for your support.

Jack and Link,

It would be greatly appreciated if you would enable historical greeks and implied volatility (per the github issue) as a preliminary step for these calculations. I do have some concerns with both the fundamental basis and the technical implementation with your above solutions.

Implied Volatility Rank (i.e. the percentile rank of a rolling period's implied volatility) is typically associated with the weighted average 30-day implied volatility of an underlying symbol. These weighted average calculations are typically done by using a "VIX-style" implied volatility calculation. You can read more about the methodology here:

Essentially, you are taking weighted averages of each OTM contract's implied volatility (symmetrical around the risk-neutral 30-day at-the-money-forward price) of the two options expiration cycles that are closest to the 30-day mark, then interpolating between the two in order to calculate a singular consant-maturity 30-day implied volatiilty. This calculation is then repeated at a minimum of once per day. Typically, this value will then be compared in a percentile rank calculation to the prior year's daily values (or 252 trading days) to compute IVR.

Note this process will naturally be reliant on using the relative dispersion of strikes around the ATM (i.e. using a constant OTM moneyness or delta, not a constant strike level), hence tracking the individual option contract symbols for more than one point in time is meaningless.

This is a much more complex calculation than simply taking the rolling 100 minute implied volatilities of each individual contract on the option chain, which is what I believe the code you proposed attempts to do. I can't say for certain, because the code does not work as intended. I have attached a clone of your backtest and simply added a logging function to record the IVR values that are being calculated at 3:45pm each day. It appears as though the IVR for each symbol returns a zero or a one only. I'm assuming that this has something to do with the interactions between the InitialFilter, the OnSecuritiesChanged function, and when the options contracts are being added to the symbol subscriptions, but I didn't spend too much time on it.

As I said in my previous post, creating a custom script or module to do all of this within a backtest that is forced to take only minutely data resolution is non-trivial. This alone would be challenging to do, but possible. However, I have found the combined lack of documentation, functionality for manipulating option chain data, and debugging capabilities in the WebIDE makes this task almost insurmountable. I either have to learn an entirely different paradigm of interacting with LEAN's option data in the Research Lab, then attempt to refactor that into something that works in the backtesting environment, or just stick to the backtesting environment and try to brute force functionality out of custom classes and objects that I can't see until I finally get it to work.

My apologies if this sounded overly critical or harsh, but these are the frustrations that I'm facing. IV30 is probably the most basic and ubiquitous implied volatility calculation on any options trading platform. It just seems like we shouldn't have to reinvent the wheel, or more aptly, program our own, in addition to the myriad of other challenges that make working with options extremely difficult (no option spread margin calculations, no prospective portfolio margin impact analysis for pre-trade analysis and position sizing, the inability to filter by delta without superflous iteration, etc.).

Hi Andy,

We appreciate the feedback and our apologies for the insufficient first example. We're constantly working to make the QC platform as powerful as possible and suggestions for features from users are valuable. We understand this is a feature which would help many community members and we'll consider it for integration to LEAN.