Liquidity
Liquidity bridge or aggregator: which one do you need?
The words bridge and aggregator are used interchangeably in sales conversations, which is a problem when a firm is trying to decide what it actually needs. They solve different problems, and buying one when you needed the other is an expensive way to find out.
What a bridge does
A bridge connects a trading platform to an external liquidity source. It translates the platform's orders into the provider's protocol, sends them on, and brings the fills back. It is a connector, and its job is to make two systems that were not designed together behave as if they were.
A firm with one platform and one provider needs a bridge and very little else. The questions that matter are latency, reliability and how it behaves when the provider disconnects mid-order.
What an aggregator does
An aggregator combines several sources of pricing into one book. It normalises symbols and precision, decides which price wins at each level, and routes an order to the source most likely to fill it at the price shown. Its job is to produce something better than any single input.
A firm with several providers, or one that wants to become less dependent on its current provider, needs aggregation. The questions that matter here are how the book is built, how a stale source is handled, and whether routing decisions can be explained after the fact.
Where they meet
Most modern liquidity hubs do both, which is why the terms blur. Connectivity sits underneath, aggregation sits on top, and execution decisions about what to pass through and what to retain sit beside them. The useful question is not which word appears on the product page but which of these layers you need today and which you will need in a year.
One platform, one provider: connectivity first
Several providers: aggregation and routing
Retaining some risk: execution models and hedging rules
Supplying other firms: distribution, per-client terms and credit controls
Questions to ask before choosing
Whichever you think you need, a few questions expose whether a product will keep up as the business changes.
Can a new provider be added as configuration, or is it a new integration project?
What happens to open orders when a source disconnects, and how is their state recovered?
Can routing be explained per order, with the prices that were available at the time?
Are reports built from the same records that drove execution?
In short
What to take away
A bridge connects; an aggregator combines and chooses
One provider rarely needs aggregation, several always do
Most hubs offer both, so choose by layer, not by label
Test failure handling and explainability before features
Read next
Map your venues before you buy anything
List your platforms and providers and we will show which layers you actually need now, and which can wait.