Prerequisites
- You already have the source code or parameter records of a trading strategy verified via backtesting, with a "good-looking" profit curve.
- You have run this strategy for at least 1 week in live or demo trading, and observed a significant gap between real and backtested returns.
High backtest returns that fail in live trading usually do not stem from the strategy itself, but from the "perfect assumptions" set in backtesting that do not exist in real markets.
Backtesting simulates trading in an "ideal world", while live trading runs in the real world. The gap between the two is the core pain point of quantitative trading. Troubleshoot the following 5 biases in order from "data" to "execution", which is far more efficient than chasing the curve to find reasons.
Bias 1: Future Information Leakage in Dataset
[What to do]: Check if your backtest uses price or event information that was completely unavailable at the time of trading.
[How to do it]: Verify if your strategy uses the high, low or close price of the current K-line as a trigger condition.
Scenario A: The strategy uses the full K-line's high/low price to judge breakouts → In backtesting, the price is already fully formed, so signals appear to trigger perfectly. But in live trading, the high or low price is only known after the K-line closes, and traders cannot see it at the moment of decision.
Scenario B: The strategy uses forward-adjusted prices for backtesting → Forward-adjusted prices adjust historical data with future dividend and share split information, creating false gaps on ex-right dates that cause technical indicators to generate wrong signals. The correct practice is to use backward-adjusted prices or raw prices with event markers.
Completion standard: Check every price reference in your strategy one by one, to confirm each data point already existed at the moment the trading signal was triggered.
High risk note: Decision-Time Leakage is the most hidden data bias — it means you use information after the decision point to build signals, and the backtesting system will not alert you. Studies show that even if training and test sets are strictly divided by time, execution time bias (e.g. generating signals with daily close data but executing trades at daily open) will still significantly overestimate returns. Part of your backtest profit may come from information you should not have known at the time.
Bias 2: Unrealistically Perfect Transaction Prices
[What to do]: Check if your backtest assumes that every order will be filled as soon as the price touches your target level.
[How to do it]: Compare the transaction price of each trade in the backtest report with the open and close price of the corresponding K-line.
Scenario A: Transaction price equals K-line close, high or low price → Backtesting assumes you get filled at the optimal price. In live trading, limit orders may not be filled due to queue position, and market orders will cross the order book and generate slippage.
Scenario B: Large order size → Backtesting does not simulate Market Impact, and defaults to infinite order book depth. In live trading, large orders will push up the buy price or pull down the sell price.
Completion standard: Enable the "slippage" and "transaction fee" models in backtesting settings, set single-trade slippage to at least 0.05%-0.1% and rerun the backtest to see if the profit still holds.
Bias 3: Misaligned Time Granularity
[What to do]: Check if the data update frequency of backtesting matches that of live trading.
[How to do it]: Compare the time precision (second-level / millisecond-level) of data push in backtesting with the actual precision of data received in live trading.
Scenario A: The strategy relies on triggers at specific timestamps (e.g. "open position at exactly 09:30:15") → Timestamps hit perfectly in backtesting. In live trading, data arrival may have microsecond-level deviations, making the condition never triggered.
Scenario B: Backtesting uses daily or hourly K-lines, while live trading receives tick-level data → The "close" of each K-line in backtesting is definite. In live trading, the exact end time of a K-line and possible delays will affect indicator calculation and signal triggering.
Completion standard: Check all time-related conditions in your strategy, change "equal to" conditions to range checks, or use the platform's scheduled event function instead of real-time instant judgment.
Bias 4: Parameter Overfitting — "Parameter Peak" Instead of "Parameter Plateau"
[What to do]: Test if the strategy parameters are only effective at a narrow, isolated peak value.
[How to do it]: Select core strategy parameters (e.g. moving average period, stop loss distance), adjust them within a small range (±30%) one by one and rerun backtests, to observe changes in the profit curve.
Scenario A: Profit drops sharply when parameters shift slightly → This is a "parameter peak", indicating the strategy captures data noise rather than real market patterns, which is a typical sign of overfitting.
Scenario B: Profit remains stable across a wide parameter range (≥30% span) → This is a "parameter plateau", indicating the strategy logic is robust to market changes and more suitable for live trading.
Completion standard: Draw a parameter-profit heatmap to confirm your strategy has a "parameter plateau" instead of isolated parameter peaks.
Bias 5: Execution-side Discrepancy — Limit Order Price Touch ≠ Order Filled
[What to do]: Check if your strategy over-relies on limit orders being filled as soon as the price touches the target level.
[How to do it]: Review all limit order fill records of your strategy, to see if there are cases where orders are 100% filled immediately after the price touches the limit level.
Scenario A: 100% of limit orders get filled once the price touches the level → Backtesting assumes there is always a counterparty in the order book. In live trading, limit orders enter the order queue, and a price touch does not mean your order is at the front of the queue.
Scenario B: The strategy frequently uses limit orders to trade at the minimum spread → In live trading, there are very few counterparties for ultra-tight spread trades, leading to extremely low fill probability. The perfect entry and exit points that look great in backtesting may not get a single order filled in live markets.
Completion standard: Enable the "limit order slippage" model in backtesting, set the rule that the price needs to penetrate the limit level by at least 0.01% to count as a fill, to simulate real order queue scenarios.
Post-correction Verification Method
Rerun the full historical dataset with the corrected backtesting settings. If the new profit curve remains positive, but is 20%-30% lower than the original "flawless curve", it means you have found the real profit level of your strategy. If the corrected profit drops directly to zero or turns negative, the original strategy is not viable at all.
Next Step Action
Run the corrected strategy in live trading with small capital (no more than 5% of your total capital) for 2-4 weeks, record the gap between every actual transaction price and the backtest simulated price, to create a "slippage record table". This difference can be used as a fixed slippage parameter for subsequent backtests, to make backtesting results closer and closer to real live performance. Verification method: Compare the "average fill price" in the exchange's order history with the "simulated transaction price" in the backtest report one by one.
