This is pretty rotten isn't it? Hiding important calculation details behind "proprietary methodology". I can tell you from experience as a user of Bloomberg, compustat, CMA, and a bunch of other pricing/analytics services in fairly esoteric stuff - vendors have always been willing to disclose how the calculations for output analytics are done. Otherwise, how would you know what you are looking at.
Oh, it's worse than rotten. Why? Because iVolatility actually very publicly discusses their methodology in great detil: http://www.ivolatility.com/news.j?nid=72&x=0&y=0 <i>Now, what does the calculation of IV Index look like? Letâs see this on the example of "IVX Call 30". Suppose today is 04/05/2004, and there are 12 days till front month (April) expiry - and 47 days till next month expiry (May). Options with these two expiries will be used for IV Index calculation of term 30 - as they are 2 expiries closest to 30-day virtual expiration.</i> More details available on the website. But if I were you, I'd ignore it... If they publish their methodology in detail, but claim to hide a piece that leads to bizarre discrepancies between their modeled index and real world realities... you know what that tells me? <b>It tells me they're full of shit.</b> They have a very serious implementation bug in their system, and they aren't sure how to fix it. Rather than saying mea culpa and trying to address it, they'll claim that it's a "feature", a feature that they can't describe because it's "proprietary". I spent $500+ in the last 2 weeks on their data. I deserve a refund. Be warned, folks. Stay away from iVolatility. PS. It's pretty gratifying that a Google search for "ivolatility" and "IVM" comes up with this thread first and foremost. If they fix the problem, then this thread will have a happy ending. If not, hopefully this thread will help bury them.
I guess this is what I should've been using all long: http://www.optionmetrics.com/ivydbus.html You get what you pay for, at the end of the day.
Ok, I see the hint of maybe a good ending for this thread, and *maybe* a thumbs up for continued use of ivolatility. In a new email, they're now living up to their mistake, and admit the algorithm is simply wrong when call/put IV is widespread. Even better, they have a "VolSurface" function which does seem to give me the right data, if I request the ATM volatility. http://www.ivolatility.com/data/historical_data.html <i>5) Implied Volatility Surface by Moneyness (sample) A surface normalized by moneyness and maturity. Terms: 1, 2, 3, 4, 5, 6, 12, 24 months Moneyness: (-50%, -40%, -30%, -20%, -10%, 0% (OTM puts), 0%, 10%, 20%, 30%, 40%, 50% (OTM calls)</i>
I think I'm a happy guy. The vol surface number seems to be working well. The estimated IV seems to be about 5% less than actual IV, which is probably because whatever function they're using over-compensates for the smile*... I'll keep playing with that, but I can probably compensate for it. Thanks to ivolatility for living up to the problem. I hope they can either fix (or simply eliminate) the IVX call/put value. For now at least, they still have my business. *Yep. Looking at further OTM/ITM options, their vol surface looks to be right on the money.