Define execution problems in a verifiable way
Execution problems are discrepancies between what you intended to do with an order and what actually happened during order handling. A “verifiable” definition focuses on observable facts, such as:
- Order intent: side (buy/sell), order type (market/limit), stated size, and submitted time.
- Reported outcomes: whether the order was accepted, partially filled, fully filled, cancelled, or rejected.
- Execution records: fill timestamps, fill prices, and any recorded errors.
This matters because later analysis should not mix stable mechanics (how orders are processed) with variable conditions (market liquidity, volatility, and the costs applied by each participant).
Build a source hierarchy for checking claims
When evaluating information about execution problems, separate the claim’s origin into layers. A practical hierarchy is:
-
Primary records you can observe
- Your order ticket details and confirmations.
- Order lifecycle history (accepted, pending, filled, cancelled, rejected).
- Trade or fill reports with timestamps and prices.
-
System-level documentation
- Exchange or trading venue rules (if applicable).
- Platform documentation that defines order states, time-in-force, and how fills are recorded.
-
Intermediary legal/operational documents
- Broker documentation describing how order execution is handled, including common failure modes.
-
Explanatory reports
- Analyses, blog posts, or summaries. Treat these as secondary because they may omit assumptions or select only favorable observations.
Use this hierarchy to decide what can be independently checked versus what is interpretive.
Use reproducible verification steps (without real-time data)
You can verify execution-problem information using a “paper trail” workflow.
-
Fix the scenario and assumptions
- State: order type, order size, and the time window you are analyzing.
- For any example with costs, list the assumed cost components explicitly (for instance: commissions and any other fees you can observe), and keep them constant across comparisons.
-
Compare intent to order status history
- Confirm the order was accepted before any claimed execution.
- Record the exact transitions (for example: submitted → pending → filled/partial → cancelled).
- If the claim says “execution delay,” verify the delay as time between submitted timestamp and first fill timestamp.
-
Compare stated and actual fill behavior
- If the claim mentions slippage, verify it from fill prices versus the intended reference (for example: intended execution price for a limit/market decision), using the same reference consistently.
- If the claim mentions incomplete fills, verify fill quantity totals versus intended order quantity.
-
Attribute failure modes carefully
- Delay: large time gaps between acceptance and first fill.
- Partial fill: multiple fill events with total quantity lower than intended at the time of the “problem.”
- Rejection or cancellation: explicit status and recorded reason codes if provided.
-
Repeat with multiple independent instances
- Verification improves when the same failure mode is observed across separate orders, not just one event.
Material limitations and risks when verifying
Even with careful checks, results can be uncertain:
- Variable market conditions: liquidity and volatility change what “good” execution looks like, so historical relationships do not guarantee future outcomes.
- Mixed causes: delays can come from both market activity and operational processing; a timeline may show symptoms but not the exact internal cause.
- Cost and quote ambiguity: different systems may record prices with different reference points, and fees may be represented differently in reports.
- One-off events: a single anomalous order may reflect a transient condition rather than a persistent “problem.”
A key failure mode in verification is confusing a real mismatch in your order record with a broader narrative that you cannot confirm from primary records.
What to ask next when verification is unclear
If you cannot reconcile a claim with your records, focus on clarifying questions that target verifiable items:
- Which exact timestamps and order statuses support the claim?
- What reference price was used to measure slippage, and where is it recorded?
- Is the claim about partial fills, delays, rejections, or price mismatches—and which one is actually present in the record?
Independently verifying execution problems is mainly about evidence quality, clear assumptions, and consistent comparisons under changing conditions.