Thursday, November 3, 2011

Periodicity for risk statistics (and other measures)

A client recently asked about the appropriateness of reporting volatility and tracking error, for one and three month time periods, based on daily values. In addition, whether the results should be annualized. He was curious about the "best practices" for reporting these values.

Volatility (presumably, standard deviation) requires at least 30 observations to have validity, and so a monthly statistic, based on the roughly 22 trading days in the month, wouldn't quite make it, but it's close; clearly the three-month period would. But, this begs a bigger question: the appropriateness of using daily values.

I would say that the "rule of thumb" is to only use monthly returns. And why is this? Because daily provide too much "noise." Just consider the past week's DJIA returns, where we've seen 100+ point movements up and down, allegedly in response to the economic crisis in Greece. Monthly returns smooth these gyrations out, into meaningful numbers. Quarterly would be arguably better, but to achieve the requisite 30 observations would require 7 1/2 years: a bit long for most folks.

As for annualizing the monthly or quarterly values, the "rule" is not to annualize returns for periods less than a year; I would think the same applies to risk stats. And, if your intent is to compare them to a monthly or quarterly return, why not have it represented in the same manner?

Disagree? Have different thoughts? Please chime in!

7 comments:

  1. I just put up a post http://www.portfolioprobe.com/2011/11/03/variability-of-volatility-estimates-from-daily-returns/ with pictures of the variability of some volatility estimates.

    I think annualizing volatility is the better thing to do -- it is a different question than annualizing returns.

    I also think that using daily data is the better thing to do. It is common to think that you get more "noise" with daily data, but noise is what you want to measure. The more of it you have the better your estimate (of noise) will be.

    ReplyDelete
  2. Pat, this is excellent, thanks!

    Can you do an analysis of three years, (a) using daily data, and (b) monthly? I did some work on this a few years back, and saw very different results. I'm curious what you'll find. Thanks!

    ReplyDelete
  3. Yes, that's not hard to do. I'll do it over the weekend and report back.

    ReplyDelete
  4. Surely it depends on what is the interval in which you are interested? If you use shorter intervals, say monthly returns and you want to estimate the annual volatility, the conventional transformation is to multiply the monthly standard deviation by the square root of 12. But this transformation is only correct if there is no serial correlation in the monthly returns. For some assets, especially thinly traded assets, there is substantial auto-correlation and the conventional transformation will severely under-estimate the annual volatility. The appropriate demonstration of this effect would be to estimate the annual volatility using the daily, weekly, monthly, quarterly and annual returns. Charles Ward, ICMA Centre, Henley Business School, Reading.

    ReplyDelete
  5. Dave,

    Your skepticism seems to have been well-founded. Here is a look at volatility from daily versus monthly data:
    http://www.portfolioprobe.com/2011/11/08/the-mystery-of-volatility-estimates-from-daily-versus-monthly-returns/

    ReplyDelete
  6. Patrick,

    Thanks for doing the research; much appreciated!

    Dave

    ReplyDelete
  7. Another way that daily is not always better than monthly: If you asset weight daily returns every day instead of monthly, you essentially end up with the aggregate method - completely defeating the purpose of choosing to asset weight!

    Regarding the periodicity of risk stats, I would think that monthly may be more appropriate for client reporting, but daily over a shorter period (and probably not annualized) might be better for helping [day] traders make investment decisions.

    ReplyDelete

Note: Only a member of this blog may post a comment.