The Volatility of Volatility for Stocks and Crypto, Part 7
In this edition of our stochastic volatility article series, we pull out the monte carlo run controls to the main sheet and add a button to trigger the monte carlo run easily from Sheet1. Now you can just change the nmonte run count and the number of days forward to run without editing the macro… so the macro doesn’t run to the full 1000 days as before if you don’t want it to. We also deleted the lesser speed macros to avoid having to maintain them with these new changes.
The Excel file for this example is here:
https://github.com/diffent/excel/blob/main/volofvol7C.xlsm
For this article’s example, we changed the envelope chart on sheet probability to only plot 100 days forward for this particular 100 day test case that we had been doing with the asset GE (see prior article). It would be nice to tie this plotting to the run count… perhaps some day.
And, we finally added the drift portion of the Heston solution into the model. Hint: Drift in this context is not nearly as exciting as diffusion.
You may have noticed the first part of this drift step in our prior article’s accompanying Excel file, where we compute a daily risk free rate (RFR) from an annual RFR. The drift term in the stochvol case is the same as the drift portion of the ordinary Geometric Brownian Motion (GBM) solution, except that the sigma (volatility) and sigma² (variance) is variable instead of constant. As to why the variable drift formulation is how it is… that comes from the solution to the base GBM stochasic diffeq, which you will have to dig into on your own for now. The Wiki on GBM is useful in this regard. The RFR is used as the mu (mean) value in the analytic solution. Here, we follow Quantstart and just use a 10 year Treasury type rate for the mu. It is actually about 4.6% as of this writing, not 4% as we put here in our sheet, but we are into round numbers for testing. You can try to re-run the model with 4.6% or (5% if you are clairvoyant, or have an “in” with the Fed?)
The drift term just adds to what was already inside the EXP( ) function’s parens in column B Sheet1.
The divide by 10000 (or 100*100) is to account for the fact that our volatility squared (sigma squared or variance) which shows up in this drift term — according to the baseline Geometric Brownian Motion stoch diffeq solution and also in the more advanced variable volatility Heston model — is computed from a baseline percentage value where we use 1 (percent) but it means 0.01. So if we square it, we have to divide by 100*100 instead of just 100 to get the units correct. We already divide the final daily (stochastically volatile) return by 100 before the roll-up into prices.
We put some snapshots of the non-variable volatility GBM solution in Part 6 of this series, so we won’t repeat them here.
This formulation of drift is constant (small percent change every day added to our diffusion) if we have a constant sigma / constant volatility model (pre Heston-era model)… since mu is constant and sigma is constant and there are no other variables in this term. Using constant values for mu and sigma and making some plots may help you understand this term better before adding the varying volatility to the mix.
The piling-on complexities of this sheet makes us think that we should build the [Quantstart] example code and start comparing runs between it and our own Excel formulation for checking. In due time. An interesting thing is that the Quantstart code seems to be mainly concerned with computing an option price… but as we see here, simulation of these models can also give envelope and price/probability risk models forward in time. You don’t have to know or care about options trading to appreciate and use this type of model.
With the macro only running 100 days into the future, the 5k monte carlo run count took about 11 minutes to run.
The macro run speed is better than before, but still “cringe.” Tough to do any exhaustive backtests or iterative tuning with a run time like that. In contrast, our MCR3D risk apps can do a 5000 trial monte carlo in a second or two for this 100 day forecast situation using only 1 CPU core. Thus the power of compiled code. For larger run counts, our apps can use multi core parallel processing for the monte carlo path generation, which is one of those “embarassingly parallel” problems that you hear about occasionally (e.g. fairly easy to parallelize).
In fact, it is more than just compiled code enabling the speedup, as our web (lite) version of this software at https://mcr3d.diffent.com is also much faster than our Excel sheet (it uses vanilla Javascript running in your browser, not on a server). A 5000 run trial only takes 2 to 3 seconds on a modern computer & browser. Javascript is not technically compiled, but it seems to be “just in time” compiled:
Other sources of slowdowns could be us leaving the graphs on the sheets (which get updated every time we need to update the sheet in the macro loops?), and of course getting/putting data from/into the sheet cells themselves.
The web “lite” version of our MCR3D application is shown above with a GE bulk backtest similar to what we presented from the Excel. It is a couple of days off in historical time versus our Excel examples; we ran it a couple of days later and didn’t take pains here for an apples-to-apples comparison. If you go to the above site on a phone or otherwise small screen, it redirects you to one of the app stores to get the native app, because mcr3d web is only set up for larger screens.
As we mentioned before, the base model that we use in our apps is not the more complicated stochastic volatility model (so there is less computation overall versus the Excel stochvol), but the model in the apps has other useful properties such as a) not assuming normality of returns, and b) taking the historical return distribution as-is. Hence, all return distribution shapes are handled automatically. Our apps do, however, support Heston-inspired stochvol model refinements if you are interested in exploring those:
Back to our Excel output: The top 99.5th percentile curve seems to drop a bit near the end of the 100 point run. This may be because of not making enough runs to smooth out the extreme curves and not the addition of the drift term.
One more run at 10k monte carlo iterations (below) shows smoother envelope curves as expected. If we compare to the plots from Part 6 of this article series, the addition of the drift term still does seem to be dragging down the extreme 99.5% curve versus that old pre-drift model.
Summary
Even though we have added a drift term to this model, we haven’t tuned it yet by any means. But we seem to be getting closer to the theoretical solution of the very intense looking stochvol equations that we started with.
We were going to put a small thumbnail of those equations here to remind you, but small thumbnails don’t seem to be supported in this Medium typesetting system… so. Please look at our prior articles in this series for those screenshots.
Further reading
Part 8 of this series has been unleashed!
https://medium.com/@nttp/the-volatility-of-volatility-for-stocks-crypto-part-8-18f7ae210365
Reference
[Quantstart] Heston Stochastic Volatility Model with Euler Discretisation in C++, https://www.quantstart.com/articles/Heston-Stochastic-Volatility-Model-with-Euler-Discretisation-in-C/
