MT5 slippage: what it costs, and how to measure it from your own trades

That gap is the reason slippage on MetaTrader 5 is so hard to argue about. Traders feel it as backtest-versus-live divergence, as an Expert Advisor that was clean in the strategy tester and flat in production, as fills that keep landing on the wrong side during news. What they usually do not have is a number, because the terminal does not hand them one.

This page is about producing that number from data your own terminal already generates. It covers which MT5 fields actually carry the requested price and the filled price, how to turn the difference into an adverse fill delta you can aggregate across hundreds of trades, what a symmetric distribution of fills looks like beside a skewed one, and — the part almost every page on this subject skips — how to separate ordinary volatility slippage from a systematic pattern, and what your own data can and cannot establish about the difference.

If you want the arithmetic without the reading, the forex slippage calculator does the per-trade and aggregate maths in your browser.

What MT5 actually records when a trade is filled

MetaTrader 5 keeps two separate records for a single market fill. An order is the instruction. A deal is the execution. One order can produce more than one deal if the fill is split across price levels, and one deal can close part of a position rather than all of it. Most of the confusion about slippage on MT5 comes from reading the deal on its own, because the deal is the half that knows what you got and not the half that knows what you asked for.

The fields that carry the answer

Why the account statement cannot answer the question

The statement MT5 exports lists deals. A deal carries the price you got, the volume, the commission, the swap. It does not carry the price you asked for. That single omission is why slippage cannot be reconstructed after the fact from a statement, and why a trader who has been running an EA for two years may genuinely have no idea what their fills have cost them. The requested price exists only if something recorded it at the moment of the request: the order record, the terminal Journal, or an Expert Advisor that logs its own MqlTradeRequest before calling OrderSend.

The trap in ORDER_PRICE_OPEN

What the Journal shows

The terminal Journal logs the request and the result as separate lines, with millisecond timestamps. A market buy produces something close to this pair:

Two lines, a requested price and a filled price, four tenths of a pip apart. The Journal is the most direct evidence a retail terminal produces, and it is also the least durable: it is local to the machine, it rotates, and it is not queryable in any useful way. Treat it as the thing you check a method against, not as the archive you build a year of measurement on.

Slippage, defined precisely enough to compute

Slippage is the difference between the price an order was sent at and the price it was filled at. That definition is the easy part, and it is where most articles on the subject stop. Two things make it harder to use than it sounds.

The first is direction. A higher fill is not universally worse and a lower fill is not universally better; it depends entirely on which way the order went. The rule that covers every case is simpler than the version usually given, because it is about the order and not about the position: any buy order is hurt by a higher fill, and any sell order is hurt by a lower fill. That holds for entries and exits alike. Closing a long is a sell order, so it is hurt by a lower fill. Closing a short is a buy order, so it is hurt by a higher fill. You never have to reason about whether a trade was an entry or an exit — only about which side the order was.

The second is sign. "Negative slippage" is the retail term for a fill that went against you. Positive or favourable slippage — a fill better than requested — is not a rounding error or a marketing myth. It happens continuously, and on a fast, neutral fill process it should happen at close to the same rate as adverse slippage.

Adverse fill delta: the number that survives aggregation

Raw price differences are not comparable across instruments — 0.00004 on EURUSD and 0.004 on USDJPY are not the same kind of object. The working metric is the signed difference expressed in the instrument's own points, with the sign convention fixed so that positive always means "against you". That is the adverse fill delta.

Converting to money needs the instrument's contract arithmetic rather than a hard-coded pip value. MT5 exposes both halves of it, and the general form works on currency pairs, metals and index CFDs alike:

Note the point-versus-pip distinction, which trips up more slippage calculations than the sign does. On a five-digit EURUSD feed a point is 0.00001 and a pip is 0.0001, so one pip is ten points. Compute in points, because that is the unit MT5 gives you, and convert to pips only for reading.

Each of those rows can be checked without the formula at all. Buying 100,000 units at 1.10003 instead of 1.10000 costs 100,000 × 0.00003 = $3.00, and the formula returns exactly that. The slippage calculator implements this arithmetic and nothing more, including the batch aggregation described below.

