|
|
|
|
Main Page for Subject Area |
||
Volatilities
Outline
1) Definition
2) How Volatilities Are Used In CTRM Systems
3) How to Calculate Volatilities
4) Assumption of Normal Distribution
5) Assumption of Lognormal Distribution
6) Considerations for CTRM Systems
1) Definition
‘Volatility’
is the annualized standard deviation of percentage
price changes for, in this case, a commodity.
It is a
measure of how widely ‘things’ (commodity prices)
move around.
Notes:
1.1) We’ll
refine this definition a bit below.
1.2) Notice we
said ‘price changes’ and not ‘prices’ in the definition.
1.3) ‘Standard
Deviation’ is a concept from the field of statistics, i.e., a generic math
concept. It is defined as the square
root of the ‘variance’, another term/concept from statistics. Those two terms are generic to all fields,
e.g., physics, etc. It is only
‘volatility’ that has a special definition for use with commodities markets
(and financial markets in general).
2) How Volatilities Are
Used In CTRM Systems
Two ways:
2.1) For use
in option pricing models, i.e., as one of the inputs to, for example, the Black
Scholes option pricing model. (The other
inputs are time to expiration in years, interest rate, strike price of the
option and market price.
2.2) For
calculating VaR (value at risk). Only
‘parametric’ (closed form formula) and ‘Monte Carlo’ methodologies of VaR use
volatilities. They aren’t used/needed if
you use the Historic VaR approach.
3) How to Calculate
Volatilities
This shows how
to calculate volatilities using historic prices. For this section, we’ll assume you are
planning to use the volatilities for use with VaR.
If you were
going to use the volatilities for use with option pricing, you probably would
not use the method described here.
Instead you would derive volatilities (back solve) using current market
*prices* (i.e., option prices) to figure out what volatilities must be applicable,
so that if you plug them into a given pricing model with the rest of the inputs
(underlying price, option strike, interest rate, time in years to expiration),
you get the same option price as the currently traded value.
3.1) First
step is to decide on your time frame to use.
Do you use 2 months of price data?
6 months? 1 year? This decision will likely change the end
result you come out with. For example,
if the most recent 2 months happened to be especially volatility, using just 2
months of price data may give a higher calculated volatility value that using a
years’ worth of price data.
For this
example, we’ll use 11 trading days. This
is probably never a value to use for real, as it is too low. It is good for keeping things short for a short
intro, and the methodology is the same no matter how many days you use.
These are the
prices we’ll use. We are assuming today
is 10-Jun-202X.
|
Day # |
Date |
Price |
|
11 |
27-May-202X |
52.53 |
|
10 |
28-May-202X |
53.14 |
|
9 |
29-May-202X |
52.12 |
|
8 |
30-May-202X |
51.66 |
|
7 |
31-May-202X |
53.42 |
|
6 |
3-Jun-202X |
51.54 |
|
5 |
4-Jun-202X |
52.66 |
|
4 |
5-Jun-202X |
52.71 |
|
3 |
6-Jun-202X |
52.43 |
|
2 |
7-Jun-202X |
51.90 |
|
1 |
10-Jun-202X |
52.13 |
The ‘Day #’
doesn’t mean anything functionally/mathematically. Just showing it to help clarify things for
the reader.
3.2) Next step
is to calculate the price changes. With
11 days of prices, we’ll get one less than that, i.e., 10 days, of price
changes.
Note for the ‘Percent
Price Changes’, we are giving the ‘one plus’ version of the return (‘return’ =
‘price change’), so we show 100.3998% instead of 0.3998%.
The way you
interpret the ‘one plus’ returns is as follows:
If you have
100%, that means, no change. i.e., you
have ‘100%’ of the prior value’. If you have a ‘one plus’ return of 101.1612%
(as shown for the first return below), then you have 101.1612% of the prior
day’s value.
If the ‘one
plus’ return was 0 (zero), then that means you are down 100%, i.e., lost all
value, i.e., price went from, for example, 52.53 down to zero. This means that ‘one plus’ returns can never
be below zero, i.e., at least for commodity prices (i.e., things that are not
spreads of two or more prices), or at least we can assume that commodity prices
can’t go below zero.
|
Day # |
Date |
Price |
Price Change |
Percent |
|
11 |
27-May-202X |
52.53 |
|
|
|
10 |
28-May-202X |
53.14 |
0.61 |
101.1612% |
|
9 |
29-May-202X |
52.12 |
-1.02 |
98.0805% |
|
8 |
30-May-202X |
51.66 |
-0.46 |
99.1174% |
|
7 |
31-May-202X |
53.42 |
1.76 |
103.4069% |
|
6 |
3-Jun-202X |
51.54 |
-1.88 |
96.4807% |
|
5 |
4-Jun-202X |
52.66 |
1.12 |
102.1731% |
|
4 |
5-Jun-202X |
52.71 |
0.05 |
100.0949% |
|
3 |
6-Jun-202X |
52.43 |
-0.28 |
99.4688% |
|
2 |
7-Jun-202X |
51.90 |
-0.53 |
98.9891% |
|
1 |
10-Jun-202X |
52.13 |
0.23 |
100.4432% |
3.3) Now take
the standard deviation of the above ten percent price changes.
In Excel, you
use the ‘STDEV’ function. Don’t use the
‘STDEVP’ function. The ‘P’ is for ‘Population’
and the ‘P’ function should only be used when you know all of the possible
outcomes and, especially, know the ‘true’ average of your values. While we can calculate the average of the
values above, that is just a ‘statistical sample’ and not assumed to be the
‘true’ (or real) average of the ‘distribution’ of price changes. Hence the need for using STDEV.
This is the
formula I used. For me, the data is in
column G, rows 5 to 14.
=STDEV(G5:G14)
And we get:
0.0200004328
Or, expressed
as a percent:
2.00004328%
Side notes:
a) If you take
the standard deviation of the non ‘one plus’ returns, i.e., [0.0116%, -0.0192%,
-0.0088%, 0.0341%, -0.0352%, 0.0217%, 0.0009%, -0.0053%, -0.0101%, 0.0044%]
then you’ll get the exact same value.
Try it and see.
b) As a
reminder: we made up the prices, i.e., so don’t infer too much based on the
calculated values.
3.4) So far,
the standard deviation we have is of daily price changes. We still need to convert this to annualized
price changes.
To do this, we
multiply by the square root of the number of days in the year. We’ll assume 256 days in a year for this
example. That is 365 minus weekends and
holidays. Of course, the actual number
of good business days in a year will vary year by year and based on local
holidays.
What’s nice
about using 256 is that the square root is 16, a nice whole number.
So, to get the
annualized volatility, you get:
32.0006924% =
2.00004328% * 16
In other
words, about 32%.
4) Assumption of Normal
Distribution
For people
familiar with the Normal Distribution, a.k.a., ‘the bell curve’, you may recall
that:
Plus or minus
one standard deviation has about 2/3 of the values.
Plus or minus
two standard deviations has about 95% of the values.
Plus or minus
two standard deviations has about 99% of the values.
Using our
example of 32% above, and assuming a starting point of $50, we get:
+/-1 one
standard deviation is a range of 34 to 66.
That means, we expect, if the price today is 50, and the volatility is
32%, that there is a 2/3 chance that the price will be between 34 and 66 in one
year’s time *if the prices are normally distributed*.
+/-2 two
standard deviations is a range of 18 to 82.
So 95% chance of prices within that range.
+/-3 two
standard deviations is a range of 2 to 98.
So 99% chance of prices within that range.
The above info
is given to help with the idea of helping with peoples’ intuition about that
‘32% annualized volatility’ means. You
might be thinking/reacting, why are we talking about crude oil at $2?!? That can’t happen (or is very unlikely to
happen). Response: That is what you get when you assume a normal
distribution. You can improve on that,
though, by making a different assumption on how to model the distribution of
commodity price changes.
5) Assumption of
Lognormal Distribution
For commodity
price changes (i.e., not prices), some will model VaR using the assumption that
commodity price changes are lognormally distributed.
This is
usually a better assumption than assuming commodity price changes are normally
(i.e., as opposed to lognormally) distributed.
The lognormal distribution is just the log (the natural log, which is
Excel function ‘ln’) of the normal distribution.
The normal
distribution is symmetric and goes from minus infinity to positive
infinity. The lognormal distribution, by
the properties of logs, goes from zero (starts at zero) and goes up to positive
infinity.
This matches
the properties of our ‘one plus’ returns.
E.g, prices can double or triple, e.g., from 50 to 100 or 150, but we
assume they can’t go from 50 to -50 or -100.
i.e., they are asymmetric in that they can go up more than they can do
down, which matches the lognormal distribution.
When we assume
that prices for a particular price index are lognormally distributed (in the
context of using volatilities in a VaR calculation), then we need to take the
log (the natural log, which is Excel function ‘ln’) of the *price changes* (not
the prices).
Here is the
same table from above, with an extra column for the log of the percent price
changes.
|
Day # |
Date |
Price |
Price Change |
Percent |
Log of Percent |
|
11 |
27-May-202X |
52.53 |
|
|
|
|
10 |
28-May-202X |
53.14 |
0.61 |
101.1612% |
1.1546% |
|
9 |
29-May-202X |
52.12 |
-1.02 |
98.0805% |
-1.9381% |
|
8 |
30-May-202X |
51.66 |
-0.46 |
99.1174% |
-0.8865% |
|
7 |
31-May-202X |
53.42 |
1.76 |
103.4069% |
3.3501% |
|
6 |
3-Jun-202X |
51.54 |
-1.88 |
96.4807% |
-3.5827% |
|
5 |
4-Jun-202X |
52.66 |
1.12 |
102.1731% |
2.1498% |
|
4 |
5-Jun-202X |
52.71 |
0.05 |
100.0949% |
0.0949% |
|
3 |
6-Jun-202X |
52.43 |
-0.28 |
99.4688% |
-0.5326% |
|
2 |
7-Jun-202X |
51.90 |
-0.53 |
98.9891% |
-1.0160% |
|
1 |
10-Jun-202X |
52.13 |
0.23 |
100.4432% |
0.4422% |
Note that the
log of the percent change has percentages that may match our intuition better
about what to expect in terms of formatting.
E.g., we see that from one day to the next the price changed by
-1.9381%, which may be easier for us to understand than saying the price today
was 98.0805% of the prior day’s price.
By using the
Excel function stdev on the new column, we get a calculated volatility of
2.00050152% for the log of the price changes, or, an annualized value of
32.008% (multiply by 16).
Compare that
new value to the 32.001% value we got from just using the simpler percent
changes and we can see that it didn’t make much of a difference in this case.
As a rule, the
bigger the price changes (as a percent), the more it will make a difference
which approach you use, i.e., using just the percent change or the log of the
percent change.
6) Considerations for
CTRM Systems
6.1) CTRM
systems should be able to automatically calculate volatilities using the
settlement (‘closing’) prices already in the system.
6.1.1) There
should be a ‘hook’ into the process, so firms can customize the
calculation. i.e., at some step in the
process, where the system has gathered up all of the prices needed to calculate
the volatilities, users should be able to tactically modify the prices, e.g.,
to handle a special method of interpolating data for days missing prices.
6.1.2) One
consideration in how systems calculate volatilities for commodities is to allow
users to configure to take either the prices for a specific month, e.g., December
2019, and use a set of those prices, e.g., for 6 months, to calculate the
volatility. Or, instead, set things up
so the system will instead take, for example, a month that is a constant 4
months out.
6.2) CTRM
systems should also allow for easy import and export of volatilities. Should allow for:
6.2.1) CSV
format (text)
6.2.2) XML
format
6.2.3) Native
Excel format
6.2.4) Web
service, i.e., for loading (importing) or exporting volatilities.
6.3) On the
topic of how volatilities are used with option valuation, CTRM systems need to
support a lot of variations, i.e., be flexible with the design and
implementation of how a particular volatility or set of volatilities is ‘looked
up’ for valuation of an option.
6.3.1) First,
talking about the structure of volatilities, you would need, for various users:
6.3.1.1) One
volatility per month. E.g., for NYMEX
Crude oil contracts, allow firms to enter in a volatility value for August,
another one for September and so on.
Side note: As
a general rule, the front month, i.e., closest to today, months have the
highest volatility and things drop off from there. That is because price-influencing events,
e.g., hurricanes, frosts, etc., tend to impact the front months more with
prices 1 or 2 years out barely moving, both because people figure the event
will have sorted itself out by then and because the back months tend to trade
less.
6.3.1.2) One
volatility per month per strike. This is called ‘two-dimensional’, with the
dimensions being time (e.g., the contract months) and the strike price being
the second dimension.
This then
leads to the need to support different ways to define the strikes. E.g., you
might setup specific values, e.g., for crude might be 48, 49, 50, 51, and so
on. Though that is less likely to be
used.
More likely,
people will want to setup relative strikes, i.e., relative to the market / the
at the money strike.
So, for
example, like this:
-3, -2, -1, 0,
1, 2, 3, etc.
So if the
market is at 50 and your option has a strike price of 50, it would get its
volatility value from the ‘0’ column, for the appropriate month (row).
Another
variation is to setup as percentages or ratios.
E.g., like this:
80%, 90%,
100%, 110%, 120%, etc.
Or, setup an
alternate way as
-20%, -10%,
0%, +10%, +20%.
So if the
market is at $50 and your option has a strike price of $55, then the system
would look up the volatility from the 110% (or +10%) column the appropriate
month (row).
6.3.1.3) One
volatility per month based on the delta
of the option. As a note, an at the
money option has a delta near 0.5, though it won’t be precisely 0.5, and
systems should account for that. A user
might want columns like:
.2, .3, .4,
.5, .6, .7, etc.
With then rows
by month.
Alternately, a
user may want to set the precise value for an at the money option, so would
want to specify values by:
.2, .3, .4,
ATM, .6, .7, etc.
Where ‘ATM’
would be a special system feature that understands that it is the at the money
value.
6.3.1.4)
Interpolation, i.e., interpolated value for options with strikes between the
values specified by the ‘volatility matrix’ of rows and columns is super
important to get the correct option values and CTRM system should support
6.3.1.4.1) a
wide variety of interpolation methods
6.3.1.4.2)
ways for users to customize their own interpolation method
6.3.1.4.3)
and, critically, a tool in the system for users to debug/diagnose/view
interpolated values. e.g., without
having to enter in an actual option, users should be able to get the ‘output’
volatility values for any strike price, especially one where interpolation is
needed.
6.3.2) Another
thing CTRM systems need to get right is the correct ‘lookup’ of volatilities
based on the correct date. The date for
an option might be, meaning the date to use for lookup:
a) the option
expiration date, which may be, for example, November 26, 2019 or
b) the
contract month of the option, which may be for the same example as above, the
Dec-19 contract.
This should be
a setting per option volatility definition.
The key is to align what a firm is putting as intended inputs (for
volatilities) with what the system will actually use for an option.
6.3.3) Special
considerations for averaging.
6.3.3.1)
Suppose you have an averaging option, e.g., one that has a (fixed) strike price
versus the average of the business day settle prices, e.g., about 22, over a
calendar month for NYMEX crude oil.
Assuming the month is for June, this would get its prices from the July
and August contract months, with a ratio of about 2/3 to 1/3.
Though this
option gets its prices in June, the June contract month would expire sometime
in the end of may, so needs to get its prices from the first nearby contract,
which would be the July contract for the beginning of the month, until it
expires, and then it would be the August contract.
To get the
correct volatility for use with an averaging option, the CTRM system will need
to pull the volatilities, as supplied by the user, for two months, the July and
August months.
CTRM systems should not only have that work correctly, they should be able to
‘show their work’ so as to show the details, i.e., one value per day, that make
up the average volatility (for the set of days) that would be fed into the
option pricing model.
Moreover, CTRM
systems need to handle the case/situation of how prices are set (‘fixed’)
during the pricing month, i.e., June in this case. Prior to the start of the pricing month, the
volatility used would be an average of, say, 14 days from July and 8 days from
August (for 22 days in total). At some
point, e.g., with just 6 days left, all of the volatility values would come
from the August month from the volatility matrix, because all of the July price
values (in the overall average) would have already been set/known/fixed.
In summary,
CTRM systems need both handle the case of averaging options so as to supply the
correct volatilities as appropriate, and make it easy for product control/risk
managers to delve into the details of how things are working.
6.3.4) Call
versus put.
Systems should
allow for a different set of volatilities to be used for calls versus
puts. While in theory, the same
volatility should be used for a call option as for a put option, all other
things being equal, some firms have special reasons in some cases to use
different volatilities. So, at a
minimum, a CTRM system should support that.
6.3.5) Smile
volatilities.
This is
another way of saying, a CTRM system should support a formula approach for the
system to calculate which volatility value should be used for a particular
option deal as an input to its pricing model.
Such a formula
is often called a ‘smile formula’, due to its most common shape, which has the
middle part be lower than the sides (the ‘wings’), i.e., so shaped like a
smile.
CTRM systems
should allow for formulas to be built-in and also for the formulas to be kept
externally, i.e., the CTRM system would have just the inputs to the formula,
and the mathematical part of the formula would be external, e.g., a DLL or a
web service.
A common
formula might have just three inputs:
a) ATM
volatility – the volatility value to use when an option strike is considered at
the money
b) a measure
of how tilted (symmetric or asymmetric) the ‘smile’ curve is
c) a measure
of how flat (or not flat) the ‘smile’ curve is
though some
more complicated formulas may have 9 or more inputs to further define the shape
of the curve to whatever model a firm wants to use.
6.3.4) Three
dimensional volatilities
For things
like swaptions, i.e., options on swaps, a CTRM should have support for
3-dimensional volatility inputs/outputs, sometimes called ‘volatility
surfaces’. Besides expiration date and
strike price, the tenor (how long it is, e.g., 3 months long or 12 months long)
can be used as a way for the system to lookup which specific volatility value
should be used when pricing a particular option.
6.3.4) Front
month issue
For markets
like natural gas and power, where you might have daily prices published and
projected for the remainder of the month (‘BOM’ or ‘balance of month’), you
have an interesting issue with regard to volatilities for the month you are
currently in. The volatility value for
the month is, in this case, an average.
At the start
of the month, you may have 22 days of prices that are part of that
average. Towards the end of the month,
you’ll have at one point, for example, just 3 days.
All things
being equal, the average of more things (days in this case) will have a lower
volatility due to the mathematical property of things (or the central limit
theory, if you want to get statistical).
As an example, if you have a 6-sided single dice (I internet-searched
and found that both ‘die’ and ‘dice’ are acceptable for a single die from a set
of dice), and you roll it twice, you would not be surprised to have an average
1.5 (e.g., you roll a one and a 2).
However, if you roll it a 1000 times, you would really expect the
average to be somewhere between 3 and 4.
i.e., the
*average* of a set of random trials (dice roll) has a lower volatility the more
‘trials’ are in the average, i.e., it has a lower/smaller range of most likely
values.
For CTRM
systems for natural gas or power, to handle this situation, users may want to
use the 2nd month, i.e., first full month out, to source the
volatility value for the first month.
E.g., if we are 11-Jun-2019, we might want to use the July 2019
volatility value for June 2019 options (and for July 2019), because using a
volatility based on the balance of month June 2019 prices may result in a
volatility value that is theoretically too high for the reason listed above.
7.1) EWMA is
another method to calculate volatilities.
Compared to the two approaches that were shown above, which was a) based
on the percent change of daily prices and b) based on the natural log of the
percent change of the daily prices, the EWMA approach is ‘just another method’
that will calculate what would typically be a slightly different number.
The key being
that any of these approaches would start with the same set of prices. And, one of the key decisions that will
impact the volatility value that ultimately gets calculated will be, perhaps
materially, influenced by the time frame used.
E.g., 2 months of prices, 6 month, a year, or other.
7.2) The idea
behind EWMA is that the more recent prices and therefore price changes would
have a bigger weighting in the overall volatility calculation. So if you are taking prices for the prior
year and the prior two months were especially volatile, then we might expect
the EWMA to show a higher calculated volatility value than taking all of the
price changes of the prior year and giving them an equal weight.
7.3) Should it
be used by risk managers?
Note that we
are talking about in a context of calculating VaR (value at risk). And, as a reminder,
that the ‘Historic VaR’ approach doesn’t require volatilities of any kind… it
just needs the historic prices.
The negatives
are:
7.3.1) This is
more complicated. In general,
complicated is bad. Even if the
calculated value is marginally better, it needs to overcome a hurdle in order
to be used of being worth the extra complexity.
My thought challenge is to imagine you had to explain to an auditor why
you chose this approach over a simpler one.
How would you do it?
7.3.2) The end
result numbers wouldn’t necessarily be material, meaning meaningful in changing
decision making, including things like trader bonuses, risk capital required,
etc. E.g., if the end result VaR changes
by a few percent as a result of using EWMA, is that material?
7.3.3) There
isn’t necessarily any theoretical reason to use one particular weighting or
another. The weighting factor may have a
value of 0.8 or 0.9. How would you
choose which one to use? And feel that
it is the best one?
7.3.4) As a
comparison… I personally would prefer to run VaR twice, first with, say 1 year
of data, and then with 2 months of data.
From prior experience, I tend to get about the same values, so it isn’t
material, i.e., doesn’t matter.
However, if I
did see some material difference, e.g., VaR being 30% higher with two months of
data, then I would want to know that.
And I would want to investigate.
Part of what I
am saying is, that having the knowledge that it does matter, i.e., if you use 2
months or 1 year of data does matter, is something perhaps important to
know. If you run VaR just one way, as
EWMA, then you don’t get that knowledge.
7.3.5) For
BlueCTRM, the nice thing about this is that people can build this in if they
want it. i.e., the EWMA method of
calculating volatilities. They could do
this as:
a)
Contributing to the code base, i.e., open source.
b) Build their
own plugin/addin/extension to the system for personal use, if they feel this is
a competitive advantage
c) Sell it as
a licensable product. i.e., that is based
on the open standards of BlueCTRM.
7.4) Next up
is GARCH.
Generalized
Auto-Regressive Conditional Heteroscedasticity
7.5)
Explaining what that means starts with an explanation of ‘Heteroscedasticity’.
Heteroscedasticity
means that the volatility changes over time.
More technically/accurately, it is the standard deviation (or the
variance) that is changing over time.
Let’s use two
examples.
Example 1 is a
die roll for a 6-sided die. Imaging you
roll a die once per business day for a year.
Example 2 is
the price change in crude oil.
For Example 1,
you can assume that the standard deviation of your rolls is the same for the
full year. i.e., assume the same die and
the same person rolling it. The
distribution of values is still 1 to 6 with an assumed equal likelihood of
each.
For Example 2,
you can’t make that same assumption.
Some big event may have causes prices to be more volatile the prior two
months, than the 10 months before that, i.e., assume some big event happened 2
months ago and things have been different since then.
For commodity
price changes, it is understood that the volatilities will change over time in
practice. Furthermore, it isn’t
necessary theoretically ‘ok’ to take price changes that span multiple
‘volatility regimes’, though in practice, there isn’t always a choice about
that.
7.6) The
Auto-Regressive Conditional part of the name means this: That volatilities tend
to be mean-reverting. Not prices, which
can go up and up forever, but, rather, volatilities. E.g., if there is a particularly
busy/volatile time, e.g., due to a frost, cocoa prices become very volatile,
then we can expect that to be short lived.
A GARCH
approach might produce a *lower* volatility number for use with VaR than the
recent period, assuming that the recent period is unusually volatility, i.e.,
the expectation being that the risk should start to go back to normal.
7.7) As with
EWMA:
a) Similar
criticisms. Except that GARCH is even
more complicated, so would need to be that much more materially better to put
the extra effort/work in.
7.8) The
biggest criticism of any standard VaR approach is the assumption that commodity
price changes are lognormally (or normally) distributed. That is demonstrably not true. Commodity price changes are likely to have
much bigger moves than you would predict from the lognormal/normal
distribution.
These can be
called ’6-sigma’ moves (or 7-sigma, 8-sigma, etc.). ‘sigma’ is the spelled out Greek letter used
to represent ‘standard deviation’. These
are also sometimes called a ‘fat tailed’ distribution because the ‘winds’
(left/right sides) contain more area than a similar type normal distribution
(‘bell curve’).
The point here
is that the precise way you calculate volatilities pales in comparison… is
never going to be as materially an issue, as an incorrect assumption about the
distribution of commodity price changes.
7.9) As a more
practical matter, have a think about this.
CTRM systems will typically assume some number of good business days in
the year for the purposes of calculating volatilities. Recall from above that you need to multiply
the standard deviation of the daily (log percent) changes by the square root of
the number of days in the year, to get the annualized number for use with VaR.
Imagine a
comparison of using 250 good business days or 260.
The square
root of 250 is: 15.8113
The square
root of 260 is: 16.1245
That is about
a 2% difference, which will carry over into the VaR calculations.
Side note: It
is probably best to use a hard coded assumption as to the number of days,
rather than try to calculate the real number of days in a year, which will vary
by holidays, and get especially complicated if you are trading in multiple
locations around the world which have different holiday dates.
7.10) One
thing to keep in mind for VaR calculations is the difference between a
‘confidence interval’, which is two-sided, and a ‘confidence level’, which is
one-sides.
For a
confidence interval, people may have learned that for a normal distribution,
plus or minus 2 standard deviations is approximately 95% of the possible
values. They may remember a table like
this:
+/- 1 standard
deviation: 66%
+/- 2 standard
deviation: 95%
+/- 3 standard
deviation: 99%
Using the Excel
function ‘NORM.S.INV(N)’ (inverse normal), we can plug in percent probability
values, e.g., ‘NORM.S.INV(0.025)’.
Plug in 0.025
and you get -1.95996 (about -2 standard deviations).
Plug in 0.975
and you get +1.95996 (about +2 standard deviations).
i.e., 0.975 -
0.025 = 95%, a two-sided ‘confidence interval’.
That value is
*not* what you would use with VaR, if you want a 95% confidence level (one
sided) VaR. i.e., you want the threshold
where 5% of the possible values are ‘to the left’ and 95% of the values are ‘to
the right’ of the dividing line.
For that, by
the way, you would have:
NORM.S.INV(0.05)
= -1.6448
i.e.,
everything to the right of -1.6448 is 95%.
Point here is:
I may have seen CTRM systems which may have the wrong number of standard
deviations used in their VaR formula.
E.g., 1.95996 instead of 1.6448 as a threshold.
i.e., so check
that is correct before spending too much time comparing approaches for
calculating volatilities from a set of historic prices.
7.11) Point
here is that other assumptions/parameters besides the volatility calculation
formula/approach can have the same to bigger implications on the end result VaR
number… and that the other assumptions/parameters are easier to
understand/explain versus something complicated like GARCH.
Such as:
7.11.1)
Assumption that price changes are lognormal:
Huge implication on VaR calc, but not much in the way of practical
alternatives:
7.11.2) Date
range of prices to use, e.g., prior 2 months or prior 1 year of pries: Typically not a material change. Good
approach is to run VaR using more than one range of dates (of prices/price
changes) for calculating volatilities.
7.11.3)
Assumption about how many business days are in a year: May have an impact of a
few percent on VaR.