C2 draw down does not make sense

Just look at the system market extreme.

BTO 400 GGDBL GOOG Feb06 360 call 2.34 2/13/06 14:59 STC 400 0.96 2/15/06 13:00 ($27,500)



If I understand correctly, the draw down should be the worst case of the trade before the trade is closed. For this trade, the realized lose is 55K but the drawdown is 27.5K. Does it make sense? It looks like against common sense.

Correct me if I am wrong.

It seems that the software is giving c2 a problem. I agree with you on that point Dave.

Actually, if you look at those systems with young history, you can find many C2 calculated parameteres are ironic. For system with many trades, it is hard to find by common sense.

So these kind of parameteres are misleading subscribers instead of helping subscribers.

I am wonderying why only I pointed out this kind of problems. It only requires common sense to figure out.


Here is another example: as can be seen below, the trade(1) (which is a multi-leg trade) has a realized gain of $13267 and max draw-down of ($13077); Trade(2) has a realized gain of $185 and max draw-down of ($525); From risk/reward standpoint the trade(1) is surely better than trade(2). But C2 consider the DrawDwn/Risk for trade(1) as “extreme” and trade(2) as “low”, which is kind of ironic … unless I misunderstood something here.


(1) BTO 61 @EUH6 1.1914 2/23/06 3:36 STC 61 1.1931 3/1/06 10:33 ($13,077) Extreme $13,267

(2) STO 5 @YMH6 11148 2/22/06 11:02 BTC 5 11140.60 2/22/06 15:13 ($525) Low $185

The per-trade risk ratings are not based on the eventual profit of the trade. They are calculated based on the percentage of your entire account equity that you lost during the course of the trade. Certainly it’s hard to argue that losing $13,000 of your $100,000 account entails less risk than losing $525.

Ok, that explains it. Thanks.

But what about the following case then?

The trade(3) below has exactly the same entry and max DrawDwn as trade(1) but a much bigger realized gain of $53000. In this case would C2 still consider the DrawDwn/Risk for trade(3) as “extreme”?


(1) BTO 61 @EUH6 1.1914 2/23/06 3:36 STC 61 1.1931 3/1/06 ($13,077) Extreme $13,267

(3) BTO 61 @EUH6 1.1914 2/23/06 3:36 STC 61 1.1997 3/5/06 ($13,077) Extreme?? $53,000

(Note: this trade(3) is not a real C2 trade. I made it up just trying to understand what the C2’s “DrawDwn/Risk” definition would be in this case.)

Yes, because the amount of the account you risked would be the same. At the time you risked that percentage of the account, you did not know whether the trade would work out or not. In other words, the risk assessment does not look back with hindsight at whether the trade was ultimately successful.

How about the case I brought up? Any explanation?

There was a bad tick in the historical data we analyzed. When I cleaned it up the dradwown figure was corrected and now makes sense.

Here are more problems.

Looking at the last trade of Bender’s S&P Emini crossover, the last trade was closed for a loss of $7499, but yet the worst drawdown is displayed as $3750 which is half of the loss. The worst price it is based on is 1290, but yet the fill breakdown, show fills as low as 1285.

Looking at the second last trade in his system, a short trade, the drawdown is based on a worst price of 1298.25, but when you look at the trade breakdown, there was a limit order filled at 1298.5!

The drawdown & risk statistics is good idea, but there are so much errors, that this is pretty useless. Instead of helping potential subscriber choose among systems, this just increase the workload as now subscribers have to verify each and every drawdown statistic to see if they are valid, or not. Maybe this is just a small percentage which is wrong, but without verifying them manually a subscriber don’t know.

I think the whole risk/profit thing should be scrapped and efforts should be directed to do something about the “Best Systems” lists, as those lists seem to be unable to really highlighting the best systems.


The most glaring error I’ve seen for this is the second trade the Black Dog system made (scroll to bottom of table). The table shows a drawdown of nearly $6 million ($5,761,750) on 10 ES contracts. Obviously a bad price in the data and not a legit number, but it is indeed hard to judge how accurate things are for other trades and systems where the error may not be as obvious, and a higher risk may be perceived by a potential subscriber than is really there (or vice versa).

Yeah, it is obvious that calculation is wrong. For others, it might be wrong but it is hard to find out.

Draw down is not the only one which has problems. Other statistics also have problem. They look good (helping) but have problems (misleading).

When the system owners see their web page, next to each drawdown stat they see a little button that they can press that says “Fix.” They can press this if they feel the drawdown stat is in error, in any way. (I’ll be introducing a series of these 1-click Customer Service buttons over the next week or so.) So, when you see a bad dradwown stat, that means the system owner hasn’t taken the time to alert me that there is a bad tick in the historical data.

Keep in mind the historical max drawdown data is based on 1-minute bar historical data, which is populated with lots of incorrect ticks. Over time, all the historical tick data will get cleaned up. There are tens of thousands of trades on Collective2. It’ll take some time, but we’ll get the meta-data about each trade clean over the next few weeks. I do need system owners’ help, though. If you see an incorrect drawdown, press the “Fix” button to let me know that there is something that needs correcting.


One more.

System: Bender’s S&P Emini crossover, the last trade

BTO 65 @ESH6 1287.69 2/27/06 20:54 STC 65 1285.38 3/1/06 9:44 ($3,750)



Technically, it is very easy to solve this problem.

If drawdown > profit/lose, then double check.

Matthew: Can’t you program in s few simple filters for your incoming data? I’ve seen quotes where the decimal place was off, quotes with a price of “0”, etc. These large errors would be very simple to detect. Maybe less so are transpositions where corn is reported at 223 instead of 232. But this is still a large magnitude error that could be filtered. I’m having to program similar filters in my systems…


Good to know a vendor can report it, but in the example I provided above, the drawdown displayed is clearly much less than what it should be. I bet many vendors would be tempted not to report an error like that, because the error make their system looks better.

If your clean up procedure depends on vendors reporting them, then this is a very unreliable method. Another reason, why this feature just doesn’t work and should be ignored by potential subscribers. If I am a vendor, I will just give up reporting all the numerous problems. This will get old really quickly if you have to day after day report the same type of problem over and over.

If bad ticks will take a few weeks to get clean up, this mean when I review a system, I should ignore the last couple of weeks’ stats because they will be error prone. The only solution then would be for C2 to not calculate the figures realtime, or near realtime, but rather wait a few weeks before posting the results for the trades.

However, I for one does not use this feature at all anymore when comparing systems and probably will never do. I just don’t trust the results and unfortunately first impressions are lasting. Of course, I cannot speak for other subscribers, but in my opinion this is just not worth the time and energy trying to solve problems for a feature which most likely will be ignored by majority of users.