Slippage Control plugin for MT5

SlippageControl for MT5 is a server plugin (CPlugin.SlippageControl64.dll) that decides the fill price of stop losses, take profits, pending orders, stop-outs and market orders. A price has to be confirmed by a run of consecutive ticks before it is used, and the broker picks which price of that run wins. This is the MetaTrader 5 edition of the MT4 plugin of the same name: the rules, parameter names and journal format are the same wherever the two platforms allow it — see Differences from the MT4 version. The MetaTrader 4 edition has its own guide: Slippage Control plugin for MT4. The product page Slippage Control compares both editions.

How it works in MetaTrader 5

MetaTrader 5 has no plugin hooks for "stop loss triggered" or "pending order triggered". Instead, on every tick the server itself creates a server trade request — activate SL, activate TP, activate a pending or stop-limit order, stop out a position — and routes it the same way as a client request.

SlippageControl works as a dealer: the broker routes the request types to be controlled to the plugin's manager login (action ACTION_DEALER), the plugin holds each request while it counts ticks, then confirms it with the price chosen from the tick window — after that price has passed a safety check. A request the plugin does not handle (disabled, group or symbol not matched, outside news hours, ticks * = 0, no licence) is never taken: it continues through the broker's next routing rules exactly as if the plugin were not installed.

Installation

Settings

Parameters are set in the plugin configuration in MT5 Administrator (not an .ini file next to the DLL, unlike MT4) and apply immediately, without restarting the server. Parameter names match the MT4 version wherever the meaning is the same.

Scope — who is affected

An exclusion (!) wins regardless of its position in the mask. If no news period is configured the plugin works around the clock; with periods configured, only inside them.

Confirmation — how many ticks

0 disables the plugin's involvement for that request type completely. satisfied means the last N ticks must all satisfy the trigger condition; following means the window is the triggering tick plus the N − 1 ticks after it, not re-checked. Stopouts are always answered the moment the request arrives, from the last N ticks seen; market orders always use the N ticks that arrive after the request.

Price — which tick wins

worst/best are the worst/best price of the window for the client; first/last are the first/last tick of the window; order is the SL/TP/order level itself; fair-worst is the worst price that is still not worse than the level for the client (falling back to worst/refusal if none qualify). Unsupported combinations are corrected at startup with a journal warning: stopout mode=order → first, stopout mode=fair-worst → best, open mode/close mode=fair-worst → worst.

Holding and operations

Worked example

A long position with SL = 1.2000, ticks SL=3, ticks (as bid): 1.2010, 1.1995 (trigger), 1.1990, 1.2003, 1.1985, 1.1992, 1.1988.

• following — the window is ticks 2-4: [1.1995, 1.1990, 1.2003], confirmed at tick 4. worst (sell, lowest bid) gives 1.1990; best 1.2003; first 1.1995; last 1.2003; order 1.2000; fair-worst 1.2003 (only price not worse than 1.2000 for the client).
• satisfied — held from tick 2; the last three ticks are checked against bid <= 1.2000 on every tick. The window only clears at tick 7 ([1.1985, 1.1992, 1.1988]), confirmed there — worst 1.1985.

What the plugin will and will not do

• Never fills at the wrong side of the quote. A buy is always filled at ask, a sell at bid.
• Never fills at a zero, negative or broken price.
• Never fills a take profit or a limit order worse than its level, whichever mode is chosen — stop losses and stop orders are the exception on purpose (protecting against a gap is what the plugin is for).
• Never closes a stopout on an old decision — it is answered the moment it arrives, from the ticks seen up to that moment.
• Never guesses. If something does not add up (the position is gone, a level is missing, the mode does not apply), the plugin does not intervene and writes the reason to the journal.

A refusal before the plugin has taken the request sends it to the broker's next routing rules. MT5 cannot hand a taken request back, so a refusal afterwards is answered at the current market price — if that price itself passes the checks — or rejected. Refusal codes (written to the journal as warnings): LIMIT_VIOLATION, INCOMPLETE_WINDOW, INVALID_PRICE, UNSUPPORTED_MODE, WRONG_QUOTE_SIDE, STALE_CONTEXT.

Journal

verbose levels are cumulative; refusals are written as warnings at every level, confirmations only after the server accepts the answer. Typical lines:

'1008': #504855410 'stop loss' held, satisfied mode, 3 ticks
'1008': #504855410 'stop loss' confirmed at 1.19900, 'worst' from [1.19950, 1.19900, 1.19980]
'1008': #504855412 'take profit' refused LIMIT_VIOLATION ('worst' 1.19950 is worse than 1.20000, 3 of 3 ticks from [1.20100, 1.19950, 1.20200]), confirmed at market 1.20200

Differences from the MT4 version

MT5 has no stop/pending/stopout hooks, so the plugin works as a dealer and needs a manager and routing rules instead of an .ini file next to the DLL. manager is required for any work. Two new parameters, hold timeout and timeout action, cover MT5's three-minute limit for held requests. Group masks follow MT5 rules; symbol masks match the symbol path.

Not available in MT5 (platform limitations, not omissions): dealer bypass * (the trade server does not tell the plugin which feeder produced a quote), stopout retried on the history of close attempts (MT5 creates a stopout request once), the virtual dealer's own stop/freeze level checks (MT5 performs them itself before the request reaches the plugin), debug symbols (verbose=2 traces every request instead).

The full contract, every worked example and the complete parameter reference ship in the readme.md of the package itself.