# Slippage

Also written slippage model, market impact.

*https://stockmarketstack.com/glossary/slippage · next to Backtesting Frameworks & Algo Trading Libraries*

**Definition:** The difference between the price a test assumed and the price a fill would actually have got. In live trading it is measured after the fact against a reference price. In a backtest nothing measures it, because no order was ever sent, so it is an assumption the framework applies on your behalf — and different models produce different answers from identical data.

## How it works

Start with the live measurement, because it is the only version of this quantity that is a fact
rather than a choice.

Execution quality in US equities is disclosed against the quote in force when the order arrived.
The SEC's order execution disclosure rule defines average effective spread as the share-weighted
average of, for buy orders, double the difference between the execution price and the midpoint of
the national best bid and national best offer at the time of order receipt, and the mirror image for
sells; realised spread is the same arithmetic against the midpoint at a specified interval *after*
execution. Those two numbers separate the cost paid on arrival from what the price did next — and
both of them require knowing the [NBBO](https://stockmarketstack.com/glossary/nbbo) at a timestamp, per order.

A backtest has none of that. No order arrived anywhere, so there is no quote at time of receipt, no
queue position, and no counterparty. What the engine has is a row of price data and a rule you gave
it for degrading the fill. That rule is the slippage model, and it comes in four shapes:

**Fixed.** A constant number of ticks, points or cents added to a buy and subtracted from a sell.
Simple, reproducible, and indifferent to the size of the order and the state of the market.

**Percentage.** A fraction of the fill price. Scales with the price level, still indifferent to
liquidity. [Composer](https://stockmarketstack.com/tools/composer) backtests with a default assumption of one basis point on
daily adjusted closing prices, which is the whole model.

**Spread-based.** Half the quoted spread charged on each side, which is the closest of the four to
the regulatory definition above — and it needs a spread. [bt](https://stockmarketstack.com/tools/bt) models this only if you hand
the backtest a bid/offer frame alongside the prices; without one, slippage is whatever cost model
you wrote.

**Volume-share or market-impact.** Cap the fill at some share of the bar's volume, and optionally
make the price concession a function of the size taken. [Backtrader](https://stockmarketstack.com/tools/backtrader) has volume
fillers that cap a fill at a proportion of the bar's volume, plus percentage or fixed slippage with
separate switches for whether opening prices and limit orders slip at all.

And a fifth shape worth naming because it looks like the others: nothing. [QSTrader](https://stockmarketstack.com/tools/qstrader)
accepts `slippage_model` and `market_impact_model` arguments on its simulated broker and then
overwrites both with `None`, each marked in a comment as still to be implemented. A parameter that
is accepted and discarded is worse than an absent one, because the code reads as though it was
configured.

## The data most tests run on cannot support any of the four

A daily or minute bar carries an open, a high, a low, a close and a volume. It does not carry the
quote, the spread, the depth, the sequence of trades inside it, or how much of that volume was
available at the moment your hypothetical order arrived. Every model above is therefore either
indifferent to those facts or inventing them.

The facts exist, at a price and a volume. The NYSE Daily TAQ product is specified as every quote and
every trade with exchange timestamps — which is what a spread-based or queue-aware fill assumption
would need, and what [tick data](https://stockmarketstack.com/glossary/tick-data) means when a vendor is using the expensive
sense of the phrase. Running a bar-level test and then reasoning about spread capture is reasoning
about a number that is not in the file. A vectorised simulator makes this concrete:
[VectorBT PRO](https://stockmarketstack.com/tools/vectorbt-pro) still fills at bar prices, so intrabar sequencing and queue
position are outside what the run can express, whatever slippage figure is passed in.

## Why it matters here

Slippage is the input in a backtest that most directly scales with turnover, which makes it the
input that most changes the ranking between two rules. Across
[backtesting frameworks](https://stockmarketstack.com/categories/backtesting-frameworks) the defaults differ, the units differ —
a percentage in one library, absolute ticks in another — and the setting usually lives in the API
reference rather than anywhere a reader will meet it. A figure copied from one framework into
another without checking the units is not a conservative assumption; it is a different assumption of
unknown size.

So the useful form of the question is not "what is the slippage" but "what did this run assume, in
what units, and could the data underneath it have supported anything better". A result is a function
of that assumption, and reporting the result without it is reporting half of the arithmetic.

## Where you will meet this

- [Backtrader](https://stockmarketstack.com/tools/backtrader.md)
- [QSTrader](https://stockmarketstack.com/tools/qstrader.md)
- [bt](https://stockmarketstack.com/tools/bt.md)
- [Composer](https://stockmarketstack.com/tools/composer.md)
- [VectorBT PRO](https://stockmarketstack.com/tools/vectorbt-pro.md)
- [AI Hedge Fund](https://stockmarketstack.com/tools/ai-hedge-fund.md)
- [Backtesting.py](https://stockmarketstack.com/tools/backtesting-py.md)
- [Build Alpha](https://stockmarketstack.com/tools/build-alpha.md)
- [ClickHouse](https://stockmarketstack.com/tools/clickhouse.md)
- [kdb+](https://stockmarketstack.com/tools/kdb.md)
- [OneTick](https://stockmarketstack.com/tools/onetick.md)
- [Zipline-reloaded](https://stockmarketstack.com/tools/zipline-reloaded.md)

## FAQ

### Is zero slippage ever the right setting?

It is a defensible setting only for a test whose purpose is to isolate something else, and only if the result is read as what it is. Read as a return, a zero-slippage run has silently assumed that every order was filled at a price that existed on a chart, which is the one part of a simulation nothing in the data supports.

### How do I know what my framework is assuming?

Look for the simulated broker or execution-handler section of the API reference rather than the README, and check three things: the default model and its default value, whether that value is a percentage or an absolute amount, and whether limit orders and opening prices are treated differently from market orders. Some libraries accept a slippage model and then never apply it.

## Sources

1. [Disclosure of Order Execution Information, Release No. 34-99679](https://www.sec.gov/files/rules/final/2024/34-99679.pdf) — US Securities and Exchange Commission, 2024-03-06
2. [Daily TAQ Client Specifications, version 4.3](https://www.nyse.com/publicdocs/nyse/data/Daily_TAQ_Client_Spec_v4.3.pdf) — New York Stock Exchange, 2026-03-03

*Last updated 2026-09-21. A reference page, corrected in place — not a dated post.*