Axonetric LLC: Volatility Manager (ver. 3.53, 1-26-2015)
Overview
The Volatility Manger algo performs a number of features related to volatility. The core
functionality involves the algo's tracking of the market's real-time implied volatility (IV) for the
user-specified options curves. The tilt (or skew) of the user's curve in Metro is *NOT* adjusted;
instead the whole curve is only translated (shifted up/down and left/right) in order to maintain
tight calibration with the market's IV at the 50-delta (ATM) point. The frequency of adjustment
can be specified with various configuration parameters. Two other parameters allow the user
to specify a minimum quantity required to be showing top-of-book for the options and the
underlying, respectively; if the quantity is less than the user-defined threshold, the price will be
automatically widened out prior to computing the implied volatility. Another set of parameters
allow additional IV information to be extracted from the current ATM straddles. Also, a
smoothing parameter allows the user to apply a proprietary short-term IV smoothing technique
which has quantitatively been demonstrated to have predictive value. Taken together, these
settings allow the algo to produce an extremely fine and accurate real-time measurement of
the market's current ATM IV and calibrate your own curves accordingly. The ATM IVs can also
be plotted visually in charts using a Metro Link "probe" as the 1.5-hour-spanning image below
illustrates:
Additionally, the algo allows the user to (optionally) specify a number of "security" features that
can help immediately detect abnormal market conditions, just as short-term spikes in volatility,
etc. For example, the user can specify the max allowed rate of change of the market's ATM IV,
the max allowed ATM options spread (in ticks), and also the max depth of apparent tradethroughs in the underlying future (market data from the CME can occasionally appear that the
last traded price has broken outside the published bid/ask prices--this is due to prioritization of
market message types during bursts of activity). When a security constraint is violated, another
user-defined parameter dictates the behavior taken (options include automatically and
immediately stopping quoting/RFQ-responding for the violated expiry, or also to stop
quoting/RFQ-responding for all expiries belonging to the violating symbol). If quotes are pulled,
the vol curve will no longer be updated/monitored until the algo is restart. These security
features can be quite useful in automatically pulling quotes right before/after a number comes
out, or other unexpected events where the market-maker would prefer to not be quoting. In
the configuration documentation below, parameters relating to security features are tagged as
"[Security Feature]".
Lastly, the algo contains an optional feature that allows the user to record (to a file) the market
IVs for various delta points on the skew at regular intervals in time. The created file is in *.CSV
file format, meaning the file can easily be imported into any spreadsheet application (eg,
Microsoft Excel) or database. This data can be useful for quantitative analysis for volatility
arbitrage strategies and other strategies. The file is generated on the server and the user can
retrieve the file using any SFTP program after OptionsCity has created an SFTP login for the
user.
Configuration Documentation
1. licenseKey: your license key from Axonetric LLC. Once you've copied the license key
string to your clipboard, put the cursor inside the cell (edit mode) and hit CTRL+V on
your keyboard to paste the license key into the cell.
2. options: the options to monitor. Double-click the cell to make the "Instrument Matcher"
dialog window appear. You will add one filter expression set for each option maturity
you wish to monitor. To add a filter expression set, click the "New" button to unlock the
filter fields. Each option expiry you wish the algo job to monitor will be identified via
these 3 fields (the other fields will always be left blank):
 Symbol: the option symbol in all upper-case. Note that the option symbol may
sometimes differ from the underling symbol (eg, CME crude futures symbol = CL,
but the options on them are symbol LO). Weekly option symbols may be suffixed
with "1" through "5", depending on the week of expiry.
 Type: this field should always contain "O", which is the code for options
outrights.
 Expires: for monthly options, this field will contain the 3-letter month
