Last Look in FX: does it make trade rejections more likely?

If you trade FX electronically you may have seen orders that are “rejected” or “not acknowledged” after you click the price. One common reason is a liquidity provider’s (LP’s) use of a Last Look evaluation window — a short time after the LP receives your trade request during which the LP can accept, improve, or reject the request. This article explains what Last Look is, why it exists, how it affects rejection rates and execution quality, and what retail and institutional traders can do to manage the impact. Trading carries risk; this is general information and not personalised advice.

What “Last Look” means and why LPs use it

Last Look is a micro‑structure feature often used in over‑the‑counter electronic FX. An LP streams a quote, a liquidity taker (your system, broker or algo) sends a request to trade on that quote, and then the LP has a brief “evaluation period” (usually measured in milliseconds) to perform a final validity and price check before sending a firm accept/reject/price‑improve decision.

Those checks typically include operational and risk controls such as credit/limit validation and a comparison of the original quoted price to the LP’s current internal price. The LP may compare the incoming request against its own contemporaneous market view and a tolerance band (a “price threshold”). If the market moved beyond that band during the evaluation window the LP may reject the request, or accept it at an improved price for the client in some implementations.

LPs implement Last Look mainly to protect against two risks. The first is latency arbitrage: very fast counterparties can sometimes hit stale quotes that have not yet been updated. The second is the operational and credit risk that arises when a single LP has exposed displayed liquidity across many venues and clients and needs the chance to confirm it can fulfil the requested size at an acceptable risk.

How Last Look increases trade rejections — the mechanics

Last Look adds optionality for the LP, and optionality implies rejection probability. Two features determine how often requests are rejected:

  • length of the evaluation window (how long the LP waits), and
  • the tolerance or thresholds the LP applies (how far prices may move before rejection).

Short, permissive windows and wide thresholds lead to few rejections. Longer windows or tighter thresholds increase the chance a request will be rejected because the market is more likely to have moved beyond the allowed band.

There are different ways LPs apply the threshold. A symmetric threshold treats price moves in either direction the same: if the live price moves beyond ±X the LP rejects. An asymmetric threshold rejects only when the move is adverse to the LP but accepts (or improves) when it moves in the LP’s favour. Asymmetric checks are more protective for LPs, but they also increase rejection rates on the side that hurts the LP.

Another structural reason rejection rates rise is aggregation and best‑price routing. If your router sends trade requests to whichever LP quotes the best price, you will tend to hit LPs who are temporarily “stale” relative to other venues. That reduces the conditional probability that those LPs will accept: you’ll win more requests when a given LP is the most aggressive, which increases the chance that price adjustments in the evaluation window will make the trade unattractive to the LP.

A concrete example

Suppose an LP streams a buy price at 1.2000 and your system sends a sell request against that price. The LP’s latest internal mid‑price is actually 1.2002 because new information arrived very briefly before the request reached the LP. The LP’s symmetric tolerance is ±0.0001 (1 pips). If the LP’s internal price moves from 1.2002 to 1.2003 during the evaluation window, the quoted price at 1.2000 is now more than 1 pip away from the LP’s live reference and the LP may reject. If the LP used an asymmetric policy that allows a wider band when the move is in the LP’s favour, your same sell request might be accepted if the move benefited the LP but rejected when it hurts them.

From the trader’s perspective a rejected request means either you must resubmit and hope for a better fill (perhaps at a worse price), or your router finds another LP with a less favourable price. Repeated rejections can increase effective trading costs even if individual quoted spreads appear tight.

Does “our” trading system use Last Look?

Whether a specific trading system or broker uses LPs who apply Last Look depends on the relationships and venues they connect to. There is no single global standard: some ECNs and certain LP streams are No‑Last‑Look (firm quotes) and others permit Last Look. Many institutional venues allow both behaviours depending on which LP is providing the liquidity.

You should not assume either way. The practical path is to ask your execution provider or broker for clear documentation. Standard disclosure items to look for include whether Last Look is used, whether the LP applies symmetric or asymmetric thresholds, the maximum evaluation delay, and how rejected trades are reported. Many major LPs and platforms publish Last Look disclosures or provide trade‑by‑trade accept/reject reporting to clients.

