I have written before about the observation that factor returns and smart beta funds tend to show much lower returns after a factor has been published in academic journals than before.
Hi Joachim, first of all: I really like the content you share and very much appreciate it! I have a question on this article, where (also read Kaplanski) the author Kaplanski tends to discuss the scientific publication of anomalies. In that way we can surely talk about Day 1 (T+1 after publication). Companies mostly have their Q-reporting deadlines at the end of month, so this is also in line with day 1. Practice shows however that the majority of reports (around 75%) is processed in the big financial databases at the 10th of the month. Did you think of this process lag, when selecting the second half of the month to run you data analysis? Aren't you missing out on the accounting variables then, or do you want to make sure 100% of reports is processed? By preloading only 'old' accounting variables, and newer price momentum etc.? A little bit a chicken and the egg story ;)
Well, I didn't think of this process lag in the publication when selecting the second half of the month. And in a sense, if I screen in the second half of the month, I will get the data from the beginning of the month, processed on or after the 10th. Meanwhile, if I would screen like everybody else on the last day of the month, I would get the same accounting data as of the beginning of the month. There is just a difference in price data.
But when it comes down to such screens for anomalies, it is all about robustness. If your screen depends on all accounting data being just a few days old, your screen is too sensitive and not robust enough to errors and shocks. In fact, the best screens work, even if you use accounting data that is a month to three months old.
Here in the UK, we anyway have only biannual reporting and the fiscal years of the companies are all over the place, so it is impossible to work on the assumption that by the first or tenth or fifteenth of the month all accounting data will be updated. That just doesn't happen, so you have to create a screen that works even if your accounting data is a couple of months old.
In fact, the best screens work, even if you use accounting data that is a month to three months old. ->
I did not know that, surprising!
My assumption is/was that integrating accounting variables in the screen should be right on time/with the least possible lag, as they are most fundamental/important, and sensitivity is exactly what you want in the screen... because you want to profit from these changes. Therefore, price data should be secondary, as it also fluctuates on external variables e.g. geopolitical decisions/irrational behaviour/more beta.
Therefore in my mind focussing on accounting variables should be primary, but just laying it out there... probably you have a better view. Thanks!
In theory you are right, but in practice you are running an enormous risk of overfitting a model to the data. And that means that if the relationship changes in the future, your mosel stops working. This kind of overfitting to current or historical data is one of the most common reasons why models that work in back tests stop working in practice. If a model works with all kinds of “frictions” in a nacktest such as long lags or high transaction costs your cha fee of it working in the future when you actually implement it in real life increase.
Hi Joachim, first of all: I really like the content you share and very much appreciate it! I have a question on this article, where (also read Kaplanski) the author Kaplanski tends to discuss the scientific publication of anomalies. In that way we can surely talk about Day 1 (T+1 after publication). Companies mostly have their Q-reporting deadlines at the end of month, so this is also in line with day 1. Practice shows however that the majority of reports (around 75%) is processed in the big financial databases at the 10th of the month. Did you think of this process lag, when selecting the second half of the month to run you data analysis? Aren't you missing out on the accounting variables then, or do you want to make sure 100% of reports is processed? By preloading only 'old' accounting variables, and newer price momentum etc.? A little bit a chicken and the egg story ;)
Well, I didn't think of this process lag in the publication when selecting the second half of the month. And in a sense, if I screen in the second half of the month, I will get the data from the beginning of the month, processed on or after the 10th. Meanwhile, if I would screen like everybody else on the last day of the month, I would get the same accounting data as of the beginning of the month. There is just a difference in price data.
But when it comes down to such screens for anomalies, it is all about robustness. If your screen depends on all accounting data being just a few days old, your screen is too sensitive and not robust enough to errors and shocks. In fact, the best screens work, even if you use accounting data that is a month to three months old.
Here in the UK, we anyway have only biannual reporting and the fiscal years of the companies are all over the place, so it is impossible to work on the assumption that by the first or tenth or fifteenth of the month all accounting data will be updated. That just doesn't happen, so you have to create a screen that works even if your accounting data is a couple of months old.
In fact, the best screens work, even if you use accounting data that is a month to three months old. ->
I did not know that, surprising!
My assumption is/was that integrating accounting variables in the screen should be right on time/with the least possible lag, as they are most fundamental/important, and sensitivity is exactly what you want in the screen... because you want to profit from these changes. Therefore, price data should be secondary, as it also fluctuates on external variables e.g. geopolitical decisions/irrational behaviour/more beta.
Therefore in my mind focussing on accounting variables should be primary, but just laying it out there... probably you have a better view. Thanks!
In theory you are right, but in practice you are running an enormous risk of overfitting a model to the data. And that means that if the relationship changes in the future, your mosel stops working. This kind of overfitting to current or historical data is one of the most common reasons why models that work in back tests stop working in practice. If a model works with all kinds of “frictions” in a nacktest such as long lags or high transaction costs your cha fee of it working in the future when you actually implement it in real life increase.