I noticed that many systems, particularly futures systems, do not increase their trade size as their account grows, so they effectively reduce leverage over time. This causes the maximum drawdown, as reported in the stats, to usually happen early in the system’s history, even though there may be larger drawdowns, relative to the trade size, later on.
New subscribers are likely to start trading the system with a sufficient amount to accommodate the usual trade size, not the system’s account size, so those later drawdowns would actually be more harmful.
Therefore, I would like to recommend a new drawdown statistic be introduced to reflect that. I though of one possibility, but someone might think of better ones:
A) Show the system’s average trade size (in $). It could be since-inception or as a moving average, in case the system does change its trade size at some point.
B) Show the system’s maximum dollar drawdown (note that this is not merely calculating the dollar value of the maximum percentage drawdown).
C) Optionally create a new APD-style statistic that shows B/A. So if the average position size is $10K and the maximum $ drawdown was $5K, this number would be 0.5.
I like that idea. But how should ‘trade size’ be defined in leveraged systems? For example, when I have $10K and I make a forex trade with $40K, should A be defined as $40K? In that case a forex system would easy get a lower DD then a stock system that trades with $40K.
I suggest to replace A by the initial capital of the system. That would still work for the purpose that you described, systems with constant trade size, and it is easier to determine.
Yes. It could be taken one step further, giving vendors the option to have a fixed buy power for their systems, which wouldn’t grow along with the account size. This would have several advantages:
- Stats such as drawdown and return could be calculated based on this amount. This would eliminate the DD problem I mentioned earlier, and also the problem of diminishing % returns as the account size gets bloated.
- It would allow prospective subscribers to easily know what kind of capital they need to start trading the system at any time.
- Subscribers could rest easy knowing that a vendor who usually trades 1 or 2 contracts won’t suddenly trade 30 contracts trying to make up a loss or something, just because his system which started with $50K and usually trades based on that amount, now happens to have a $1M account at C2.
- No need for the current rescaling process, which doesn’t seem to have much acceptance and screws up the historical trade record.
The usual account size would be maintained for displaying the equity curve and such, but only as a historical record. The vendor would only be allowed to trade using his fixed buy power amount (if he chose to have his system operating in this mode).
I like that idea too, and similar requests have been made previously because most statistics assume that the system is compounding. But there is one little problem with it: Will the buying power also remain constant after losses that reduce the capital to an amount smaller than the initial size? That would act like a bonus on gambling, because it assumes that the account will be refunded after each major loss. The rule has to be somewhat more subtle than only a fixed buying power. Can you formulate a clear rule that deals with this problem?
If this is implemented, then vendors who use this mode should be warned that it is disadvantageous for many statistics. Most statistics at C2 assume compounding. It is also hard to compare a noncompounding system with a noncompounding system, even if you are aware of the difference. For example, for a compounding system you should use the compounded annual return and for a non-compounding system you should use the non-compounded annual return, but even if you do this then the two annual returns are still not comparable. This problem exists already now, so this is not due to your suggestion, but having a separate mode for fixed buying power suggests that this is a fully supported mode while it is actually less supported - even after adding your DD statistic.
On a related note, I wonder if it’s possible to calculate RAROC (as VaR is already calculated) or Jensen’s alpha using the data available to C2 for a given system. This would help assess returns in a more normalized way.
Actually, both of the problems that you mention are already happening. Suppose that a system is successful for a couple of months and it multiplies its account size ten-fold while still trading the same amounts (happens all the time in futures systems, maybe not ten-fold, but just to make a point). A new subscriber is likely to begin trading the system with an amount similar to the system’s starting capital. The system can then have a drawdown twice that amount, blow the subscriber’s account to pieces, and still show as a mere 20% drawdown, as it stands today. With the “new system”, it would show as a 200% drawdown. The system wouldn’t go bankrupt, but it would be a much more realistic stat: the system performed awfully and blew through twice the capital it uses for trading. I think it would encourage consistency in vendors, not allowing them to rest on their laurels of previous gains.
As for the returns, the vendors would benefit from the new system. Their % return, assuming they trade fixed amounts, wouldn’t be eroded as their account grows. Of course, some may not like the fact that they can’t hide big drawdowns inside bloated accounts, but good vendors may like that.
I agree, both points are already happening. So what you suggest is that the vendor can specify that the buying power is maximized by a certain amount? I suggest the following details:
1. When the system is first created, the vendor can chose for a fixed mode.
2. If this mode is chosen, then the maximum buying power is determined as the buying power at the start of the system. (I think this is more convenient than making it a second free parameter).
3. At each later moment the buying power is the minimum of the ordinary buying power (as it is computed now) and the maximum buying power that was determined at the creation of the system.
4. The new DD stat is computed as the dollar value of the maximum drawdown, divided by the specified maximum buying power.
5. Let’s name this new stat the Fixed Capital DD (FC DD).
6. In other systems, which are not of fixed mode, the value of the FC DD is displayed as N/A.
With respect to the % return, I do not agree that this erodes as the account grows. The present situation at the old site is this:
- The basic stats table shows the compounded annual return (geometric extrapolation), which is valid for compounding systems
- The Grid shows the uncompounded annual return (linear extrapolation), which is valid for systems with fixed trade size.
- The advanced stats display both the compounded and the uncompounded annual return.
So there is no omission here; you just have to know where to look. Actually systems with fixed size have an advantage here because only “their” annual return is properly dislayed in the Grid.
Jensen alpha is reported in the advanced statistics.
RAROC could in principle be implemented in the advanced stats. However, my impression is that the advanced stats are rarely used, so I am not inclined to spend more time in it unless a lot of people request the same statistic. Note that the estimate of VaR depends on the distribution that is assumed (normal or log normal) or on the estimation method of the tail-index. If the estimate is computed entirely from the observed returns, without distributional assumptions, then the estimate is ususally unreliable because only 5% of the observations can be used to determine VaR(95%). Because of this the advanced stats report four different VaR estimates. Altogether this makes VaR a rather superficial statistic IMHO. RAROC will necessarily have the same problem.
Somehow my eye skipped over Jensen’s alpha, thanks for pointing it out. This is very helpful to me. As far as VaR, I’m aware of the several flaws in its use and that some consider it borderline fraudulent, but I would never consider it (or RAROC) to be the definitive measure of a system’s risk, just like I would not put such weight on any other statistic. I still like to see it as part of the toolbox (I suspect it’s included in C2 because I’m not alone in that regard), and RAROC would be a nice complement to save me some time, but to each his own.
Thanks for the explanation, however. Your input is always illuminating.
I see your point. Perhaps this helps to do it in an Excel sheet: In the advanced stats, under Ratio statistics of excess return rates, Statistics related to Sharpe ratio, you can see the row "Mean". This is the mean return, minus the riskfree return, multiplied by the average number of trading days per year (T). I believe that T is currently set at 242 (I am not entirely sure of this). The riskfree rate is probably set at 5% per year (I am not sure of this either), from which you can compute the daily riskfree rate as r = 1.05 ^ (1 / T). This is the same number for all systems. The mean return for one time period can then be computed as Mean / T + r - 1. The outcome can be used as numerator of RAROC. Once you have this in an Excel sheet, the only input needed to compute RAROC for a system are the values of Mean and VaR.
It may look like this would be easily implemented, but even small changes in the advanced stats are somewhat cumbersome because it requires that changes that I make in the module are matched by changes that Matthew should make in the C2 environment of which the module is a part. And Matthew Klein is a very busy man, as you know.
Jules, thanks for the recommendation. I’ll give it a shot.
As far as C2 implementation, this is hardly a high priority request. But for me, at least, RAROC would help address the apples-to-apples comparison issue, and since constant sizing was raised, I took the opportunity to throw this in. That said, I would be more than satisfied if Matthew prioritized server stability (and hope against hope, introduction of more compatible Gen 3 autotrading brokers) for the foreseeable future. I can’t be sure, but I suspect this would encourage more subscriptions (and thus more revenue to Matthew) than the changes around the margin like site layout.
Yeah but, for example, the monthly returns shown at the top of a system’s page will diminish over time for successful systems that use a fixed trade size. The equity curve will tend to flatten too. Basically all % stats become “attenuated” over time if a system increases its account size and maintains the trade size, because leverage is reduced. The fixed buy power method would prevent this, which for vendors can be good (better returns, no rescaling, etc.) or bad (worse drawdowns), but I think is great for subscribers.
But let me press you on this.
In C2 World, as a system vendor, you have some kind of responsibility to do money management on a given account. If your C2 Model account is $10,000, then you should issue instructions as if you were controlling a $10,000 dollar account. Have $100,000 at C2? Then issue C2 signals as if your were managing $100,000.
Remember that subscribers can configure autotrading to trade a percentage of your trades, and/or can set a cap on position size.
Asking for a "fixed trade size" is just another way of saying that you are refusing to do money management, which (in my mind, at least) is just as important as the long or short signal generation.
Remember, if you have too much capital in your C2 model account, you can always "rescale" your system and thus give up your extra capital, and start issuing signals with a smaller base account size.
Those system vendors that issue signals at a constant quantity level, regardless of their account size, are ignoring an important dimension of being a money manager. They should either opt out of money management altogether (by rescaling their system to remove extra capital, every now and then), or should take into account the size of their capital base when issuing trade signals.
What think ye?
Apart from the fundamental points raised by Matthew, I think that the situation is not so bad as you suggest. Let me review the basic stats that are displayed at the system page on the old site:
If the trade size grows then the realism factor becomes smaller, but with a fixed trade size it will probably stabilize if the market conditions are stable. No erosion here for systems with a fixed trade size. Actually these systems have an advantage here, because the RF will erode for other systems.
Trades, Profitable, and Losses
These numbers do not depend on the trade sizes.
This number does not depend on the trade sizes.
If the trade sizes increase, later trades will get more weight, but this does not necessarily make the outcome larger or smaller. Both the profits and the DDs increase proportionally with the trade size. With a fixed trade size the outcome will probably stabilize at the same value if the market conditions are stable. No erosion here.
I am not sure how the correlation is affected. Fixed trade size will lead to lower return rates, but the standard deviation will also decrease. If I have to bet, I bet that the correlation is hardly affected by the trade sizes.
This will not really erode if the system is profitable, but it will be lower in comparison to compounding systems.
Avg Win and Avg Loss
These numbers will grow for a compounding system, but they will probably stabilize if the trade size is fixed and the market conditions are stable.
If the trade sizes increase, later trades will get more weight, but this does not necessarily make the outcome larger or smaller. Both the profits and the losses increase proportionally with the trade size. With a fixed trade size the outcome will probably stabilize at the same value if the market conditions are stable. No erosion here.
P/L per unit
This statistic is actually computed with a fixed trade size, so no erosion here.
Avg Trade Length
This number does not depend on the trade sizes.
Compound Annual %
This will indeed erode if the system uses fixed trade sizes, but the Grid displays the version of annual % that will not erode for these systems.
I am not sure how the SR is affected. Fixed trade size will lead to lower return rates, but the standard deviation will also decrease. I presume that the SR is hardly affected by the trade sizes, because risk and reward decrease proportionally.
This will indeed erode for systems with fixed trade size.
Risk of x% account loss
I don’t know, but probably this behaves much like the max DD.
The max DD is the only stat at the systems page for which it is clear that it will erode with fixed trade sizes and for which there is no alternative measure elsewhere at the C2 site. This is why I agree with your suggestion to add an alternative DD measure. For most other stats, however, it is either clear that there will be no erosion (APD, profit factor), or it is unclear how they are affected (SR, correlation), or an alternative exists already elsewhere (annual %).
In theory, that is true. But in practice, subscribers have to do that aspect of money management themselves anyway, because they all join a system at different times, with different account sizes, different risk tolerances, etc. Also, when subscribers scale down a system, there can be all kinds of problems with odd amounts, scaling in and out of positions, and so on. The vendor could open many 1-contract positions, for example, which cannot be scaled down by the subscriber. With a fixed buy power, everyone would know the required capital to fully trade the system, at any time. Subscribers can then scale up, use more or less leverage, and reinvest gains as they see fit.
I’m not saying there’s a serious flaw or anything like that, I just think it could be a nice change. Not only statistics-wise, but also so that potential subscribers know how much capital they need, avoid the shortcomings of scaling down (see above), prevent vendors from usually trading 1-2 contracts and suddenly go nuts and trade 30, avoid the current rescaling system that distorts previous trades to fractions of a contract, and so on. I see more advantages than disadvantages, but that’s just my opinion.
I forgot the monthly returns, for which you are correct that they will erode. But this will not change if you only limit the buying power and add new DD stat. I also agree that the equity curve will be different, but then again this would be unaffected by your initial suggestions. So your latest post suggests that you want much more than only a new DD stat, and that you basically want a revision of all % stats. I am not sure if this is the correct interpretation of your latest post, but if it is, then I don’t agree with it for the reasons discussed by Matthew. I also think that it would be rather confusing if there are two versions of each stat. Having two versions of only annual return and max DD is acceptable IMHO.
Sorry, I posted my previous post before I saw your answer. Yes, I still agree with these points and with your suggestions to add a new DD stat and to have the possibility to maximize buying power. I am only opposed to revision of the other stats, if that was implied.
It wouldn’t be a revision of the stats per se. It’s just that they would be calculated based on the fixed buying power, not on the varying account size of the system as they are today. There would only be one of each stat for every system.