How to calculate actual slippage from real life results?

AntiMatter · Post by **AntiMatter** » Wed Mar 30, 2011 4:39 pm

I want to derive a meaningful value to plug back into TB from my actual trading data. TB defines the slippage as the percentage of the OrderFill from the OrderPrice to the DaysHigh:

Slippage % = (ActualFill - OrderPrice) / (High - OrderPrice) * 100

Which is all when and good. I can then calculate my slippage on each real life trade, and take the average. However, in situations where I get a good fill (e.g better than the OrderPrice -- "Negative Slippage") and the distance between the High and OrderPrice is very low, the above calculation can give me extremely distorting values for slippage - the slippage may be -200%, for example. This results in an average slippage which is overly optimistic.

There are some obvious solutions, but I'm not sure....

1) I could take a very conservative estimate whereby I only take an average of those values where slippage > 0.
2) I could take a fairly conservative estimate whereby when slippage is less than zero, I change the value to zero. I then take an average of all values.
3) I could calculate the slippage for those with negative slippage as the distance to the days low (e.g, so that the maximum negative slippage is also -100%). This would seem to produce the most realistic figure.

What do people do here?

sluggo · Post by **sluggo** » Wed Mar 30, 2011 6:08 pm

Do you have access to the Blox Marketplace? If so, this free download may stimulate your thinking: (LINK)

This example block loads up a custom slippage file so that each market can use a different slippage amount. The fill prices are then computed using this custom value.

AntiMatter · Post by **AntiMatter** » Thu Mar 31, 2011 4:25 am

Thanks sluggo, I did see that, it does seem useful. Fwiw I'm trading stocks, so sometimes I will only trade an instrument once, hence I haven't looked closely until now.

Nonetheless, I guess in theory using ATR/volatility based slippage would overcome my above calculation problem. However, at this point in time, I am backtesting using TB, and real-life trading using custom software. It would be some work to get the ATR for the instruments I have traded, and then plug this back into my spreadsheet for ATR based slippage results.

Thus, for the time being, I'm going to have to go with something like number (3) above for simplicity, unless anyone has any thoughts? What do others do?

sluggo · Post by **sluggo** » Thu Mar 31, 2011 8:20 am

One of the ways the Marketplace Block may stimulate your thinking is this: it may nudge you towards realizing

Eureka, I am not forced to use the slippage calculation formula presupplied in Blox! I can write my own code to calculate and charge slippage however I wish!

After that eureka moment, you may decide to write out a list of a couple dozen possible ways to calculate slippage, which you could implement in Blox code yourself, if you wanted to.

The list of your ideas might include

XYZ percent of the (High - Low) range of the entry bar
XYZ percent of the True Range of the entry bar
XYZ percent of the N-bar ATR
XYZ percent of the N-bar range: HH(N) - LL(N)
XYZ percent of the N-bar standard deviation of closes
Randomly chosen sample from a file of your actual slippages on your actual trades
Randomly chosen sample from a probability density function of your own choosing
The average of calculations 1-5 above
The second-biggest value from calculations 1-5 above
Whichever is bigger: (2 x instrument.minimumTick), or calculation 3 above
Whichever is smaller: $100, or the average of calculations 2 and 4 above

(If you're already trading in real life with real money, you could analyze your own actual trades to see what actual slippage you've actually experienced. Then you could use your actual slippage data to calibrate your Blox calculations (which are, after all, mere estimates) of slippage).

AntiMatter · Post by **AntiMatter** » Thu Mar 31, 2011 11:21 am

lol @ sarcasm, fair enuff

..... BUT I WANT WANT WANT quick easy fixes/hacks..... writing a custom slippage block is sooo far down the to-do-list that it isn't even funny.

OK I'm going to try and think for myself here, so please be patient with me.....

I should imagine that 1-5 above are going to give somewhat comparable results. However, ATR/volatilty could be problematic under my current system (atypical market conditions). Moreover, given that I have actually been keeping data for (1), I would like to use something along those lines. However, I'm struggling to think of a simple/elegant way to take this data from real-life, get a value e.g. 20% slippage, and plug it into TB (with either the default, or with a custom block).

With your no.1 - slippage as a % of distance from High-Low: This would work fine for record keeping. However, when backtesting with TB, it could give some strange results where the entry point is very close to e.g. the high, but the low is a long distance away. Essentially the mirror of my original problem.... which brings me full circle. So maybe I should run with my original suggestion number 3 for now.... I can't think of a better simple solution for now.

sluggo · Post by **sluggo** » Thu Mar 31, 2011 1:48 pm

Just imagine that history woulda been different if your buy order was present.

The historical "high" price in your historical data set, came from an alternate universe that did not include your buy order. In another, different, alternate universe which does include your buy order, your bidding influences other market participants. Just imagine the result being a higher "high", which enables your buy order to be filled at (your_orderprice + your_slippage) and still remain below the (now higher) high.

Or, imagine that history woulda been half-different. Calculate price1 = (your_orderprice + your_slippage). Calculate price2 = MIN(price1, Historical_High).

Fill half your order at price1 and the other half at price2. When in doubt, do half. (reference)

AntiMatter · Post by **AntiMatter** » Thu Mar 31, 2011 2:22 pm

Ah yes, of course - I need not worry about producing a trade on a backtest which is outside of the OHLC bar. In fact, it might be "more realistic" than history.....

Thanks for the help.

rabidric · Post by **rabidric** » Fri Apr 01, 2011 3:54 am

lets not forget the butterfly effect!

your 1 lot triggers a snowball of orders that , while not giving any slippage to that order itself, triggers a black swan blow out of a 25ATR multiple consecutive limit days price spike, which results in your other 3 strategies/units all getting filled at obscene prices

AntiMatter · Post by **AntiMatter** » Fri Apr 01, 2011 5:11 am

lol, i will get started on teh BlackSwan.tbx right away then