Slippage: what it is, before you verify it
Slippage is the difference between the price you expect an order to execute at and the price it actually executes at. In plain terms: if your order is filled worse than expected, slippage is positive; if it is filled better than expected, slippage can be negative. Verification starts with a definition, because “expected price” can mean different things (for example, the quoted price at the moment you submit, the quote at order acceptance, or the first available price when the order becomes executable).
To verify information about slippage, first write down the exact fields you are using: order side (buy/sell), the reference price for “expected,” the actual fill price(s), and the time mapping between them. Without those, different parties can produce incompatible “slippage” numbers while still using the same word.
A source hierarchy you can apply to slippage claims
When you see a statement about slippage, you can verify it by preferring more concrete evidence over summaries:
- Primary execution records (most direct): order and trade logs that include expected/reference price, executed price(s), quantities, and timestamps.
- Platform or provider documentation (stable definitions): explanations of how fills are generated, how timestamps are recorded, what “quote” means, and how partial fills are handled.
- Methodology descriptions (interpretation layer): documents or explanations that define how slippage is calculated from the underlying records.
- Aggregated summaries (least direct): dashboards or averages. These are useful context, but they are harder to verify because the calculation details may be hidden.
This hierarchy matters because verification is easiest when you can start from raw logs and reproduce the reported slippage calculation.
Reproducible verification steps (no real-time data required)
Follow a repeatable checklist using your own records or any dataset that includes the necessary fields.
1) State assumptions explicitly
Pick and write down:
- Expected price definition: e.g., “the quote at order submission time,” or “the best executable price at acceptance.”
- Which price to use: for a buy order, use an ask-derived reference; for a sell order, use a bid-derived reference. If the dataset provides a single “expected” value, keep using it.
- Measurement unit: absolute price difference, or basis points / percent of expected price.
Assumptions are not optional; they are part of what you are verifying.
2) Calculate per fill, not just per order
If an order can be partially filled, calculate slippage for each fill and then decide how to aggregate (commonly weighted by executed quantity). A common failure mode is comparing one expected price to an aggregated average fill without confirming the averaging method.
3) Confirm timestamp alignment
Make sure “expected” and “actual” are compared using consistent timing:
- If expected price comes from one timestamp event and execution price from another, document the exact mapping rule.
- If the dataset has different timestamp sources (server time vs. client time), treat that as a verification limitation.
4) Check that the reported numbers can be reproduced
If a provider reports slippage statistics, attempt to reproduce them from the underlying records:
- Recalculate each slippage value using the stated formula.
- Then recompute the aggregate statistic (mean, median, distribution buckets) using the same method.
If reproduction is impossible, that is evidence of either missing fields, a different definition, or a hidden transformation.
Limitations and failure modes you should expect
Even with careful steps, slippage verification can fail for reasons that are inherent to execution data and market behavior:
- Market movement: the expected price is a snapshot; execution happens later, so price changes can create slippage even under identical operational conditions.
- Incomplete or mismatched records: some feeds may omit order acceptance events or may not contain the “reference” quote used for expectations.
- Partial fills and aggregation bias: averaging across multiple fills can hide worsening and improving segments.
- Timestamp mismatch: differences in how time is recorded can distort comparisons.
- Provider-specific definitions: two parties may both say they measured “slippage” but use different reference points.
Also, historical relationships (for example, “average slippage over the last month”) describe past execution patterns. They do not establish what will happen in future conditions.