UV garch model forecasts

[TomDoan]

A priori I'd expect for a long position in an equity index to have a higher VaR and ES level than for a short position simply because equity indices historically are trending-upwards, but that depends on sample. However, in FX it's more difficult to have a view.

That's exactly wrong. The VaR is minus the alpha-percentile, so if the alpha-percentile is a less negative value (which it would be if the drift is positive for the long position) the VaR is smaller.

There might be a reason to expect that equities would have a higher VaR on long positions than short because of asymmetries in the returns (big negative price changes are more likely than big positive ones), but that's a completely different story.

[ac_1]

Over a short period (like 10 days), the difference should be quite modest, as the drift is small compared to the day-to-day movements.

Returns to a short position are sign flips of the returns to a long position. You *can* simply flip the sign of the returns data and redo the calculations. Alternatively, you can analyze the opposite tail of a model done in longs. For simulated data, the alpha VaR to a short position is the 1-alpha percentile of the simulated returns to a long position; the ES is the mean of the simulations that exceed that (note >= not <= that you would do for ES on a long position, since it's the upper tail behavior you are analyzing). If you use a symmetrical parametric distribution (t or Normal), the VaR and ES formulas are the same except for a sign flip on the mean.

I think there's an error in GARCHBOOT.RPF

sstats(mean) 1 ndraws %if(returns(t)<VaR(i),returns(t),%na)>>es

it should be <=


For Parametric and simulations (using 10,000 draws with the SAME SEED), generating rolling 1-step ahead VaR and ES forecasts:

GARCH
Parametric (Normal, t, GED) distributions, both "flip-sign" and "right-tail" = SAME results.

Bootstrap: "flip-sign" and "right-tail" = SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.


GJR-GARCH
Conclusions: same as for GARCH, except,

Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results for ES only.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results for ES only.


EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.


Why would "flip-sign" and "right-tail" have different results in simulations, and which method do I use?

[TomDoan]

Over a short period (like 10 days), the difference should be quite modest, as the drift is small compared to the day-to-day movements.

Returns to a short position are sign flips of the returns to a long position. You *can* simply flip the sign of the returns data and redo the calculations. Alternatively, you can analyze the opposite tail of a model done in longs. For simulated data, the alpha VaR to a short position is the 1-alpha percentile of the simulated returns to a long position; the ES is the mean of the simulations that exceed that (note >= not <= that you would do for ES on a long position, since it's the upper tail behavior you are analyzing). If you use a symmetrical parametric distribution (t or Normal), the VaR and ES formulas are the same except for a sign flip on the mean.

I think there's an error in GARCHBOOT.RPF

sstats(mean) 1 ndraws %if(returns(t)<VaR(i),returns(t),%na)>>es

it should be <=

Doesn't matter. Nothing will be =.

For Parametric and simulations (using 10,000 draws with the SAME SEED), generating rolling 1-step ahead VaR and ES forecasts:

GARCH
Parametric (Normal, t, GED) distributions, both "flip-sign" and "right-tail" = SAME results.

Bootstrap: "flip-sign" and "right-tail" = SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.


GJR-GARCH
Conclusions: same as for GARCH, except,

Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results for ES only.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results for ES only.


EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.


Why would "flip-sign" and "right-tail" have different results in simulations, and which method do I use?

I assume you are doing something wrong, or not interpreting the results correctly. By sign-flip, I mean flipping the sign of the data itself:

set dlogdm = -100*log(dm/dm{1})

and letting the rest of the program stand. Unless you use a SEED instruction, the results won't be exactly the same, but will be similar (probably within +/-.05.) Note that some of the estimation methods use random numbers, which can throw off the ability of the simulator to control the random numbers used for simulations or bootstrapping.

If you are planning to look at both long and short positions on the same security, then it clearly makes sense to analyze returns to long positions and use the right tail analysis to do the short positions.

[ac_1]

I have solved a couple of the Simulation's from the aforementioned: replacing %ran(1.0) with -%ran(1.0).

Those remaining are:

GJR-GARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results (the VaR's are very similar, but the ES are on occasion different).

EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.

But as you say,

Note that some of the estimation methods use random numbers, which can throw off the ability of the simulator to control the random numbers used for simulations or bootstrapping.

Also,

If you are planning to look at both long and short positions on the same security, then it clearly makes sense to analyze returns to long positions and use the right tail analysis to do the short positions.

Yes, I agree.


For an upwardly trending series (which is left-skewed), I have generated multi-step ahead forecasts (previously mentioned models, not all completed yet ), fixed-window rolling backtests, and judging VaR's w.r.t. violation ratios, LONG's are superior to SHORT's. Does that seem reasonable?

I would also like to plot 3 fan charts for the simulations:
(1) MEAN
(2) VaR
(3) ES
(Presumably this is not possible for the non-simulated models)?

So as in GARCHBOOT.RPF (i.e. LONG investment) e.g. I have the following for 1 step, 2 steps, 3 steps, 4 steps and 5 steps ahead inclusive:

Code: Select all

 set ustandard gstart gend = u/sqrt(h)

   dofor kk = 1 2 3 4 5

   * kk-STEPS
   * ========
   *
   * span is the number of periods over which returns are to be computed.
   * ndraws is the number of bootstrapping draws
   *
   compute span=kk
   compute ndraws=ndraws
   *
   * Extend out the h series (values aren't important--this is just to get
   * the extra space).
   *
   set h gend+1 gend+span = h(gend)
   *
   dec vect returns(ndraws)
   do draw=1,ndraws
      *
      * This draws standardized u's from the ustandard series
      *
      boot entries gend+1 gend+span gstart gend
      *
      * Simulate the GARCH model out of sample, scaling up the standardized
      * residuals by the square root of the current h.
      *
      set udraw gend+1 gend+span = ustandard(entries)
      set u     gend+1 gend+span = (h(t)=hf(t)),udraw(t)*sqrt(h(t))
      *
      * Figure out the cumulative return over the span. As written, this
      * allows for the continuation of the sample mean return. If you want
      * to look at zero mean returns, take the b0 out.
      *
      sstats gend+1 gend+span b0+u>>returns(draw)

      if jj==%allocend()-WE-1; set mybootseries(kk) 1 ndraws = returns(t); * TOOS returns 1 Day to 5 Day

   end do draw

   end dofor kk

Then I can use DENSITY

density(smoothing=2.0) mybootseries(1) 1 ndraws g1Day f1Day
...
density(smoothing=2.0) mybootseries(5) 1 ndraws g5Day f5Day

And SCATTER to plot density forecasts, with vertical lines at VaR & ES, for EACH of the 1 to 5 steps ahead.


How do I use mybootseries (or otherwise) to graph 3 fan charts (just for TOOS forecasts):
(1) MEAN
(2) VaR
(3) ES
?

[TomDoan]

I have solved a couple of the Simulation's from the aforementioned: replacing %ran(1.0) with -%ran(1.0).

Those remaining are:

GJR-GARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results (the VaR's are very similar, but the ES are on occasion different).

EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.

What do you mean by "NOT THE SAME"? Can you give an example?

For an upwardly trending series (which is left-skewed), I have generated multi-step ahead forecasts (previously mentioned models, not all completed yet ), fixed-window rolling backtests, and judging VaR's w.r.t. violation ratios, LONG's are superior to SHORT's. Does that seem reasonable?

What do you mean by "superior"?

I would also like to plot 3 fan charts for the simulations:
(1) MEAN
(2) VaR
(3) ES
(Presumably this is not possible for the non-simulated models)?

Fan chart of what? A fan chart is designed to display an ordered set of ranges such as the percentiles of a single random variable.

[ac_1]

I have solved a couple of the Simulation's from the aforementioned: replacing %ran(1.0) with -%ran(1.0).

Those remaining are:

GJR-GARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results (the VaR's are very similar, but the ES are on occasion different).

EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.

What do you mean by "NOT THE SAME"? Can you give an example?

Yes, with the SAME SEED, here's a small snippet of results from a comparison backtest. They should be the SAME

EGARCH bootstrap[flip-sign], h=1 step ahead forecasts, VaR & ES
5000 1.621695895282 1.912455111422
5001 1.706472380909 1.928871658632
5002 1.498655286173 1.794614013460
5003 1.506204201672 1.693990643464
5004 1.342332726758 1.574743424737
5005 1.357867204979 1.571295443634
5006 1.347145915648 1.515423154922
5007 1.245112486839 1.468016529707
5008 1.314740247624 1.437060201684
5009 1.542121758605 1.865784772737

EGARCH bootstrap[right-tail], h=1 step ahead forecasts, VaR & ES
5000 1.802159188460 1.986904132971
5001 1.706484327695 1.939985336561
5002 1.664396928928 1.850375914635
5003 1.506159805930 1.729892780748
5004 1.492935911553 1.667239253508
5005 1.268475708382 1.547860812484
5006 1.399810419794 1.527050730573
5007 1.330595189161 1.520861642121
5008 1.314928855250 1.452064902798
5009 1.526455425847 1.771709078837

For an upwardly trending series (which is left-skewed), I have generated multi-step ahead forecasts (previously mentioned models, not all completed yet ), fixed-window rolling backtests, and judging VaR's w.r.t. violation ratios, LONG's are superior to SHORT's. Does that seem reasonable?

What do you mean by "superior"?

Superior is probably not the right word; better would be more apt, either way I meant:
LONG: Via Kupiec, violation ratio's statistically indifferent from 1 for some multiple steps ahead forecasts e.g. at h=1, at h=2.
SHORT: For h>=3 steps ahead (say) violation ratio's = 0, otherwise sometimes not near 1.

Also I have noticed, in the LONG's the simpler GARCH specifications provide better forecasts for h=2, and the more complicated for h=1.

I would also like to plot 3 fan charts for the simulations:
(1) MEAN
(2) VaR
(3) ES
(Presumably this is not possible for the non-simulated models)?

Fan chart of what? A fan chart is designed to display an ordered set of ranges such as the percentiles of a single random variable.

GARCH model's model the MEAN and VARIANCE, from which I can calculate SIGMA, hence VaR & ES.

Multiple steps ahead I would like:
- a fan chart of the MEAN
- a fan chart of VaR
- a fan chart of ES

Are you saying a fan chart is only possible for the MEAN and a fan chart for the VARIANCE, and this is not possible from mybootseries?

[TomDoan]

I have solved a couple of the Simulation's from the aforementioned: replacing %ran(1.0) with -%ran(1.0).

Those remaining are:

GJR-GARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results (the VaR's are very similar, but the ES are on occasion different).

EGARCH
Bootstrap: "flip-sign" and "right-tail" = NOT THE SAME results.
Simulation: "flip-sign" and "right-tail" = NOT THE SAME results.

What do you mean by "NOT THE SAME"? Can you give an example?

Yes, with the SAME SEED, here's a small snippet of results from a comparison backtest. They should be the SAME

EGARCH bootstrap[flip-sign], h=1 step ahead forecasts, VaR & ES
5000 1.621695895282 1.912455111422
5001 1.706472380909 1.928871658632
5002 1.498655286173 1.794614013460
5003 1.506204201672 1.693990643464
5004 1.342332726758 1.574743424737
5005 1.357867204979 1.571295443634
5006 1.347145915648 1.515423154922
5007 1.245112486839 1.468016529707
5008 1.314740247624 1.437060201684
5009 1.542121758605 1.865784772737

EGARCH bootstrap[right-tail], h=1 step ahead forecasts, VaR & ES
5000 1.802159188460 1.986904132971
5001 1.706484327695 1.939985336561
5002 1.664396928928 1.850375914635
5003 1.506159805930 1.729892780748
5004 1.492935911553 1.667239253508
5005 1.268475708382 1.547860812484
5006 1.399810419794 1.527050730573
5007 1.330595189161 1.520861642121
5008 1.314928855250 1.452064902798
5009 1.526455425847 1.771709078837

Then you are doing something wrong. There's a (very) slight difference in the estimates for asymmetric models between +sign and -sign data because the asymmetry term is given a guess value that is very slightly positive (which will be the "wrong" sign for one of the two), but that would be at worst a 3rd or 4th decimal point difference.

For an upwardly trending series (which is left-skewed), I have generated multi-step ahead forecasts (previously mentioned models, not all completed yet ), fixed-window rolling backtests, and judging VaR's w.r.t. violation ratios, LONG's are superior to SHORT's. Does that seem reasonable?

What do you mean by "superior"?

Superior is probably not the right word; better would be more apt, either way I meant:
LONG: Via Kupiec, violation ratio's statistically indifferent from 1 for some multiple steps ahead forecasts e.g. at h=1, at h=2.
SHORT: For h>=3 steps ahead (say) violation ratio's = 0, otherwise sometimes not near 1.

Also I have noticed, in the LONG's the simpler GARCH specifications provide better forecasts for h=2, and the more complicated for h=1.

Is this with exchange rate data? Since with FX data, the long v short is arbitrary. If not, maybe it's due to the problem that manifests itself above.

I would also like to plot 3 fan charts for the simulations:
(1) MEAN
(2) VaR
(3) ES
(Presumably this is not possible for the non-simulated models)?

Fan chart of what? A fan chart is designed to display an ordered set of ranges such as the percentiles of a single random variable.

GARCH model's model the MEAN and VARIANCE, from which I can calculate SIGMA, hence VaR & ES.

Multiple steps ahead I would like:
- a fan chart of the MEAN
- a fan chart of VaR
- a fan chart of ES

Are you saying a fan chart is only possible for the MEAN and a fan chart for the VARIANCE, and this is not possible from mybootseries?

What does the fan chart of any of those things mean?

[ac_1]

Then you are doing something wrong. There's a (very) slight difference in the estimates for asymmetric models between +sign and -sign data because the asymmetry term is given a guess value that is very slightly positive (which will be the "wrong" sign for one of the two), but that would be at worst a 3rd or 4th decimal point difference.

In all models, thus far, I have included:

Returns to a short position are sign flips of the returns to a long position. You *can* simply flip the sign of the returns data and redo the calculations. Alternatively, you can analyze the opposite tail of a model done in longs. For simulated data, the alpha VaR to a short position is the 1-alpha percentile of the simulated returns to a long position; the ES is the mean of the simulations that exceed that (note >= not <= that you would do for ES on a long position, since it's the upper tail behavior you are analyzing). If you use a symmetrical parametric distribution (t or Normal), the VaR and ES formulas are the same except for a sign flip on the mean.

Comparison for EGARCH-bootstrapped(1,1), SHORT's, one-step ahead:

EGARCH-bootstrapped(1,1)[flip-sign]

Code: Select all

*===============================
*
* EGARCH-bootstrapped(1,1)
*

set p = Close

set lp = log(p)
diff lp / dlp

set dlp = -dlp; * SHORT

*prin /


*seed 100
seed %today()

set y = 100.0*dlp; * MULTIPLY BY 100.0

comp WE = 1000
comp SCALE = 100.0
comp ndraws = 10000

compute tstart= 1
compute tend  = WE

compute nsteps=1


dec rect[real] mVaR(%allocend()+nsteps,%allocend()-WE)
dec rect[real] mES(%allocend()+nsteps,%allocend()-WE)


*===============================
infobox(action=define,lower=0,upper=%allocend()-WE-1,progress) "EGARCH-bootstrapped Model Backtest"
infobox(action=modify) "SHORT[flip-sign]"
*
do jj = 1, %allocend()-WE

   *
   * Estimate the EGARCH-bootstrapped(1,1) model.
   *
   garch(p=1,q=1,EXP,ASYMMETRIC,resids=u,hseries=h,print,METHOD=SIMPLEX) tstart+jj tend+jj y
   *
   if (%converged == 0); disp 'NO CONVERGENCE'


   * Pull out the coefficients for the EGARCH process
   *
   compute gmu=%beta(1),c=%beta(2),a=%beta(3),b=%beta(4),d=%beta(5)
   *
   * Estimation range, which is also the source range for bootstrapped residuals
   *
   compute gstart=%regstart(),gend=%regend()
   *
   set stdu = %resids/sqrt(h)
   *
   compute ndraws=ndraws
   compute nsteps=nsteps
   *
   compute bstart=gend+1,bend=gend+nsteps
   set h bstart bend = %na
   set x bstart bend = %na
   dec series[vect] hdraws xdraws
   gset hdraws bstart bend = %zeros(ndraws,1)
   gset xdraws bstart bend = %zeros(ndraws,1)
   do draw=1,ndraws
      boot entries bstart bend gstart gend
      *
      * This is way the asymmetric EGARCH instruction is parameterized in
      * RATS. Nelson's original formulation is equivalent, but the c
      * coefficient has a different meaning. The recursion for the variance
      * uses the standardized residuals only.
      *
      set stdu bstart bend = su=stdu(entries(t)),$
                h=exp(c+b*log(h{1})+a*abs(stdu{1})+d*stdu{1}),$
                 x=gmu+sqrt(h)*su,su
      *
      * Replace x by its accumulation
      *
      acc x bstart bend
      do t=bstart,bend
         compute hdraws(t)(draw)=h(t)
         compute xdraws(t)(draw)=x(t)
      end do t

   end do draw


   *===============================
   do tt=bstart,bend

      compute var=%fractiles(xdraws(tt),||.01||)(1)
      sstats(mean) 1 ndraws %if(xdraws(tt)(t)<=var,xdraws(tt)(t),%na)>>es

      disp -var -es

      comp [rect] mVaR(tt,jj) = -var
      comp [rect] mES(tt,jj) = -es

   end do tt


  INFOBOX(CURRENT=jj)
end do jj
*
infobox(action=remove)


*===============================*===============================
* gather VaR forecasts
dec vect[real] mmVaR_1(%allocend()-WE)

do kk = 1, %allocend()-WE
   comp [vect] mmVaR_1(kk) = mVaR(1002+kk-1,kk)
end do kk


* gather ES forecasts
dec vect[real] mmES_1(%allocend()-WE)

do kk = 1, %allocend()-WE
   comp [vect] mmES_1(kk) = mES(1002+kk-1,kk)
end do kk


*===============================*===============================
* ALL OOS
* =======

* sVaR SERIES
* -----------
set sVaR_1 WE+1+1 %allocend()+1 = mmVaR_1(t-WE-1)

prin / sVaR_1


* negsVaR SERIES
* --------------
set negsVAR_1 WE+1+1 %allocend()+1 = -sVaR_1/SCALE

prin / negsVaR_1


* sES SERIES
* ----------
set sES_1 WE+1+1 %allocend()+1 = mmES_1(t-WE-1)

prin / sES_1

EGARCH-bootstrapped(1,1)[right-tail]

Code: Select all

*===============================
*
* EGARCH-bootstrapped(1,1)
*

set p = Close

set lp = log(p)
diff lp / dlp

*prin /


*seed 100
seed %today()

set y = 100.0*dlp; * MULTIPLY BY 100.0

comp WE = 1000
comp SCALE = 100.0
comp ndraws = 10000

compute tstart= 1
compute tend  = WE

compute nsteps=1


dec rect[real] mVaR(%allocend()+nsteps,%allocend()-WE)
dec rect[real] mES(%allocend()+nsteps,%allocend()-WE)


*===============================
infobox(action=define,lower=0,upper=%allocend()-WE-1,progress) "EGARCH-bootstrapped Model Backtest"
infobox(action=modify) "SHORT[right-tail]"
*
do jj = 1, %allocend()-WE

   *
   * Estimate the EGARCH-bootstrapped(1,1) model.
   *
   garch(p=1,q=1,EXP,ASYMMETRIC,resids=u,hseries=h,print,METHOD=SIMPLEX) tstart+jj tend+jj y
   *
   if (%converged == 0); disp 'NO CONVERGENCE'


   * Pull out the coefficients for the EGARCH process
   *
   compute gmu=%beta(1),c=%beta(2),a=%beta(3),b=%beta(4),d=%beta(5)
   *
   * Estimation range, which is also the source range for bootstrapped residuals
   *
   compute gstart=%regstart(),gend=%regend()
   *
   set stdu = %resids/sqrt(h)
   *
   compute ndraws=ndraws
   compute nsteps=nsteps
   *
   compute bstart=gend+1,bend=gend+nsteps
   set h bstart bend = %na
   set x bstart bend = %na
   dec series[vect] hdraws xdraws
   gset hdraws bstart bend = %zeros(ndraws,1)
   gset xdraws bstart bend = %zeros(ndraws,1)
   do draw=1,ndraws
      boot entries bstart bend gstart gend
      *
      * This is way the asymmetric EGARCH instruction is parameterized in
      * RATS. Nelson's original formulation is equivalent, but the c
      * coefficient has a different meaning. The recursion for the variance
      * uses the standardized residuals only.
      *
      set stdu bstart bend = su=stdu(entries(t)),$
                h=exp(c+b*log(h{1})+a*abs(stdu{1})+d*stdu{1}),$
                 x=gmu+sqrt(h)*su,su
      *
      * Replace x by its accumulation
      *
      acc x bstart bend
      do t=bstart,bend
         compute hdraws(t)(draw)=h(t)
         compute xdraws(t)(draw)=x(t)
      end do t

   end do draw


   *===============================
   do tt=bstart,bend

      compute var=%fractiles(xdraws(tt),||.99||)(1); * SHORT[right-tail]
      sstats(mean) 1 ndraws %if(xdraws(tt)(t)>=var,xdraws(tt)(t),%na)>>es; * SHORT[right-tail]

      disp var es; * SHORT[right-tail]

      comp [rect] mVaR(tt,jj) = var; * SHORT[right-tail]
      comp [rect] mES(tt,jj) = es; * SHORT[right-tail]

   end do tt


  INFOBOX(CURRENT=jj)
end do jj
*
infobox(action=remove)


*===============================*===============================
* gather VaR forecasts
dec vect[real] mmVaR_1(%allocend()-WE)

do kk = 1, %allocend()-WE
   comp [vect] mmVaR_1(kk) = mVaR(1002+kk-1,kk)
end do kk


* gather ES forecasts
dec vect[real] mmES_1(%allocend()-WE)

do kk = 1, %allocend()-WE
   comp [vect] mmES_1(kk) = mES(1002+kk-1,kk)
end do kk


*===============================*===============================
* ALL OOS
* =======

* sVaR SERIES
* -----------
set sVaR_1 WE+1+1 %allocend()+1 = mmVaR_1(t-WE-1)

prin / sVaR_1


* negsVaR SERIES
* --------------
set negsVAR_1 WE+1+1 %allocend()+1 = -sVaR_1/SCALE

prin / negsVaR_1


* sES SERIES
* ----------
set sES_1 WE+1+1 %allocend()+1 = mmES_1(t-WE-1)

prin / sES_1

Is this with exchange rate data? Since with FX data, the long v short is arbitrary. If not, maybe it's due to the problem that manifests itself above.

No, an equity index. The upward trending results in a positive mean, negative skewness as there are large downwards movements. Why the poor performance in the SHORT's w.r.t. violation ratio's (VaR is large - bad sigma forecast) compared to the LONG's, across the models?

With FX data I'd expect similar performance between the LONG's and SHORT's --- there is no obvious general direction or asymmetry.

[TomDoan]

Superior is probably not the right word; better would be more apt, either way I meant:
LONG: Via Kupiec, violation ratio's statistically indifferent from 1 for some multiple steps ahead forecasts e.g. at h=1, at h=2.
SHORT: For h>=3 steps ahead (say) violation ratio's = 0, otherwise sometimes not near 1.

I'm confused about what you're saying. You're finding that the short positions rarely hit the trigger? Why would that be surprising?

[ac_1]

Superior is probably not the right word; better would be more apt, either way I meant:
LONG: Via Kupiec, violation ratio's statistically indifferent from 1 for some multiple steps ahead forecasts e.g. at h=1, at h=2.
SHORT: For h>=3 steps ahead (say) violation ratio's = 0, otherwise sometimes not near 1.

I'm confused about what you're saying. You're finding that the short positions rarely hit the trigger?

Correct, although simulations for SHORT at h=1 are more near vr=1 than non-simulations (especially bootstraps, but in theory MC-simulated = analytical for large ndraws). I have not done EGARCH multi-step ahead simulations as per previous comments for comparison SHORT one-step ahead.

Why would that be surprising?

I am not certain.

[TomDoan]

Regarding the differences between the estimates with long and short returns, it turns out that it's possible for the asymmetric models to have multiple modes. Because the standard initial conditions use a positive guess value for D, which is the "wrong" sign for sign flipped data, the models in the different signs can go to different modes. As is suggested in the manual, you are better off estimating the model through the full data set and feeding the full sample estimates in as guess values. (Again, as described in the manual, there are issues with doing rolling estimates in GARCH models as there are relatively few "influential" observations). The example below shows a difference between the estimates with long and short returns for a data range. It then shows estimates over the full sample (which because it has more observations overall and particularly more observations that dominate the log likelihood), and feeds the overall estimates in as guesses for the shorter range.

Code: Select all

all 6237
open data g10xrate.xls
data(format=xls,org=columns) / usxjpn

set close = usxjpn

set p = Close
set dlp = 100.0*log(p/p{1})
seed %today()
set y = dlp
set my = -dlp
compute bstart=100,bend=bstart+999
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs) bstart bend y
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs) bstart bend my
*
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs) / y
compute initbeta=%beta
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs,initial=initbeta) bstart bend y
*
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs) / my
compute initbeta=%beta
garch(p=1,q=1,exp,asymm,pmethod=simplex,method=bfgs,initial=initbeta) bstart bend my

[ac_1]

(A) I have used right-tail analysis in all SHORT models.


(B)

Value-at-Risk
In addition to having calculated the academic coverage tests:
- (i) Kupiec (unconditional coverage)
- (ii) Christoffersen (conditional coverage)
there is the industry standard "Zone" or traffic light system, for VaR, as described in:

"Basel Committee on Banking Supervision, Supervisory Framework for the Use of 'Backtesting' in Conjunction with the Internal Models Approach to Market Risk Capital Requirements", January, 1996.
https://www.bis.org/publ/bcbs22.htm

In RATS, there is no CDF binomial distribution function, and as I may be using different parameter values for N and p, to replicate Table 2 (in the above which has N=250, p=0.01), I have used the Normal approximation to the binomial with continuity correction 0.5.

Code: Select all

comp N = 250; * 500, 750, 1000, 1250, 1500, 1750, 2000
comp p = 0.01; * 0.025, 0.05

* The Normal approximation to the Binomial (asymptotic Normal distribution) is used
* to compute the Cumulative Probabilities
comp mu = (N * p)
comp sigma = sqrt( N * p * (1-p) )

comp xx=%seqa(0.5,1.0,11); * continuity correction 0.5
disp xx

dec vect f(%size(xx))
ewise f(j)=%cdf((xx(j)-mu)/sigma)
disp f

But, those cumulative probabilities are not exact as in Table 2. How do I calculate exact values, or does the Normal approximation suffice including continuity correction?


In my results I want to add an additional column 'Basel Zone Approach to VaR' with entries Green, Yellow, Red; based on the total number of breaches/triggers in the LAST rolling backtest OOS period, for EACH multi-step ahead forecast e.g. for h=1 step, for h=2 step, for h=3 step, etc

Although, on initial readings, the "Zone" system is not as 'powerful' as the academic coverage tests e.g. there can be rejections of the null
- (i) VaR model correctly specified
- (ii) independence
for violation ratios > 0

whereas the "Zone" system says a total violation = 0 to 4, (N=250, p=0.01) is acceptable of a Green model.

The "Zones" defined as:
Green if PHI(z) < 0.95;
Yellow if 0.95 ≤ PHI(z) < 0.9999;
Red if PHI(z) ≥ 0.9999.


Expected Shortfall
I'd also like to do similar for ES as in the following:

COSTANZINO N and CURRAN M (2018) A simple traffic light approach to backtesting expected shortfall, Risks, 6(1), 2
An earlier version: https://papers.ssrn.com/sol3/papers.cfm ... id=2603976

I want to generate (ideally exact, but that's complicated and involves root-finding) numbers as in Table 2, N=250, p=0.025, again using Normal approximation to the binomial, based on equation (3.13) in the paper,

comp mu = (0.5 * N * p)
comp sigma = sqrt( N * p * ( (4 - (3 * p))/12 ) )

etc

Does that seem reasonable?

[TomDoan]

With p=.01, the Poisson approximation to the binomial is MUCH better than the Normal. You can also do an exact calculation using the %BETAINC (incomplete beta) function:

compute p=.01,n=250
do i=0,10
   ?i %poisson(n*p,i) %betainc(1-p,n-i,i+1)
end do i

though there is no practical difference between the Poisson approximation and the exact calculation.

[TomDoan]

Why would you need "tables"? In practice, you have the number of observations and the number of breaches. The table is just an example for a paper.

[ac_1]

With p=.01, the Poisson approximation to the binomial is MUCH better than the Normal. You can also do an exact calculation using the %BETAINC (incomplete beta) function:

compute p=.01,n=250
do i=0,10
   ?i %poisson(n*p,i) %betainc(1-p,n-i,i+1)
end do i

though there is no practical difference between the Poisson approximation and the exact calculation.

Thanks - Yes, it's a one liner:

report(atrow=5,atcol=6,fillby=cols) %if(ntrigger_1>=10.0,"Red",%if(ntrigger_1<=4.0,"Green","Yellow"))

How to proceed with the ES Traffic Light?