BridgeX · Use Cases
Six problems a liquidity hub is built to solve
Every firm arrives with a different reason. These are the situations we meet most often, what goes wrong without a hub, and the modules that take the problem away.
Several CFD providers, one tradeable book
The situation
A broker takes CFD pricing from three providers. Each has its own symbols, precision and session rules, and the dealing desk is switching between them by hand when one widens.
How the hub handles it
The three streams are normalised and aggregated into one book. Routing sends each order to the best price that can actually fill it, and a provider that degrades simply stops winning.
Quoting crosses nobody streams
The situation
Clients in one region want pairs such as a local currency against gold or against a major crypto asset. No provider quotes them directly, so the broker either refuses the business or prices it by spreadsheet.
How the hub handles it
The cross is composed from live legs that are streamed, with the broker's spread on top. A fill on the synthetic is hedged through the underlying legs automatically.
Live rates for a payment flow
The situation
A payment processor quotes customers a conversion rate at checkout. A stale or single-source rate means it either overcharges and loses the customer or undercharges and loses the margin.
How the hub handles it
BridgeX publishes a continuously aggregated rate to the checkout through the API, with stablecoins held at parity and a defined fallback when a source goes quiet.
Spot and perpetuals on one venue
The situation
An exchange lists spot pairs and wants to add perpetual futures. Running a second liquidity stack for derivatives would double the integrations and split the client's margin.
How the hub handles it
Spot and perpetual liquidity come in over the same hub, and margin accounts can be held in the asset the venue's clients actually use, including stablecoins and bitcoin.
Hedging bursts without paying for every ticket
The situation
A popular strategy opens a position and two thousand follower accounts copy it within a second. Hedging every ticket floods the provider and pays the spread two thousand times.
How the hub handles it
Offsetting flow nets internally, the retained amount stays inside a threshold the desk chose, and the remainder is hedged from a pooled book on a time or size trigger.
Becoming a liquidity provider
The situation
A broker with spare balance sheet and good provider relationships wants to supply liquidity to other brokers and funds, but has no distribution layer or counterparty administration.
How the hub handles it
BridgeX distributes the firm's own pricing to counterparties on terms set per account, with margin, stop-out and reporting handled by the hub. The turnkey route adds the rest of the business.
Related pages
Where these cases lead next
Use case questions
Before you pick a starting point
4 short answers to what teams ask before a demo.
No. Most firms start with the module that solves their most expensive problem, usually aggregation or hedging, and switch on more as the book grows. Each module is configured independently.
Yes, and most do. A broker that aggregates CFD providers often adds synthetic crosses and hedging programmes later on the same hub, with the same counterparty accounts.
Not at all. These are the patterns we see most often, not a limit on what the hub does. Describe your flow and we will map it to the modules that fit.
It depends on how many venues and counterparties are involved and how quickly sessions can be certified. We agree a timeline once the venues and accounts are known rather than quoting one in advance.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialist