Liquidity Bridge for a Forex or CFD Broker: Buy a Bridge, Use What Your Trading Platform Offers, or Build Your Own

A liquidity bridge is the software that connects a broker's trading platform, such as MetaTrader 5 or cTrader, to its liquidity providers. These are the banks and brokers that quote prices to the broker and fill its orders. The bridge brings in their prices and adds the broker's markup, the amount a broker adds to a provider's price before clients see it. For each client order, it decides whether to pass the order to a provider or keep it on the broker's own book, with the broker taking the other side. You can buy a bridge, use the tools your platform maker offers, or build your own. The choice depends on how many platforms and providers you run, and on whether your routing rules are part of what you sell. Your firm keeps the same duties whichever path you choose.

What does a liquidity bridge do for a broker?

Once the platform has checked a client's order, the bridge takes over. It does five jobs:

• It takes in each provider's prices and builds the prices your clients see, for example the best price across providers plus your markup
• It applies your routing rules: which orders go out, to which provider, and which stay on your own book
• It sends each outgoing order and brings back the fill, meaning the price and amount actually traded, or a rejection
• It tracks your exposure, meaning the positions you hold against your clients, and applies your risk limits to it
• It logs every price, order, fill and rejection with its time

The link to each provider often runs over FIX, a shared message format that banks, brokers and trading venues use. The FIX Trading Community, which maintains it, says FIX covers messages such as “orders, executions and market data”.

What does a bridge not do?

A bridge leaves four things to the rest of your business:

• Liquidity. You still need an account and an agreement with each provider. MetaQuotes, the maker of MetaTrader 5, lists “sign an agreement” among the steps for connecting one
• Client accounts, balances and margin, which the trading platform keeps
• Your execution policy, meaning your written rules for handling client orders, and your risk limits. Your staff set them, and the bridge applies them
• Matching your records against each provider's statement, which someone on your side still does

Where do A-book, B-book and hybrid rules live?

In the bridge, or in the part of your platform that does the bridge's job. Each term names where a client's trade goes:

• A-book: you pass the client's trade to a provider. The market risk sits with the provider, and you earn the markup and any commission
• B-book: you keep the trade on your own book and take the other side. When the client loses, you gain, and the other way round
• Hybrid: rules decide which way each trade goes, by client group, instrument, order size or your open position. A rule can also pass on part of a trade and keep the rest

MetaQuotes says of Ultency, its matching engine for MetaTrader 5: “You can manage order routing between A-Book, B-Book, and partial hedge executions.” Before you choose any product, write each rule down in plain words with an example order. Then check that the product applies it exactly.

Your rules also need an answer for orders a provider refuses. Some providers use last look, which lets them turn down your order after it arrives. The FX Global Code is a set of good-practice principles for the wholesale currency market, maintained by the Global Foreign Exchange Committee. It describes last look as a practice in which the receiver of a trade request “has a final opportunity to accept or reject the request against its quoted price”. The Code's Principle 17 says firms that use last look “should be transparent regarding its use and provide appropriate disclosures to Clients”. The Code is voluntary: it says it “does not impose legal or regulatory obligations” on market participants.

Decide what your bridge does with a refused order: send it to the next provider, fill it from your own book, or reject it. Each choice changes your risk and what the client sees.

What do regulators expect from the rules inside a bridge?

In the EU, Article 27 of MiFID II requires investment firms to take “all sufficient steps to obtain, when executing orders, the best possible result for their clients”. The factors it lists start with “price, costs, speed, likelihood of execution and settlement”.

The firm's order execution policy must include information on “the different venues where the investment firm executes its client orders and the factors affecting the choice of execution venue”. For a broker, that choice happens in the bridge, so the policy and the routing rules have to match. Firms must also “monitor the effectiveness” of their order execution arrangements and policy. In practice, that means reviewing the bridge's records provider by provider.

Products not traded on an exchange or another trading venue are called over the counter (OTC). ESMA, the EU's markets authority, covers them in one of its published questions and answers. It explains that Article 64 of the MiFID II Delegated Regulation requires firms to “check the fairness of the price proposed to the client”. The answer dates from 2016 and is still on ESMA's website. It adds that the aim is for firms “to be able to justify their pricing decisions”. If you add markups or keep trades on your own book, store each provider price next to the price your client got.

All sources in this article were opened on 3 November 2026. For regulation, the article quotes EU rules and ESMA guidance only. Other countries have their own.

What stays the same whichever path we choose?

These jobs exist on every path. What changes is who writes and runs the software:

• Price feeds and markups: which provider's prices feed each client group, and what you add to them
• Routing rules: A-book, B-book or hybrid, and what happens when a provider rejects an order
• Risk limits: how much exposure you keep in each instrument before you pass it on
• A FIX session with each provider, set up and tested with that provider
• Records and reconciliation: every order and fill matched each day against each provider's statement
• Failover: moving prices and orders to another provider when one disconnects

Failover is the part to test hardest. When a connection drops mid-order, the bridge must find out whether that order was filled before it sends more. The FIX Trading Community's session standard says the FIX session layer is used “to provide reliable and recoverable messaging for electronic trading”. Messages are numbered, and a side that sees a gap asks for the missing ones again.

A vendor or a platform can do part of this work for you, but your firm still answers for all of it.