abbreviation followed by the 2-digit year code of the month of expiry. For other
option types, you will need to specify the exact expiration date using the 8-digit
"YYYYMMDD" format.
If you correctly specified the 3 fields above, the "# matches" text will normally display a
number somewhere between 30 and 600, which represents the total number of option
outrights (calls and puts) that belong to that symbol and expiry. In the screenshot
below, we see that the system has identified 484 option outrights belonging to the ES
June 2015 monthly options. This number of matches confirms that we have correctly
identified the option expiry we wish to monitor. If the "# Matches" displayed "0", that
would indicate that one or more of our filter fields is incorrect.
Please note that a volatility curve must be assigned in Metro for each options expiry
that you wish to monitor. If there is no curve assigned in Metro, the algo will have no
curve to update as it tracks the market's implied volatilties (IVs). Both "Fixed" and
"Floating" Metro curves are supported, of the following types: "Two-Sided", "Bounded
Spline", and "Quartic". Other Metro curve types are not currently supported.
3. minIVDivergence: the minimum ATM IV deviation required to trigger a curve update.
This value is in units of one vol point (1%). A typical value might be "0.1", which
represents 1/10th of 1%. This value represents the maximum deviation allowed
between the ATM value for the current vol curve in Metro and the current market's
ATM IV. For example, imagine the trader's vol curve in Metro currently has an ATM (50
delta) volatility set at 0.2268. If the trader had this variable set to "0.1", that would
mean that his vol curve would be updated to the market's ATM IV value as soon as the
market's ATM IV value was either 0.2278 (or greater), or 0.2258 (or less). The smaller
this value is, the more frequently the vol curve will be updated. It is recommended the
user does not specify a value much smaller than "0.05", as this will cause very frequent
curve updates and thus incur some performance hits on the theoreticals caches.
4. maxIVDivergence: [Security Feature] the maximum ATM IV deviation allowed (0=no
limit). This value is also in units of one vol point (1%). This value is used in conjunction
with the following parameter "maxIVDivergencePeriodInMs" in order to create a "rate
limit" on the market ATM IV. If the rate limit is ever exceeded, this will be considered a
security constraint violation and action will be taken as specified by the user in the
parameter "behaviorOnConstraintViolation" (which may include automatically pulling
quotes from Metro on one or more curves). For illustrative purposes, two examples will
be given here to demonstrate how different rate constraints could be set on the ATM IV:

5.
6.
7.
8.
"maxIVDivergence" = 0.75, "maxIVDivergencePeriodInMs" = 0; because the
maxIVDivergencePeriodInMs = 0, the IV divergence limit will be taken over the
job's lifetime. So if the ATM IV for a given curve was 19% when the algo was
started, the security constraint will only be violated once the market's ATM IV for
the given curve exceeds 0.1975 or falls below 0.1825.
 "maxIVDivergence" = 0.2, "maxIVDivergencePeriodInMs" =60000; in this case,
the IV divergence limit is taken over a period of 1 minute (60,000 milliseconds).
So if at any time the algo detected the market ATM IV moving either up or down
0.2% (or more) in one minute or less, the rate constraint will be violated.
maxIVDivergencePeriodInMs: [Security Feature] the period in milliseconds over which
the "maxIVDivergence" limit is allowed (0=job lifetime). Please see the examples directly
above for illustrative purposes.
maxATMSpreadInTicks: [Security Feature] the maximum spread (in ticks) allowed in the
ATM options of monitored curves (0=no limit). If this feature is enabled (the user has
specified a number of ticks > 0), then a security constraint violation will occur if the
spread in the ATM options ever exceeds the number of ticks specified here. When
liquidity suddenly dries up, spreads become increasingly wide and this security feature
can help identify and act upon those events. The specific call(s) and put(s) checked for
this feature will depend on the "interpolationMode" parameter (see below for more
details).
bidAskBandToleranceInTicks: [Security Feature] the maximum number of ticks beyond
the underlying's most recently published bid/ask that the most recently published
traded price is allowed. On some exchanges like the CME, higher prioritization is given
to "last trade" market data messages that "bid/ask price update" market data messages.
This means that during a flurry of trading activity, or due to one or more large trades
that take out one or more price levels in the book, the last traded price of the future can
appear to be outside the most recently known bid/ask band (also known as an
"apparent trade-through"). The trader may wish to specify a max number of ticks here
to abort his quoting once this phenomenon occurs. Typical values might range from 3 to
8 (or more) depending the market. Values less than 3 might trigger more frequently
than the trader wishes, as minor trade-throughs are fairly commonplace in even normal
market conditions. Major trade-throughs are less common and usually more concerning.
minUnderlyingQty: the minimum quantity required on the underlying future's bid or ask
to use that price level (0=any quantity). The calculations to determine the market's IV
require the current price of the underlying. The side one would hedge the option on is
taken as this price. This setting, however, allows the calculation to widen out the
underlying price if the top-of-book quantity showing on the relevant side of the futures
spread is less than this specified threshold value. For example, a user might specify "5"
here to prevent a one-lot price level from skewing the probable true futures price.
Specifying zero will disable the feature (will take the top-of-book prices no matter the
size showing).
9. minOptionsQty: the minimum quantity required on the option's bid or ask to use that
price level (0=any quantity). This setting is essentially the same as the
"minUnderlyingQty" setting just discussed, except it applies to the options' prices that
are inputted into the IV calculations. If the user set "5" here, it would require at least 5
contracts showing in order to use that price level as the input. The options subject to
this setting will depend on the user's "interpolationMode" setting.
10. interpolationMode: the local interpolation method: 1=linear, 2=parabolic, 3=auto,
4=nearest OTM only. This parameter is fairly important and determines precisely what
strikes are involved in the market's ATM IV calculation--the final computed ATM IV is a
composite value determined from the IVs of multiple put(s) and call(s). It should be
noted that the price of the underlying will rarely fall exactly on a strike price, but will
generally be in between 2 strike prices (which we will call the "upper" and "lower"
bounding strikes). The two most common settings will be either "Linear" (1) or "Nearest
OTM only" (4). The best setting to use will depend on the convexity of the skew near 50delta and also upon the current liquidity of the strikes beyond the ATM. The following
table describes each setting:
 1=Linear. Linear mode will utilize IV information from 4 different options: the put
