We teach how to annualize rates of return in our **Fundamentals of Performance Measurement **course. Invariably, someone will ask whether using trade days might be better than calendar days. I normally give a brief explanation as to why it wouldn’t, and then move on.

## But a funny thing happened recently:

While conducting a “non-GIPS” verification for a client, I discovered someone who uses trade days when annualizing rates of return. I found this quite curious, and so gave this topic more thought than before.

My first question was “**why?**” Interestingly, no clear or decisive answer could be given; perhaps it *just seemed like the right thing to do at the time*. Whoever was responsible for making the decision apparently is long gone, and no record of its basis apparently exists.

Let’s consider this topic a bit and see if we can decide whether annualizing rates of return with trading days rather than calendar days would work okay.

## Before we proceed, let’s ensure that we understand *why *this is even a topic

When annualizing periods, especially ones that involve ** from **and

*dates that aren’t month-ends,*

**to****we need to know the number of days for the period**[as an aside, some insist on using days even when whole months are involved, since the number of days from one month to another can vary; this is an interesting idea, worthy of further reflection, but not today]. A formula we can use to annualize is:

R_{Cum }is the cumulative return for the period. We’re raising it (plus one) to the 365/T power, where “T” is the total number of days in the period. [As a further aside, the use of 365 is a totally different topic, as we might want to adjust it for leap years, something I’ve briefly addressed.]

If you’re using trade days, then instead of 365, you would use the number of trading days in the year: something like 252.

## Here are the issues I have raised regarding this idea for annualizing rates of return

**There are several:**

**Why?**I think it’s safe to say that**the standard “convention”**is to use calendar days. And so, to switch to trading days for annualizing rates of return must be based on some belief that it’s better; what is it? None that I could discover.**The number of trading days per year changes from year-to-year**: How will you handle these switches? What number do you then use in your “power”?**The number of trading days can vary from region to region, country to country:**While we generally agree that there are 365 days in a year, except for leap years when one is added, there is no agreement to the number of trade days across countries. This is partly because we celebrate different holidays. For example, in the USA Martin Luther King’s birthday, as well as Presidents’ Day, are holidays, while in the UK they celebrate Boxing Day. If you have a global portfolio, how will you handle these variations across countries?**The number of trading days can vary within a country, depending on who’s doing the trading:**In the USA, there are times when the banks are closed while the stock exchange remain open (and vice versa); as a result, folks who work for a bank may have fewer or more trading days than those who work for an asset manager; will there be differences within the system to account for this?**How will you handle half-days?**In the USA, there are times when the exchange closes at noon: will this be a half day?**How do you handle dynamic changes to the number?**Following 9/11, the stock exchanges in the States closed for a few days, thus reducing the number of trading days: do we alter the original number? Also, some countries will introduce “banking holidays”: will their introduction result in a change in the original number for the year?**Income accrues over weekends and holidays; shouldn’t these days be included with the annualization?**Even though we may not be trading, income accrues. Why would this be ignored? The return includes these accruals.**What about inception-to-date – how do you determine the number of days?**Imagine if you’re deriving a return for someone whose inception date was, for example, June 8, 1997, and you’re reporting to them through July 15, 2015. How many days are there in the intervening period? The number of calendar days is quite easy to derive: Excel will even do the counting for you. But coming up with the number of trading days? That seems like a lot of work.**If you thought leap year was bad enough already…**There is no standard way to handle leap years. However, whether you’re using 365, 365.25, or 366 as your standard term in your equation, the difference will be slight. As you lower the number, however, the impact will be greater.**How do you explain differences in results?**I’ve done some preliminary testing, and for the most part I get the same answer. I did a test for inception-to-date and had a one basis point difference, which isn’t huge, but it’s still a difference. More testing might reveal greater differences. If a vendor has adopted what we believe is a much more difficult way to do annualization, they have to have a good reason: what is it?

I’m a bit excited to have learned of this, as it gives us a chance to consider the possible merits of using trading days. I’m open to your thoughts. Please chime in! Should we have a RULE that says ALWAYS use calendar days? I suspect, “yes.” Let me know what YOU think!

