Couple of questions that significantly impact how we evaluate these systems -
1) Reported P&L (%) - is this based on starting model account size? If so, it doesn’t tally for several systems - e.g. 1DayNQ has been active since 1year, and reported P&L (compounded) is 159% per-yr, but the sum of daily P&L from the csv file is $59K (which is 590% on the starting model account size of $10K). Since most of the daily P&L are profits, compounding will make these gains even higher than 5.9x.
2) The % of the model funds that are invested in active positions seems inconsistent. e.g. Futures Daily system has a model account of $232K but invests only $2500 on each day, even though the margined requirements seem to be only $25.4K. As a result, most of the model account is sitting in cash, and the system performance is under-reported. Shouldn’t it take much bigger positions and minimize cash holding to just the margin, to show the true P&L performance?
3) Related to (2), when i subscribe to a system for manual email alerts (not auto-trading), does it recommend position size based on my account size? Or do i have to size my positions based on my account size? If it’s the latter, how do i determine typical/recommended % of account to invest in a system?
thanks
Kiran[LINKSYSTEM_52737021]
I’ll take a shot at answering question #2 and #3
Some vendors try to keep a constant position size so that subscribers can jump in at any time and still work with the same position sizes as if they started at the beginning. The obvious disadvantage of doing this is that the system shows no performance gain through compounding. The system equity curve goes up rapidly to start, then flattens out.
Other vendors maintain position size as a fraction of the system equity, and periodically rescale the system as equity grows. This allows for compounding performance characteristics to be maintained, but has the disadvantage of requiring subscribers to perform appropriate scale adjustments in their own accounts to match the system’s position sizes.
Given the first case, the vendor may recommend a position size for trades and always maintain that position size.
For the latter case, it will, likely, be up to the subscriber to determine the appropriate position size, but most vendors are happy to help subscribers perform the appropriate calculations so their own accounts scale to match the system account as closely as possible.
Thanks Jack,
Still need to know how Reported P&L (%) is calculated - is this based on starting model account size? If so, it doesn’t tally for several systems - e.g. 1DayNQ has been active since 1year, and reported P&L (compounded) is 159% per-yr, but the sum of daily P&L from the csv file is $59K (which is 590% on the starting model account size of $10K). Since most of the daily P&L are profits, compounding will make these gains even higher than 5.9x. [LINKSYSTEM_47139702]
Kiran
Your math is wrong. Are you looking at the same system that you are posting about?
Specifically, the equity of system 1 Day NQ (system 47139702) is now $24,705. The starting account was $10,000. That means an increase in account equity of 14,705 – not $59K. Where did you get that $59K number from?
I double-checked the CSV file about 30 seconds ago, and when I add the right-most column, I get approximately $14,000 … not $59,000. What numbers are you looking at?
Regarding questions 2 and 3: System developers are allowed to manage the money in their C2 Model account however they like. At C2, we think money management is just as important as being correct about buy and sell signals. So if a system developer wants to bet 10% of his C2 Model Account on a position, that decision is part of the system, just as is whether to go long or short.
All % Return numbers therefore are based on total account equity. This is industry standard. Basing return numbers on “capital” invested per trade is not only unhelpful from a subscriber perspective; it’s also not kosher from a regulatory point of view. (I say it’s unhelpful for subscribers because, as a subscriber to a C2 system, you can’t know in advance what trade sizes will be used by the system – not with certainty, anyway; but you can know the upper bound of the system’s Model Account size, and thus can scale your trades appropriately).
Regarding trade scaling:
If you simply “subscribe” to a system without AutoTrading, you’ll receive the trade signals as entered by the system vendor. If he has a $100,000 Model Account, and he opens a position for $10,000 of stock, for example, the signal you will receive will be to Buy $10,000 dollars of stock. We assume customers trading manually will be able to decide how to scale trades into their own accounts, based on the knowledge of how large the C2 System’s Model Account is, versus the customer’s trading account.
People who use C2 AutoTrading will be able to set a “scaling factor” which will translate trade sizes so that they meet with your own personal account criteria. The typical way this is used is as follows:
Let’s say a trading system has $100,000 in its C2 Model Account, but your real-world brokerage account has $25,000. A typical way to configure AutoTrading in this case is to select a “AutoTrade scaling” of 25%. In addition, on top of the percentage-based scaling factor, you can also specify maximum unit sizes per trade and position.
Matthew Klein said on 2/08/11 (9:20) in reply to my previous post, âReturns are based on STARTING Model Account value. In other words, if the system starts with $10,000 cash on C2 that is the denominator for return calculationsâ.
My system always uses a constant position size of $17,500. My STARTING Model Account value was $20,000. If I make $2,000 in a month then C2 reports I made 10%.
In a few years, say my model account value has built up to $100,000 but I still only use a constant position size of $17,500. If I still make $2,000 in a month then C2 still reports I made 10% (âbased on STARTING Model Account valueâ) and not $2,000/$100,000 = 2%.
Otherwise I would need to keep rescaling back down to $20,000 as my equity built up in order to show 10% gain when my system made $2,000. The problem with C2 rescaling is that it is not real life and previous 10% gains are all rescaled down.
When I say “returns are based on starting model account value” I mean that - for any percentage-based return calculation on C2 - the denominator is the total account value at the initial time you are considering.
Example: When C2 calculates Feb 2011 percentage-based return, we do this: February profit / February starting capital.
Example: When C2 calculates your total system return (for all time), we do this: Total profit / starting capital.
Regarding rescaling:
Let me explain what “rescaling” is for on C2. Rescaling is simply a way to change the magnitude of your account size, without changing any trading results on a percentage basis. It is used (for example) when a system makes a lot of profit in its C2 Model Account, and so would otherwise be forced to start using very large trade sizes (in terms of units or shares) in order to deploy a desired percentage of capital. Many people do not like typing in trade sizes of “1000 contracts” or “$250,000 dollars worth of stock.” Rescaling allows you to reset the magnitudes of your trade sizes while keeping historical results intact on a percentage basis.
Here is what rescaling is not. Rescaling is not used to “take cash out of your C2 system” – an idea which makes no sense in the context of how C2 works. (After all, how can you command that your AutoTraders “take money out” of their real life brokerage account? You can’t. And if your AutoTraders don’t do so, but your C2 system acts as if it has, then all subsequent AutoTrades will be at the wrong magnitudes versus subscribers’ desired preferences. So this idea is a non-starter.)
You have mentioned several times that you desire to “use a constant position size of $17,500” for your C2 system’s trades.
While the idea of a fixed position size is a good one, you shouldn’t fix the dollar-magnitude of your trades. That idea doesn’t really work in the C2 context. You should fix the percentage-of-account-capital.
Here’s why. You will have AutoTraders who will be following your system at a fixed percentage level. So: if you make 20% during a year, but you insist on keeping your position size at a fixed dollar amount of $17,500, that means that over time, effectively you will be recommending to your autotraders to trade at smaller and smaller sizes versus account capital. (And if your system loses money, it means you will effectively cause your AutoTraders to trade at higher and higher percentages versus account capital.)
The important thing to remember is this. As your C2 Model account grows (or shrinks), your AutoTraders’ accounts will grow and shrink by the same percentage (multiplied by their autotrade “scaling percentage,” of course). So if your desire is to trade with a fixed trade size, you should not keep the number of dollars fixed. You should keep the trade as a percentage of current capital fixed. This will achieve the results you seek.
Since the number of contracts my system trades is fixed to a maximum of five so the NUMBER OF DOLLARS is fixed (5 x $3,500 = $17,500). I set my starting model at $20,000 to allow for DD. I only need a $17,500 maximum investment. I do not want to change the number of contracts traded as my model account balance changes. My system never buys more than five contracts even if I have a ten billion dollar model account balance.
Since C2âs stats calculate returns based upon model account balance, I guess I will have to keep rescaling each month as the model account balance increases so my returns still look good (i.e. large). Would this constant rescaling be confusing to subscribers?
IMHO returns should be calculated based on the size of the investment rather than the model account balance or my total net worth or the value of beans or anything else.
I guess it begs the question…
What would you do if the CME decided to change the margin maintenance requirement on NASDAQ 100 e-mini futures (since your assumption of "fixed investment dollars" seems to be based on that)?
My system uses position (money) management based on market conditions rather than based on model account balance. ROI is normally based on how much you INVEST - not on how much you have.
Hi Warren,
I would say that you should rescale every time the equity of your system has increased by a certain percentage point and not after a certain time period, like one month, as you suggest, in order to keep your equity curve and CAGR comparable to systems which base their position size on total equity.
I can understand Matthew’s point to show returns based on industry standards, that is Compound Annual Groth Rate (CAGR), although I have long advocated that in the statiscs section below the CAGR the APR (non compounded return as shown, for example, in the Grid) should also be shown.
Karl
Matthew,
In addition to CAGR (or P&L %), C2 should report another metric that shows the money management style of each system (something like perhaps Avg Position Size over last month/Current Model Account Size: .
you might think of a better metric). Also, the system seller should indicate the rationale for their money management/scaling strategy (i.e. why are they leaving such a large cash position in their model account)
This will help system buyers assess why the equity curve is flattening out - either because the system isn’t rescaling as the equity OR the system isn’t working as well as it originally did.
This also helps system buyers make the decision whether to adopt the system sellers scaling strategy or to re-scale their own manual or auto-trades based on their own risk appetite.
Kiran
I still don’t understand why we need this confusing model account ‘scaling’. I have never ‘scaled’ my real world IB account. I use Wealth-Lab and that provides all kinds of stats and equity curves (that don’t ‘flatten out’) and % returns (based on invested equity) calculated correctly without needing to ‘scale’.
If a buyer wants to trade double or triple the number of contracts then that is possible in C2’s autotrade setup without needing to ‘scale’ my model account. I guess I will just have to live with C2 ‘scaling’.
