I was recently looking at monthly momentum/rotation trading systems with stocks. The concept seems to have become quite popular in the blogosphere in the last few years. See this earlier post for another monthly trading discussion
The generic concept for a rotation strategy is usually fairly simple: pick a relatively large set of instruments, calculate a monthly ranking (based on 1-month, 6-month returns, etc. or a combination of several monthly returns and/or other factors) and allocate your equity to the top N instruments. Repeat every month by selling instruments that have fallen out of the top N and by buying new entrants.
The system appears simple enough to operate and to backtest, but as with everything, the devil is in the details.
There is of course other devil in other details: rebalancing, volatility consideration, position sizing, etc. are not taken into account in this simple model “description” and the discussion below.
Using Monthly Close data
Lots of (free) historical data – going back far enough for relevant back-testing – only contains monthly closes. The usual assumption made when backtesting using this type of data is to use the monthly closing price to generate the entry/exit signals as well as for the entry/exit prices themselves. Operationally, this is obviously not possible: you cannot wait for market close to get prices and generate signals, then go back to trade at market close.
This is one of the reasons backtesting software such as Trading Blox does not allow to trade at today’s close – although this “safeguard for realistic results” can be overridden if need be (using a command such as
order.SetFillPrice(instrument.close) in script
Can Fill Price).
Using monthly close data only is not necessarily “wrong” but represents an approximation one has to be aware of. A workaround might be to get prices x minutes before the close to generate signals and send “Market on Close” orders before trading terminates – with the potential risk that market moves in these last monthly closing minutes would change the actual ranking and signal generation (giving different live trading and backtesting results).
Another workaround might be to actually trade on open the next day; the difference between live trading and backtesting results then being the difference between the monthly closing price and monthly open price – which could be costly in terms of missed performance when considering the turn of the month effect.
Using OHLC Monthly data might avoid this approximation in backtesting, by allowing the use of Close for ranking/signal generation and Open for entry/exit price.
Note: for historical data sources (including free ones), fellow bloggers Mebane Faber and Mike Stokes have compiled lists on their respective blogs World Beta and MarketSci. A new-coming website Wikiposit seems also very promising for all sorts of free data.
On my side, I use and am pretty pleased with CSI, which gives me access to the full history of World Futures and World Stocks, and allows for several data aggregation periods (daily, weekly, monthly, etc.) with different back-adjustment options for futures.
Different Monthly Opening/Closing Dates
Another complication could come from a portfolio of instruments trading in different locations: Monthly open/close might occur on different dates for different instruments (ie. different markets close on different days depending on the local holidays of the exchanges).
Assume that some instruments do not trade for the last global business day of the month: it is then clearly impossible to trade at the monthly closing price when generating trading signals on the last day of the month – making the x-minutes-before-close workaround impossible to implement, and increasing the backtesting approximation.
Again, using monthly OHLC data and the open price as entry price would prevent this issue.
Another case, which might cause an issue, relates to different monthly open dates. Imagine trading a rotation system, which is invested in the top 10 ranking stocks:
Every month the system would sell the stocks that have fallen out of the top 10 and use the proceeds to finance the purchase of the new entrants in the top 10 (assuming no use of leverage: ie. the system can only buy after selling, when invested at 100%).
If some of the “Sell” instruments do not trade on the first global business day of the month (local exchange on holiday or other reason), the new purchases will be under-funded, with a decision to be made as to how to partially allocate across the new entrants, until full funding is available. This would mean that start-of-month returns from new additions would not be fully captured by the system.
The use of daily OHLC data with a more sophisticated backtesting logic would be required to reflect this logic in the simulation results. A more automated (than manual) order execution would also require a more complex algorithm defining how to handle these cases and being aware of non-trading days.
Of course, this issue can be largely avoided by choosing a set of instruments all trading in the same “holiday jurisdiction”.
Note that the margin constraint would generate another issue related to the delta between prices used for order sizing (monthly close prices) and order execution (monthly open prices).
A “jump” in prices might result in the total allocation going over 100% of equity. A buffer to allow for price variations is probably required when calculated signal and position sizes for the next day, at the risk of being slightly under-allocated every month. Some testing would point to the “most optimal” buffer size to limit over-allocation without reducing the overall average allocation too much.
Not Only Relevant to Monthly Systems
Quite a few of these issues actually apply to systems that trade on various frequencies, not necessarily on a monthly basis. As for every model or testing procedure, it is always good to be aware of assumptions and limitations.
One has to get a feel for the related issues to decide whether one can live with the resulting approximations in their backtests, or whether more realistic results are worth the extra effort in developing backtesting logic and operational procedures.