Liquidity aggregation, defined
Liquidity aggregation is the process where liquidity from multiple market sources is combined into a single, usable view for trade matching and execution. In practice, this can involve aggregating quotes and order-flow across venues, intermediaries, or internal systems so that buyers and sellers can interact more efficiently.
To assess liquidity aggregation, you first need data that describes (1) what is being aggregated, (2) where it comes from, and (3) how it is transformed into the executable outcome you observe. Without those pieces, you cannot tell whether observed behavior is due to the aggregation mechanism or due to changing market conditions.
Direct answer: what data you need
Assessing liquidity aggregation requires four groups of data: inputs, provenance, timeliness, and quality checks.
- Inputs (what is being aggregated)
- Quote-related fields: bid/ask levels, quote timestamps, and depth or size-at-price measures (if available).
- Execution-related fields: fill prices, fill times, and quantities.
- Routing/matching-related fields: how orders are matched or routed across sources (even a high-level description matters).
- Provenance (where each input comes from)
- Source identity: the venue, intermediary, internal pool, or feed provider for each data stream.
- Data collection method: streaming vs. polling, snapshot vs. incremental updates.
- Transformation notes: any aggregation rules, unit conversions, latency compensation, or filtering.
- Timeliness (how fresh and comparable the data is)
- Timestamp definitions: whether timestamps represent quote creation time, receipt time, or system time.
- Update frequency and jitter: how often data changes and the variability in update timing.
- Synchronization: whether multiple sources are time-aligned or whether observed differences could be timing artifacts.
- Quality checks (whether the data is usable for assessment)
- Missingness and gaps: quantify when and where data drops.
- Consistency checks: verify units (base/quote), decimals, and sign conventions.
- Duplicates and reordering: detect repeated snapshots, out-of-order updates, or clock drift.
- Comparability: confirm that data streams measure the same “thing” (e.g., displayed depth vs. tradable depth).
How the data is used, with a concrete example
A simple assessment approach is to compare the “aggregated view” to the underlying sources, while controlling for time and quality.
Example (assumption-based, not real-time): suppose you can observe (a) source A quotes, (b) source B quotes, and (c) an aggregated quote or execution outcome at the aggregator.
- Define an explicit time window (assume 1-minute windows) and a synchronization rule (assume timestamps are in the same time standard).
- Measure whether the aggregated bid/ask represents a combination of available liquidity from sources, not just a single source.
- If you see executions at prices that exceed what either source shows in the same window, the discrepancy could indicate transformation rules, stale quotes, latency, or different liquidity definitions.
The key point is that the same mechanism can look different depending on timestamp interpretation, filtering rules, and how “depth” is defined. This is why timeliness and provenance data are required, not optional.
Material limitations and failure modes
Several limitations can break an assessment even with good data.
- Timing failure mode: if timestamps are not comparable across sources, you may attribute differences to aggregation, when they are actually due to delayed updates.
- Definition mismatch: “liquidity” can mean displayed quotes, executable quotes, or routed order-flow. If the measured fields do not match the definition used in the aggregator, conclusions can be wrong.
- Stale data failure mode: historical or infrequently updated inputs may preserve relationships that do not hold under current conditions.
- Execution-and-cost distortion: observed fills can be affected by costs, spreads at execution time, and venue-specific mechanics. Historical relationships do not establish future outcomes.
Because outcomes vary with market conditions, costs, execution, and jurisdiction, you must frame findings as conditional on the data window and assumptions you used.
Evidence checklist: verification and next questions
To verify your assessment independently, ensure you can answer the following “ready-to-audit” questions.
- Are all input streams tagged with their source and collection method?
- Do you know what each timestamp represents (quote time vs receipt time)?
- Can you quantify missing data and remove or flag low-quality periods?
- Do you have documentation for any aggregation transformation rules (such as filtering, conversion, or routing logic)?
If any of these answers are “unknown,” treat the assessment as incomplete.