Backtesting Limitations: Slippage and Liquidity Explained

A backtest is only as useful as its assumptions about when, where, and how much you can trade. Slippage, spreads, fees, limited liquidity, and unfilled orders can turn an attractive historical result into an impractical strategy. Adding one cost setting improves a test; it does not make the simulation fully realistic.
Start in LuxAlgo’s native charts and use Quant to help create explicit strategy rules. Review the code, fill assumptions, and costs before interpreting the report. Keep strategy research separate from live execution: neither a chart indicator nor an AI-written script proves that the simulated quantity could have traded at the displayed price.
Slippage in Backtesting
Slippage is the difference between a reference price and the actual fill. It can be favorable or unfavorable. Define the reference and timestamp: a decision-time ask, arrival midpoint, stop trigger, and session VWAP answer different execution questions.
For a hypothetical 100-share buy, a $50.00 reference and $50.03 fill produce $3 of unfavorable slippage before fees. Include entry and exit costs, use weighted-average prices for multiple fills, and apply the correct contract multiplier. Our slippage guide explains the calculations.
Fixed and Variable Models
| Model | What it approximates | What to verify |
|---|---|---|
| Fixed ticks or percentage | A consistent execution penalty | Units, affected orders, and entry/exit application |
| Session or volatility scenarios | Different cost conditions | Inputs available at the decision time and evidence for the assumptions |
| Size/volume-dependent impact | Costs changing with participation | Volume coverage, calibration, and missing-data behavior |
| Order-book replay | Execution against a recorded sequence of events | Venue rules, latency, queue assumptions, and incomplete history |
A more complex model is not automatically more accurate. QuantConnect’s documentation, for example, describes constant and volume-share models, including data-dependent behavior when volume is missing. That illustrates why you must inspect a model’s implementation and inputs rather than relying on its name.
There is no universal “normal” rate for large-cap stocks, small-caps, major currencies, or crypto. Spreads, size, venue, news, and execution urgency change the outcome. Use your own fill evidence where available and test adverse scenarios instead of treating an unsourced market-wide percentage table as a forecast.
Size, Latency, and Gaps
Large orders can consume several price levels. Delays allow the market to change before execution. News and reopenings can create gaps through stop prices. These effects interact, so a fixed number of milliseconds does not translate into a universal pip cost.
A stop-market may execute beyond its trigger; a stop-limit may remain unfilled. A limit order can miss a trade even when a print occurs at its price. A simulation that always fills the full quantity at the trigger or touched limit can overstate performance.
Liquidity Issues in Backtesting
Volume, Spread, and Depth Measure Different Things
| Input | What it tells you | What it cannot establish alone |
|---|---|---|
| Traded volume | Activity already executed during a period | Quantity available for your next order |
| Bid–ask spread | Distance between quoted best prices | Depth beyond those prices or future availability |
| Order-book depth | Displayed interest by price at a point in time | Hidden interest, your exact queue outcome, or future cancellations |
| Trade timestamps | Observed execution sequence | A complete history of all submitted and canceled orders |
Fill models determine both price and quantity. Check whether your engine simulates partial fills, pending orders, rejections, and cancellations, or assumes a simplified immediate fill. Price data at tick resolution is not automatically historical order-book data.
Match the Data to the Market
For equities, check venue coverage, corporate-action adjustments, and whether the universe includes delisted securities. For futures, check contract multipliers, rolls, and whether a continuous series represents prices you could actually trade. For forex, distinguish broker tick activity from traded volume. For crypto, specify the exchange or liquidity pool rather than treating all activity as one market.
Likewise, activity during a London–New York overlap is not a universal liquidity rule for every currency pair or asset. Measure the relevant instrument and session, including announcement and holiday effects.
Use Capacity Constraints Without Looking Ahead
A cap of 5% of average daily volume is a possible research assumption, not a universal safe size. More importantly, daily activity says little about how much you can execute within one minute.
Suppose a stock’s prior 20-day average volume is 1,000,000 shares. A 5% cap permits 50,000 shares for the day, yet the minute in which your strategy submits an order might normally trade only 5,000 shares. The daily cap alone has not made a 50,000-share immediate fill plausible.
Use past observations for decision-time filters and separately model the execution window. Do not use the completed day’s volume to decide how much to trade earlier that same day. If the strategy excludes a thin session, define that rule before testing and retain stressed periods that the live strategy could encounter.
Measure the Effect on Net Results
Separate Data Adjustments from Execution Costs
“Adjusted close” generally refers to historical price adjustments for corporate actions, not adding 0.1% slippage. TradingView’s dividend-adjustment guide explains its total-return chart treatment. Keep price normalization consistent with share counts and returns, then model trading costs separately.
VWAP is a benchmark or modeled execution target, not a guarantee that your order could fill at that average. Minute bars remain aggregated data; calling them “high-frequency” does not reconstruct their underlying order sequence.
Run a Cost Sensitivity Comparison
Keep the signal rules and sample fixed while changing cost assumptions. For 100 hypothetical completed trades with $2,000 total gross profit and $200 total commissions:
| Round-trip slippage per trade | Total slippage | Net result after commissions |
|---|---|---|
| $0 | $0 | $1,800 |
| $5 | $500 | $1,300 |
| $15 | $1,500 | $300 |
| $20 | $2,000 | −$200 |
This arithmetic holds the trades fixed to isolate costs. A fuller fill model can change which trades occur, their timing, position size, and subsequent signals. Re-run the strategy when those mechanics change instead of only subtracting a fee from the final equity curve.
Compare drawdown, trade count, missed entries, holding time, turnover, and sensitivity to size alongside net profit. Include both routine costs and plausible adverse cases; neither an optimistic zero-cost run nor an arbitrarily punitive scenario is a calibrated forecast.
Reduce Backtest Errors with a Clear LuxAlgo Workflow
Inspect the Market Context in Native Charts
Review standard price bars and the correct session in LuxAlgo. Indicators such as RSI, MACD, Bollinger Bands, Donchian channels, Ichimoku, and VWAP can describe momentum, trend, or price dispersion. They do not directly measure execution cost or prove available liquidity.

