 Main Page for Subject Area

Volatilities

Outline

‘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).

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.

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 Price Change 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

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.

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 Price Change Log of Percent Price Change 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.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.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 hurtle 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.