Regular Stop Loss too slow - did I just find a solution?

 

Well it turns out when backtesting, I found out that the regular stop loss of MetaTrader 5 is an easy victim of slippage and the results are catastrophic, specially when the stop loss is "skipped" and "jumped over" (ignored). Sometimes it is simply ignored in intense movements and then you keep losing and losing and the stop loss is never activated.

Yea yea, I know. In a buy limit order, the stop loss hits the BID price (below) and in a sell limit order, the stop loss hits the ASK price (above).

However, it looks to me like the regular Stop Loss of Meta Trader 5 activates only when the instrument at the TERMINAL reaches the price of stop loss. And if it doesn't, it simply doesn't get activated. And then infinite losses are possible.

Not only that, it seems that even when the BID price is at the stop loss price (in the case of a buy limit order), it doesn't activate the stop loss. It only does when the LOW of the candle hits the SL price (correct me if I'm wrong). 

Also, I suspect that the delay between SERVER and TERMINAL might cause, in the case of strong movements, slippage to be worse.

Of course this happens on both buy and sell orders.


So I was thinking of a way to improve this issue, and SPECIALLY avoid having the stop loss being skipped and ignored.

And then I thought of the obvious, let's say, in the case of a buy limit order: why not, on every tick, check the BID price and then, if bid == stop loss, then do a market execution of a sell order?

I'm getting BID price by using SymbolInfoDouble(_Symbol,SYMBOL_BID);

I've implemented this idea on code, and when back testing, it turns out I had WAY LESS slippage and the stop loss order was never ignored again.


Of course I don't believe I was the first one to think of this solution.

My questions are: what are the drawbacks of this approach? Is my thinking correct? What am I missing? Is this worse than the regular stop loss included in pending orders on MT5?

Last but not least, is my way of getting the BID price (SymbolInfoDouble) actually reaching the server or only the terminal?

Thank you very much.

Documentation on MQL5: Constants, Enumerations and Structures / Environment State / Symbol Properties
Documentation on MQL5: Constants, Enumerations and Structures / Environment State / Symbol Properties
  • www.mql5.com
To obtain the current market information there are several functions: SymbolInfoInteger() , SymbolInfoDouble() and SymbolInfoString() . The first...
 

I commend you on realising the issue, but your analysis is incomplete which in turn affects your proposed solution.

Firstly, the back-test issue depends on what modelling method you are using for the back-test. For every modelling model, except the "Every tick based on real ticks", the Strategy Tester uses virtual ticks, which are based on the OHLC bar data (Bid only) and a reference "spread" stored with the OHLC data.

It so happens, that the "spread" stored is usually the minimum spread, not the average nor the maximum. In essence the spread is either zero or so small, that it is practically only using Bid prices for the modelling. This makes modelling pending orders or triggered stops very inaccurate.

Only when using "Every tick based on real ticks" does the accuracy improve. However, that is not necessarily a "good thing", because in a "live" trade environment, delays and slippage are a real thing and problematic. That is why the Strategy Tester offers the "Delay" setting, so that you can make slippage more pronounced to be able to stress-test your EA.

Your solution of using Market Orders instead of pending ones is a good one, and it is used by many savvy traders and EA programmers, but it also has its disadvantages, of which you need to be aware.

Yes, with the virtual pending orders (using Market Orders) you can better analyse the Bid, Ask and Spread and adjust or only trigger when the conditions are ideal for the strategy. But when "live" and the broker's trading servers are under high stress due to high volatility or low liquidity (e.g. during news events), there can be long communications delays, preventing your EA from updating and reacting in a timely fashion.

There can also be total loss of communications, leaving any open and exposed trades, floating without any trade or risk management in place.

The solution I use for exits, is to combine both methods, by having two levels for stops:

  1. A virtual/stealth stop that is triggered by the EA when conditions are ideal (e.g. at a 1% risk)
  2. A real hard broker-side stop, further out from the virtual stop, in case communications are lost and the EA is unable to trigger the virtual stop (e.g. at a 2% risk).

I do this for both the Stop-Loss and the Take-profit. If I am using a trailing-stop as my main exit, then I still set a continually adjusting hard take-profit further out, in case a loss of communications prevents the trailing-stop from updating.

In this way, all entries and exits are totally controlled by the EA, but the broker stop prevents exposed floating positions in case of a delays or loss of communications.

One more thing I need to mention, is that I do not rely on the SymbolInfoDoubleor the SymbolInfoTick for current quote prices, because they easily skip over incoming ticks. Instead, I use CopyTicks to obtain and process every tick (not skipping any) to check if conditions or levels were triggered.

 

Hi!

Thanks so much for your answer. You gave me great insights.

Yes, I'm using "Every tick based on real ticks" on my backtesting, and I'm using the same delay as I currently have as a parameter.

It's worth noticing that I'm only referring to stop loss orders. I'm not talking about starting a trade with a buy stop or sell stop order. Even though a stop loss order is also a buy/sell stop order, my only concern is about finishing a losing trade, not opening a trade.

