What “Last Look” means in Forex
Last Look is a mechanism used by some liquidity providers where an incoming trade request is not immediately final. Instead, the provider can perform checks at or near the time the request is received and then either accept the quote for execution or reject it.
A simple model helps when thinking about implications:
- A client submits an execution request.
- The provider decides whether the request is still acceptable under its Last Look rules.
- The provider either executes (or confirms) the request, or it rejects it.
A crucial point is that the “checks” are not part of the client’s submitted intent alone. They depend on conditions at the provider side: whether the market moved since a reference moment, whether internal thresholds were exceeded, and how the provider compares prices or rates.
Because this mechanism is provider-controlled, “Last Look” can behave differently across venues and providers. When reading documentation or analyzing execution logs, treat it as a family of behaviors, not one fixed rule.
Advanced considerations: dependencies you must separate
1) Stable mechanics vs variable conditions
Separate what is stable from what is variable:
- Stable mechanics: Last Look introduces a conditional acceptance step after an execution request is received.
- Variable conditions: the provider’s decision can depend on market volatility, latency, spreads, internal risk limits, and jurisdiction or venue policies.
If you do not separate these, you may incorrectly attribute outcomes to your client-side logic. For example, a rejected request does not automatically imply that your request was “wrong”; it may reflect the provider’s internal accept/reject rules under current conditions.
2) Timing and the meaning of “still acceptable”
Advanced analysis often hinges on timing. You need to understand what “reference time” the provider uses for comparison and how much time it allows before a decision must be made.
Assumptions you should make explicit for any calculation or example:
- The exchange or feed timestamp on the client side may differ from the provider’s internal timestamp.
- Network latency and processing time can be meaningful compared with any Last Look decision window.
- A fast price change can turn an initially acceptable request into a rejected one.
3) Which price or rate is compared
Last Look decisions typically require comparing something about the incoming request against something observable at the provider side. Common uncertainties include:
- Whether the comparison uses bid/ask at decision time or a mid reference.
- Whether the comparison includes the provider’s own spread or pricing model.
- Whether the provider uses a tolerance band (for example, a maximum deviation) rather than a strict equality.
If the provider does not expose these details transparently, independent verification is limited to what your records show (request times, accept/reject outcomes, and any reason codes included in your data).
4) Costs and post-decision effects
Even when Last Look only controls accept/reject, overall results can still be affected by:
- The effective spread at execution time.
- The presence of any fees or commissions applied by intermediaries.
- Differences between the quote you expected and the quote actually executed.
To keep analysis self-contained, treat “cost” as an observed delta in your execution records (for example, the difference between your intended price reference and the executed price), rather than relying on assumptions about future market behavior.
Evidence and examples: how Last Look shows up in real execution data
Below are example patterns you can look for without assuming any particular provider implementation.
Example A: Rejections cluster during fast moves
Assumption for the example:
- You have execution logs with timestamps for each request and an accept/reject outcome.
What to check:
- Whether rejections increase during periods known for higher volatility.
- Whether the time between request and final response is consistent.
Limit of this approach:
- Correlation does not prove causation. Higher volatility may coincide with other factors such as risk limits or order-handling rules.
Example B: “Late” decisions create mismatched expectations
Assumption for the example:
- Your system records a quote or reference price when you submit the request.
What to check:
- The relationship between your submission timestamp and the price level at the time your recorded response arrives.
- Whether accepts and rejects show systematically different timing.
Key uncertainty:
- Without synchronized clocks between your system and the provider, “what the provider saw” may not be reconstructable exactly.
Example C: Partial fills and multiple legs
If the mechanism interacts with partial fills, you may see:
- Some parts accepted and others rejected.
- Different outcomes across repeated attempts.
Assumption:
- Your dataset distinguishes fills, rejects, and partial acknowledgments.
What to check:
- Whether the rejection rate depends on size, number of attempts, or sequence.
Failure mode:
- If your logging merges multiple events into a single “attempt” record, you may misread how Last Look affected each segment.
Limitations and risks: failure modes in understanding Last Look
1) Limited transparency
A material limitation is that you may not receive detailed information about why a request was rejected. Without reason codes or documented thresholds, it is hard to separate:
- Market movement effects from provider risk checks.
- Technical handling differences from Last Look-specific filters.
2) Hidden constraints and edge-case behavior
Advanced edge cases can produce outcomes that look inconsistent:
- Rapid price changes that occur between request submission and the provider’s internal evaluation.
- Moments where spreads widen quickly, changing what is “acceptable.”
- Situations where your retries are treated as separate decisions, possibly with different timing and therefore different outcomes.
3) Analytics can be misleading without careful definitions
Verification requires clear definitions. Common pitfalls:
- Treating “reject” as “price was worse” without confirming the provider’s decision rule.
- Comparing request reference prices to execution prices without accounting for timestamp differences.
- Overfitting conclusions to one market regime.
Historical relationships do not establish future results, especially in markets with varying volatility and liquidity.
4) Jurisdiction and venue variability
Execution and legal handling can differ across jurisdictions and venues. This creates a risk of assuming one provider’s behavior generalizes. For accurate understanding, rely on provider legal documentation, official venue explanations, and your observed execution records, and expect variability.
How to verify Last Look behavior and what to ask next
Independent verification checklist
To independently verify how Last Look affected your executions, focus on data you control:
- For each request: record request timestamp, intended reference (what you used), and accept/reject outcome.