I am researching the TOM (Turn of the Month) effect and was planning to build a dynamic strategy in Portfolio123 that enters the market on the fifth day prior to the end of the month and closes the position on the third business day of the following month.
Any ideas on how to program and evaluate the TOM effect on a selection of Russell 3000 stocks?
Thanks.
It probably can be done, but it’s complicated.
The fifth day before the end of the month would be
DaysDiff (AsOfDate, Year * 10000 + Eval(Month < 12, Month, 100) * 100 + 101) = 5
.
Problem: if the fifth day before the end of the month is a weekend or holiday, you don’t trade that month.
The third business day of the month would be
(Weekday = 2 and MonthDay = 5) or (Weekday = 3 and MonthDay = 5) or (Weekday = 5 and MonthDay = 3) or (Weekday = 6 and MonthDay = 3) or (Weekday = 4 and MonthDay = 3) or (Weekday = 4 and MonthDay = 4) or (Weekday = 4 and MonthDay = 5)
That doesn’t take holidays into account, though.
As you can see, it’s complicated. You might be able to adjust the formula to deal with the exceptions . . .
All,
I think Yuval has some good ideas that can be used to test the effect with small modifications. I did not proof read his formula but I assume his formula is correct.
That being the case (that Yuval’s formula is good), using <= 5 should get you there in most situations and very close in those situations were it misses the optimal buy-day by a day or two. Specifically, this formula should give you a good idea as to how effective a turn-of-the-month strategy might work:
DaysDiff (AsOfDate, Year * 10000 + Eval(Month < 12, Month, 100) * 100 + 101) <= 5
.
So if the fifth day before the end of the month is a weekend or a holiday it will just try to made the trade the fourth day before the end of the month, and if it cannot it will try again on the third day before the end of the month…
This assumes that occasionally buying the fourth trading day before the end of the month (or the third) still gives you some idea as to how effective the strategy is.
Also it assumes the program fills all the positions in one day when it buys at the end of the month with little cash left: so that it does not keep buying. But clearly this works for some situations, for example where you are buying just one ETF (e.g., SPY) and the sim holds only one position.
Probably, the buy-rule can also be modified in a similar manner with one additional “or” in the rule. Perhaps adding "or month day > 7 " as a fallback would get your there most of the time and give you a pretty good idea as to the effectiveness of the strategy.
I have not tried these formulas in a sim and I apologize if I have missed something basic. But does seem like using inequalities (greater-than or less-than) can go a long way toward seeing how the turn-of-the-month effect works and I wanted to suggest it.
TL;DR. You can probably avoid months where you make no trades at all in the sim with the above minor changes (or similar changes). And it probably accurate enough–after avoiding the problem of months with buys or sells–that if it does not give positive results you might consider using a different strategy.
Thank you Yuval. That should work.
-Jim
Thank you very much Yuval and Jim for helping me with the problem of evaluating strategies based on the month-end effect. As you are no doubt aware, this type of calendar anomaly has been one of the most studied in academia. My intention is to analyze if this anomaly still exists in the markets and it allows to generate alpha. Many of these anomalies have been weakening in recent decades or have disappeared completely. But in the case of the TOM effect there are still doubts and there are some studies that show contradictory results.
That is why I wanted to verify for myself the TOM effect in the US markets by building a strategy using Portfolio123.
For the problem of holidays and weekends I came up with this possible solution: Take as a reference any of the major indices (e.g. the S&P 500) and assume that the days when there is no trading are holidays. Therefore, to build a TOM [-5,3] strategy we would only have to identify the last day of each month in the daily series of the SP500 and count 4 bars backwards to set the market entry day and count 3 bars forward to set the position closing day.
Do you think something like this would solve the problem and allow an accurate simulation? Could you give me the formula in P123 to calculate this?
Best regards,
Andres.
There is a function called “PrevBarDaysAgo” that might be useful; it was designed to “restrict buying to a specific day of the week.” (Factor doc.)
Could it be adapted for monthly buy/sell restriction? e.g. for 1st day of the month sell restriction:
$MonthlySell= (MonthDay=1 or (MonthDay=2 and PrevBarDaysAGO>2) or (MonthDay=3 and PrevBarDaysAGO>2) or (MonthDay=4 and PrevBarDaysAGO>3) or (MonthDay=5 and PrevBarDaysAGO>4)or (MonthDay=6 and PrevBarDaysAGO>5)or (MonthDay=7 and PrevBarDaysAGO>6))
Someone check my code 
For the end of the month restriction, would we need a (new) companion function “NextBarDaysAhead?” Is this feasible?
We definitely recognize a demand for this. So we are planning to introduce a new function: MonthBars. MonthBars(1) would be the first trading day of the month, MonthBars(-1) would be the last trading day of the month, MonthBars(-5) would be the fifth trading day before the end of the month, and so on. We still have to work out some details, and this is probably going to be on the back burner until we launch Europe, but we hope to get it done soon.
It should also be mentioned that strategies now rebalance 5 days a week for daily simulations. Holidays are no longer defined at the strategy level and thus cannot be skipped. Instead, transactions are scheduled for the next trading day based on the country of the exchange of a stock, and subsequent rebalances will not happen until all pending transactions have executed. All that to say, with recent changes, you now only need to check 3 days to handle weekends and ensure a rebalance happens.
To implement MonthBars, we’d likely accept a country code as the second parameter, defaulting to the benchmark’s country (esp. as a convenience for USA).