What to verify in a slippage question
A “slippage question” usually asks whether a fill was worse than expected, and by how much. Verification starts with separating three parts: (1) a stable definition (what “expected price” means), (2) variable conditions (market movement and execution rules), and (3) the evidence trail (order and trade records). If you mix these parts, you can reach misleading conclusions.
The core definition: expected vs. actual
Before you calculate anything, define the reference point for “expected price.” Common reference choices include the price at order submission, a quoted price shown at decision time, or an internal benchmark used by the execution system. Different reference points produce different slippage numbers even when the same fill occurred.
Then define the actual execution price as the price of the trade (or the volume-weighted average price if there are multiple fills). If a fill is partial, you should decide whether “slippage” is measured per fill or for the full intended size.
When you compute a numeric slippage amount, state your assumptions explicitly (for example: which “expected” reference you used, whether you used mid-price or last price, and whether you compared in price terms or converted to cost in account currency).
Evidence to collect and how to compare it
Verification is mostly document work. Gather:
- Order submission records (time and price fields as stored by the platform or order management system).
- Execution reports (fill prices, quantities, and timestamps).
- Any available quote/market snapshot that explains what the platform could see at the time of order acceptance.
To answer the question, you match timestamps and identifiers: the order ID links the expectation (what the user/system intended to trade) to the resulting execution events. If there are multiple fills, a volume-weighted method is often used so the final number reflects the full executed size.
How slippage “works” without assuming a predictable outcome
Slippage can occur when the market moves between the time the expected reference price is observed and the time the order is executed. It can also occur because execution is constrained by order rules (such as how the order is matched), liquidity available at the moment of execution, and additional costs that affect effective price (like spreads, fees, or other execution-related adjustments).
A key verification mindset is to treat slippage as conditional: it is not a fixed feature of a provider or a market. It is an observed difference produced by timing, available liquidity, and execution mechanics.
Limitations and failure modes to watch
At least one material limitation is that outcomes vary with market conditions and the execution environment. Historical patterns do not establish future results.
Common failure modes when verifying slippage questions include:
- Using inconsistent reference prices (for example, comparing an order-submission price with an execution-report price that used a different matching basis).
- Ignoring partial fills or averaging across fills incorrectly.
- Relying on data from only one side of the timeline (for example, using fills but not the quote or acceptance time).
- Comparing numbers that were not calculated under the same assumptions (price vs. cost, or different time windows).
These issues can make it look like slippage was “caused” by one factor, when it may simply be the result of measurement mismatch.
A clear verification checklist and the next question
A practical verification approach is to ask four questions in order: (1) What exactly was the “expected price” reference? (2) What is the exact definition of “actual execution price” for single or multiple fills? (3) Which records prove the timeline alignment (order submission and execution timestamps)? (4) Under what assumptions did you compute the slippage figure?
If you cannot answer any of these, your conclusion should remain uncertain. A follow-up question to resolve ambiguity is: “Which specific timestamp and price field did you treat as the reference for expectation, and does it match the platform’s stored event that led to execution?”