Being clever about which contract to pick? (roll yield)

[Jez Liberty]

The so-called "roll yield" can sometimes have a strong impact on the return of a future contract. A prime example being how it was impossible to match crude oil spot price performance using futures in 2009. (A) (B) (C) (D) [shameless plug to a blog post with charts illustrating that point ]

In absolute - and ignoring the beta moves from the spot price - you'd want to be short contracts in contango (premium deflates over time) and long futures in backwardation.

Most of us probably backtest/generate trading signals using continuous/rolled contracts, but this approach does not attempt to "be smart" about the "term structure" (ie whether in backwardation/contango and the slope of the yield curve) of the instrument. I wanted to test whether this approach could be improved

The main gist of the idea for the "improved approach" is to avoid contracts with a "penalising roll yield rate". For each new Buy/Sell signal, check which contract offers the best roll yield rate and pick that one instead of the front-month contract. For any long signal, pick the contract with the lowest contango or highest backwardation rate and for any short signal, pick the contract with the highest contango or lowest backwardation rate.

I ran a comparison test on Crude Oil using a standard 20-50 day MA crossover. The first test only picks the front-contract rolling over with a fixed date trigger (ie similar to backtest/trading with standard back-adjusted contract), whereas the second test looks up all the contracts in the next 12 months and picks the one with the best implied roll yield rate.

The performance of the second test looks quite appealing - check chart below

Wonder what you guys think about this concept...

I have not (yet) considered volume/liquidity constraints (assuming that any of the next 12 months contracts would offer enough liquidity for a small trader).


A TB question I have is: how would you do this in TB? I wrote custom code for this (completely outside TBB) to load each individual contract file to calculate daily yield curves and compute the equity curve based on each contract choice, trading signals, etc. Works ok for a single instrument but I'd like to do some portfolio testing on the same concept without having to rewrite a whole backtesting software
Would appreciate any bright ideas on how to do this in Blox in a more automated manner

[bobsyd]

Why not trade Spot Brent or WTI directly? Scroll down to end of http://www.gft.com.au/sheets/cfd/commodities.asp

[Jez Liberty]

Why not trade Spot Brent or WTI directly? Scroll down to end of http://www.gft.com.au/sheets/cfd/commodities.asp

There could be a couple of reasons:
- being long (short) a contract in backwardation (contango) should add a positive roll yield to the spot price move
- you'd probably want to be able to trade a wide range of instruments in a diversified strategy (GFT or others do not seem to offer many "spot" products).
- Using GFT products would probably expose you to some extra counterparty risk (compared to trading futures on an exchange)

But other than that, it could be an option to consider..

[sluggo]

A buddy of mine embarked on a project to "trade term structure," only to discover that there aren't very many futures with decent volume in the non-front-month contract. A feature of CSI UA software makes it fairly easy to plot the volume of the non-front-month (see below), and then you can eyeball it, apply technical indicators, etc.

[Jez Liberty]

Thanks for the feedback sluggo.

I am actually using the CSI API to extract all individual contracts into separate file so I'll try to enhance the code to include liquidity/volume in the export and record the actual volume in further contracts compared to the front-month contract to see if it drops to unacceptable levels...

which leads me to the question: what is unacceptable? ie at which percentage of volume woud you think you are too big for the market: 1%, 5%, 10%, 20% ...?

[sluggo]

One way to go is to set a liquidity threshold that gives your account plenty of room to grow; that way you won't be discarding instruments from your portfolio a mere six months from now: viewtopic.php?p=41731&highlight=multiply#41731

Another way to get a "minimum required volume", independent of account size, is to compute the average number of contracts traded per second (don't include the time when the market is closed). How many contracts per second are required for YOU to feel a contract is "liquid" ? Would YOU feel comfortable trading an instrument that averages 0.1 contracts traded per second? (i.e. ten seconds between contracts)? If the market is open 12 hours per day, that would be a volume of 0.1 x 12 x 60 x 60 = 4320 contracts per day.

Then just use whichever of the two minimum-volume constraints is the most conservative (largest).

[AFJ Garner]

When back testing multiple systems or systems which allow pyramiding it is also an idea to consider the operation of a typical volume limit filter and whether it suffices.

It is one thing to restrict any one trade to 0.5% or 5% of the average daily volume but consideration needs to be given to total net position size. You may wish to restrict total net position size to 0.5% or 5% of average daily volume over a given period. In which case some additional coding is likely to be necessary.

Such exercises lend new perspective to capacity and how the likes of Man AHL, Winton, Transtrend and Bluecrest manage this.

[Moto moto]

Additionally - by trying to go to less liquid months, slippage would definitely increase.
yesterday for example - while day trading crude oil (I know shame on me for day trading) I traded the front month and also the next month. There can be significant gaps between the last sale and the next sale even though bids and offers appear to be there every time and the volume might be good enough. So even if the contracts appear to have enough volume in them, there will be issues regards how accurate back tested results will be relative to live trading in terms of actually getting set.

[svquant]

Jez,

Take a look at DB Optimum Yield version of their commodity indicies - they look out upto 12 mos for the best contract at every rebalance point and go long that contract as part of their long only commodity index products. Since they do trade this index and there is an ETF I would think the liquidity of the contracts they use and the span of months they look at the "yield curve" (uptp 12 mos for some commodities) would be tradeable by most people. Please note that the DBLCI-OY trades very few contracts (less than the 23 in GSCI) so it sort of confirms what Sluggo was posting that perhaps not many commodities are easily tradeable out on the curve.

I've been doing some work on "term structure" trading and there is a lot of interesting papers out there to look at FYI.

As for implementing in TBB one thought would be to load all the 12 series (one for each month) as instruments and then use a portfolio manager to only allow trades in the optimum contract. Details left to the reader as an exercise

[Jez Liberty]

Take a look at DB Optimum Yield version of their commodity indicies

Thanks svquant, I was not aware of this index/ETF - and it seems encouraging if a big fund can implement this sort of strategy (ie it means it should be viable for smaller traders...)

Indeed, they only have 14 components in their index (list attached), far from a global diversified TF portfolio with 100+ futures.
However, I am thinking this logic could possibly still be added as an extra logic in the trading process for a global diversified TF programme: only applying it to the highly liquid instruments in the portfolio, whereas other instruments take a more standard approach.

Here is their webpage for those interested in more info..

[Jez Liberty]

Forgot to mention.. I did some further analysis on Crude Oil with volume checking/constraints.

I output the volume of chosen contract vs. volume of most liquid contract and did some analysis on these numbers (hoping they would prove liquidity was always good - if the method is good enough for DB, it should be good enough for "small-trader" me..). However there were cases where volume was very low (<50) and in total 17% of trades (of a total of 193 trades including some roll-overs) had volume of less than 1,000.

That was a bit disappointing but I ran another test by adding a "liquidity filter": only pick the best yielding contract with a minimum of X contracts.

The good news is that I did not have to bother calculating the difference in CAGR because results were so close whether I chose 0, 1000 or 5000 contracts as the liquidity threshold: end balances were identical +/- 3% over 20 years.

I also did some analysis on potential slippage impact (ie slippage would probably be worse on less liquid months).
With a pessimistic slippage set at 25% in TB, the "non-optimised" performance drops from 10.5% CAGR (no slippage) to 8% CAGR, giving us a 2.5 percentage points CAGR slippage cost, whereas the optimal roll yield system was giving a 3.1 percentage points CAGR gain...
This balance between extra slippage cost and extra roll yield gain depends on how much worse fills would be on less liquid months... Something that can really only be tested in real-life trading I suppose.