Direct answer
Liquidity aggregation is the idea that buy and sell liquidity from multiple sources can be combined—directly or indirectly—so a system can represent a more complete view of what prices can be traded at. A “worked example” is a numerical scenario that states assumptions (depth, spread, and costs) and then shows what changes when liquidity comes from one source versus several.
Mechanism or definition
In a typical market, “liquidity” is how much of an asset can be bought or sold near a price, often described as order-book depth. Liquidity aggregation aims to treat liquidity from multiple sources (for example, different counterparties or trading venues) as if it were available together.
A worked example usually separates mechanics from variability:
- Stable mechanics (assumed): you can model depth by price levels and compute the notional you can fill before reaching a limit price.
- Variable conditions (not assumed stable): bid–ask spread, depth distribution, execution latency, fees, and venue behavior can differ over time.
To avoid treating it as a standalone signal, the example should focus on how an execution might be constructed rather than predicting profitability.
Evidence or example
Assume an FX pair quoted as a simplified bid/ask ladder (no real-time data). Also assume:
- You want to buy 1,000,000 units (base currency) at “marketable” prices.
- You consider three sources of liquidity: Source A, Source B, and Source C.
- Each source has depth at specific price levels relative to a reference mid-price.
- There is a constant fee of 0.10% of executed notional.
Step 1: Single-source view
You are able to execute only against Source A. Assume Source A has the following ask-side depth for your order size:
- At ask level 1: price quality corresponds to fill 400,000 units
- At ask level 2 (worse by a small amount): fill 300,000 units
- At ask level 3 (even worse): fill remaining 300,000 units So Source A can fill the entire 1,000,000 units, but the average execution price will be worse than the best level.
Step 2: Aggregated view across sources
Now you allow liquidity aggregation across Sources A, B, and C. Assume:
- Source A provides 400,000 units at the best level, then 100,000 at the next level.
- Source B provides 300,000 units at a level that is better than A’s third level.
- Source C provides the remaining 200,000 units at a further level.
In this scenario, aggregation changes the distribution of fills across price levels. Even with the same total size (1,000,000 units), using more favorable liquidity levels can reduce the average execution price compared with using only Source A.
Step 3: Account for costs (fees)
Executed notional is still 1,000,000 units, so the fee component is the same in this simplified setup: fee = 0.10% of executed notional.
What differs is the price you pay at each level, which affects gross transaction value and therefore net results. Because we did not specify exact price increments in this article, the worked example illustrates structure: aggregation changes which levels you can hit first.
What you can independently verify
You can verify the logic without real-time prices by checking whether a system’s execution respects the modeled constraints:
- Does it avoid worse price levels when better liquidity exists in other sources?
- Does it fill partially when depth is insufficient?
- Do realized fills correspond to the stated depth assumptions?
Limitations and risks
One material failure mode is insufficient or changing depth. If the aggregated sources do not maintain the assumed order-book levels, the system may experience partial fills or move to worse prices.
Other important limitations:
- Spread and depth variability: the best available liquidity can disappear as other participants trade.
- Latency effects: between calculating an aggregated view and executing, conditions can change.
- Execution and venue differences: “liquidity” may not be equally executable; some sources can have constraints, different fee schedules, or different operational behavior.
- Model mismatch risk: the numeric ladder you assume may not reflect the real distribution of orders.
Because costs, execution quality, and market conditions vary, historical relationships do not establish future results.