When a broker tells me it has “liquidity connected,” I ask one question: can the team draw the route of an order from the trading platform to the company that fills it?
If the diagram has one box labelled LP / bridge / aggregator, the setup is not understood yet. These layers can come in one commercial package, but they do different jobs.
- A liquidity provider, or LP, supplies executable prices and available size. It accepts, rejects or fills an order under the agreed execution terms.
- A liquidity aggregator collects prices and depth from several sources. It builds a combined view and decides which source or sources can fill the order.
- A liquidity bridge connects the broker’s platform with external or internal execution. It translates messages, maps symbols, applies the broker’s routing rules and returns execution results.
The shortest useful explanation is this: the LP provides the liquidity, the aggregator organizes access to several sources, and the bridge connects that execution stack to the broker’s platform.
| Question | Liquidity provider | Aggregator | Bridge |
|---|---|---|---|
| Where do prices come from? | The LP quotes its own or upstream prices | Combines prices received from connected sources | Passes the selected price stream to the platform |
| Who supplies depth? | The LP | Nobody; it combines available LP depth | Nobody; it carries and applies the configured data |
| Who chooses among LPs? | Not across the broker’s other LPs | The aggregation and routing logic | The bridge sends the order to the configured route |
| Who connects to the trading platform? | Sometimes directly | Sometimes as part of a bundled product | This is the bridge’s core role |
| Who fills the external order? | The selected LP or venue | It may coordinate several fills | It receives and maps the reports back to the platform |
Where each layer sits
How the layers connect
EUR/USD · illustrative external execution
Trading platform
Shows prices
and trade results
Bridge
Translates messages
for the platform
Aggregator
Compares quotes
and selects a source
Liquidity providers
Supply prices and fills
Three sources, one price stream. The aggregator compares LP quotes. The bridge carries the selected stream to the platform.
Buy 100,000 EUR. The bridge translates the order. The aggregator routes it to LP A, which has the best eligible ask and enough size in this example.
LP A fills the order at 1.08420. Its execution report returns through the aggregator and bridge. The platform updates the trade.
Quotes flow from liquidity providers through the aggregator and bridge to the trading platform. Orders travel in the opposite direction. Fill reports return from the selected provider.
Quotes travel from liquidity sources toward the trading platform. Orders travel in the other direction. Execution reports then return through the same chain.
That clean diagram has two common variations.
First, a broker using one LP may connect the bridge directly to that provider. There is nothing to aggregate.
Second, a hybrid broker may internalize some client flow. The bridge or connected risk engine can send only the required hedge to the aggregator or LP. A client order and an external hedge are therefore not always the same size or even a one-to-one pair.
What a liquidity provider does
An LP makes prices available and stands behind a defined amount of executable size. In FX and CFDs, the provider may be a bank, non-bank market maker, prime-of-prime, broker, venue or another counterparty with access to upstream liquidity.
The label alone tells me very little. I want to know:
- which instruments and sessions it covers;
- bid and ask prices at each depth level;
- minimum and maximum order size;
- whether prices are firm or subject to last look;
- fill, partial-fill and reject behavior;
- margin, collateral and credit terms;
- commissions and other execution costs;
- how performance changes during news, rollover and market gaps.
An LP does not guarantee a tight spread for every order. A quote can be tight at the top of book but carry only a small amount of size. The next level may be several points away.
Some FX providers use last look, meaning they perform a final price or validity check after receiving a trade request. The result can be an acceptance or a rejection. That policy belongs to the LP or venue relationship. The aggregator and bridge must record the response accurately, but they do not create the provider’s acceptance rules.
What a liquidity aggregator does
An aggregator receives streams from several LPs or venues and normalizes them into one usable view.
For each symbol, it may:
- compare the best bid and ask;
- combine depth from several sources;
- remove stale, invalid or unavailable quotes;
- respect per-LP credit and size limits;
- split a large order across price levels;
- choose a route based on price, depth, latency and fill history;
- move to another source after a reject, if the policy allows it.
The aggregator does not manufacture liquidity. If three connected providers all withdraw their quotes, the combined book is still empty. If every provider widens, aggregation cannot preserve yesterday’s spread.
It can, however, reduce dependence on one source. One LP may offer the best price for a small EUR/USD order, while another carries more depth for a larger order. The aggregator exposes that difference and can use both.
Price aggregation is not the same as order aggregation
Price aggregation builds a composite price or book from incoming quotes.
Order aggregation combines or nets orders before they are sent onward. That may happen elsewhere in the broker’s risk and execution stack. The two functions can share technology, but they answer different questions.
This distinction matters in a hybrid model. A broker may show clients a price built from several LP streams, internalize some positions, and send only net exposure outside. Seeing an aggregated price does not prove that every client trade reached an external LP.
What a liquidity bridge does
The bridge is the integration and control layer between the trading platform and the chosen execution route.
Its responsibilities can include:
- translating platform messages into FIX or another API format;
- converting lots into units or contract quantities;
- mapping symbols, decimals and contract sizes;
- sending price streams to the correct platform groups;
- applying markups or execution settings;
- routing orders to an LP, aggregator or internal book;
- handling partial fills, rejects and disconnects;
- mapping external execution IDs back to platform orders;
- preserving timestamps and logs for reconciliation.
The bridge executes the broker’s configuration. It does not decide the business model on its own. Someone still has to define which flow is externalized, which routes are permitted and what happens when the primary connection fails.
This is also why a bridge cannot repair weak liquidity. It may reroute an order after one LP rejects it, but the next available price can be worse or unavailable. Failover improves resilience; it does not promise the same execution conditions.
A EUR/USD order through all three layers
Assume the broker’s risk policy sends a €750,000 EUR/USD buy order outside. The available ask side is:
| Source | Ask | Available size |
|---|---|---|
| LP A | 1.08420 | €300,000 |
| LP B | 1.08422 | €500,000 |
| LP C | 1.08425 | €1,000,000 |
[Custom HTML block: Aggregated liquidity order sweep – paste 02-aggregated-order-sweep.html here.]
The bridge receives the platform order, confirms the symbol and volume, and sends it to the configured external route.
The aggregator sees that LP A has the best ask but cannot fill the full amount. It sends €300,000 to LP A and the remaining €450,000 to LP B.
The volume-weighted average price is:
(€300,000 x 1.08420 + €450,000 x 1.08422) / €750,000 = 1.084212
The two fills return through the aggregator. The bridge maps them to the original platform order and reports the combined result.
This example isolates the roles. Real execution can also include latency, price movement, commissions, markups, last look, partial fills and LP-specific minimum sizes.
Why product names make this confusing
One vendor may sell “a bridge” that includes aggregation. Another may call the entire product an aggregator even though it also supplies platform connectors, risk rules and reporting. An LP may aggregate several upstream sources before showing the broker one price stream.
The commercial label does not change the logical questions:
- Who supplies the executable quote and carries the external fill?
- Who combines and ranks multiple sources?
- Who translates the platform order and applies the broker’s route?
- Who owns the log that proves what happened?
I ask vendors to draw those responsibilities before discussing latency claims. A fast system with unclear ownership becomes slow the moment an order is disputed.
Which setup does a broker need?
One LP and a simple external route
A bridge connected directly to one LP may be enough. This is the smallest architecture, but the LP remains a single point of dependency.
Several LPs competing for flow
The broker needs aggregation logic to compare prices and depth. It also needs a bridge or equivalent connector between that aggregated route and the trading platform.
A hybrid execution model
The broker needs platform connectivity plus risk rules that decide whether to internalize, hedge or route each exposure. The aggregator matters when the external route has several sources.
A managed white-label stack
The bridge and aggregation layers may be included and largely invisible to the broker. That reduces integration work, but the operator should still receive execution reports, reject reasons, route status and incident ownership.
Quadcode’s turnkey brokerage solution combines the trading platform with liquidity, dealing, risk management and back-office infrastructure. It also supports pre-connected liquidity and the option to connect other LPs. The practical question for a broker is which parts are managed by the provider and which controls remain in the broker’s hands.
Who owns common execution problems?
| Symptom | Start the investigation here | Why |
|---|---|---|
| Only one LP stops quoting | LP connection and aggregator | Confirm source status and whether stale quotes were removed |
| All client prices use the wrong decimals | Bridge or platform mapping | The symbol definition is being translated incorrectly |
| A large order fills at several prices | Aggregator and LP depth | The order may have swept more than one level or source |
| An order is rejected after hitting a quote | LP response, then route policy | Check the reject reason and whether retry was permitted |
| Platform and LP volumes differ | Bridge logs and broker risk policy | The external hedge may have been netted, split or partially filled |
| The platform shows a fill but finance cannot match it | Bridge, aggregator and LP execution IDs | The chain needs one traceable set of identifiers |
Calling every case an “LP issue” wastes time. Calling every case a “bridge issue” does the same. Follow the order ID from the platform outward until the state changes.
[Internal link: Broker Reports Don’t Match]
Metrics to monitor by layer
Liquidity provider
- spread and available depth by symbol and session;
- fill, partial-fill and reject rates;
- last-look acceptance where applicable;
- slippage and response time by order size;
- collateral use and counterparty exposure.
Aggregator
- contribution of each LP to best price and executed volume;
- composite spread and depth;
- stale-quote removals;
- number of sources used per order;
- reroutes, sweeps and route concentration.
Bridge
- platform-to-route latency;
- mapping and validation rejects;
- dropped or duplicated messages;
- connection uptime and failover events;
- unmatched platform and external execution IDs.
End-to-end execution quality still matters most. A broker should compare requested and filled prices, slippage distributions, fill ratios and rejects across order sizes and market conditions. A healthy average can hide poor outcomes during rollover or high volatility.
The distinction I keep
The provider owns the quote and fill. The aggregator decides how several sources are viewed and used. The bridge makes that execution route work with the broker’s platform and policies.
Keep those responsibilities visible even when one contract bundles all three. That is how a broker knows which layer to change, which team to call and which log should explain the trade.
