What is a worked example of Liquidity by Session?

Direct answer: what a worked example is

A worked example of “Liquidity by Session” is a transparent, step-by-step scenario that illustrates the idea that liquidity conditions can differ by trading session (for example, when more participants are active). The example should state assumptions (times, direction, price levels, and costs), do simple calculations, and then explain why real outcomes may differ.

Mechanism and definition

“Liquidity” generally means how easily a market accepts trades with limited price movement. “Liquidity by session” is the concept that this ease can change depending on the session window (often linked to when particular markets are most active). In a worked example, you separate the stable mechanics from variable conditions:

• Stable mechanics (example framework): define a reference price, define a session window, and model “liquidity draw” as the idea that price may travel toward areas where liquidity is thinner or where many orders are clustered.
• Variable conditions (example limits): spreads, execution quality, order-book depth, and news-driven volatility can change from one day to another.

A worked example should not claim a guaranteed result. Instead, it shows a plausible path under explicit assumptions, then highlights where the assumption could fail.

Worked numerical/scenario example (with assumptions)

Assume the following simplified setup for one day. (These values are placeholders chosen for illustration; they are not live prices.)

Assumptions

1. We study one session window (Session A) lasting from time T1 to T2.
2. The starting mid-price at T1 is 1.2000.
3. We identify a “liquidity area” (a price zone we expect price to interact with) at 1.1970–1.1990.
4. We model a “potential travel range” during Session A of 30 pips total in either direction, based on an assumed typical volatility for that session.
5. Transaction cost (spread + slippage + fees) is treated as 2 pips per round-trip for simplicity.
6. We measure movement in pips where 1 pip = 0.0001 for this example.

Step-by-step example

• Step 1 (expected interaction): since the liquidity zone lies below the start price (1.2000 to 1.1990/1.1970), we assume price initially trades lower.
• Step 2 (pick a modeled path): suppose the price reaches 1.1985 at some point in Session A.
• Step 3 (compute movement): from 1.2000 to 1.1985 is 15 pips.
• Step 4 (include costs): if a trader enters and exits during the same session, approximate net movement after 2 pips total costs becomes 13 pips in this simplified measurement.

What the example is “proving”

• It demonstrates how “liquidity by session” can be operationalized as: session window → different trading intensity → modeled interaction with a pre-defined price zone → measurable movement under assumptions.

You can repeat the same structure for a different session (Session B) by changing only the assumed travel range (for example, 10 pips in a less active period vs 30 pips in a more active period) and leaving the zone and starting price the same. The “worked example” then shows the difference comes from changed assumptions about liquidity conditions, not from changing the concept itself.

Limitations and failure modes (why outcomes can differ)

1. Model dependence: the example relies on assumed travel ranges and costs. Real spreads and execution quality vary, so the same framework can produce different results.
2. Provider and venue effects: liquidity availability can differ across brokers and trading venues. A session may look “liquid” in one environment and not in another.
3. Assuming causality from correlation: even if certain sessions have historically shown more movement, that does not guarantee the same behavior tomorrow.
4. Zone selection bias: if “liquidity areas” are chosen after seeing price behavior, the example becomes circular and less verifiable.

Verification and next questions

To independently verify the relevant facts for a liquidity-by-session explanation, you can:

• Keep the framework constant (same calculation steps), but change only one assumption at a time (session window, assumed travel range, or cost).
• Check whether your chosen “liquidity zone” definition is predetermined (based on rules, not on the outcome).
• Compare behavior across multiple sessions to see whether the assumption about “more liquidity” aligns with observed execution conditions.

A useful next question is: what specific rule defines your “liquidity area,” and how would you define it using information available before the session begins?