Check the specific profile’s data source and mode. Footprints and trade-based tools can add context on supported markets, but displaying them does not mean every underlying value is accessible to a script or incorporated into the backtest’s fill model. Missing data is not zero liquidity.
Make Quant’s Rules and Assumptions Reviewable
Ask Quant to help write or revise the strategy with explicit entries, exits, sizing, sessions, and costs. Review the generated code, then run it and inspect the trade log and performance report. Use editable inputs for strategy parameters and the available strategy properties for costs and sizing.
Example research prompt: “Create the strategy with explicit entries, exits, and sizing. Use only information available at each decision time. Explain commission and slippage units, limit-fill assumptions, and how missing volume is handled. Help compare baseline and adverse cost scenarios, and identify liquidity effects this dataset cannot simulate.”
Do not assume a prompt automatically adds order-book replay, custom variable-impact curves, or portfolio execution simulation. Confirm what the generated script and runtime actually support. If a required mechanism is unavailable, describe that limitation and evaluate it separately rather than relabeling a simpler test as fully realistic.
Validate Any TradingView Export Separately
TradingView’s Pine Script® strategy documentation describes fixed-tick slippage and a limit-fill verification setting. These are approximations: stricter price verification can alter fill timing, and excessive fixed slippage can create fills outside a candle’s range.
When exporting a script, check compatibility, data, timeframe, order behavior, commissions, and slippage in the destination. Do not assume there is a universal separate spread control or that every script and feature behaves identically across environments. Lower-timeframe detail can improve sequencing without proving a real queue position or available quantity.
Validate Beyond the Original Sample
Use out-of-sample testing and preserve an untouched evaluation period. Track how many parameter combinations you tried: selecting the best historical result can overfit both the trading rules and the cost assumptions.
Then compare forward observations with the simulation. The LuxAlgo Journal can hold supported trade records and notes, but decision-time quotes and order timestamps may need separate recording. Paper fills also have assumptions; they do not prove the strategy’s live capacity.
FAQs
What is the problem with backtesting?
A backtest can overstate performance when its data, trade rules, fill assumptions, or costs differ from live conditions. Slippage, spreads, limited depth, partial fills, missed orders, lookahead, survivorship bias, and overfitting can all affect results. Use appropriate data, explicit cost scenarios, out-of-sample evaluation, and forward observations, while documenting the effects your simulator cannot model.
Backtest Realism Checklist
- Verify symbol, venue, session, data adjustments, and historical coverage.
- Document signal timing, order types, fill rules, and missing-data behavior.
- Model costs in the correct units and test capacity at the execution horizon.
- Compare baseline and stressed results without selecting assumptions merely to improve performance.
- Validate outside the development sample and reconcile observed fills with the model.
The goal is a transparent test whose limitations you understand. A strong result under plausible assumptions is more informative than a precise-looking return built on fills the market could not provide.
Read next