What Last Look is, in measurable terms
Last Look in Forex is a mechanism where an order can be provisionally accepted for execution but later rejected (or not executed) after a short check by the liquidity provider. To measure it, you translate the concept into observable events and recordable fields. That approach separates relatively stable mechanics (what decisions happen and when) from variable conditions (market movement, costs, and implementation choices).
A practical way to define it for measurement is to track each attempted order as an event with at least these fields:
- Order timestamp (t_order): when you believe the request was sent.
- Quote or price basis timestamp (t_quote): when the price used for the request was observed.
- Decision outcome: accepted/executed or rejected/not executed.
- Decision latency (Δt): the time between the relevant price basis and the final outcome.
- Execution price and fees (if executed): the final fill price and any directly attributable costs you can record.
If you cannot observe all of these fields from your own logs, you should measure only what you can verify and explicitly note what is missing.
How to measure it using acceptance, timing, and price-quality metrics
A common measurement goal is to quantify both frequency and timing/quality.
1) Acceptance and rejection rates
For a sample of attempted orders, you can compute:
- Acceptance rate = executed orders / total attempted orders
- Rejection rate = rejected orders / total attempted orders
Assumption needed: you define “attempted” consistently (for example, any order that reached the provider, not cancelled locally before sending). Without that, rates can be misleading.
2) Latency distribution
For executed and/or rejected outcomes, compute latency from the fields you trust:
- Decision latency (Δt) = t_outcome − t_quote (or − t_order, depending on what you can justify)
Then summarize using percentiles (for example, median, 90th, 99th). This measures whether decisions cluster around short intervals or stretch under certain conditions.
Assumption needed: t_quote and t_outcome must come from comparable clocks and processing stages. If timestamps are produced by different systems with different delays, your Δt is not an accurate representation of the provider’s internal check.
3) Price-quality comparison at decision time
To measure “price quality” differences without assuming future predictability, compare how the execution price (when executed) relates to the price basis used at the time of the decision input.
One example metric is:
- Price difference = execution_price − reference_price
Assumption needed: reference_price is defined and captured consistently (same quote type, same moment, and same rounding rules). Because markets move continuously, even a correct reference can be outdated by milliseconds; your metric measures the relationship between execution and your chosen reference, not the provider’s “fair value.”
4) Conditional comparisons
To reduce the chance that market movement drives everything, group events by observable conditions you can measure, such as:
- the time window (example: before/after a specific market session)
- volatility proxies you compute from your own price feed
- order size buckets (if you record them)
Similarity requirement: each bucket should have enough events, and your buckets must use the same definitions of reference time and outcomes.
Evidence and failure modes: what can break measurement
Measurement can fail in several material ways. At least one common limitation is missing or inconsistent timestamps.
Limitation: you may not observe the same decision clock
If your t_quote is derived from a feed and t_outcome is from your order management system, there can be delays in both directions. Your measured Δt then reflects pipeline and software latency, not the provider’s Last Look decision timing.
Limitation: “rejection” can have multiple meanings
An apparent rejection could come from:
- the Last Look decision
- a local cancel due to timeout
- rejection due to execution constraints or risk checks you did not model
To treat rejections as Last Look outcomes, you must separate them using definitions from your own logs (for example, distinct status codes). Otherwise, acceptance/rejection rates mix mechanisms.
Limitation: market conditions dominate short horizons
Even with correct timestamps and clear definitions, short-horizon results vary with market conditions, trading costs, and execution venues. Historical acceptance rates and price-difference distributions do not establish future outcomes.
Verification and next question to make the measurement reliable
Independent verification comes from auditing your definitions and reconstructing the event timeline.