A quoted EUR/USD price does not alone establish an accepted trade. Last look is a final validity or price check before a trade request is accepted or rejected. It is primarily a wholesale electronic FX practice; a retail CFD’s execution path and contractual duties are separate questions. A rejection or requote alone does not identify the mechanism.

What last look actually is

Last look gives a liquidity provider a disclosed checking window before accepting or rejecting a trade request. The validity and price checks, timing and information use should be assessed against its policy and the applicable framework. This article does not establish a typical few-to-dozens-of-milliseconds range for the whole market.

The key difference from an exchange-traded market is that exchange matching follows the venue's rules and available orders, while a last-look provider reserves a checking window before accepting or rejecting a trade request. In a last look model the provider's quote is, in practice, an invitation to trade rather than a binding offer — the final word belongs to the entity quoting. For you this means the price on your screen is not a guarantee of execution. Between your click and the confirmation stands a decision by the other side.

Why the window exists at all

The argument for last look is serious and worth understanding before you write the mechanism off as pure malpractice. A liquidity provider quotes prices to many clients across many platforms at once. In a world where information moves faster than its own systems can refresh a quote, it is exposed to latency arbitrage — a situation where a faster participant trades on a price that is already stale before the provider can pull it. Last look gives it a moment to catch such a case and protect itself against so-called toxic order flow, a stream of trades that systematically exploits its latency.

Checking a stale quote can limit the quoting provider’s exposure, but does not guarantee a tighter spread or a better result for every client. Rejected requests can leave the client exposed to a different price. Evaluate the complete process and subsequent execution cost, not just the displayed spread.

Where the controversy hides — asymmetry

The problem starts with asymmetry. Imagine that during the last look window the price can move either way. If the move favours the liquidity provider (and works against you), the trade is accepted — the provider is happy to take the rate that suits it better. If the move favours you, the trade is rejected, because the entity quoting does not want to fill at a price that has just turned unfavourable for it. It is an arrangement in which one side keeps the favourable deviations for itself and passes the unfavourable ones on to the client.

Separate an unfilled request, a new quote and slippage that lands against the client surprisingly often. Acceptance at the original requested price has no slippage against that reference even if a later quote is better. Existing logs and policy can justify further questions, but statistics alone do not identify every cause. The alleged hunting of stop-loss orders is a separate issue.

Two clocks do not make one measurement

Fictional client and server logs record milliseconds from different origins. Their values cannot be directly compared.

Two clocks do not make one measurementThe consistent client clock shows a 16 ms response time. The server entry alone does not establish the last-look window.MODEL / SPECIFIC DISTINCTIONClient clock: send100 ms from its originServer clock: receipt96 ms from another originClient clock: response116 ms from the same originValid available measurement116 − 100 = 16 ms response time

Hypothetical logs for one request, with unsynchronised client and server origins. We assume a stable client clock and no measurement error. The numbers are not broker data. Transport, checks and execution are not measured separately. The document GFXC — last-look report distinguishes request stages and the checking window; it does not determine the offset of these fictional clocks.

The consistent client clock shows a 16 ms response time. The server entry alone does not establish the last-look window.

Subtracting 96 from 100 would suggest an event before sending, but mixes two clocks. Measuring the checking window requires its boundaries on a comparable time scale. A response can accept or reject the request; 16 ms proves neither last look nor improper delay.

A hypothetical example — what one rejection looks like

This is a hypothetical one-sided rule, not a provider measurement. Marek requests a EUR/USD purchase at ask 1.0850; assume a 50-millisecond check. An ask rise to 1.0851 causes rejection of the original request; a subsequent purchase would depend on a new available quote. An ask fall to 1.0849 instead leaves the request accepted at 1.0850. With a 0.0001 pip, that fill is one pip above the later ask but exactly at the requested price. Rejection is not a realised loss, and the second case is not slippage against the original request.

The hypothetical example uses a one-sided acceptance rule. It does not establish how your provider checks prices. Ask which reference price, tolerance and acceptance criteria apply, including whether checks differ by direction. Comparing a single requote does not identify the full checking policy.

What the rules say

Principle 17 of the wholesale FX Global Code addresses validity and price checks, disclosures and use of information from the request. It generally discourages trading that uses that information during the check, with a narrowly described exception for documented and disclosed cover-and-deal arrangements passing the full traded volume to the client. The Code is not itself a statute or a worldwide legal permission.

The FX Global Code is a wholesale-market good-practice code and explicitly does not replace local law or impose legal obligations. Principle 17 addresses last-look transparency and appropriate use as a validity or price check. Distinguish a participant’s Code commitment from the regulatory rules governing your retail account.

Where you will meet last look, and where you will not

Last look is used in parts of electronic FX liquidity provision, but neither an ECN label nor a retail platform screen establishes its use on your order. Read the execution policy and ask the provider about the relevant request path and checking criteria; no market-wide prevalence is quantified here. Related reading: wholesale interbank market, ECN model differs from the market-maker model.

Ask which part of the actual request path uses last look, the reference price, directional tolerance, expected timing and rejection reasons. Lack of information limits assessment; it does not alone prove misconduct. The FCA’s dated 2021 statement treats extra delay to observe future prices as inconsistent with the voluntary codes and stresses disclosure. Assess the actual conduct and applicable law separately.

What to do tomorrow

  1. Put one concrete question to your broker. Write on chat or by email: "Is last look applied to the execution of my orders, and if so, is it symmetric or asymmetric, and what is the typical window length?" Save the answer. The absence of a clear reply is itself information about how transparent that broker is.
  2. Review your own rejection history from the past month. Open the trade report in your platform and count how many orders were rejected or requoted, and at which moments it happened. If the rejections cluster around fast moves in your favour, you have grounds to look closer and to raise the matter with your broker.
  3. Check the execution-quality documents. Go to your broker's website and find the order execution policy and any liquidity-provider disclosure sheet. Look for the words "last look", "price check", "symmetric" and "asymmetric". What a broker declines to disclose tells you more than what it advertises.
  4. Use comparable existing data first. Do not open live positions merely to diagnose infrastructure. In a hypothetical sample, eight acceptances after 5 ms and two rejections after 80 ms give (8 × 5 + 2 × 80) / 10 = 20 ms mean response time, compared with 5 ms among acceptances. The mean of all responses is not mean fill time; neither statistic alone proves improper last look.