Last Look in Forex, in plain language
Last Look is a mechanism some forex execution systems use around an incoming trade request. In simplified terms, a participant receives an order and may briefly evaluate whether it can accept it under the provider’s rules. During that evaluation window, the system can accept the request, potentially reject it, or apply an execution outcome that differs from what the trader first saw.
Because the details depend on the provider and the trading relationship, people often overgeneralize. The core mistake is treating Last Look as if it were a fixed, universally behaving feature. It is better understood as a set of configurable rules whose practical effect depends on market conditions and the provider’s implementation.
Common misunderstandings and why they matter
1) Assuming Last Look guarantees execution
A frequent misconception is that sending an order implies it will be executed exactly as requested. With Last Look, acceptance is conditional. A rejection or a changed outcome means the realized trade experience can differ from the initial request.
Consequence: Any expectation based on “submit means filled” breaks down, especially in fast or stressed markets.
2) Confusing “evaluation time” with market price stability
Another mistake is ignoring timing. Even if the underlying quote moves only briefly, the evaluation window can still matter. People may calculate outcomes as if the order price and acceptance decision are made at one single moment.
Consequence: Results from back-of-envelope assumptions can be misleading because the acceptance decision can occur after the time you think it happened.
3) Treating historical fills as a repeatable relationship
Some readers look for a stable relationship between “order intent” and “realized execution” and assume it will generalize. Historical fill behavior can shift when spreads, liquidity, or market volatility change.
Consequence: A model calibrated to past conditions may not hold when the market regime changes.
4) Using the wrong mental model for “improvement”
Last Look is sometimes discussed in ways that blur cause and effect—such as assuming that conditional acceptance always benefits one side. In reality, the provider’s objective and risk management rules are not the same as the trader’s. The mechanism can produce different outcomes depending on who is submitting and how conditions are judged.
Consequence: Conclusions that rely on a single-sided narrative (rather than documented rules) can be false.
Evidence and examples with explicit assumptions
Example: acceptance is conditional
Assume a system evaluates whether an order request meets certain criteria during a short window. If, under those criteria, the order is rejected, then your “intended” position differs from your “realized” position.
To check your reasoning neutrally, separate:
- The order submission parameters (what you asked for).
- The acceptance outcome (accepted vs rejected, and whether execution differs).
- The timing (when the decision occurs relative to quote changes).
If you do not explicitly model conditional acceptance and timing, your example can quietly assume what it is trying to explain.
Example: costs and realized price
Assume a market spread widens. Even if an order is accepted, realized execution may reflect the effective cost environment at the time of acceptance. If your calculation assumes the original spread remains unchanged, you will overestimate similarity between “requested” and “realized” outcomes.
Material limitations, risks, and neutral checks
Material limitation / failure mode: rejection and execution difference
A key limitation is that Last Look can result in rejection or an execution outcome different from the initial request. This is not a theoretical edge case; it is the direct implication of conditional acceptance.
Neutral checks (non-promotional, document- and data-based)
- Document check (afvinkpunten): Identify what is stated in execution or platform documentation about how orders are evaluated, including conditions that can lead to rejection or non-standard outcomes.
- Evidence of behavior (bewijs of document): Compare submitted requests with execution reports over a range of market conditions to see how often outcomes differ from the initial request.
- Red flags (rode vlaggen): Watch for unclear wording about evaluation rules, missing execution reporting fields, or ambiguity about timing measurements.
- “Ready to conclude” criterion (klaarcriterium): Only treat your understanding as complete when you can map each step—submission, evaluation window, acceptance/rejection, and the resulting execution details—to what the documentation and your observed reports show.