I've worked as a sole proprietor and in small and larger companies over the last fifteen years. In these environments I've experienced different managerial structures as related to the practice of producing quantitative trading systems. My experiences have lead me to believe that Rapid Strategy Development is the best operational model for a quantitative research to follow.

Rapid Strategy Development means chosing to create a platform that removes roadblocks to the streamlined implementation of trading systems. The typical system development path can be defined as follows:

• empirical study of the market to generate ideas;
• use of analytical methods to specify viable ideas on historical data;
• use of analytical methods of verify viable ideas on newly captured data;
• definition of trading systems to implement the strategy;
• implementation of the codebase to execute the strategy.

The first two parts, the empirical and statistical research to create a system, should be the overwhelmingly longest part of the development path. The final stage should be the shortest. Once it has been researched, one should be able to code and execute a strategy within a day, that is the primary goal of the RSD paradigm. This really boils down to three principles.

1. Think First;
2. Avoid Ownership;
3. Just Do It.

Think First means the early recognition and implementation of generalizable structures (think before you type). Don't oppose generalization because it is “inefficient” — it is not.

Avoid Ownership means that my code is everybody's code and that everybody's code is my code. This means

1. accept input from others;
2. create of public use code (i.e. provided to other systems) over private use code (i.e. local to a specific system) whenever possible;
3. create of public use data tables whenever possible;
4. avoid of ad hoc nomenclature always;
5. avoid of non-conforming private data tables and private data storage whenever possible.

Just Do It (sometimes referred to in economics as "The Nike Strategy") means:

1. don't wait for permission to continue;
2. don't make private codes and seek to generalize them later "when I have the time" as that time will not come;
3. always compartmentalize to allow component reuse;
4. always make changes when their need is recognized — Fix It Now.

In prior posts we have investigated whether it is possible to make an early forecast of the Dynamic Trading Risk Factor return for a specific month, and discussed our motivation for making an early forecast. In this post we examine a necessary condition for that work to be worthwhile — that the returns of an asset due to the factor are not delivered in a clump at the start of the month.

To make things easy for ourselves, we'll start with the Franklin Mutual Shares fund, which we have under the ticker TESIX. We found that this fund has a β of 1.7 onto the Dynamic Trading Risk Factor. With such a strong correlation, hopefully it will show a strong effect if one is there. (Of course, this is actually a bad choice for market timing because the front load fee of over 5% for this mutual fund will likely kill any timing alpha we can discover.)

Here we find a daily β of 2.3 with an apparent linear decay rate of (0.12 ± 0.06) per day. This result has borderline significance (p-Value of 3.5%) and so does not contradict the hypothesis that the factor returns are delivered uniformly throughout the month.

In the prior post we showed some skill in estimating the end-of-month factor returns for the Dynamic Trading Risk Factor based on early measurements of partial universe returns and a bias correction model.

However, we've not indicated why that would be interesting. The principal reason is as follows: we have good evidence that the Dynamic Trading Risk Factor trends — specifically that an AR(1) model can be fitted to it. This means that we can predict the next month's returns of the factor based on this months inferred value. But, and this is the problem, we typically only fully know a month's factor return at the end of the next month — and that's the month we're trying to predict.

If we could take an early estimate of the value we would record at the end of the current month, then we can make an estimte of the forecast for the current month with sufficient time to act upon that information. For example, we could time trades in one of the public listed securities that we have demonstrated have a high R² onto the factor.

Of course, for our market timing to work, it is necessary that the asset returns that are associated with the factor be delivered, to some extent, over the remaining part of the month. In the next post, we will seek to establish the validity of this proposition. 

In the previous post, we investigated whether outperforming funds report their results earlier in the month, and whether that induces a systematic bias into the early reported hedge fund indices relative to the finalized values at the end of the month. The table below shows my measurements of the Dynamic Trading Risk Factor, as estimated through the procedures outlined on this blog, as determined according to a fairly ad-hoc updating schedule determined by my commitments to other projects.

For each month we present the first recorded estimate of the factor return, the final recorded estimate of the factor return, and a “corrected estimate” or forecast final value based upon our bias expression from the prior post and the initial estimate. We compute residuals for two hypotheses:

1. the null, H₀, that the early measurement is an unbiased estimate of the final value; and,
2. the alternate, H₁, that the corrected estimate is a better forecast of this final value.

We can compare these hypothesis by evaluating their forecasting skill, which gives a 23% edge to the corrected estimate. This skill is usually defined by the following equation, where MSE means mean square error.

In an earlier post we addressed the question as to whether there is any bias in the delay between a fund's month end and the performance of that month. Our cynical theory is that managers with good news to report report it early and those with bad news to report report it late.

Since September, 2009, I've been sampling the reported monthly return of the BarclayHedge Hedge Fund Index. This is a simple average of the monthly returns of all funds that have reported to the group at that time. From time-to-time during each month I've sampled the main index's reported average monthly rate of return and the number of funds that have reported. You can find this data on my blog at the page Return Index Accumulation Report. The chart below is an analysis of the error, meaning the difference between the average monthly rate of return for the entire universe reporting on the sample date and that value finally reported at the end of the month. To gauge the average scale of the bias we fit a simple model by least squares:

Here B is the bias, or the average error between the sampled monthly rate of return and the final monthly rate of return; S is the scale we seek to estimate; and, p is the proportion of funds reported (i.e. the number in the sample divided by the final number of funds reporting in that month). Our estimate of the average scale of the error is (51 ± 8) bp/month.

It appears that Microsoft's file replication service, NTFRS, decided to delete the copies of my charts and regression results from both my web servers. This is frustrating, but I am in the process of reproducing them. Some of them may end up “more up-to-date” than the post text refers to — but apart from being contextually jarring that's no big deal. (This is presumably why they replaced NTFRS with a completely new product in R2 version of the operating system.)