What slippage costs

The reason a fraction of a pip is worth measuring at all is that it is levied per trade, and trade counts get large quickly. Here is the same cost across plausible activity levels, on EURUSD at one lot, with a pip worth $10.00.

Set that beside commission. At a typical $7 per lot round turn, 400 trades a month costs $2,800 in commission — a figure that is itemised, budgeted for, and shopped around on. A mean adverse fill delta of 0.6 pips on the same account is $2,400. It is very nearly a second commission line, and it never appears anywhere a trader would think to look for it.

The other half of the story is that the same number does not mean the same thing to two different strategies. A scalper taking three pips gross gives up a fifth of that gross edge to a 0.6-pip mean adverse delta. A swing strategy taking sixty pips gives up one percent. Same broker, same measurement, twenty times the significance. This is why "is 0.6 pips a lot of slippage?" has no answer in the abstract, and why the useful comparison is always against your own edge per trade and your own baseline.

What a normal distribution of fills looks like

A mean on its own hides almost everything interesting. Two accounts can report the same average adverse fill delta while one of them is filling symmetrically around zero and the other is filling well most of the time and catastrophically occasionally. The shape is the finding.

Four things are worth reading off a table like that, in roughly this order of importance.

1. Symmetry. A median near zero, with the share against and the share in favour close to equal, is what a neutral fill process looks like. It is the most reassuring property in the data and the first one to check.
2. Tail asymmetry. Compare the 90th percentile against the 10th. In the symmetric column the tail against the trader is somewhat longer than the tail in their favour, which is expected — price moves fastest exactly when orders are hardest to fill. In the skewed column it is roughly twelve times longer. Fills go badly much further than they go well. That asymmetry is a stronger signal than the mean, and it is invisible in any summary that reports only an average.
3. Share against, over a large sample. A share against materially above 50% that persists across thousands of fills, several symbols and several sessions, is the thing genuinely worth investigating. Over a hundred fills, it is noise.
4. Share exact. A high proportion of fills at exactly zero on a market-execution account, including during fast conditions, is not a good sign so much as a suspicious one. It usually means the requested price is not really being recorded — go back to the ORDER_PRICE_OPEN caveat and re-check the source.

Volatility slippage versus a systematic pattern

This is where the subject usually goes wrong in both directions at once: forum threads treat every bad fill as evidence of something, and broker education pages treat every bad fill as an unavoidable fact of markets. Neither is a measurement. The honest position is that most slippage has causes that have nothing to do with anyone's intent, and that separating those causes out is work you can actually do.

Causes that are not about your broker

• Genuine spread widening. Around scheduled news, at rollover near midnight server time, at session opens and closes, and through thin holiday liquidity, the spread widens because the available liquidity really is thinner. Fills degrade along with it.
• Your own latency. A VPS in the wrong region adds tens of milliseconds each way, and the market moves inside that window. This is measurable independently as send-to-fill time, and it is usually the cheapest item on this list to fix.
• Order size against available depth. A large market order on a thin symbol walks the book by construction. That is not a fill quality problem, it is an order sizing problem in disguise.
• Your strategy's own timing. A momentum entry fires precisely when price is moving in the direction it is about to be filled in. A mean-reversion entry fires when it is moving the other way. Two strategies on the same account at the same broker will harvest structurally different slippage from the same market, and comparing them against each other proves nothing about either.
• Order type. A stop order becomes a market order the moment it is touched, and fills at whatever is available. Slippage on stops is expected and is not comparable to slippage on entries triggered by your own logic. Limit orders, by contrast, cannot slip against you at all — they can only go unfilled. Averaging all three together produces a number about your order mix.

What would have to be true for a pattern to be systematic

• It survives splitting. Break the data down by symbol, order type, session hour and volatility bucket. If the effect disappears once news windows are separated out, it was news.
• It is stable over time. Adverse-heavy in one month and symmetric the next is a regime or a coincidence, not a process.
• It survives a control. The strongest control available to a retail trader is a second account at a different broker, running the same strategy on the same symbol at the same moments. Nothing else separates "the market did this" from "this account did this" nearly as cleanly. Everything short of that is inference, and should be described as inference.
• It shows up in the timing as well as the price. When adverse fill delta and send-to-fill latency degrade together, the explanation is likely somewhere along the path. When price degrades and timing does not, the market is the better candidate.

On stop-loss hunting, specifically

It is the most searched question on this topic and it deserves a straight answer rather than either a refusal or a story. Stops fill at whatever is available when they are touched, so a stop fill is structurally worse than an ordinary market fill and will look worse in your data regardless of who your broker is. What your own data can show is whether your stop fills are worse than your other market fills by a stable, repeatable margin, and whether that margin changed at some identifiable point. What it cannot show is who could see your stop, or why price went where it went. Those two sentences are the entire honest boundary, and anyone collapsing them into one is either overclaiming or refusing to engage with the question.

What your own data can and cannot establish

Your terminal's record supports these conclusions:

• What your fills cost, in your account currency, broken down by symbol, session and order type.
• Whether your fills are symmetric around zero or skewed against you.
• Whether your execution conditions changed, and when they changed.
• Whether two accounts running the same strategy at the same time received materially different fills.

It does not support these:

• What happened inside a broker or its liquidity providers.
• Whether any individual bad fill was avoidable.
• Anyone's intent.

How much data before the number means anything

Slippage is noisy, heavy-tailed, and driven by a small number of large events. That combination makes small samples actively misleading rather than merely imprecise: one 40-point fill during a news release will dominate the mean of a hundred trades and tell you nothing about the other ninety-nine.

And a rule that matters more than the sample size: split before you aggregate. One number computed across every symbol, session and order type is a number about your trading schedule, not about your execution. If you traded gold during the London open in March and only EURUSD overnight in April, an account-level average will show a change that has nothing to do with your fills.

A measurement routine you can run this week

1. Record the request. Before OrderSend returns, log the requested price, the millisecond timestamp, symbol, side, volume, order type, the deviation setting, and the bid and ask at that instant. The bid/ask pair is what later lets you tell spread widening apart from a fill problem.
2. Record the result. Deal ticket, DEAL_PRICE, DEAL_TIME_MSC, the return code, and the bid and ask at fill. Keep rejected and requoted attempts too — they are exactly what a slippage-only measurement silently deletes.
3. Normalise to points. Divide the price difference by SYMBOL_POINT. Never compare raw price differences across instruments.
4. Apply the sign. Multiply by +1 for buy orders and −1 for sell orders, and keep the result signed. Do not take an absolute value at any point in the pipeline.
5. Convert to money once, at the end, using tick value and tick size rather than an assumed pip value.
6. Split before you summarise: symbol, order type, session hour, and news versus no news.
7. Report percentiles, not just a mean, alongside share against, share in favour and share exact.
8. Keep the raw rows. A summary you cannot trace back to individual trades is not evidence, and the raw rows are the first thing a broker's support desk will ask you to produce.
9. Establish a baseline before you need one. A month of ordinary conditions is what makes a later change visible. Almost everyone starts measuring after they already suspect something, which is precisely the point at which a clean baseline is no longer available.

Steps 3 to 5 are arithmetic you can run immediately on trades you already have, in the slippage calculator. Steps 1 and 2 are the part that has to be running before the trade, which is what a tracking Expert Advisor is for.

Questions traders actually ask

If you want this measured rather than estimated

Everything on this page is computable from data your terminal already produces, and almost none of it is computable by hand at the sample sizes that make it meaningful. ExecGuard is a tracking Expert Advisor that records both halves of every trade — requested against filled price, send-to-fill in milliseconds, spread at entry and exit, commission — and keeps the raw rows so that any summary can be traced back to the trades it came from. The tracking EA will be published in full, so what it records will be inspectable rather than something you have to take on trust.

It is not finished, and the waitlist exists to work out what it should do next rather than to sell you anything. If you join, the genuinely useful thing you can tell us is which question on this page you are actually trying to answer: backtest-versus-live divergence, one specific hour of the trading day, a comparison between two brokers, stop fills against entry fills — or something that is not on this page at all. That last category is the one we most want to hear about.

Join the waitlist Open the slippage calculator