Definition first: what “Last Look” means in execution
Last Look in Forex generally refers to an execution workflow where, after an order is received and before final acceptance, the liquidity provider (or execution venue) may apply a decision process to accept or reject the order. To assess Last Look, treat it as a process and data pipeline, not a trading strategy.
The key idea is separation:
- Stable mechanics: what steps exist (receive quote/order, apply acceptance criteria, then confirm or cancel).
- Variable conditions: market volatility, latency, costs, and jurisdictional or contractual terms.
Because execution outcomes depend on variables you may not observe, assessment should focus on the observable data you can verify and the documented rules you can independently check.
What data is needed: inputs, provenance, timeliness
1) Execution workflow inputs (what data the system uses)
To evaluate whether Last Look is present and how it behaves, you need inputs that reflect the acceptance decision. Depending on what documentation you can access, this typically includes:
- Order/quote lifecycle timestamps (order received, quote/response sent, acceptance or rejection time).
- Identifiers that preserve provenance (order ID, quote ID, venue/provider identifiers).
- Execution outcome fields (accepted, rejected/cancelled, partial fill indicators).
- Price-related fields (the price level used for decision-making and the final confirmed price, if available).
If you only have final outcomes (fills vs. no fills), you usually cannot distinguish Last Look from other mechanisms such as general quote expiration, liquidity unavailability, or risk controls.
2) Provenance (where each data element came from)
Provenance checks ensure that “what you think happened” matches “what the provider reports happened.” Collect data that indicates:
- Source of the execution report (your trading platform, a FIX gateway, an order management system, or the provider’s statement).
- Matching keys across systems (consistent IDs for the same attempted order).
- Clock assumptions (which system clock generated which timestamp).
A common failure mode is mixing timestamps from different systems without compensating for clock skew or different time zones. That can make the timing of acceptance/rejection look inconsistent even when the workflow is stable.
3) Timeliness (whether timing data is relevant to the decision)
Because Last Look decisions can occur in short windows, timeliness data must be suitable for timing analysis. Include:
- High-resolution timestamps if available (e.g., milliseconds).
- Clear ordering of events: receipt time must precede acceptance/rejection confirmation.
- Documentation of timestamp semantics (when the time is recorded: at submission, at network receipt, or at generation of a report).
If timeliness information is coarse or undefined, you may only be able to conclude that outcomes exist, not what decision timing implies.
Evidence and example checks: what to look for in data
Use a control-style checklist to organize evidence:
- AFVINKPUNT (done/not done): For each attempted order, do you have an acceptance/rejection event plus the corresponding timestamps and IDs?
- BEWIJS OF DOCUMENT: Do you have a provider contract, legal/operational documentation, or platform documentation describing an acceptance step after receipt?
- RODE VLAGGEN (red flags): missing timestamps, inconsistent IDs, or re-labeled outcomes that prevent matching attempts to decisions.
- KLAARCRITERIUM (clear criterion): can you show a complete event sequence for a meaningful sample where the acceptance decision is attributable to the stated workflow?
A limited example approach (without assuming real-time market data):
- Take historical orders you placed, keep the raw execution reports and their identifiers.
- Verify that every attempted order has a decision outcome field and decision timing field.
- Confirm that the event sequence is internally consistent (no acceptance reported before receipt in your dataset).
If these checks fail, your dataset is insufficient for a reliable assessment of Last Look behavior.
Limitations and risks: what you cannot conclude from incomplete data
Even with good inputs, there are material limitations:
- Different market conditions can change behavior: acceptance criteria may vary with volatility or liquidity, so a relationship observed historically may not apply later. - Costs and execution quality affect outcomes: spreads, fees, and partial fills can alter what you observe, even when the workflow is unchanged. - Jurisdiction and contract terms may govern interpretation: two providers can label similar workflows differently, and legal definitions can matter. - Data gaps can hide the mechanism: if the provider does not expose the fields you need (e. g.