A conventional bridge sits between a broker and a pool of external liquidity providers. It solves
a problem the broker only has once they are large enough for an LP to answer the phone. The bridge
described here works differently: both ends are MetaTrader 5 servers, and the liquidity itself is a
single trading account on the master side. That inverts the economics — the operator of the master
server becomes the liquidity source, and a downstream broker integrates by installing a plugin
rather than by negotiating credit.
This is the same model behind the cross-server coverage products sold by the established plugin
vendors, with one architectural difference: both halves are server plugins, so there is no separate
gateway process to license, host and keep alive.
ComponentLiquidity Bridge (MT5 to MT5)
Liquidity as a service. The downstream broker's server connects to a master liquidity facility
and covers client flow through one omnibus account: real-time quotes streamed to the downstream
server, execution with configurable markup and commission, per-broker exposure limits, an
automatic failover policy, and monthly volume and settlement reporting.
On the master side a provider plugin accepts requests from every connected downstream server,
executes them in-process on the omnibus account — held in netting mode, so exposure aggregates
per symbol — and returns the fill. On the client side a consumer plugin acts as an automatic
dealer: it intercepts trade requests on covered symbols and groups, forwards them upstream, and
confirms the client's trade at the master's price. The trade does not exist until the master has
filled it, which is what separates a bridge from trade copying, where replication happens after
the fact.
What it solves
- Institutional coverage for brokers who have no route to a prime broker
- A-book capability from day one, instead of carrying an unhedged book while relationships are built
- One integration replaces LP negotiation, a gateway project and its ongoing maintenance
- For the operator of the master server, a volume-based revenue business rather than a one-off licence
How it ships. Two C++ plugins, one on each server, plus a console on the master side for
connecting downstream brokers, setting markup and exposure limits, and reading volume and
settlement reports. Nothing is installed between the servers: there is no gateway host to
provision, and no third-party bridge licence in the path.
What has to be right
A bridge is unforgiving in ways a reporting module is not, and the details below are where these
projects usually fail.
Ticket mapping. Fills land on a netting omnibus account and must be attributed back to
individual tickets on each downstream server. The mapping has to be written per operation; rewriting
a whole map on every trade is the classic mistake that turns into quadratic cost as volume grows.
Markup is the business model. Spread markup and commission are applied on the downstream
plugin, configured per symbol and per group, which is what makes the arrangement pay for both sides.
Exposure limits per downstream broker. The master plugin caps volume and exposure for each
connected server. Without it a single downstream broker can consume the margin of the shared account
and take the whole network with it.
Settlement and symbol mapping. Swaps and commissions on the omnibus account will not match
what each downstream broker charges its own clients, so monthly reconciliation is part of the
product. Contract sizes, digits and trading sessions differ between servers, so a symbol
correspondence table is required from the first day rather than bolted on later.