iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: http://epchan.blogspot.com/2011/09/
Quantitative Trading: September 2011

Friday, September 30, 2011

Stop loss, profit cap, survivorship bias, and black swans

I have long espoused the view that we should not impose stop-losses on mean-reverting strategies, nor profit caps on momentum strategies. My view on the latter has not changed, but it has evolved on the former.

My original reason for opposing stop-losses on mean-reverting strategy is this. Say you believe your specific price series is mean-reverting, and say you have entered into a long position when the price is low. Now, however, the price gets much lower, and you are suffering a large unrealized loss. Well, based on your mean-reverting belief, you should buy more instead of liquidating! Indeed, if you backtest the effect of stop-losses on mean-reverting strategies, you will almost inevitably find that they decrease the overall returns and even Sharpe ratios.

But what this simplistic view ignored is 1) survivorship bias, and 2) black swan events. (Hat tip: Ben, who prompted me to consider these two issues.)

1) We normally would only trade those price series with a mean-reverting strategy only if we see that the prices did eventually revert. No one would bother to trade those price series that used to mean-revert, but suddenly stopped doing so. But saying that stop-losses are harmful to mean-reverting strategies is ignoring the fact that some mean-reverting will stop working altogether and would not survive our strategies selection process.

2) Let's define black swan events as those that did not occur in your backtest period. For example, let's say you never had a loss of 20% in a single day. So if you backtest a stop-loss of 20%, it will have no effect whatsoever on your backtest performance. However, no one can say for sure that it won't occur in the future. So if you or your investors simply cannot tolerate a 20% loss, you should impose this as a stop-loss. (After all, your brokerage has already imposed a stop-loss of 100% on you whether you like it or not.)

We can in fact turn point 2) around when deciding what stop-loss to use: a stop-loss should be loose enough so that it should have no effect on the backtest performance, and of course tight enough so that it will not result in the demise of your trading career.

There is also the issue of whether to use stop-loss on the intraday drawdown, or to use it on the multiple-day drawdown. I would argue that only intraday stop-loss is important to prevent a black-swan loss. In practice, when a strategy has a string of non-catastrophic losses occurring over multiple days, resulting in a large, unprecedented, drawdown, the trader will typically re-examine the strategy, taking into account this most recent performance and tweak the strategy so that it could theoretically be avoided. This is almost like a multi-day stop-loss strategy, as we stop an old strategy and start a new, modified, one. (Though the modified strategy might still recommend that you keep holding the current position!)

Now why am I still holding dear to the principle that one should not impose profit-caps on momentum strategies? Why, the possibility of black swan events again! But this time, any black swan can only result in unprecedented one-day gain instead of loss, since we should always have stop-losses on momentum strategies. We certainly don't want to impose a profit-cap to rule out this possibility!

Sunday, September 18, 2011

More on automated trading platforms

The ideal software platform for automating backtesting and executing your algorithmic trading strategies depends mainly on your level of programming expertise and your budget. If you are a competent programmer in, say, Java or C#, there is nothing to prevent you from utilizing the API offered (usually for free) by many brokerages to automate execution. And of course, it is also easy for you to write a separate backtesting program utilizing historical data. However, even for programmer-traders, there are a couple of inconveniences in developing these programs from scratch:

A) Every time we change brokerages, we have to re-write parts of the low-level functions that utilize the brokerage's API;

B) The automated trading program cannot be used to backtest unless a simulator is built to feed the historical data into the program as if they were live. To reduce bugs, it is better to have the same code that both backtests and trades live.

This is where a number of open-source algorithmic trading development platforms come in. These platforms all assume that the user is a Java programmer. But they eliminate the hassles A) and B) above as they serve as the layer that shield you from the details of the brokerage's API, and let you go from backtesting to live trading mode with a figurative turn of a key. I have taken a tour of one such platforms Marketcetera, and will highlight some features here:

1) It has a trading GUI with features similar to that of IB's TWS. This will be useful if your own brokerage's GUI is dysfunctional.

2) Complex Event Processing (CEP) is available as a module. CEP is essentially a way for you to easily specify what kind of market/pricing events should trigger a trading action. For e.g., "BUY if ask price is below 20-min moving average." Of course, you could have written this trading rule in a callback function, but to retrieve the 20-min MA on-demand could be quite messy. CEP solves that data retrieval problem for you by storing only those data that is needed by your registered trading rules.

3) It can use either FIX or a brokerage's API for connection. Available brokerage connectors include Interactive Brokers and Lime Brokerage.

4) It offers a news feed, which can be used by your trading algorithms to trigger trading actions if you use Java's string processing utilities to parse the stories properly.

5) The monthly cost ranges from $3,500 - $4,500.

If Marketcera is beyond your budget, you can check out AlgoTrader. It has advantages 1)-3) but not 4) listed above, and is completely free. I invite readers who have tried these or other similar automated trading platforms to comment their user experience here.

P.S. For those of us who use Matlab to automate our executions, a reader pointed out there is a new product MATTICK that allows you to send order via the FIX protocol which should let us trade with a great variety of brokerages.