Every broker running A-book or hybrid flow has a liquidity bridge somewhere in the stack, even if nobody calls it that. It is the piece of infrastructure that takes an order off the MT4 or MT5 server, decides what to do with it, and — if it is going to a liquidity provider — speaks FIX to get it filled. Most brokers inherit whatever bridge came with their platform installation and never look at it again. That is a mistake: the bridge is where routing policy, price aggregation, markup and risk controls actually live, and a poorly configured one costs real money whether or not anyone notices.
This guide walks through what a liquidity bridge does, the decisions worth caring about, and the pricing trap that catches brokers who never read their vendor's fine print.
What a FIX liquidity bridge actually does
Architecturally, a liquidity bridge is a gateway core paired with a node process per MetaTrader platform it serves. The node connects to the MT4 or MT5 server; the core speaks FIX 4.3 or 4.4 to every connected liquidity provider — market data on one session, order entry on another. Every order that reaches the bridge passes through a policy engine before it goes anywhere, and that policy engine is where the real decisions happen:
- Where does this order get routed — kept in-house (B-book), sent to an LP (A-book), or split?
- What price does the client actually see, after aggregation and markup?
- What happens if the LP rejects, times out, disconnects, or rate-limits the request?
- Is the incoming LP quote even trustworthy, or is it a spike that should never reach pricing?
A-book, B-book, and the control that actually matters
Most broker conversations about routing stop at "A-book or B-book" as if it were a single switch. In practice the switch is the least interesting part. What determines execution quality — and how much the broker keeps or gives away — is the fine print attached to that switch: how many points worse than the quoted price a market-if-touched fill is allowed to be, and how much of any price improvement on limit and stop orders actually reaches the client.
A routing action with a 0-point worse-price tolerance and no improvement pass-through behaves completely differently from one that tolerates 1000 points worse with improvement capped at zero — both are technically "B-book," but one is strict price-matching and the other has real slippage built in. Brokers who only ever toggle A/B-book and never touch these caps are leaving the actual execution-quality decision unmade.
Aggregation: one price, assembled from many feeds
Connecting to a single LP means a single point of failure and a single, possibly thin, order book. A properly built bridge aggregates market data from every connected LP into one VWAP book per symbol — bid and ask, ten levels deep, with cumulative size and a volume-weighted price at each level. When real depth is thin, a quantity multiplier, extra synthetic quantity or a synthetic spread can thicken the published book per LP and product, independent of what that LP is actually quoting. Used honestly this smooths out gaps between real liquidity and what the broker needs to publish; used dishonestly it is how brokers end up quoting prices nobody can actually fill at. The distinction is whether the published book still resolves to something fillable when it matters.
The same liquidity, priced differently per platform
A detail that surprises brokers running more than one brand: the same underlying LP liquidity can be republished to several MT4 and MT5 platforms under different symbol names, each with its own markup — bid/ask markup or a single percent markup, a price shift that moves both sides together without changing the spread, and spread control that is either a floating passthrough, a min/max clamp, or a fixed spread. This is how a grey-label brand and a flagship platform sell the same depth at different spreads without maintaining two separate liquidity relationships. If your bridge cannot do this per platform, every brand is stuck with identical pricing regardless of its market position.
Protecting the price before it ever reaches a client
Aggregation is only as good as what feeds it. A single bad tick from one LP — a fat-finger, a feed glitch, a flash crash on a thin venue — can blow out a VWAP price and trigger stop-outs on perfectly good positions. A rate-filtering layer judges every incoming quote before it reaches pricing: a spike/jump filter that skips quotes whose mid moves further than a threshold versus the LP's own previous quote, a quote-shape check for an implausible spread or a crossed book, a deviation check against that LP's own recent average, and — more usefully — a deviation check against the median of the other LPs quoting the same instrument, with a configurable recovery (automatic once a good quote returns, or manual). A bridge that aggregates without filtering is aggregating garbage along with everything else.
Rules, not releases: the policy engine
The decisions above — routing, execution caps, liquidity behaviour — should not require an engineering release to change. A policy engine built around ordered rules, matched by account group and request scope (symbol, platform, size, time), lets each rule decide routing, execution and liquidity independently; any kind a rule leaves unset passes down to the next matching rule, and anything no rule decides falls back to a global default. That composability is what lets a broker write two narrow rules — demo accounts get a 750–1500ms delay with 10–100pt slippage, VIP crypto above 0.5 lots gets fast-tracked to A-book with a 3-second hedge window — instead of one sprawling rule trying to cover every case.
Test before you publish
Because policy changes affect live execution, a bridge worth trusting lets you simulate a hypothetical client — platform, MT5 group, symbol, side, size — against the currently published policy and see exactly which rule matches, what routing/execution/liquidity decision results, and a full price-resolution trace (platform price, raw price, fill price, slippage). Shipping a routing-policy change without being able to test it first is how brokers discover a misconfigured rule from a client complaint instead of from a dry run.
Pricing models: don't let the bridge become a volume tax
Here is the part vendors rarely lead with: a meaningful share of liquidity-bridge and gateway pricing in this market is volume-based — a commission or markup that scales with the broker's own trading flow. That means the bridge's cost grows exactly when the broker is succeeding, turning infrastructure into a tax on growth. A fixed-price model avoids this entirely: the bridge costs the same whether the desk routes ten lots a day or ten thousand, so cost stays predictable and the broker keeps 100% of what the spread and markup actually earn.
How brokerQ.io approaches it
BridgeQ is brokerQ.io's answer to all of the above, for both MT4 and MT5: point-level A/B-book routing control (not a blunt switch), multi-LP FIX aggregation into one VWAP book, per-platform symbol markup for grey-label brands, a rate-filtering layer that screens bad ticks before they reach pricing, a composable rule engine with a policy simulator to test changes before they go live — and a fixed price starting at $1,000/month, independent of trading volume. It also includes Copilot, a built-in AI assistant: describe a routing, pricing or policy change in plain language and it stages the exact diff for an admin to review and approve, instead of waiting on a release cycle. If you are evaluating whether your current bridge is actually doing its job, the fastest way to find out is to compare it against a live one.