Hi David, I have had a similar conversation with a few managers in the past and have come to the same conclusion that calendar days is the most appropriate way to annualize returns. Trade days/hours are just opportunities to invest or change allocations. At the end of the trading day money is tactically invested and ownership is established. Just because the market is closed does not mean investments are not accruing income or company operations come to a halt. Using trading days does not correctly reflect ownership.

Patrick, thanks for your comment!

I have a strong preference for trading days.

To answer your questions:

1. Why shouldn’t someone use calendar days? Because it would disingenuous to assume that a stock, or bond, or any other instrument has 5 days (weekdays) of volatility and two days (weekends) of zero volatility. Just as we acknowledge that real estate volatility, due to its infrequent trading, is understated if we use traditional methods, using calendar days, with 5 days of volatility and 2 days of zero volatility) would understate the instruments risk profile.

My response assumes the instruments being discussed are relatively frequently traded securities such as stock and bonds.

2.The number of trading days per year changes from year-to-year – Simple, you would only have a return on a trading day. If there is no trading, the day doesn’t count; if there is trading the day counts. Simply add up the number of days.

3. Reasonable question, but if you’re going to the step of breaking a portfolio into geographical locations to do risk analysis, determining a procedure for different bank holidays is very small problem. And to your point that using 365 days versus trading days only resulted in a .01 difference, the difference between different countries days would be much smaller.

4. See answer #2. If trading occurs, then the day counts.

5. See answer #2. If trading occurs, then the day counts.

6. See answer #2. If trading occurs, then the day counts.

7. For equities, it is a non issue. Stocks dont go ex dividend on a non trading day. For fix income, the issue appears to be extremely minor and if you wanted to sell the instrument you couldnt because there is no trading.

8. See answer #2. If trading occurs, then the day counts.

9. See answer #2. If trading occurs, then the day counts.

10. I would propose to put the question back to you, how do you explain the differences. The phrasing of the question presumes calendar days should be the default and trading days needs defense.

Andrew,

Very sorry for the long delay in responding. The software usually alerts me when comments arrive; however, there were several for which I wasn’t notified, and I only yesterday learned of this, and so am going through the pile now, responding and posting.

Your reply seems to miss my point and the context in which calendar days (rather than trade) should be applied: we’re only talking about in the calculation for annualizing performance. Volatility isn’t a factor here. To suggest that you only take the trade days into consideration when you actually trade is fine, but would only be so in limited contexts.

As for volatility, it is best to use months, as days are considered too volatile. If we WERE to use days, trade days WOULD, I believe, be fine, for just the reasons you allude to (why include month-ends and holidays, when performance is 0.00%: it would only serve to flatten volatility, though if you did the same for the benchmark, the impact would be equivalent, but that’s hardly reason to employ it).

As for turning the question around, I believe I answered on both sides; at least I hope so. Hope this helps, too! Again, sorry for the delay.

Hi David,

this also links in to annualisation of ex post risk statistics and the ‘square root of single periods’ rule when daily observations are being used (I know there then is the argument about using daily returns in these calcs for long term investors). I’ve seen various approaches that would assume 365 days, 252 days (or whatever working days there were in year), ‘use 365 assumptions if x number of non working days have non-zero returns, actual number of days traded etc.

Jim

Thanks, Jim! Good points.

That’s quite a comprehensive (and convincing!) list of arguments against the use of trade days. If one publishes returns to the last calendar day (which might be on a weekend or public holiday) one should definitely use calendar days to annualise. What would be the arguments for the use of trade days? As per your list, trade days will just make it a nightmare when comparing returns between different countries/regions.

Thanks, Pieter; no reasons have been put forward. I think it’s probably something as basic as “well, why not?”

I strongly disagree that calendar days are the right way to think about returns, at least for publicly traded securities (like stocks and bonds) where price changes are an important contributor to total returns. Returns result from taking risk, and risk manifests itself only when markets are open! The use of calendar days in calculating returns tends to smooth volatility (including 2 non-trading days a week), making investments look less risky than they are. Allowing 2 out of every 7 days to register 0% price changes creates a highly distorted picture of investment risk. Anyone who cares about accurately measuring return versus volatility tradeoffs should favor trading days over calendar days in calculating returns.

Will,

First sorry about the delay; the blog software failed to notify me of your comment, and I only now stumbled upon it.

