SV-AR(1) model

[ac_1]

Hi Tom,

I want to backtest and generate multistep ahead VaR and ES forecasts using the classic SV-AR(1) model, like viewtopic.php?t=3645, for financial returns.

I have no experience in SV type models but have read some of the literature and used AI for explanations.

Here's a short description

The model is:

Observation (returns):
y(t) =  exp(0.5*h(t)) * eps(t) , eps(t)∼IID N(0,1)

State (log-volatility):
h(t) =  mu  +  phi (h(t−1) - mu) + sigma(eta)*eta(t) , eta(t)∼IID N(0,1)

with |phi|<1 for stationarity. Typically h(0) ∼ N(mu, sigmasq(eta)/(1-phi^2))

And unconditional facts (checks)

• h(t) ∼ N(mu, sigmasq(eta)/(1-phi^2))

• E[y^2(t)] = E[exp(h(t))] = exp(mu + 0.5*(sigmasq(eta)/(1-phi^2)))

• Returns are conditionally normal but marginally heavy-tailed.

Estimation:
The SV-AR(1) model is a nonlinear, non-Gaussian state-space model. Therefore, use approximations/simulations as the exact likelihood has no closed form.


How in RATS?

Amarjit

[TomDoan]

https://estima.com/webhelp/topics/svrpf.html

[ac_1]

Thanks.

Here's an attempt to estimate and generate 1-step ahead VaR and ES forecasts, SV State-Space model, using fixed rolling windows. I'm ultimately aiming for multistep ahead: h=2, h=3, ... , h=T, saving the hth forecast, as with SKIPSAVE in FORECAST instruction.

Do I need to loop round the DLM instruction, because DLM's yhat is the 1-step ahead forecasts?

The following probably has errors.

Code: Select all

*===============================
open data xrates.xls
data(format=xls,org=columns) 1 946 usxuk usxger usxjpn usxsui


*===============================
set retsq = 100.0*((log(usxjpn{0}/usxjpn{1}))**2.0)

set dlp = 100.0*log(usxjpn{0}/usxjpn{1})

set dlp = -dlp; * would give you the return to a long position of $100 US

set y = dlp

prin /

disp %allocend()


*===============================
comp WIN = 750

compute rstart= 1
compute rend  = WIN


*===============================
*
* meanx2=mean of log chi-square,varx2=variance of log chi-square
*
compute meanx2=%digamma(0.5)-log(0.5)
compute varx2 =%trigamma(0.5)


*===============================
infobox(action=define,lower=0,upper=%allocend()-WIN-1,progress) "SV Model Backtest: JPYUSD"
infobox(action=modify) "LONG"
*
do jj = 0, %allocend()-WIN

   *
   * The "gamma" and "phi" variables are very highly correlated when
   * phi is near 1, which makes estimation by general hill-climbing
   * procedures somewhat tricky. Instead, we reparameterize this to
   * use gammax=gamma/(1-phi) in place of gamma.
   *
   * Remove any deterministic components (in this case, just the CONSTANT).
   *
   linreg dlp rstart+1+jj rend+1+jj
   # constant
   set demean = %resids
   *
   nonlin phi sw gammax
   set ysq rstart+1+jj rend+1+jj = log(demean^2)-meanx2
   *
   * Get initial guess values from ARMA(1,1) model
   *
   boxjenk(ar=1,ma=1,constant,print,MAXL) ysq rstart+1+jj rend+1+jj
   *
   * PHI is taken directly as the AR(1) coefficient The variance SW is backed out by
   * matching first order autocorrelations in the MA term. gammax is chosen as the
   * mean of the ysq series. (BOXJENK sets %MEAN to the mean of the dependent
   * variable).
   *
   compute phi=%beta(2),sw=-phi*varx2*(1+%beta(3)^2)/%beta(3)-(1+phi^2)*varx2
   compute sw=%if(sw<0,.1,sw)
   compute gammax=%mean
   *
   * Estimate the unconstrained model
   *
   dlm(method=bfgs,sw=sw,sv=varx2,y=ysq,type=filter,c=1.0, $
   sx0=sw/(1-phi^2),x0=gammax,a=phi,z=gammax*(1-phi), $
   yhat=yhat,svhat=fhat) rstart+1+jj rend+1+jj states


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