Now you mentioned that virtual pending orders (using market orders) might suffer from communication delays that might prevent the EA from having the correct data at the right time.
But how is that different from the regular stop loss included in a pending order on MT5? Since the stop loss is NOT stored online. The common stop loss order by MT5 depends on the terminal to receive info from the server, recognize the price and THEN activate the stop loss order (in other words, if I close my Meta Trader 5, the stop loss order will NOT be activated once it reaches the stop loss price - It depends on the terminal (the MT5 application) to be running, and the terminal depends of the data it receives from the server). If there's a communication delay from the server, the delay won't be any different in the virtual stop loss order compared to the regular stop loss order. The difference would be HOW that position will be closed (what triggers it). I've written my code to execute a market sell order once the stop loss price is the same as the bid price (losing trade in a buy limit order), so I know what my code is doing. But I'm still wondering by what exactly the regular stop loss order is triggered... is it the candle low? Bid price? Why do I seem to have more slippage with the regular stop loss order instead of the virtual stop loss?

In order words: what are the benefits of using the regular stop loss order included in a pending order?

 
Arthur Monticelli #Now you mentioned that virtual pending orders (using market orders) might suffer from communication delays that might prevent the EA from having the correct data at the right time.

But how is that different from the regular stop loss included in a pending order on MT5? Since the stop loss is NOT stored online. The common stop loss order by MT5 depends on the terminal to receive info from the server, recognize the price and THEN activate the stop loss order (in other words, if I close my Meta Trader 5, the stop loss order will NOT be activated once it reaches the stop loss price - It depends on the terminal (the MT5 application) to be running, and the terminal depends of the data it receives from the server). If there's a communication delay from the server, the delay won't be any different in the virtual stop loss order compared to the regular stop loss order. The difference would be HOW that position will be closed (what triggers it). I've written my code to execute a market sell order once the stop loss price is the same as the bid price (losing trade in a buy limit order), so I know what my code is doing. But I'm still wondering by what exactly the regular stop loss order is triggered... is it the candle low? Bid price? Why do I seem to have more slippage with the regular stop loss order instead of the virtual stop loss? In order words: what are the benefits of using the regular stop loss order included in a pending order?

False! It seems you are mixing up some concepts.

Regular pending orders, or the regular stops (Stop-loss, Take-profit) are managed on the broker side, not on the terminal side. If you disconnect your terminal, the pending orders and open position stops (S/L, T/P) will still continue to function because their trigger levels are stored on the trade-server, not the terminal.

Only the trailing-stop functionality is managed by the MetaTrader terminal application. The normal stops and peding orders are managed by the broker's trade-server.

Only when an EA implements virtual/stealth pending orders or stops, does the control depend on the EA running on the terminal. That is why I stated that I use a hybrid model using both types of stops.

 
Fernando Carreiro #:

False! It seems you are mixing up some concepts.

Regular pending orders, or the regular stops (Stop-loss, Take-profit) are managed on the broker side, not on the terminal side. If you disconnect your terminal, the pending orders and open position stops (S/L, T/P) will still continue to function because their trigger levels are stored on the trade-server, not the terminal.

Only the trailing-stop functionality is managed by the MetaTrader terminal application. The normal stops and peding orders are managed by the broker's trade-server.

Only when an EA implements virtual/stealth pending orders or stops, does the control depend on the EA running on the terminal. That is why I stated that I use a hybrid model using both types of stops.

Well I didn't know that. It's strange cause when trading in the live account, the stop loss seems slow and I have the same kind of slippage as I have in the back tests (that's why I wanted to find ways to minimize them and came up with this idea of the virtual stop loss being executed as a market order). I haven't used this approach (virtual stop losses) on the live account yet. So I'm not really sure if slippage will indeed be reduced with this method, but at least during the back tests it seems to be improving.

Thanks so much for your help and I appreciate your time.

 
Arthur Monticelli #It's strange cause when trading in the live account, the stop loss seems slow and I have the same kind of slippage as I have in the back tests

Yes, in live trading, a stop can be slow when volatility is high or liquidity low, and slippage can and usually is worse than the simulations during back-tests. It also depends on the symbol, and the type of account you have with the broker.

Arthur Monticelli #(that's why I wanted to find ways to minimize them and came up with this idea of the virtual stop loss being executed as a market order)

Yes, you can mitigate slippage to a degree (but not completely) with virtual stops, as long as you also accept the disadvantages associated with virtual stops.

Arthur Monticelli #So I'm not really sure if slippage will indeed be reduced with this method, but at least during the back tests it seems to be improving.

Mitigating slippage is not as simple as you may think. You have to take into account the type of strategy and you really have to fully understand how things work at the tick level.

 

If I may chime in here... My best EA enters a position, immediately sends a fixed server-side stop order n pips away, begins to monitor a client-side dynamic exit that matches the price level of the fixed stop, and then the server-side stop becomes a trailing stop in theoretical synch with the client-side dynamic exit. The result is a stop competing with a dynamic exit.

How do I know where my dynamic exit will be at every moment?

It's all based on Renko bricks.😉