How liquidity aggregation works (and why your fill isn't the one you expected)

Between the price a Tier-1 bank quotes and the fill your broker's client receives, there's a chain of technical decisions that almost never gets explained. That's where execution quality is won or lost, and where most of the arguments that end in "the provider is doing something funny to us" actually live.

Usually it isn't doing anything funny. It's applying rules nobody explained to you.

What aggregating actually means

Aggregating liquidity is building a synthetic book out of several real books.

The aggregator maintains simultaneous sessions with multiple sources — banks, ECNs, non-bank market makers — and receives from each a price stream with its levels and sizes. Its job is to merge all of that into a single coherent book you can execute on.

Sounds trivial. It isn't, for four reasons.

1. Prices don't arrive at the same time

Each source has its own latency to the aggregator. A feed that arrives 3 milliseconds later than another is describing a slightly different market.

The aggregator has to decide what to do with that desynchronization: if it builds the book with the latest it received from each source, it's mixing photos taken at different moments. If it waits to synchronize, it adds latency.

There's no universally correct answer. There's a design decision, and you should know which one your counterparty made.

2. Sizes overlap

If three banks each quote 1 million at 1.0850, your book doesn't necessarily have 3 million at that price. It might. It might also be that two of those banks are covering the same position and, when you try to execute all three, one rejects.

Nominal aggregated depth and real executable depth are different numbers. A serious aggregator shows you the second.

3. Symbols have to be normalized

Each source names its instruments its own way. XAUUSD, GOLD, XAU/USD and Gold Spot can be the same asset under four different conventions, with differences in contract size, price digits and session hours.

Symbol mapping is tedious and unglamorous, and it's where half of all integrations break. If your provider doesn't agree the full mapping of your catalogue before certification, you'll discover it in production with an instrument that quotes wrong.

4. There are routing rules

With the book built, there's still the decision of who each order is sent to. And there, neutrality ends: there's policy.

The routing rules are the part that matters

An aggregator can route by several criteria, and the choice directly affects your fill:

By best price. The obvious one: it's sent to whoever quotes best. The problem is that the best price sometimes comes from the source with the worst acceptance rate, so you optimize the nominal price and worsen the real fill.

By acceptance rate. Sources that historically reject less are prioritized, even if they quote slightly worse. Better effective fill, slightly wider nominal spread.

By latency. Whoever responds fastest is prioritized. Relevant for time-sensitive strategies, irrelevant for large tickets where depth matters more.

Weighted. Combinations of the above with configurable weights. This is the norm among serious operators.

Here's the point: the criterion your provider uses determines what fills you get, and many brokers never ask which it is. If your clients complain about slippage and your provider routes by nominal best price against sources with aggressive Last-Look, you already know where it comes from.

Ask this: by what criterion do you route my flow, is it configurable, and can you show me the acceptance rate for each upstream source?

Where execution quality is lost

There are four specific points in the chain where the fill degrades:

In book construction. If the aggregator shows nominal depth instead of executable depth, your desk is making decisions on a book that doesn't quite exist.

In the rejection. When a source rejects under Last-Look, the order is re-routed. That retry costs time and, in a moving market, price. A 5% rejection rate doesn't mean 5% of your orders fail: it means 5% execute worse.

In the markup. Almost every aggregator applies a margin over the source price. It's legitimate — it's their business — but it should be explicit and consistent, not variable depending on the moment.

In the last mile. Between the aggregator and your platform there's another hop, with its own latency and its own behavior on disconnection.

What you should be able to audit

A healthy execution relationship lets you reconstruct, for any transaction:

• The reference price at the moment the order arrived
• Which source it was routed to and why
• Whether there was a rejection and re-routing
• The timestamp of each step
• The final price and the difference from the reference

If your provider can't give you that, it's not necessarily hiding something: it might simply not record it. But in any discussion about execution quality you'll be at a permanent disadvantage, and before a regulator or an allocator you won't be able to prove anything.

A common misunderstanding: aggregating is not providing

A clarification is worth making, because it causes expensive confusion.

An entity that aggregates liquidity and executes its clients' transactions against that book is acting as an intermediary in the execution. It's a specific activity, with a specific license.

An entity that hands you the aggregated feed for you to execute against it on your own book is doing something different, which in several jurisdictions requires different permissions.

From the commercial side, both present themselves as "we give you liquidity." From the regulatory side they aren't the same, and the difference matters when someone asks under what authorization each part of the chain operates.

At Exura Prime the relationship is the first one: brokers, prop firms and funds onboard as institutional clients and execute through us. The license details and the link to the FSC's public register are in legal information.

How to evaluate this in a demo

Most demos show the pretty book and the perfect fills. For the demo to mean anything, ask specifically for:

1. To see the executable depth, not the nominal, at the ticket size you actually trade
2. A complete log of a test transaction, with timestamps for each hop
3. To execute during a news window, not in a flat market on a Tuesday afternoon
4. The acceptance rate by source over the last 30 days
5. The symbol mapping of your full catalogue, not a sample

If the sandbox has production parity, all of this is possible before you sign anything. If it doesn't, any test you run describes a system that isn't the one you'll use.

For the general evaluation framework: how a broker chooses liquidity. For the technical detail on connectivity: FIX API.

Frequently asked questions

Is more aggregated sources always better? No. Adding sources with a poor acceptance rate or high latency worsens the effective book even if it improves the nominal one. Source quality and routing policy matter more than the number.

Why does my spread widen on the news if the aggregator has 15 banks? Because the banks widen simultaneously. Aggregation diversifies the risk of one source failing, not the risk of the whole market moving. No aggregator can give you liquidity that doesn't exist in the underlying market; anyone who promises you that is describing internalization, not aggregation.

How do I know if I'm being charged a markup? By asking directly and requiring it to be explicit in the agreement. A declared, consistent markup is normal. A variable one that appears only at certain moments is a problem, and it's only detected by comparing your fills against an independent reference.

Is nominal depth good for anything? For comparing providers in a very rough way, and little else. To decide, always ask for the executable depth at your real size.