Guru's Verification engine ensures consistency, confidence, and trust in the knowledge your organization shares. Learn more.

Slippage Analysis

Retail Trading Business

As part of running a scalable retail trading business, its good to understand slippage a commonly cited churn factor for clients at retail trading businesses.

What is slippage?

From Investopedia:

Slippage refers to the difference between the expected price of a trade and the price at which the trade is executed. Slippage can occur at any time but is most prevalent during periods of higher volatility when market orders are used. It can also occur when a large order is executed but there isn't enough volume at the chosen price to maintain the current bid/ask spread.

Slippage refers to all situations in which a market participant receives a different trade execution price than intended.

Slippage occurs when the bid/ask spread changes between the time a market order is requested and the time an exchange or other market-maker executes the order.

Slippage occurs in all market venues, including equities, bonds, currencies, and futures.

Where in your business is slippage introduced?

A typical route of a tick to a retail client trader:

LPs & ECNs -> LPs -> Bridge Provider -> Pricing Engine -> Bridge Provider -> MetaQuotes Server -> MetaQuote Client

At each hop on this pipeline there will be various buffers, network switches/hops, all of which may be shared, different conflation strategies may be in use across the pipeline.

LPs tick rates are determine by the LP, so they can and often do spike in busy markets.

Chatty LPs are not always the most informational LPs. Predictivity is fundamental to planning bandwidth allocation on trading system setups.

Historically, we have defined slippage as the difference between the current published (at pricing engine) and the filled price.

However, this doesn't cover the full pipeline of slippage sources as far as the end client is concerned.

Business Tradeoffs

As we discuss in Troubleshooting Slippage

With your MT4/5 flow by the time the order reaches us, it is often passed with a FIX order type of market i.e. not proposed with a price

It is often felt better to guarantee the fill and slip vs reject the order

Slippage can occur where a stop loss or take profit is triggered in MT4/5 and there is a delay in getting that order to us. During which successive updates to the price may have occurred

Even a small delay of 10 ms can at certain times have multiple price ticks elapse.

Another factor here is that the price can move through the SL/TP price in a single tick.

Slippage can occur when MetaQuotes only sees the cost of a BUY or SELL in the Top of Book i.e. small order quantities. A VWAP price for the order may be not as attractive to the user

So a lot of the time its a business tradeoff between whether you want to reject the proposed order if phrased as a limit price (i.e on arrival to us the price is gone), or slip them.

Slippage Tracing

The new slippage analytics, help trace where in your brokerage setup, slippage is being introduced and whether those slippages are symmetric.

This style of analysis works best when Mahi is both the execution bridge (Synapse) + compass (Pricing & Execution). But most of the solution is delivered via our straight forward MetaQuotes analytics plugin too.

MetaQuotes SL/TP trigger latency issues

Is slippage purely in MT4/5? MetaQuotes server taking a long time in between a trigger SL/TP price and placing its order?

As we go into in our MetaQuotes performance optimisation and tuning guide, there are certain setup behaviours that can result in sub-optimal MetaQuotes server setup. A common source of problems is:

  • Too many MetaQuote Groups
  • Too many Symbols (sometimes 4-5 EURUSD symbols into a single server)
  • Over-clocking the data rate into MetaQuotes such that at busy periods the server is overwhelmed

A way of monitoring whether your MetaQuotes server is adequately provisioned is assessing its slippage in response to processing SL/TP limit prices as part of its resting order triggering.

The user will have entered a trigger price with which they want to either stop their losses (SL), or take their profits (TP).

When these are in effect they are the principle and most obvious end retail client reference for measuring slippage (and thus inferring quality of brokerage execution)

A huge source of client churn.

For this we have the TP/SL Trigger Price to Fill Price slippage in $ terms and also $/M terms

Trigger Price to Filled

Pricing Engine Published Price to Filled Price Slippage

This can be useful for consideration, but the latest published price from the pricing engine can vary hugely vs what the client has as their perceived latest price. At any point in the bolded part of the chain below, the "published price" can still be en route to the client.

LPs & ECNs -> LPs -> Bridge Provider -> Pricing Engine -> Bridge Provider -> MetaQuotes Server -> [Multi-region WAN]-> MetaQuote Client

Published To Filled

Published Price vs MetaQuotes Price Slippage

Does the pricing engine's publish price (or your LPs price) differ significantly to what MetaQuotes thinks the price is? (MetaQuotes or Bridge Provider publication latency issues or network or MetaQuote buffers being filled).

This is analysing the below leg of the potential slippage pipeline:

LPs & ECNs -> LPs -> Bridge Provider -> Pricing Engine -> Bridge Provider -> MetaQuotes Server -> [Multi-region WAN]-> MetaQuote Client

MetaQuotes Price Slippage

This is the closest proxy to what the client will perceive as slippage (some slippage plugins run in the client's MT4/5 terminal). These will be actual slippage. MetaQuotes Price to Filled

SLIPPAGE Symmetry

For some regulatory regions you may need to show your slippage is symmetrical. Using this tool you can demonstrate this

Beyond Analytics

These analytics help you understand how a client may feel they are being slipped which in turn can result in more client complaints, tickets, emails and operational support and operation staff required to successfully run your business.

They can be used to assess when your MetaQuotes servers may be overwhelmed by high tick rates and large amounts of client flow.

Slippage spike detection can be automated and this analysis proactively performed to tell you when you have capacity issues with your business. It doesn't require people to manually monitor this behaviour

Synapse Execution Bridge

With a Mahi execution bridge we pass on the various prices as part of the order into our client order execution component.

This allows you to tie execution quality and fill orders in accordance to the nature of the flow. For some types of retail flow, you can eliminate a huge swathe of perceived slippage.

You must have Author or Collection Owner permission to create Guru Cards. Contact your team's Guru admins to use this template.