MT5 Liquidity Bridge Explained: How Orders Reach Liquidity Providers

What is an MT5 liquidity bridge?

An MT5 liquidity bridge is a piece of middleware that sits between a MetaTrader 5 trade server and external liquidity sources such as banks, non-bank liquidity providers (LPs), prime-of-prime firms or electronic venues. It translates between the MT5 world (accounts, groups, symbols and deals) and the protocols that liquidity providers use, which in FX is most often the FIX protocol.

Bridges are typically built as MT5 gateways or server plugins using the interfaces MetaQuotes provides to platform operators. Some run on the same infrastructure as the MT5 server; others run in a separate data centre, close to the liquidity providers they connect to.

A bridge has three core jobs:

• Price distribution: receive streaming quotes from one or more providers and deliver them to MT5 as the symbol price feed.
• Order routing: take orders accepted by the MT5 server and send them to the right provider, with the right parameters.
• Confirmation: receive execution reports (fills, partial fills, rejections) and update MT5 so the client sees the correct position and price.

How an order flows from MT5 through a bridge

The exact sequence depends on configuration, but a typical market order follows these steps:

1. The trader submits an order in the MT5 terminal (desktop, web or mobile). The terminal sends it to the MT5 trade server.
2. The server runs its own checks: account permissions, margin, symbol trading hours and group settings.
3. MT5 routing rules decide how the order is handled. Orders that are routed externally are passed to the bridge.
4. The bridge applies its own logic: symbol mapping, size limits, provider selection and any order-splitting rules. It then sends a new order message to one or more providers, usually over a FIX session.
5. Each provider responds with an execution report: filled, partially filled or rejected, with the executed price and quantity.
6. The bridge returns the result to MT5, which creates the deal and updates the client's position and balance.

Every hop adds time. The total round trip, from the terminal click to the confirmed deal, is what traders experience as execution speed. Measuring each stage separately is the only reliable way to see where time is spent; see latency measurement in execution systems for how this is approached at the infrastructure level.

The price feed runs the other way

While orders flow outwards, quotes flow inwards. Providers stream bid and ask prices to the bridge, which normalises them (symbol names, decimal precision, contract sizes) and publishes them into MT5. If the operator applies a markup or spread adjustment, it is usually done at this stage. Because the price a trader sees is the bridge's output, not the raw provider quote, the price feed and the execution path need to stay consistent, or traders will see fills that differ from what was on screen.

Liquidity aggregation

When a bridge connects to more than one provider, it can aggregate their quotes. Aggregation builds a consolidated order book from several streams, so the best available bid and offer can be taken from different providers at the same moment. Common approaches include:

• Best bid and offer: route each order to whichever provider is showing the best price for the requested size.
• Depth sweeping: split a larger order across several price levels or providers to fill the full size.
• Weighted or rule-based routing: prefer providers by historical fill quality, response time or symbol, not only by quoted price.

A quoted price is not the same as an executable price. Providers differ in how often they reject orders, how long they take to respond and how their quotes behave in fast markets. A good aggregator takes that behaviour into account rather than chasing the tightest quote. Our page on institutional FX liquidity covers how liquidity sources and venue behaviour differ.

Execution models a bridge can support

A bridge is a routing tool, so the execution model is a result of how it is configured. The main patterns are:

Straight-through processing (STP)

Every eligible order is passed to an external provider, and the client's fill reflects the provider's execution report. The operator does not take the other side of the trade.

Internal or mixed routing

Some MT5 operators route only part of their flow externally and handle the rest internally, by symbol, account group, order size or client profile. This is the technical basis of hybrid execution, explained in more detail in our article on A-book vs B-book vs hybrid execution.

Order handling parameters

Within any model, details matter: whether orders are sent as fill-or-kill (FOK) or immediate-or-cancel (IOC), whether partial fills are passed to the client, how slippage tolerance is set, and how the bridge reacts to a rejection (retry with another provider, or reject to the client). These settings directly shape fill rates and slippage.

What to check when evaluating an MT5 bridge

Bridges are often compared on features lists, but the practical differences show up in operation. Useful questions include:

• Latency and hosting: where does the bridge run, how close is it to the MT5 server and to the providers, and can it report latency per stage rather than as a single average?
• Execution reporting: does it record request, send, acknowledgement and fill timestamps for every order, and can you export fill ratios, rejection reasons and slippage by provider and symbol?
• Connectivity: which FIX versions and provider-specific dialects are supported, and how much work does adding a new provider involve? See FIX API execution models for background.
• Failover: what happens if a provider session drops, or if the bridge itself fails? Are open orders reconciled automatically?
• Risk controls: maximum order size, exposure limits per symbol or group, price-deviation checks and kill switches.
• Routing transparency: can you see and audit why each order went where it did? Opaque routing makes execution quality hard to verify.
• Symbol and contract mapping: how are differences in naming, precision and contract size between MT5 and each provider handled?
• Operational support: monitoring, alerting, upgrade handling for new MT5 builds and the support model during market hours.

It is worth testing a bridge with realistic order flow in a staging environment before going live, and comparing the bridge's own reports against provider-side records.

Where Keystone FX fits

Keystone FX builds execution and connectivity technology for professional FX participants, including MT5 connectivity, FIX API access, liquidity routing and latency and slippage measurement. An overview is on our execution infrastructure page, and supported front ends are listed under platforms. If you are reviewing your own bridge setup, you can contact our team to discuss your requirements.

Frequently asked questions