If you control a routing or aggregation system, you can also detect Last Look indirectly by analysing trade and quote data: unusually high rates of “NACK” or rejected requests, or a pattern where fills are concentrated on trades that later perform poorly, can indicate LPs are exercising Last Look. But remember, interpreting the raw numbers requires care — market volatility, order size and routing choices all affect observable rejection rates.

How to check whether Last Look is the cause of rejections

Start by asking your broker or platform for the official policy and for the trade‑level data they can provide. A good disclosure will tell you whether they use Last Look, the typical hold‑time range, and whether it is applied symmetrically. If you get trade logs, you can compute:

  • the rejection rate: rejections divided by total requests;
  • the time distribution between request and accept/reject (average and percentiles);
  • conditional fill performance: whether accepted trades later move against you more often than rejected trades would have.

If you receive richer FIX or platform messages, look for accept/reject reason codes, timestamps of request/decision, and whether the platform flags “rejected due to price check” or similar. These data allow you to benchmark LP behaviour and look for outliers.

Practical steps traders can take to reduce Last Look impact

If Last Look is contributing to higher effective costs or excessive rejections, there are several practical responses that can reduce its impact. Below is a short list of typical actions traders take; read it as examples rather than advice tailored to your situation.

  • Discuss execution settings and disclosures with your broker. Ask for Last Look policy detail and whether they will route you to No‑Last‑Look pools for certain order types.
  • Adjust order size and timing. Smaller child orders are less likely to trigger LP limits and may face fewer rejections; spreading a block trade in time reduces the chance of hitting a stale quote.
  • Choose execution style to match venue characteristics. Use limit orders to preserve price, or accept market execution on firm pools if you prioritise certainty of execution over price.
  • Use multi‑venue routing and measure performance. Route across several LPs and tiers; measure post‑trade slippage and rejection patterns to identify which LPs/venues fit your strategy.
  • Request trade‑level reporting. Ask for accept/reject reason codes, timestamps and any available Last Look logs to perform TCA and hold providers accountable.

Backtesting and TCA: why Last Look complicates evaluation

Last Look breaks the simple assumption that a historical quote you saw would have been tradeable. When you backtest or evaluate an execution algorithm, you must account for the possibility of rejections. Accepted trades on Last Look venues are often biased toward outcomes that are worse for the liquidity taker because LPs are able to reject the most favourable stale fills. That means naive backtests that assume all displayed quotes are firm understate real trading costs.

Good practice is to include a rejection model in backtests (for example, a rejection probability that depends on order size and market volatility) and to run post‑trade analysis that inspects the difference in realised price moves for accepted versus rejected requests.

Risks and caveats

Last Look is a trade‑offs problem. It can allow LPs to offer tighter quoted spreads and deeper displayed liquidity because they have a final short check to limit loss from stale quotes and technical errors. At the same time it introduces execution uncertainty and can create an asymmetric information environment that, if misused, disadvantages liquidity takers.

There are legitimate concerns beyond simple rejections. If an LP pre‑hedges, or uses rejected requests to inform subsequent proprietary trading, that would be contrary to best practice and many industry codes. Conversely, not having Last Look does not guarantee better outcomes: LPs without it typically widen spreads or reduce available quantities to protect themselves, and that can increase cost for large or urgent trades.

Finally, measuring Last Look effects is difficult. Rejection rates depend on client behaviour, number of LPs in the panel, market volatility, order size, and routing logic. Two traders on the same platform but pushing different order types can see very different rejection patterns.

Trading carries risk, and none of the material here is personalised trading advice. If you suspect Last Look is affecting your execution quality, raise it with your execution provider and consider careful, data‑driven TCA before changing strategy.

Key takeaways

  • Last Look is an evaluation window LPs use to accept, reject, or improve a client’s trade request; longer windows and tighter thresholds raise rejection probability.
  • Many FX venues and LPs use Last Look; some pools are No‑Last‑Look — ask your broker for disclosures and trade‑level logs.
  • Rejections can raise effective costs even when quoted spreads are tight; measure rejection rates, timestamps, and post‑trade slippage as part of TCA.
  • Practical mitigations include changing order size/timing, routing to firm pools or multiple LPs, and negotiating execution settings with your provider.

References

Previous Article

How many Tier‑1 liquidity providers are aggregated into a pricing engine?

Next Article

How matching engines handle asymmetric slippage — what traders should know

Write a Comment

Leave a Comment

Your email address will not be published. Required fields are marked *