Measuring Slippage: Make it a Top Priority!

The computer reported a gain of +$1,365.81 for the Sistema SGA121 Daxsystem’s day trade on the iSystems platform on 4/25/14 after accounting for $17.26 in commissions , but clients trading the system earned just $1,249.29 on the trade. What happened? Where did that extra $116.52 go?

It’s called slippage, and it is the difference between where the computer signaled the entry and exit for a trade and where actual clients, with actual money, entered and exited the market using the computer’s signals.  But shouldn’t the computer reported profit and the profit in actual client accounts be one and the same, you ask? That would be nice, but no, there will always be a difference between the prices where the computer generates the signals and the prices actual clients using actual money get.

This can seem like an alarming problem at first, as even small differences of $20 to $30 per trade can add up to investor’s actual results being $1000 — $2000 less than the computer has generated over the course of a year.

But the good news is slippage can be fully accounted for in backtesting, and fully measured in real-time. And all of the hypothetical testing and reports on the iSystems platform include an allowance for slippage in order to give investors as realistic a picture as possible for what sort of performance they can expect moving forward.  Getting a handle on how much slippage to expect in each market a trading system includes in its portfolios is paramount to achieving success with these systems. If too little slippage was used in the testing, a system may be operating exactly as it was designed to operate, but at the same time grossly under performing an investor’s expectations.

Too many developers take the easy way out, unfortunately; by assigning a single number for slippage to each market. This number generally includes commission costs as well, and ranges from $10 per trade to $50 per trade, meaning many are allotting just $5 to $10 for each buy and sell for slippage.Is this enough? Are these slippage estimates realistic? The answers to these questions depend on many factors, but in first understanding why slippage exists, we can start to make educated decisions on how much slippage to account for in our backtesting.

On the iSystems platform, there are two separate ways to evaluate slippage, depending on if the system is active or only displaying backtested and forward tested results. If the system is not trading live, the slippage is a representation of the rolling 50 day average of slippage across all systems trading that market on the date being tested. While that may not sound all that impressive at first glance, it is a quantum leap ahead of assigning a fixed slippage amount in testing. This is a sort of big data approach to assigning slippage in testing, and uses the actual observed slippage across other systems trading the market you wish to test on. What’s more – it uses a 50 day average of the slippage, so the slippage is dynamic – increasing during periods of high market volatility and expanded bid/ask spreads, and declining during opposite periods of low volatility. It is also dynamic per market, meaning there’s no ‘one size fits all’ here. The Dax will rightly get a slippage number much higher than the Euro Stoxx, and so forth.

This dynamic slippage number is applied per market, per trade date, on any backtested performance – resulting in the amount the computer ‘thinks’ it made (or lost) on any certain date being decreased by the amount of slippage for that market on that day.

All of this can be seen in the ‘trade log’ and ‘session log’ for any algorithm on the iSystems platform, listing the so called ‘hypo fill’ (where the computer thinks it got filled) and the platform fill, which is the slippage adjusted price. Sound too complicated – luckily, this is all done by the platform automatically – with the slippage amount already built into the equity curve, the P/L, all returns, and drawdowns.

0 Comments

Leave a reply

Your email address will not be published.

*