Liquidity aggregation, in measurable terms
Liquidity aggregation is the process where buy and sell interest from multiple sources is made available to interact, typically across one or more trading venues. To measure it, you need observable inputs and a defined time window, because liquidity is not a single value: it changes with time, venue, and trading costs.
A practical definition for measurement is: how much tradable opposing interest is accessible and how quickly trades can be executed against it, given a specific instrument, venue scope, and measurement time.
Measurable fields: what to compute
You can measure liquidity aggregation using several fields. Each field must include (1) the instrument (e.g., the currency pair), (2) the venue or venue set you treat as “aggregated,” and (3) a timestamp or time window.
- Displayed depth / visible liquidity (per snapshot)
- Define a snapshot time (T) and record quantities at price levels near mid-price.
- Compare depth in the aggregated view versus depth in a single venue view.
- Assumption: displayed liquidity is an imperfect proxy for true fillability, because orders can be canceled.
- Effective execution metrics (over a window)
- Define a test window [T1, T2] and collect executed trades from the same instrument and venue set.
- Use fields such as average execution price relative to a reference (e.g., mid-price at or before execution), realized spread, and slippage.
- Assumption: costs include bid-ask effects and any observable fees; unobserved costs should be documented.
- Market impact and fillability proxies
- Estimate how much the price moves when buying or selling a known notional over the window.
- If you have access to order-level data, compare how quickly marketable orders are filled (fill rates) versus how long they remain unmatched.
- Limitation: different routing and matching rules across venues can change results even when “liquidity” appears similar.
Evidence and example comparisons (with explicit assumptions)
Consider two measurement approaches over the same instrument and the same time window [T1, T2].
Option A: Snapshot depth comparison
- Take snapshots every N seconds and record visible depth within a fixed distance from mid-price.
- Compute the average aggregated depth across snapshots.
- Compare it to the average depth from one selected venue.
Option B: Execution quality comparison
- Collect executions during [T1, T2] that are routed or attributed to the aggregated venue set.
- Compute realized spread and average slippage versus a reference at the time of execution.
- Compare it to executions from the single selected venue.
Key assumption for both options: the timestamping and reference price must be consistent. If one dataset uses one timestamp standard (or updates at different frequencies) while another uses another standard, differences may reflect measurement timing rather than liquidity aggregation.
Limitations, failure modes, and verification
Material limitations can prevent a single metric from representing “aggregation” reliably.
-
Dynamic liquidity and cancellations Displayed depth can appear stable during calm periods but change quickly due to cancellations. A snapshot-based measure may overstate executable liquidity if many orders do not survive to interaction.
-
Venue scope and attribution differences “Aggregated” can mean different things depending on data source. Two datasets can label similar venues but differ in which routes, pools, or execution channels they include, changing measured depth and execution quality.
-
Execution-cost confounding Realized slippage and spreads depend on trading costs and execution mechanics. Even if aggregated liquidity increases, poor routing or latency can worsen execution quality.
-
Historical relationships do not guarantee future results If you observe that aggregated execution quality is better in one period, that does not establish the same relationship later under different volatility regimes.
Independent verification checklist:
- Confirm instrument identity, venue set, and time window.
- Use consistent timestamps and reference definitions.
- Repeat measurements across multiple windows with different volatility.
- Compare at least one liquidity metric (depth/marketable availability) and one execution metric (realized spread/slippage).
If you cannot access both order-book-like information and execution outcomes, you should expect incomplete measurement. In that case, measurement should be framed as “a partial proxy,” not as a direct quantification of aggregation.
Next question to clarify before measuring
Before you choose metrics, clarify what “aggregated” means for your context: which venues are included, what data feed defines them, and what timestamp standard is used.