Direct answer
Slippage assumptions are simplified beliefs about how much worse (or sometimes better) a trade’s executed price will be compared with an expected price. Common mistakes are treating that simplification as accurate, using an unrealistically stable slippage value, or forgetting that slippage interacts with spread, commissions, order types, and market conditions. Another frequent issue is failing to state the assumption clearly for each calculation, so the reader cannot independently verify whether the results relied on optimistic execution.
Mechanism and definition
A slippage assumption usually covers one or more of these gaps:
- Price difference at execution: the fill happens at a different price than the “reference” price used in calculations.
- Timing difference: the model assumes an immediate fill, while real execution can wait until an order matches.
- Liquidity impact: when markets move quickly or depth is thin, the cost to reach your desired fill can change.
A useful way to think about it is: if your model uses an expected entry and exit price, then the assumed slippage adjusts those prices (or adjusts costs) to represent execution friction. If you do not separate the “reference price” logic from the “slippage” logic, you can double-count costs or leave them out.
Evidence or example (neutral checks)
Below are common mistake patterns and a neutral way to check them without assuming any specific provider, platform, or current market data.
-
Understating slippage by using the wrong reference Mistake: Using historical mid-prices or idealized quotes as the reference price while assuming minimal slippage, even though real fills occur through bids/asks and order matching. Neutral check: Recalculate using a clearly defined reference price type (for example, quote-based expected execution) and confirm that slippage is applied consistently to entry and exit.
-
Using a single constant slippage number across all conditions Mistake: Applying the same slippage assumption during calm periods and during fast moves. Neutral check: Run multiple scenarios with different slippage levels and changing spreads/fees. If conclusions flip entirely, the original assumption was likely not robust.
-
Ignoring that commissions and spread changes can mimic slippage Mistake: Treating slippage as only “one extra price tick,” while commissions and spread widening during volatility are handled inconsistently. Neutral check: Separate components in your accounting (reference price gap vs. spread vs. fees). Then verify that “total execution cost” is not created twice.
-
Assuming historical slippage will repeat Mistake: Seeing a stable relationship in past data and concluding it will hold in the future. Neutral check: Validate that your slippage assumption is not inferred from the same data used for performance evaluation. Use a time split or independent sample conceptually, and expect the distribution to change.
Limitations and risks
At least one material failure mode is that slippage assumptions can become hidden optimism: if slippage is omitted, treated too small, or applied only in favorable directions, the calculated outcomes can look better than what execution would likely produce.
Other limitations:
- Slippage depends on market conditions (liquidity, volatility, order-book depth) and execution details (order type, timing, and how quickly an order can be re-priced).
- Historical relationships do not guarantee future behavior.
- Small assumption errors can compound over many trades, especially when the model assumes frequent entries/exits.
Verification or next question
To verify your slippage assumptions independently, do three neutral checks:
- State the assumption precisely: what reference price is used, and how slippage modifies entry and exit?
- Stress test the assumption: test a range of slippage values and conditions rather than a single number.
- Reconcile total costs: confirm spread, commissions, and slippage are accounted for once, with consistent units.
Next question to consider: “If my slippage assumption changes within a plausible range, which parts of my calculations change the most, and are those changes mainly driven by execution cost or by something else in the model?”