and the call of the lower bounding strike, and also the put and the call from the
upper bounding strike. The overall composite market ATM IV will be a linear
combination of all these individual option IVs. Linear is the most setting and
should be used in typical markets where the bounding puts and calls both have
good liquidity and the skew near 50-delta does not have significant curvature.
 2=Parabolic. Parabolic mode will utilize IV information from 8 different options:
the puts and calls of both bounding strikes, as well as the puts and calls of both
strikes 1 strike further away. The overall composite market ATM IV will be a 2nd
order parabolic "best fit" to better approximate the convexity of the skew near
the 50-delta point. Most vol skews do not exhibit much curvature near the ATM
point, so this setting will rarely be used. Skews that form "volatility smiles"
would be potential candidates for this setting, such as near-term equity options
and also forex options.
 3=Auto. Auto mode will use a simple heuristic to detect possible curvature
around the ATM point and then automatically choose between either Linear or
Parabolic based upon results of the test. In most cases, this setting will end up
being set to Linear.

4=Nearest OTM only. "Nearest Out-of-The-Money only" mode will utilize IV
information from only 2 options: the nearest OTM call (the call on the upper
bounding strike) and the nearest OTM put (the put on the lower bounding
strike). These 2 options generally are the most liquid of all available options in
any market. This setting is good for relatively illiquid markets (or back months),
where the put on the upper bounding strike and/or the call on the lower
bounding strike may not have dependable markets, due to absent or illiquid
quoting. In this case, it is preferable to use the "Nearest OTM only" setting to get
good data from the 2 most dependable options, rather than use "Linear" and
possibly lower the accuracy of the computation with undependable price levels
when pulling in the additional 2 illiquid options. It should be noted that if
"Linear" mode is specified, but valid markets only exist on the nearest OTM put
and call, the "Linear" mode will automatically and temporarily revert to "Nearest
OTM only" mode.
11. smoothingWindow: the published-IV-smoothing window: 0-1=no smoothing, 21000=the number of observations to use. If the user specifies a value 2 or greater here,
the ATM IV published to the Metro curve will first be smoothed with a proprietary
technique that is related to an exponential moving average. This smoothing operation
can be advantageous because the real-time IV time series is subject to a good deal of
high-frequency noise (mainly due to spread up-ticks and down-ticks). Quantitative
studies have shown that for every market studied, a value between 2-4 here offers
some predictive value, meaning that the smoothed version of the IV is more likely to be
nearer to the next (future) actual IV value, than the original unfiltered IV value is. For
small values (eg, "smoothingWindow" < 8 ), the effect is very minor adjustment to IVs,
often less than 5/100ths of 1% vol (vol point). This minor adjustment will only rarely
cause options prices to round to a different tick than the unfiltered IV would; however
in the cases that it does so, it would be considered to produce a better theoretical price.
Users can disable this feature by setting it to "1" or "0".
The image below shows the effect of a large smoothing window (of 100) over a 1-hour
period in CME's EUR/USD futures options. The blue line represents the smoothed IV
time series, which clearly removes much of the high-frequency noise from the actual IV
time series (red) and also has a predictive effect. Most users are recommended,
however, to set a "smoothingWindow" of less than 8 for typical market-making
operations. Large smoothing windows may have pronounced effects on the theoretical
options prices (and thus the quoted prices) and should only be used in advanced
scenarios where the trader's strategy is specifically designed to capitalize on short-term
mean-reversion in volatility.
12. isFloatingCurves: the volatility curve type the user has assigned in Metro: 1=fixed,
2=floating. The user must specify here whether the Metro curve(s) the algo will be
updating are fixed or floating type. Floating is more common. Note that if the algo has
been assigned to monitor multiple option symbols or expiries, then all monitored curves
must be of the same type (fixed vs. floating). If they are not, the user will need to create
a second algo job, so that the different symbols or expiries can be segregated by curve
type between the two algo jobs (or "instances").
13. curveUpdateThrottleInSec: the minimum elapsed seconds required between curve
updates, per curve (0=no limit). As already discussed, the "minIVDivergence" setting will
be the primary parameter affecting the frequency with which Metro vol curves are
updated. However, the trader can choose to additionally throttle the update frequency
using this field as well. For example, if the trader sets this parameter to "2", it will force
two seconds (at least) to elapse between any consecutive updates for a given Metro
curve. Common settings for this parameter are 0 to 5. In most cases, it is preferable to
affect update frequency via the "minIVDivergence" setting than by utilizing this setting.
14. ivCalcThrottleInMs: the minimum elapsed milliseconds required between IV calcs, per
curve (0=no limit). A new IV calculation will normally be conducted every time there is a
top-of-book change in the ATM options, the underlying future, or the ATM straddle (if
straddle weighting is enabled--this will be discussed below). The new IV calculation will
not necessarily result in a curve update. The curve update will only occur if the new IV
value is different than the currently published Metro curve's ATM vol value by at least
"minIVDivergence" (and no other throttling restrictions prohibit the update). This
parameter allows the user to actually throttle the IV calculation itself. It is
recommended that the user leaves this setting at "0" (disabled). The algo uses very low
CPU resources in all market conditions and there is really no good use case to throttle
the IV calculation itself. Throttling the IV calculations could cause the Metro curve to
update "noticeably late" on a large market move, because the calculation itself was
being throttled.
15. behaviorOnConstraintViolation: 0=only log violations, 1=stop quotes/RFQs for symbol's
monitored months, 2=stop all quotes/RFQs for symbol. This parameter dictates the
behavior taken (automatically) by the algo when a constraint violation occurs for any of
the [Security Features] (see above) that the user has enabled. "0" will only log the
violation event to the algo log. "1" will automatically pull the quotes and RFQ responses
for the violating curve (specific symbol and month). "2" will automatically pull the
quotes for all expiries on the symbol of the violating curve (regardless of whether or not
the other months are actually being monitored by the algo). For example, if the trader
has set up some security feature constraints on the front month of his ES options, and
the front month violates when the algo has "behaviorOnConstraintViolation"=2, the
algo will automatically pull quoting and RFQ responding for all ES options (front and
any/all back months) the trader may be quoting.
16. verbosity: the log detail level: 0=minimal, 1=basic, 2=full. It is recommended the user
sets this parameter to "1". The Full verbosity level will print quite a bit of info to the log
and is only advisable if attempting to troubleshoot an IV calculation or gain additional
details on the mathematical results.
17. displayIVsFromDaysAgo: for historical IVs Scatterplot displays, the number of days ago
to start the display at. If this parameter is set to 1 or more, the algo will create the
binding for a Scatterplot display upon startup. The log will display the critical
information the user will need to create the appropriate Scatterplot dashboard to
display the historical IVs. The Scatterplot will go back in time the number of days
specified here. Please note that the algo had to have been running during those prior
days in order to have saved the historical IVs for that time period to the database (any
missing days will effectively be gaps). Also note that multiple maturities of a given
symbol can be assigned to the same scatterplot to view the term structure of volatility
across maturity. The X-axis of the scatterplot will be in units of "hours ago from the
current time", where the gaps from the overnight periods have been removed (if
present). The image below shows an interesting spike in crude options (symbol LO) ATM
IV that occurred around June 2014. The scatterplot shows approximately 20 trading
days of history in the front month (red), mid month (blue), and back month (gray). The
term structure of volatility displayed here exhibits very typical behavior where volatility
movements are most pronounced in the front month and progressively decay as time to
maturity increases. This phenomenon exists because volatility is mean-reverting on
longer time scales; further maturities are thus less affected by the most immediate
moves. Users should note that the term structure of volatility can also be impacted by
seasonal patterns in many commodities.
18. incorporateStraddleIVs: 0=no, 1=yes. In addition to the ATM IV information gleaned
from the outright options specified by the "interpolationMode" setting, additional ATM
IV info can be obtained from the current pricing of the ATM straddle. If the user
specifies "1" here, the algo will attempt to obtain this additional IV information from the
straddle (as long as a valid market exists for the straddle; if it does not, the straddle info
will be ignored for the time being). If the user specifies "0" here, the algo will not use
the straddle pricing as part of the overall ATM IV computations.
19. straddleSideDepthQty: the aggregate quantity to trigger a valid price level on each side
of the ATM straddle's spread. This setting is only relevant if "incorporateStraddleIVs" =
1. This setting indicates the aggregate minimum quantity required for a bid or ask price
to be established. For example, a value of "1" would indicate the algo will always use the
ATM straddle's top-of-book prices. A value of "50", however, would use the first bid /
ask price level where all previous levels (closer to the top-of-book) accumulate to a total
of 50 contracts. If 50 contracts aggregate did not exist in total on either the bid or the
ask side of the ATM straddle's book, the market would be considered invalid and the
straddle incorporation would be omitted for the time being (until a sufficient market
returned).
20. straddleIvCapWeight: the percentage of weight to assign the straddle IV boundary
when exceeded (0-100). This setting is only relevant if "incorporateStraddleIVs" = 1. This
setting comes into play only if and when the ATM IV computed via the outright options
(specified by the "interpolationMode") falls outside the IV band created by the bid and
ask prices on the ATM straddle. This event can occur somewhat regularly and is due to
supply/demand imbalances existing between the ATM straddle and the outright options
that constitute the same straddle's legs. Because there is no mathematical rationale to
prefer the straddle IV information over the IV information from its deconstructed legs, it
is recommended that the user specify "50" for this setting. This represents a 50%
weighting and means that, when the straddle and option outright IVs occasionally
conflict, to simply take the average of the two. Empirical evidence suggests that this
joint IV is indeed more accurate than either of the two separate IVs taken alone.
21. atmVolOffset: the ATM volatility offset to apply before assigning the value to the Metro
vol curve. This value is in units of one vol point (1%). Setting this to "0" would allow the
market ATM IV value to be assigned directly (no offset). However, if the user instead
specified "-0.25", a quarter point of vol would be subtracted from the market's ATM IV
value prior to each publication to the Metro curve. For example, 18% market IV would
be assigned as 0.1775 ATM volatility in the Metro curve (assuming a curve update was
triggered and not prevented by throttling). This setting allows traders the option to
"lean" on the market's implied volatility, even as they follow it.
22. allowedVolRange: hard limits on the ATM vol (eg, '10-13' means between 10% and 13%)
allowed to be published; leave blank to omit. In all but the most liquid markets, there
may be rare (maybe once every month or two) events that cause much liquidity to
suddenly dry up, even for the ATM options. In this case, very wide spreads may
suddenly develop in the ATM options. Preferably, the user has set up the
"maxATMSpreadInTicks" security feature in order to detect these events and proactively
abort curve monitoring immediately (as well as pulling quotes and RFQs). However, if
the user has not set up this security feature, or the security feature is too wide to be
triggered, then the algo may produce an inaccurate IV value due to the abnormally wide
prices quoted in the market. These rare "bad" IV values are usually much lower or
higher than would be expected. In order to prevent such "bad" IVs from being published
to Metro, it is important the user specifies a "hard" vol range using this parameter. Even
if this setting is only updated once a day or once a week, it will generally serve sufficient
to prevent any bad IV from slipping through. Please note, though, that proper use of the
various Security Features should make this parameter unnecessary for purposes of
filtering out any rare "bad" IVs.
23. underlyingFutureOverride: this setting is not required for normal use cases.
24. ivArchiveFileDeltaSet: a comma-separated list of deltas (1-50) to record; leave blank to
omit. This parameter is only relevant if the "ivArchiveFileIntervalInMins" parameter is 1
or more (the IV archive file writing feature is enabled). When this feature is enabled, the
algo will write the market IVs of the monitored curve(s) to a file on the server at regular
intervals. The created file is in *.CSV file format, meaning the file can easily be imported
into any spreadsheet application (eg, Microsoft Excel) or database. In addition to the 50delta (ATM) point, users can specify any number of deltas to record in a commaseparated format. Each specified delta point can be between 1 and 50. For example, if
the user set this parameter to a value of "1,10,30,50", then the algo would regularly
write to the IV archive file the following deltas (note that OTM options are always
reported; ITM deltas are not currently supported for this feature):
 -1 delta from the OTM put
 -10 delta from the OTM put
 -30 delta from the OTM put
 50 delta (ATM), essentially the same value from the core calculations used to