Second, I think you raise a good point, but are missing the relevance of the use of calendar days. As for volatility, we first of all don’t use daily returns, but monthly, because daily are too noisy. Second, if we were going to use daily, we WOULD only calculate returns on days when the market is open (e.g., we wouldn’t calculate for Saturdays and Sundays). Finally, this discussion is limited to the calculation of the annualized return, where volatility wouldn’t play a role. Hope this helps!

Dave

This article and conversation is exactly what I was looking for. I thought it would be interesting to note that, in my research to find out what is the industry norm (calendar vs trading days), I found a document by Morningstar Inc called “Standard Performance Calculation Methodology” that outlines how they calculate their returns for indexes. And it would seem to me that for comparison purposes, an investment’s return would need to be calculated the same as it’s index/benchmark. The document indicates that they use 365.25 days to calculate Since Inception Total Returns of periods greater than one year. Here is the statement from the document:

“Annualised Total Return = {[(F/I)^(1/n)] – 1} * 100 (% per annum)

where ‘F’ is the (final) total value index figure for the month at the end of the time period and ‘I’ is the (initial) index value for the month at the beginning of the time period….

“Note that for since inception total returns of periods of greater than one year ‘n’ represents the number of days since performance inception date to the current month end divided by 365.25. In addition ‘i’ is value as of the performance commencement date.”

Our firm also uses Morningstar’s portfolio accounting software called Morningstar Office. I confirmed with Morningstar Office service reps that the system will use the previous closing price for weekends and holidays. Meaning, Friday’s closing price for a security (assuming that was a trading day) will be used as the closing price for Saturday and Sunday for a security. This sounds like to me then they are effectively using calendar days. Also, when computing the Time Weighted Return of a portfolio, the value of the portfolio as of close of Friday will be used for Saturday and Sunday when computing daily TWR, which is then used to calculate the TWR of the period being measured. It may also be important to note that Morningstar Office only offers standard deviation data points for month-end period- not daily.

Similar to a previous comment above, Morningstar reports their returns as of month-end (last day of month) and not as of last trading day of the month. This would seem to indicate that they would need to use calendar days and not trading days.

….just food for thought.

Dear Trey,

Thanks for passing this along. Interesting to learn that they’ve elected to use 365.25, regardless of the presence of leap years, though I believe others do this, too. It’s probably a worthwhile project to delve more into: all I need is a bit more time! Appreciate you sharing this … yes, food for thought.

Best wishes,

Dave

There is a return over non trading days! Friday close to Monday opening. Plus there is accrual of dividends every day and risk over a weekend. Were you around for the crash of 87? What day of the week did it happen? Where were the futures on Monday morning in Europe Vs the Close the previous Friday?

There is no fixed income day count or accrual convention in bonds that uses trading days. To compare bonds and equities with the same measure you must use a bond convention.

BTW way – my theory about flash crashes involves the use of mid prices in some systems. If there is no bid there is no mid; or a mid is half what it should be and therefore there is a de facto crash.

Great points, Gary; thanks for your comments.

I’m a quant and I always use trading days (and assume 252 trading days a year) in my models when I annualize performance. I realize this may not be rigorous enough for GIPS but it makes it easier to normalize performance when comparing 2 or more strategies. Besides, a strategy with a 10.5% and a 10.7% annual returns are both pretty much in the same league.

Anon, thanks for your note. A few comments:

1) I don’t see why being a quant would impel you to want to use trading days; perhaps you can explain.

2) GIPS doesn’t speak to annualization. The use of calendar days is just pretty much standard. I outlined 10 reasons why they make sense.

3) Perhaps you have a reason why you favor trading days; please share.

And yes, the differences won’t be very different, but I don’t think that’s the point. Assuming 252 trading days as opposed to knowing that there are 365 (or 366) calendar, plus all the other reasons, suggests to me, at least, as well as apparently most of the performance measurement world, that calendar is the way. Again, perhaps you can persuade me to think otherwise. Thanks!

All of the above are valid points and speak to the fact that there are many ways to represent the risk/return profile. But one point I would like to add (as augmentative to Anon’s point) is that for any systematic intraday strategy trading days would be a much more fair way to calc performance and subsequently calc a realistic sharpe (assuming Anon was referring to intraday quant strategies as well)

Thanks for your comments; sorry for not responding sooner. Our blog software is supposed to alert me whenever a comment is made; but, it is failing us: something to work on, I guess.