*===============================
set fy WIN+1+1 %allocend()+1 = %scalar(yhat(t))
set efy WIN+1+1 %allocend()+1 = exp(fy)

set VaR WIN+1+1 %allocend()+1 = -%invnormal(.01) * sqrt(efy)
set ES WIN+1+1 %allocend()+1 = %density(%invnormal(.01))/(.01) * sqrt(efy)

print / retsq efy VaR ES

[TomDoan]

The log volatility has a simple extrapolation (it's just an AR(1) process) out-of-sample. But that would be out-of-sample inside the rolling windows loop, not outside of it. Your "yhat" is going to keep getting overwritten as you moving through the sample---it sets the value for each data point, not just the last one (and doesn't go out of sample at all).

[ac_1]

The log volatility has a simple extrapolation (it's just an AR(1) process) out-of-sample. But that would be out-of-sample inside the rolling windows loop, not outside of it. Your "yhat" is going to keep getting overwritten as you moving through the sample---it sets the value for each data point, not just the last one (and doesn't go out of sample at all).

So, how do I generate h-step ahead VaR and ES forecasts using fixed rolling windows, SV State-Space model?

And the set-up should be like

Code: Select all

set p = 1.0/usxjpn

set lp = log(p)
diff lp / dlp
set dlp = -dlp; * would give you the return to a long position of $100 US

[TomDoan]

As I said, it's a simple AR(1) extrapolation:

set(first=states(t)(1)) loghfore rend+1+jj rend+nn+jj = phi*loghfore{1}+gammax*(1-phi)

where nn is the number of steps that you want.

In general, you forecast a state-space model by Kalman filtering beyond the end of the data, but that's overkill in this case.

[ac_1]

As I said, it's a simple AR(1) extrapolation:

set(first=states(t)(1)) loghfore rend+1+jj rend+nn+jj = phi*loghfore{1}+gammax*(1-phi)

where nn is the number of steps that you want.

In general, you forecast a state-space model by Kalman filtering beyond the end of the data, but that's overkill in this case.

Thanks!

At the moment, I have put nn=1, for 1-step ahead only.


With DLM METHOD=SOLVE, there is no display of parameters unlike other METHOD options. Why?