When should a broker buy a bridge product?

Buy when your needs look like those of the vendor's other clients. Typical signs:

• You run more than one trading platform, or plan to, and want one set of routing rules across them
• You need several providers soon, and the vendor already connects to them for other brokers
• Your team is small, and you want someone else to keep provider connections working when specifications change

What you give up is control. Your rules have to fit the product's settings, and a missing feature waits for the vendor's plans. With a hosted bridge, your clients' orders also pass through servers you do not run.

When are the tools in our trading platform enough?

When most of your clients trade on one platform and the providers you want already connect to it. MetaQuotes says “MetaTrader 5 includes a built-in solution for liquidity aggregation and order matching through Ultency”. Aggregation means combining several providers' prices into the prices your clients see. MetaQuotes lists the providers with “native Ultency connectivity” on its site, and also offers gateways, its name for connectors to providers and exchanges.

Spotware, the maker of cTrader, can connect a broker to a new provider over FIX. Its page on FIX for liquidity says Spotware obtains the provider's FIX specifications and “builds a dedicated server adapter”.

This path has the fewest parts to run. MetaQuotes notes that with Ultency the main instrument and trading session settings are “configured once in MetaTrader 5”. The limit is that the rules live inside one platform. A provider the platform maker does not support yet waits on its plans. A second platform means setting up the rules again, or moving to a bridge that serves both.

When is building our own bridge worth it?

When at least one of these is true:

• Your routing, pricing or hedging rules are part of what you sell, and the products you tested cannot apply them as written
• Bridge fees that grow with your volume now cost more than a team that runs your own system
• You want every price, order and fill on servers you control, in a layout you choose

It does not have to replace everything. Often it is one piece, such as your own hedging rules or records, next to a bought bridge or your platform's tools. On MetaTrader 5, your own bridge plugs in through the platform's interfaces. MetaQuotes says its “Gateway API is used for MetaTrader 5 integration with other trading systems and creation of custom data feeds.” Spotware says it “provides platform-as-a-service”, and its page for brokers says cTrader's “complete technology stack” is hosted in data centres in London and New York. So ask Spotware which interface your own bridge would use.

After launch, someone has to answer alerts at every hour your clients can trade, and retest each provider connection when it changes. If you have nobody for that, start with a bought bridge or your platform's tools.

What should we check before signing a bridge contract?

• Who can see our order flow, meaning our clients' orders? Where do the servers run, who at the vendor has access, and is any company in the vendor's group also a liquidity provider or a broker?
• Can we export every price, order, fill, rejection and rule change at any time, in a documented format, including after we leave?
• What are the exit terms: the notice period, an export of our routing rules and instrument settings, and help with a move to another bridge?
• How do the fees change when our volume doubles? MetaQuotes describes Ultency's pricing as “volume-based”. Spotware says pricing for cBridge, its own bridge product, “is based on the number of servers and connections involved”.
• Which providers are live with other brokers today, and which are only planned?
• Can our dealers change routing rules and markups themselves, with every change logged?
• What happens when a provider rejects an order or disconnects, and who chooses that rule?
• Do the vendor's support hours cover every hour our clients can trade?

Who owns the code, the routing rules and the trade records?

A vendor owns the code of its bridge, and a platform maker owns its platform. Your routing rules and markups are your business logic, but inside a product they sit in the vendor's format. Ask for an export you can read, and keep your own written copy of every rule.

Trade records come in two halves. The platform holds the client side: accounts, orders and positions. The bridge holds the provider side: which provider got which order, when, at what price and markup, and what came back. You need both to answer a client or a regulator. MetaQuotes, for example, says Ultency's logs are “accessible only to the broker”. Get the same answer from every vendor in writing.

With your own build, you can own the code too. The contract should say so and list any components the builder keeps, with the licence under which you may keep using them.

What should we ask a firm that would build our bridge?

• Which platforms will the bridge connect to, and through which of their interfaces?
• Which providers come first, over which FIX version, and who arranges the connection tests with each one?
• How will our dealers change routing rules and markups without a developer, and how is each change logged?
• If a connection drops mid-order, how does the bridge check with the provider what happened to that order before trading resumes?
• How does failover to another provider work, and what do clients see meanwhile?
• How do you store provider prices next to client prices, so we can later show how each client price was set?
• How does the daily reconciliation with each provider's statement work, and who is told about a difference?
• Can you show this working in a system that runs today?

Where does amBrain fit?

amBrain publishes this blog. It describes this part of its work in one line: “amBrain builds algorithmic trading infrastructure: order execution, market data and pre-trade risk controls.” Another line on amBrain's website reads: “Trading terminal development, order management systems, and FIX protocol exchange integration.”

amBrain has been building software since 2019. On how it works with clients, it says: “Three formats: full delivery, a dedicated team, or engineers embedded in your team.” Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” Ask for the list of those components by name before you sign.

This article is not a case study and describes no client work. It does not say that amBrain has built, bought or connected a liquidity bridge for any client. It quotes MetaQuotes, Spotware, the FIX Trading Community, the Global Foreign Exchange Committee and ESMA from their published pages and claims no relationship between amBrain and any of them. It gives no amBrain prices or timelines.

It is not legal advice either. Check the rules that apply to your firm with a lawyer. If amBrain is on your shortlist, ask it the same questions as any other firm.