Using execution delay slippage

Modified on Mon, 21 Aug, 2017 at 11:23 AM

Preamble

Backtest slippage based on execution delay attempts to simulate slippage as it occurs when using live accounts opened with true ECN brokers. On live servers, there is a delay between the time the order is sent and the time it is received by the server and executed; the market price can - and often will - change during this time interval. The Tick Data Suite is able to simulate such an execution delay and execute the order at the prices that are current after a certain amount of time.

To give you an idea how to configure this, you need to check your journal and compute the delay between the time the order was sent and the time the order was executed. For example, you may have something like this in your log file for a closed order:

0        16:54:35.180        '1234567': close order #4865179 buy 0.55 EURUSD at 1.11977 sl: 1.06843 tp: 1.16843 at price 0.00000
0        16:54:35.330        '1234567': order #4865179 buy 0.55 EURUSD at 1.11977 sl: 1.06843 tp: 1.16843 closed at price 1.13978

The difference between the time of sending the order close command and the time the MT4 terminal received information about the actual order closure is 150ms in this case. Ideally you will compute this for many, many market orders, put all the numbers in a table and determine a minimum and maximum using for example an average and the standard deviation.

It's important to note that the delay computed this way is round-trip, meaning that the server received your order in less than half the time, took some time to execute it and then sent back the reply. In our example, it could be that the command to close the order took 70ms to get to the server, the server spent 10ms executing it and the execution result took an additional 70ms to get back to the MT4 terminal. So, given the above example, the actual execution delay was not 150 milliseconds, but rather somewhere around 80-85 milliseconds from the point of view of the server (using the assumptions made above).

Long story short, the real execution delay is typically a bit more than half the delay that can be computed from the log entries displayed in the MT4 journal.

Depending on the bridge plugin used by the MT4 broker and on its configuration, this type of slippage may or may not happen for pending orders (stop, limit, SL, TP) - if these orders are configured to sit on the liquidity provider server, they will execute at the price that triggered them and incur no further slippage. On the other hand, if the pending orders are stored on the MT4 server they will also incur slippage; the execution delay is smaller in this case because presumably the broker has a good connection to the liquidity provider. If you're seeing slippage in your live account for pending orders, a decent way to estimate the execution delay is to subtract your average ping time from the average delay that you have on your market orders.

Disclaimer: execution delay slippage is meant for EA developers. While it can indeed be used with any EA, due to the limitations exposed below it may be that some EAs will not work properly with it. If you don't know what your EA is doing internally, it could be that it will not work at all or it will yield incorrect results although generally it should be perfectly fine for most EAs. Please note that Tick Data Suite support cannot offer assistance for issues related to using execution delay slippage with EAs that you do not have the source code for; if in doubt, contact the EA vendor, point them to this article and ask them if their EA should work with this type of slippage. Alternatively, you could simply use a different slippage type.

Recommendations

The following configuration is recommended if you enable slippage and select the Execution delay slippage type:

Enable Simulate live execution for all pending order types (stop, limit, SL, TP) in the Advanced tab of the Tick data settings dialog. This will ensure that these orders are executed at the price that triggered them and that they cannot be executed inside a gap - just like it happens on ECN servers.
If you're using an ECN broker and trying to simulate their trading conditions, ask them if the pending orders sit on the MT4 server or on the liquidity provider server. Otherwise, you can observe the execution of pending orders in your live account and identify if they have slippage or not - if they have slippage, they're typically on the MT4 server whereas otherwise chances are they're at the LP. If uncertain, err on the safe side and enable slippage for pending order types - most MT4 brokers keep the pending orders on the MT4 server.
- If the pending orders sit on the LP server, disable slippage for all pending order types (stop, limit, SL, TP) in the Slippage tab of the Tick data settings dialog - since they are supposed to be executed at the price that triggered them, there is no need for them to execute with a delay.
- If the orders sit on the MT4 server, enable slippage for all pending order types (stop, limit, SL, TP). For TDS v2.2.5 and newer, you can separately configure the Pending order delay - you can use the difference between your execution delay and your typical ping time to configure it.
Ensure that your EA does not send more than one order with each OnTick() call. If it does, make sure that the limitations (see below) are fully taken into consideration.
Verify that the Enforce OrderSend slippage parameter checkbox remains disabled in the Misc tab of the Tick data settings dialog. You do not need to enable it unless you want to test the reaction of your EA to requotes. If you enable it and do not send a sufficiently high slippage parameter with your OrderSend() calls you will get a lot of OrderSend Error 138 in your backtest log - see the features for more information about this.

Features

There are several things that are good to know when it comes to execution delay slippage:

The Ask and Bid prices are updated to the prices of the new tick after an OrderSend() that had slippage. You do not need to call RefreshRates() but there is no harm in doing it.
When slippage occurs, ticks will be skipped if they are situated between the OnTick() call during which the order was sent and the tick with the price that the order was executed at. In other words, just as it is with live execution, your EA will not be receiving ticks while it's waiting for the order to execute. These ticks are practically gone from your backtest.
The number of processed ticks displayed at the end of the backtest will not include the ticks that were skipped due to slippage.
When the Enforce OrderSend slippage parameter checkbox is enabled in the Misc tab, repeated OrderSend() calls that result in a requote will push the current tick further and further if they are sent during the same OnTick() event.
You can find out detailed information about the slippage of each order in the backtest journal. For each order, the actual slippage is logged together with the computed execution time and the delay between the tick that generated the order and the tick that was the most recent after the computed time passed.

Limitations

Due to the nature of the MT4 backtesting engine, there are unfortunately some limitations:

When execution slippage occurs, prices cannot slip ahead further than 1000 ticks during each OnTick() event. If you use very large delays or if you send multiple orders during the same OnTick() event, they will simply stop slipping after 1000 ticks.
TimeCurrent() does not get updated when an order has delay slippage. It remains at the same value that was valid when the OnTick() event occurred.
Using Sleep() does not advance the backtest time by skipping ticks.
If delay slippage pushes the current tick into the next bar, the bar series and indicators are not updated until the next OnTick() event. That means Open[], Close[], High[], Low[], Time[], Volume[], iOpen(), iClose(), iHigh(), iLow(), iTime(), iVolume(), iHighest(), iLowest() and so on will return the values that were valid for the bar during which the OnTick() event occurred. Consequently, the indicators will also update during the next OnTick() event. Bottom line is that if your EA sends multiple orders during a single OnTick() event, do not rely on updated indicators or bar series. For example, this can happen if you're backtesting the M1 timeframe, your OrderSend() occurs at XX:17:59 and it gets pushed by execution delay slippage until XX:18:01.
When using stop and limit orders pay attention to their attached SL and TP if the Simulate live execution option is enabled. Just as it happens on a live server, if a gap is encountered your pending order may get executed and then closed immediately due to a SL or TP price that gets triggered by the same gap.
There is no delay for OrderModify() and OrderDelete().
Keep the slippage delay realistic, in a range between a few milliseconds up to a few seconds, just like the delays seen on a live account. Do not try to simulate slippage over 60 seconds or multiple orders per OnTick() event that can slip over 60 seconds total - doing that will result in bars that are completely skipped when backtesting on an M1 timeframe.