Using Realized Kernels to Estimate Volatility from Intraday Data

# How to use a realized kernel?


# How to use a realized kernel?












I've read that realized kernels are the thing to use for calculating daily volatility from high-frequency data. So I've got minute data, how do I actually use such a kernel? Will it give me minute-ly volatility, do I have to normalize it somehow? Also, what data do I feed it - minute data since the start of the trading day, one day's worth of data, all historical data I have until this point, or something else?

## Answer by lehalle (score 9, accepted)

https://quant.stackexchange.com/a/10432

The use of kernels to estimate volatility using intraday data is "nothing more" than combining:

- intraday volatility estimation

- kernel smoothing

Thus you have to take care about the "usual pits" of these two approaches.

Intraday volatility estimation. I hope you know the "signature plot" effect. Of course if you use the proper estimation method, it should take care of if, but just in case you should check that you do not suffer from it.

Kernel smoothing. You will have to tune the time scale of your kernel. Of course theoretical papers like Designing Realized Kernels to Measure the ex post Variation of Equity Prices in the Presence of Noise do not really have to do it since their results are asymptotic but real life is not. Moreover you may know that since you will have at date $t$ information of previous dates in your estimator $\hat\sigma_t$, if you multiply it by a statistic from the past $X_{t-\delta t}$ you will obtain a "trace" of the correlation between $X$ and $\sigma$ (i.e. somewhere inside $\mathbb{E}(\hat\sigma_t \cdot X_{t-\delta t})$ you have a term in $\mathbb{E}(K(\delta t) \cdot \sigma_{t-\delta t} \cdot X_{t-\delta t})$, where $K$ is your kernel). It may add biais if you use your kernel volatility estimate to build other estimators. And not only for multiplications.

## Answer by Shalom Craimer (score 3)

https://quant.stackexchange.com/a/10428

Using a realized kernel for calculating volatility will give you results in the same resolution as the data you feed them. So if you feed them minute-by-minute data, then the volatility will be calculated minute-by-minute. What that really means is that only once per minute will you have a good estimate of the volatility of whatever asset you're looking at. The other 99.99% of the the time, the market might introduce changes which may throw that estimate out of the window.

If you're not interested in high-frequency volatility estimates, then it's a completely different matter. You'd be better off trying to pre-filter your data before feeding it to the realized kernel. The goal there is to reduce the noise so that the remaining signal matches up to the frequency you wish to use. So if you want to have a day-by-day estimate based on minute-by-minute data, you can probably get a pretty good result by boiling down the minute-by-minute event data into a hour-by-hour events.

I'm not familiar with such algorithms that give weight to temporal heuristics such as day-of-week or month-in-year or year-by-year cycles. Unless you know you're using such an algorithm, then there's no reason to feed more than a just today's data if you want an estimate for the current day. If anything, adding more data only causes the estimate to become duller, giving you only week- or month-accurate estimates.

If you don't weight your data at all, then feeding in all your historical data might give you a volatility estimate for the next decade, but it will be off by a mile in the short term.