8
$\begingroup$

I have two backtesting algorithms:

  1. One that uses bid and ask prices for signal generation. For example: Buy when $ask < threshold_1 $ and sell when $bid > threshold_2$. Bid and ask prices are calculated from the closing price using a 20 basis-point spread.
  2. One that uses closing prices for signal generation. For example: Buy when $price < threshold_1$ and sell when $price > threshold_2$. The 20 basis-points bid-ask spread is taken as a transaction cost and subtracted from the P&L.

The two alternatives give me different results. I guess that the first backtesting algorithm is closer to reality, but the second (i.e. considering bid-ask spread as a transaction cost) is common among the literature.

What's the rationale of considering bid-ask spread as a transaction cost and which of the two alternatives should I use?

PS: I'm backtesting a mean-reverting pair-trading strategy of liquid ETFs.

Improve this question
$\endgroup$

4 Answers 4

Reset to default
6
$\begingroup$

Other answers all give helpful advice, but none actually answer your question, so I will try.

First off, backtesting based on close is reasonable only as a poor-man's first approximation, and before committing serious capital I would recommend collecting some higher frequency data. Having said that, it is actually quite common to investigate ideas quickly using close price data, and what you suggest is not unreasonable.

The differences between the two strategies you mention actually has little to do with transaction/liquidity costs. Rather, especially given the mechanical way in which you construct bid/ask prices, the difference will primarily be driven by the increased difference between the two thresholds for buying and selling. Ultimately, it does not matter whether you consider yourself to always be buying at the "ask" and selling at the "bid", or whether you adjust the thresholds and add the bid-ask spread at the end. It is more important to just understand exactly what you are assuming so you can replicate it as closely as possible in live trading.

FYI, the way you have set up your strategy also appears prone to look-ahead bias. Keep in mind that you do not know the close price until after the close, by which time it is too late to decide whether you are buying or selling. This is a problem for either of your two proposed strategies. Be careful to never use the same data point for signal generation and execution. When working with daily close data, common practice is to execute on the next day's close. This is a very hard barrier to overcome, though, and is yet another reason to invest in higher frequency data.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ After receiving a signal from daily close data the earliest opportunity to open a trade would be the following day's open. Why is it "common practice" to use the following day's close? This implies that one waits a whole trading session before acting on the signal. $\endgroup$
    – babelproofreader
    Commented Sep 17, 2012 at 18:08
  • $\begingroup$ @babelproofreader I think he means that when your test data is just a time series of only closing prices, you don't have the open price available $\endgroup$
    – Paccc
    Commented Sep 23, 2012 at 0:35
  • 2
    $\begingroup$ No, this is the common practice because you need to allow time for the order to be executed. It is unrealistic to assume the trade could have been executed at the next day's open. If you have higher frequency data, as I said, that is better. $\endgroup$
    – Tal Fishman
    Commented Sep 23, 2012 at 12:42
5
$\begingroup$

We discussed the validity of using bid-ask spreads as transaction costs in this post.

Essentially the bid-ask spread represents the cost of liquidity which can be seen only as part of the transaction cost you will have to pay in live trading.

There are a lot of things to be considered if you want to include transaction cost in your backtest. The main factor you do not include in your model is simply the transaction fee that the broker will charge you. Another aspect that can drive you crazy is the slippage (see the post previously mentioned) which is very difficult to model. And that's just the beginning, you can then add market impact, bugs in your execution system, and so on...

In general, the problems that arise during live trading are grouped in the implementation shortfall concept. I think you will never be able to take everything into consideration during the backtest and you should always expect that things can go wrong when you're live. Arguably, that's part of the beauty of trading.

Improve this answer
$\endgroup$
5
$\begingroup$

The bid/offer spread is informative about a narrow range of transaction sizes, i.e. the quote depth. E.g. if we see a bid/offer of 99/101 with quantities of 1000/1500 shares respectively then we know that doing a trade to sell upto 1000 shares will get an execution of 99 and doing a trade to buy upto 1500 will get an execution of 101.

But the trades that you might like to do include many values far beyond this narrow range (from -1000 to +1500).

Modern electronic markets show the full order book which is a whole new perspective on liquidity. Given good datafrom a modern electronic exchange, you can simulate the execution obtained by any one single market order. This is a whole new world in terms of the observability of transactions costs.

See http://ajayshahblog.blogspot.in/2012/05/costs-in-buying-versus-costs-in-selling.html

Improve this answer
$\endgroup$
4
$\begingroup$

IMO, there is only one satisfactory answer to your question. You must measure the actual total cost of implementation. Spread, slippage, comish. Test what you trade/trade what you test.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.