What counts as an “Execution Problem”?
An execution problem is any mismatch between how you expect an order to be handled and what actually happens after you submit it. In practical terms, it can show up as fills at different prices than expected, delayed fills, partial fills, or orders that are rejected or not filled.
To evaluate execution problems objectively, separate three layers:
- Your order intent (the exact parameters you submitted).
- The execution path (how the market and order handling processes translate that intent into fills).
- Your outcome record (what you receive: fills, timestamps, and costs).
This separation helps you avoid confusing normal market movement with provider or infrastructure issues.
How to inspect the mechanics (what to verify in your records)
Use a checklist that compares intended vs observed behavior:
- Order details and assumptions
- Confirm the order type (e.g., market vs limit) and all parameters you chose.
- State assumptions for any example you calculate (for instance, “expected price” means your last quoted price at submission time).
- Timestamps and sequencing
- Verify the order submission time and the times when you received acknowledgements and fills.
- Look for unusual delays between submission and fill events.
- Exact fill and pricing information
- Compare requested execution conditions (if any) with the actual fill prices.
- Note whether price differences appear consistently during the same event window.
- Quantity matching and partial fills
- Check whether the full requested size was filled.
- If partial fills occurred, verify whether they were at different prices and whether the remaining quantity was filled later or not at all.
- Costs and net effect
- Identify all relevant costs included in your outcome record (commissions, spread/transaction costs, and any other fees shown).
- Evaluate net results: a small price difference can be magnified once costs are included.
- Failure and rejection markers
- Record any explicit rejection/stop/“not executed” messages.
- Determine whether the problem was an order-level failure (no fill) or an execution-level mismatch (fill but not as expected).
Evidence and examples: proving what happened (without guessing)
A useful way to evaluate an event is to compute an “expected vs actual” comparison using only data you can verify from your own logs.
Example framework (assumptions must be explicit):
- Assume expected price = the last displayed quote at the moment you submitted the order.
- Compute price difference = actual fill price minus expected price (use the correct sign convention).
- If there are multiple fills (partial fills), compute differences per fill and also on a weighted basis using filled quantities.
Then classify the pattern:
- Price difference without delay often aligns with market movement between your reference price and the fill.
- Delay plus eventual fill can indicate the market was moving faster than the reference you used.
- Rejections or missing fills point to a failure mode at the order-handling stage.
This approach focuses on observation and record-based comparisons, not on attributing blame.
Limitations, risks, and the main failure modes to watch
Execution outcomes are affected by changing market conditions, liquidity, and the structure of order handling. Because of this, even well-documented “problems” may not have a single cause.
Material failure modes to look for include:
- Slippage: fills occur at prices different from your reference.
- Partial fills: you receive less than requested immediately, sometimes across multiple fill events.
- Order rejection or non-execution: the order does not enter execution as intended.
- Asynchronous events: acknowledgements, edits, cancellations, or fills arrive in an unexpected order.
Verification limitation: historical relationships (for example, “when X happened before, the price moved similarly”) do not prove future outcomes. Costs and market behavior can change.
Verification and next questions to ask
To verify your conclusion independently, ensure each claim is tied to something you can show in the record:
- Do you have the exact order parameters you submitted?
- Do you have timestamps that let you compare submission vs fill timing?
- Do you have complete fill and cost details for the full executed size?
- Do you have explicit rejection/error messages if execution failed?
If a discrepancy is real, the next question is usually not “Who caused it?” but “Which layer is inconsistent with my intent?”—your inputs, the timing, the fill/pricing details, or the presence of explicit failure messages.