I have run with my data: financial returns on an equity index, I am not getting "clean" line risk forecasts: "blotchy/jittery" vs. "clean" appearance throughout the backtest (unlike in GARCH-family where conditional variance is deterministic, and hence so are the VaR/ES forecast's). Those "blotchy/jittery" SV forecasts are typically in turbulent periods compared to calm periods "clean" line(s). Although, my SV violation ratio's, Kupiec and Christoffersen are very good.

I have asked AI as to why "blotchy/jittery" and received acceptable reasons. The question is how best to handle "blotchy/jittery" w.r.t. RATS estimation, which stems from the SV state-space methodology and loghfore?

As per usual:

Code: Select all

set sVaR_1 WIN+1+1 %allocend()+nn = -%invnormal(.01) * sqrt(efy_1)
set sES_1 WIN+1+1 %allocend()+nn = %density(%invnormal(.01))/(.01) * sqrt(efy_1)

Also, relaxation of normality to fat-tails e.g. t-dist would be appropriate - somewhere?

[TomDoan]

METHOD selects the estimation method used by DLM. If you choose any of these other than SOLVE, it is assumed that there are free parameters to be estimated, which need to be defined ahead of time with NONLIN.

There's nothing to estimate, therefore nothing to report.

In your AI "research" have you run across anyone who thought the SV models would be useful in this context? I've always seen SV models as being of academic rather than practical interest (because of the "inlier" problem).

[ac_1]

METHOD selects the estimation method used by DLM. If you choose any of these other than SOLVE, it is assumed that there are free parameters to be estimated, which need to be defined ahead of time with NONLIN.

There's nothing to estimate, therefore nothing to report.

Ahh - I didn't see that.

In your AI "research" have you run across anyone who thought the SV models would be useful in this context? I've always seen SV models as being of academic rather than practical interest (because of the "inlier" problem).

No. inlier problem: small returns observed during periods of high latent volatility ?!?

[TomDoan]

Inliers are covered in the SV.RPF discussion. They are the main technical issue in dealing with SV models. The quick and dirty fix is the change the data to avoid them. That's not exactly what you want to be doing in a practical setting.

[ac_1]

Inliers are covered in the SV.RPF discussion. They are the main technical issue in dealing with SV models. The quick and dirty fix is the change the data to avoid them. That's not exactly what you want to be doing in a practical setting.

I agree the data should not be changed. So, how best to progress?

[TomDoan]

Recognize that maybe this isn't designed to do what you intend.

[ac_1]

Recognize that maybe this isn't designed to do what you intend.

Alright. Looking at the forecast lines again they are not too bad w.r.t. "blotchy/jittery" but they are not as "clean" in appeareance as (G)ARCH-family and simpler risk algo's. How would SV (Bayesian) Gibb's Sampling estimation compare? Or please suggest other risk algo's I may try in RATS. Thanks.

[tclark]

In the event this helps:

1. In macro forecasting, Bayesian vector autoregressions with stochastic volatility are used commonly and work well. The replication package for a recent paper of mine published in JMCB has RATS code for a BVAR-SV (procedure file is BVAR.SV.src). This is more than you want for the univariate problem you evidently have but the code shows to form proper forecasts (posterior predictive distributions in the Bayesian setting) that involve taking draws of shocks to the volatility process and iterating volatility forward, etc. It could be stripped down to the univariate setting. The paper is at https://onlinelibrary.wiley.com/doi/10.1111/jmcb.13121. From that page, click on the indicator for "supporting information," and there you will see links for an online appendix and a .zip file with the main code and data. (https://onlinelibrary.wiley.com/action/ ... onData.zip)

2. FWIW: In the macro setting with SV, in my experience, "in-liers" have never shown up as a clear problem in practice. Of course, this setting could be quite difference from finance applications. In macro, I and others are commonly working with data written as annualized percentage points (e.g., 400 * log difference of quarterly GDP). Following Omori, et al (J. of Econometrics 2007), in the SV estimation, to be sure an "in-lier" does not cause estimation to blow up, the measurement equation uses log(y(t)^2 + c), with the offset constant c set to 0.0001.

[ac_1]

In the event this helps:

1. In macro forecasting, Bayesian vector autoregressions with stochastic volatility are used commonly and work well. The replication package for a recent paper of mine published in JMCB has RATS code for a BVAR-SV (procedure file is BVAR.SV.src). This is more than you want for the univariate problem you evidently have but the code shows to form proper forecasts (posterior predictive distributions in the Bayesian setting) that involve taking draws of shocks to the volatility process and iterating volatility forward, etc. It could be stripped down to the univariate setting. The paper is at https://onlinelibrary.wiley.com/doi/10.1111/jmcb.13121. From that page, click on the indicator for "supporting information," and there you will see links for an online appendix and a .zip file with the main code and data. (https://onlinelibrary.wiley.com/action/ ... onData.zip)

2. FWIW: In the macro setting with SV, in my experience, "in-liers" have never shown up as a clear problem in practice. Of course, this setting could be quite difference from finance applications. In macro, I and others are commonly working with data written as annualized percentage points (e.g., 400 * log difference of quarterly GDP). Following Omori, et al (J. of Econometrics 2007), in the SV estimation, to be sure an "in-lier" does not cause estimation to blow up, the measurement equation uses log(y(t)^2 + c), with the offset constant c set to 0.0001.

Hi Todd,

Thanks for the information.

As you say:
Andrea Carriero, Todd E. Clark, and Massimiliano Marcellino, "Capturing Macroeconomic Tail Risks with Bayesian Vector Autoregressions," Journal of Money, Credit, and Banking, forthcoming.
is more than I want for the univariate setting.

My aim is to backtest and generate multistep ahead VaR and ES forecasts using the classic SV-AR(1) model, or a variation, to compare with simpler risk algo's and (G)ARCH-family, within a univariate setting. I am using DAILY financial returns, hence require fast efficient estimation/forecasts. DLM suffices, unfortunately however produces "unclean" line(s), in places.

Cheers,
Amarjit