Direct answer
To assess stop slippage, you need data that links the original stop intent to what actually happened at execution time. Practically, that means (1) the planned stop price and order parameters, (2) the execution outcome including the fill price and timing, and (3) the surrounding execution context such as liquidity, spread/quote quality, and any costs that affect the effective exit. You also need data provenance and quality checks—so you can independently verify which numbers came from where and whether they are aligned in time and definition.
Mechanism or definition
Stop slippage is the difference between the stop price you intended to trigger an exit and the price at which the exit order is actually filled. “Slippage” can be measured as price difference (planned vs executed) and sometimes as a cost difference (after including transaction costs and the effective spread).
Separating stable mechanics from variable conditions helps: the mechanics are the mapping from intent to execution; the variability comes from market microstructure (how quickly prices move, whether liquidity is available) and from the execution process (how the provider routes orders, how quotes are represented, and whether fills are partial).
Inputs you should collect usually include:
- Order intent: instrument, side (buy/sell), stop type (e.g., standard stop vs other variations), planned stop level, and quantity.
- Execution record: actual fill price(s), fill timestamps, and whether the stop resulted in one fill or multiple partial fills.
- Price reference data: the quote or price stream used for comparison (bid/ask vs mid), with clear precision and rounding rules.
- Costs and effective price adjustments: commissions, fees, and any spread treatment that changes “effective” exit price.
Evidence or example (what to calculate with assumptions)
A simple, self-contained way to assess stop slippage is to compute a per-fill difference:
- Planned stop level = P_stop
- Executed fill price = P_exec
- Slippage (price) = P_exec − P_stop (sign depends on instrument side convention)
If you want a cost-like comparison, you need explicit assumptions:
- Use a defined “effective” fill price, such as executed price plus or minus stated transaction costs.
- If you include spread, state how you convert bid/ask into a single comparison reference (for example, whether you compare against the ask for a sell stop).
At least one material limitation: if fills are partial or occur over multiple ticks, collapsing everything into a single number can hide the true distribution of slippage. You may need a weighted average fill price using executed quantities, and you should state that choice.
Data-quality checks that function like “evidence controls”:
- Timeliness alignment: ensure the execution timestamp and the quote reference are from comparable time bases.
- Definition consistency: confirm you compare the planned stop against the same price basis (bid vs ask) that your execution data implies.
- Provenance: document where each value originates (order ticket, execution report, independent price feed) and keep raw fields intact.
- Completeness: check for missing executions, cancellations, or re-quotes that can change what “planned stop” actually meant.
Limitations and risks
Stop slippage is not fully predictable from historical data. Outcomes vary with market conditions (speed of price changes, available liquidity), costs (spreads, commissions, fees), and execution mechanics (latency, routing, partial fills). Even with good data, you can misinterpret results if:
- The market reference is stale or uses a different price basis than the one implied by execution.
- The dataset mixes order types or provider policies without labeling.
- You assume a single execution tick when the exit happens across several fills.
Another failure mode is jurisdiction- and provider-specific execution behavior: you may observe differences that are caused by how orders are handled rather than by “market slippage” alone. Therefore, any conclusion should be scoped to the observed context and to the data definitions used.
Verification or next question
You can independently verify stop slippage information by using a checklist:
- AFVINKPUNTEN (agreement points): planned stop level from the order record; executed fill(s) from execution reports; timestamps from the same time basis. - BEWIJS OF DOCUMENT: keep the raw order ticket fields and the raw execution statements so calculations can be reproduced. - RODE VLAGGEN (red flags): mismatched timezones/timestamps, undefined bid/ask vs mid, missing partial fills, or rounding that changes the comparison.