What data is needed to assess Liquidity By Session?

What data is needed to assess liquidity by session

Assessing liquidity by session starts with collecting inputs that let you describe trading depth and trading “ability to transact” over defined time windows. The key is to use (1) measurable liquidity proxies, (2) a clear time definition for each session, (3) reliable provenance for every dataset, and (4) checks that confirm timeliness and internal consistency. Without these, results can reflect data artifacts rather than liquidity behavior.

Mechanism and definition: what you are measuring

“Liquidity by session” means comparing market liquidity characteristics across specific trading sessions (for example, major regional trading hours). To assess it, you typically need:

1. Session boundaries

• The exact start/end times used for each session.
• The time zone (and how daylight saving changes are handled).
• A rule for what happens at overlaps (if two sessions overlap, decide whether you assign trades to one session or split them).

2. A liquidity proxy (the observable you can compute) Liquidity is not a single physical quantity, so you must choose proxies that match your definition. Common categories include:

• Transaction-based: measures derived from trade prints such as number of trades per window.
• Quote-based: measures derived from bid/ask quotes such as spread or quote updates.
• Order-book based (if available): depth at price levels or volume in the book.

3. Market coverage and instrument mapping

• Which instruments are included (for example, specific forex spot pairs or derivatives), and whether the mapping is one-to-one.
• Whether you aggregate multiple venues or providers into one dataset.

4. Costs and execution context (needed for interpretation) Even if your goal is descriptive liquidity, you should record the context that affects observed liquidity measures:

• Trading costs that influence quotes and trades in your data feed.
• Data feed rules (how missing quotes or late updates are represented).
• Whether observations are mid-price, bid/ask, or last trade.

Evidence and example: inputs, provenance, and assumptions

Below is a self-contained checklist of data you need and the quality you should confirm.

Inputs to collect

• Quote series: bid and ask prices (or at least spread) at a known sampling frequency, with timestamps.
• Trade series (if used): executed trade timestamps and sizes.
• Session calendar: session start/end times plus the chosen time zone.

Provenance to record

• Where the data came from: a data provider, an exchange/venue feed, or a broker/API.
• How timestamps are produced: whether timestamps are in UTC, exchange-local time, or broker-local time.
• Data handling rules: whether the provider interpolates, drops, or flags gaps.

Timeliness assumptions (because “liquidity” is time-dependent)

State explicitly whether you are analyzing:

• Historical liquidity for past sessions, or
• Near-real-time snapshots. If your dataset is historical, you cannot claim current liquidity conditions; you can only describe what the dataset shows for those past windows.

Calculation assumptions for any metric

For any metric you compute (spread average, fraction of time within a spread band, trade count, quote update intensity), document:

• The aggregation window (per minute, per session, per sub-interval).
• How you treat missing bid/ask pairs.
• Whether you use simple averages, medians, or time-weighted measures.

A minimal example assumption might read like: “Session liquidity is computed per session using time-weighted average spread from bid/ask quotes sampled with provider timestamps; intervals with missing bid or ask are excluded.” Such assumptions are what make the result independently explainable.

Limitations and risks (including failure modes)

At least one material limitation should always be considered:

1. Time-zone and boundary errors If session boundaries are misaligned (wrong time zone or daylight saving handling), your “session” comparison may be mixing different liquidity regimes.

2. Data incompleteness and venue effects Quotes may be missing during fast moves, and trade feeds may reflect a subset of activity. This can distort liquidity proxies even if prices look plausible.

3. Proxy mismatch Spread, trade count, and depth are related but not identical. A narrow spread can coexist with low depth, and a higher trade rate can reflect volatility rather than investable liquidity.

4. No guarantee of forward-looking validity Historical relationships between session timing and liquidity do not establish future results. Market structure, participation, and costs can change.