How does Last Look in Forex work in forex?

What Last Look is, in plain terms

Last Look in forex is a process used by some execution providers where the provider may pause briefly after receiving an execution request, then decide whether to accept (fill) or reject that request.

A helpful way to think about it is an “accept-or-decline” gate placed after the client request reaches the provider but before the final trade is confirmed. The client’s intended transaction is not automatically guaranteed at the moment the request is sent; the provider’s decision can depend on checks performed during the short window.

Because implementations differ across providers and jurisdictions, any explanation of how it works should separate stable mechanics (what the gate does) from variable conditions (what checks are used, how long the window is, and how rejections are handled).

A simple, check-based model of the workflow

Below is a generic sequence that illustrates the mechanism without assuming any specific outcome.

Request arrives A market participant sends an execution request (for a buy or sell of a currency pair at a stated price and size, depending on the system design).
Provider performs Last Look checks During the Last Look window, the provider evaluates one or more conditions. Examples of check categories commonly described in industry discussions include:

Timing checks (whether the request is received within an expected time tolerance)
Price consistency checks (whether the price implied by the request is still acceptable)
Liquidity or slippage-related checks (whether the provider’s ability to execute is still within internal tolerances)
Risk or policy checks (whether the request breaches limits or constraints)

Provider outputs a decision The provider then returns an outcome such as:

Acceptance (the execution proceeds and a fill is confirmed), or
Rejection (the requested fill is declined), sometimes with additional details communicated through the execution protocol.

Client observes the result The trader-side system receives the confirmation or rejection and updates its position, reporting, and order state accordingly.

This model highlights the “inputs → checks → outputs” structure. The key point is that the final realized result is determined after the checks, not only at the moment of request.

Inputs and outputs you should map in your own systems

To explain Last Look accurately, it helps to define the terms you will use when analyzing an execution event.

Inputs (what the decision can be based on)

Typical input elements you can look for in execution logs and protocol messages include:

Requested parameters: side (buy/sell), currency pair, size, and the price context associated with the request.
Time-related data: timestamps for when the request was received and when the decision was sent.
Market-reference information: depending on the provider, the checks may use internal reference prices, recent quotes, or other measures.
Operational constraints: whether the provider currently permits accepting requests under certain conditions.

Because providers use different rules, you cannot assume a specific list of checks from the concept alone.

Outputs (what changes from your point of view)

On the client side, the output usually matters as:

Accepted vs rejected execution: this directly affects whether your position is entered.
Execution confirmation details: the confirmed price, size, and any reporting fields.
Latency/response time: delays can differ between acceptance and rejection paths.

A practical way to verify your understanding is to compare your request records with the provider’s confirmations/rejections and measure how the timing and conditions correlate.

An example scenario (with explicit assumptions)

Consider a simplified example of a single execution request.

Assumptions (for illustration only):

A Last Look window exists.
The provider runs price-consistency and timing checks.
The provider’s policy may reject requests if the request is outside tolerance.

Scenario:

You send an execution request to buy a given currency pair at an expected price.
The provider receives the request and starts the Last Look window.
During the window, the provider’s checks determine whether the request still meets its criteria.

Two possible outcomes:

If the checks pass, the provider accepts and confirms the fill.
If the checks fail, the provider rejects the fill, and you do not enter the position as requested.

This example is intentionally neutral: it does not claim the request will be accepted. It shows how the gate can change the realized execution relative to the initial request.

Material limitations and failure modes

Last Look can introduce uncertainty even when an execution request is well-formed, because acceptance depends on checks that may not be fully observable.

Common limitations to consider:

Outcome uncertainty Acceptance is not purely determined by the client’s instruction. The provider’s checks can lead to rejections.
Different provider policies Providers can vary in what they check, how they apply tolerances, and how quickly they decide. Two different providers may respond differently to the same request.
Timing and market volatility Rapid market movement can increase the chance that a request falls outside internal tolerances by the time checks complete.
Partial observability in practice Even if you can log request and decision timestamps, you may not know the exact internal reference data used by the provider.
Operational edge cases There can be failure modes such as inconsistent handling of retries, differences in protocol messaging, or cases where the decision arrives after client-side assumptions about order state.

In short, the main risk is not only the possibility of rejection; it is also the difficulty of predicting which executions will be accepted and why, especially without full visibility into provider-specific policies.

How to verify what Last Look means for a specific setup

To independently verify the relevant facts for your environment, you can focus on evidence you can collect rather than expectations.

Compare requests to confirmations Use execution logs to count how often requests are accepted versus rejected.
Measure timing Record the time from request receipt to decision return and check whether latency differs between accepted and rejected outcomes.
Test under controlled conditions (conceptually) Instead of relying on predictions, evaluate how your system behaves when the provider’s acceptance criteria changes—for example, by observing outcomes during different market regimes.
Confirm policy language from the provider’s documentation Last Look mechanics are often described in legal and execution documentation. Read the specific definitions and the conditions under which acceptance can be refused.

If you want, share what logs or documentation fields you have (without any confidential values).