update the Metro curves
 +30 delta from the OTM call
 +10 delta from the OTM call
 +1 delta from the OTM call
Note that reported IVs will always be a linear interpolation between the closest
bounding strikes at each delta point (regardless of the "interpolationMode" setting used
for interpolation at the ATM point). Also note that, because the list of specified deltas
maps directly to the columns created in the archive file, changing this list of deltas will
force the algo to create a new file for writing (if a prior file with different columns
already exists). However, if the list of deltas stays the same each time the algo starts, it
will continue to write to the same IV archive file as before (or in prior days).
25. ivArchiveFileIntervalInMins: 0=disabled, 1-60 = number of minutes between each write.
To enable the IV archive file writing feature, specify a number of minutes here between
1 and 60. This will be the interval (in minutes) between each successive IV archive file
write. Each write event will produce one line for every curve the algo is monitoring. The
example below shows the IV archive file contents produced in the ES MAR15 options
over a period of 80 minutes or so, with writes occurring on 10-minute intervals using
"ivArchiveFileDeltaSet" = "1,5,10,15,20,25,30,35,40,45,50". Note that many of the delta
columns have been removed here and replaced with ellipses due to the excessive
horizontal length.
Curve,Date,Time,-1D_IV,-5D_IV,-10D_IV,…,10D_IV,5D_IV,1D_IV
ES_O_20150320,1/26/2015,8:30:00,0.16385,0.15953,0.15698,…,0.14036,0.13808,0.13376
ES_O_20150320,1/26/2015,8:40:00,0.16636,0.16174,0.15965,…,0.14239,0.14013,0.13586
ES_O_20150320,1/26/2015,8:50:00,0.16773,0.16349,0.16106,…,0.14451,0.14219,0.13773
ES_O_20150320,1/26/2015,9:00:00,0.16529,0.16097,0.15841,…,0.14194,0.13961,0.13537
ES_O_20150320,1/26/2015,9:10:00,0.16304,0.15879,0.15653,…,0.14015,0.13761,0.13331
ES_O_20150320,1/26/2015,9:20:00,0.16527,0.16061,0.15845,…,0.14178,0.13909,0.13488
ES_O_20150320,1/26/2015,9:30:00,0.16387,0.15959,0.15755,…,0.14075,0.13826,0.13379
ES_O_20150320,1/26/2015,9:40:00,0.16329,0.15899,0.15664,…,0.13989,0.13759,0.13328
The same information charted graphically in Excel is shown in the image below, where
time has been coded in colors from cold to hot ("rainbow order"). Note that the values
displayed on the "Delta" X-axis are not strictly correct; in actuality, the X-axis goes from
a delta of -1 to -50, then continuing left to right, from +50 to +1 (just like the ordering of
the delta columns in the file).