Define “execution problems” and what you can verify
Execution problems are situations where the outcome of placing an order does not match the execution behavior a provider states it will apply, or where the actual order handling shows unexpected delays, rejections, partial fills, or price/distribution outcomes that are inconsistent with the claimed process. Verification means you can point to observable facts (timestamps, order status changes, fill details, and message logs) and compare them to the rules described in the provider’s public documents.
Separate stable mechanics from variable conditions
To verify execution issues accurately, separate what is structural from what varies:
- Stable mechanics: order lifecycle steps (submitted → accepted → routed/queued → executed/filled → completed or cancelled), and how “market” vs “limit” intent is interpreted.
- Variable conditions: liquidity depth, volatility, trading costs (fees/spreads/commission), and external market-wide events.
A material risk in verification is assuming that any mismatch is a “problem.” Even when an execution process is working as described, market movement can change fills between order submission and execution.
Build an evidence checklist you can reproduce
A self-contained verification process usually combines three document-and-data categories:
- Event evidence (what happened): collect broker/platform export data for the specific order—order ID, timestamps for each status change, request/confirmation messages if available, and the full list of fills (price, quantity, time). If the provider only exposes aggregated results, note that limitation.
- Policy evidence (what should happen): use the provider’s current documents describing execution and order handling (for example, order types, execution venues or routing description, dealing rules, and how quotes are formed). Use the document version that matches the timeframe you are investigating.
- Constraints evidence (why outcomes can differ): capture the assumptions behind the example you will analyze—trade size relative to available liquidity, approximate costs model you used, and what you treat as the reference price (e.g., quote at a specific timestamp). State these assumptions explicitly.
A practical “calculation example” can still be valid without live prices: for instance, if you observed a sequence of partial fills, you can verify whether the fill aggregation is consistent with the documented order handling for partial executions (even if the exact market price at each instant is unknown to you).
Identify limitations and failure modes
At least one material limitation is common in execution verification:
- Legitimate divergence: execution outcomes can differ from a reference price because markets move faster than confirmation, or because order types interact with liquidity.
- Incomplete observability: some platforms do not provide a full end-to-end message log, so you cannot prove exactly where a delay occurred.
- Reference-point ambiguity: “the price you saw” may not be the price used for matching, especially if quotes update or if conversion/cost components apply.
These limitations mean verification should aim to determine whether the observed facts contradict documented rules, not to infer intent or predict future performance.
Verification as a clear conclusion (and the next question)
A robust conclusion is one of the following forms:
- Mismatch conclusion: the observed event timeline or handling behavior contradicts the provider’s documented order/execution rules for that order type.
- Inconclusive conclusion: the observed data are insufficient to compare against the relevant documented rules, or variable conditions dominate the outcome.
Next question to ask: “Which exact document section governs the order type and the observed step (acceptance, routing, fill, cancellation), and do the timestamps and fill details align with that described step?”