Sharpe/sortino ratio risk-free-rate being changed to 3Mo T-Bill instead of 10Y T-note

Dear All,

We are beginning to use the new FRED series for some of our stats. We have been using the 10Y t-note since it’s all we had from our data provider. Sharpe/Sortino ratios are most commonly calculated with 3M t-bill and we have revised the algorithm. THey are now using the 3M t-bill for the risk free rate which makes the values higher (better) since the 3M t-bill has been essentially 0 for a while vs 2+% of the 10Y t-note.

Should not be a noticeable change for live ports since they risk stats are re-calculated every night. It would be noticeable though if you compare a recent simulation vs an older simulation. Let us know if this is a major problem.

Thanks

Why the change of P123 view on how to best calculate the Sharpe ratio?

See discussion in this thread

Marco

Marc Gerstein

Main reason is so that our sharpe ratios match others, like Morningstar. It will make more sense as we evolve our strategy sharing (R2G) into a real alternative to funds/etfs: easier, more liquid, flat fees, for a wider market, etc.

Agreed, using the 3 month T-bill seems to be the industry norm.

Thank you for sharing the rationale behind this change.

Would it be possible, in the long fun, for p123 to create user choice regarding risk-free rate? Given the discussion above, particularly Marc’s comments, it seems it would be useful if members could backtest using different risk-free rates.

On a different and perhaps even more important front, has p123 adequately tested its implementation of the FRED series data?

I posted concerns earlier about the transition from #tnx to ##ust10yr, which have not received a reply. Unfortunately, the issue seems to persist. Checking p123 values for #tnx and #ust10yr on July 8th and 9th, this is what comes up:

Date #tnx ##ust10yr
7-8 22.06 2.22
7-9 23.01 2.22

When making the change, p123 was critical of #tnx, which other than the decimal point eccentricity, seems to update properly, appears to have been consistently presented and happens to be a very useful and widely used data point: the 10 year note’s yield.

##ust10yr should be useful, too - not instead of, by the way. Unfortunately, ##ust10yr’s data update seems to run a day behind, which of course throws into question the entire pit value of the data being presented, and in addition ##ust10yr is rounded to two decimal points.

Has anyone looked into the timeliness issue? How would members feel if they knew they were using one day old stock prices?

p123’s evolution is terrific. I’m a huge fan. But sometimes I fear that p123 underestimates the issues that unilateral changes, particularly when these changes have not been thoroughly tested before implementation, create for its users.

Hugh

I have noticed that the FRED rates are reported up to 2 days late. For example, this morning 7/10/2015 at 6:30 EDT the FRED data is from 7/8/2015. Usually by mid-day the data gets updated to yesterday’s values. So this seems to be the reason why P123 has the 10-Year Treasury Constant Maturity Rate one day late.

The Department of the Treasury has yesterday’s rates on their website which differs significantly from the day before. http://www.treasury.gov/resource-center/data-chart-center/interest-rates/Pages/TextView.aspx?data=yield

The 10-yr rate as listed:
7/8/15 2.22
7/9/15 2.32

So if P123 has the rate of 7/8/15 in their database for 7/9/15 then this is a big mistake.

Thank you, geov.

I have several follow-up questions:

  1. Would it be possible for p123 to maintain, not deprecate, #tnx?
  2. Is there an outside corroborating source for #tnx such as geov identified for ##ust10yr?
  3. Will #sprp be affected by p123’s recent decision to transition from #tnx?
  4. Do dating issues exist for all FRED variables?

I understand these issues are difficult, recognize that they are growing pains of an uncomfortable sort, and also really appreciate what p123 is working to achieve.

Hugh

Creating a whole new download mechanism to get data from a different site is a big undertaking. Can you tell us what the problem is with FRED data being a couple of days late? I don’t undertand a use-case (within the P123 framework) where using t-bill data from a few days ago is a big deal. Thanks

#tnx is from Interactive Data. We can keep even if it’s x10 (therefore confusing). We’ll add better documentation.

Compustat gives us monthly values for this kind of data.

We’re still using #tnx/10 for Risk Premium. No plans to change that

Dating issue, meaning a few days late? Probably yes

I updated the description of #tnx:

NOTE: in reality with T-bills you get two semi-annual payments (electronic payments, not physical coupons that you once had to take to the bank)

I have just downloaded the FRED data again at 4:00 pm EDT on 7/10/2015. They still have only rates data up to 7/8/15 there, same as this morning.

As to why this would be a problem within the P123 framework, I can only think of market-timing signals derived from this data.

Hi Marco,

Thank you for your immediate response. At the risk of repeating myself, I’d like to again express my appreciation to p123 and its continuing effort to improve the platform’s data, tools, documentation and support. The introduction and integration of macroeconomic data into the system is an astonishingly positive development, way beyond expectation.

As a fan of the site, there are a few things I’d like p123 to know:

  1. I can’t always spend as much time with p123 as I’d like. Therefore unexpected changes and inexplicable results can be particularly unnerving because I don’t always have time to make adjustments or properly explore the underlying reasons. Probably like a lot of users I go through periods when I use the site in a developmental manner and other times when I’m preoccupied with other aspects of life and in more of a maintenance mode. It would be helpful to have advance notice of possible changes, an ongoing log of changes that have been made to the data, variables, tools and site, and a more substantial beta period in which changes could be tested so that the inevitable glitches could be worked out.

  2. If one is writing an academic paper about the relationship between interest rates and airline profitability it probably doesn’t matter if your data lags by a day. But if you believe that changes in interest rates might be related to stock market returns and therefore important when developing hedging strategies, or anticipating the returns of certain industries such as home builders, then – like all data made available for testing on p123 – you want to make sure that you are backtesting and simulating trading decisions using data that really was available on the day in question. This is one of p123’s strongest features, a first principle, absolute bedrock.

  3. I do understand that theory is often easier than practice when it comes to PIT issues. I believe p123’s policy is to correct historical data errors if the “true” data was available from other public sources on the day in question. Is that so? Speaking personally, I’m a bit uptight in this regard and so I’d possibly argue the data shouldn’t be corrected. However, a) I’m not sure I’m right, and b) I appreciate the thoughtfulness behind p123’s policy – assuming I’ve stated it correctly. Therefore, I can easily live with p123’s policy. In the case of FRED data if we know the data wasn’t really available on the day in question, then I think a case can be made to lag the entire data base – by the way, is the lag with FRED data consistently one day or does it vary by variable? – but then also provide a heads-up to users in the variable name itself. For example, the ##ust10yr could become ##ust10yrpit . This is not an easy question and hopefully others will contribute to the conversation. But creating FRED pit-labeled variables this way does anticipate a future in which the data will become available in a more timely manner. Whether there is a lag or not in the future, the pit variables will always be true to what information was actually available for decision-making and trading.

Thanks again for your attention to this matter.

Hugh