Why does my live trading perform worse than my backtest strategy?
Short answer: Usually because simulated results rely on assumptions that are too optimistic or incomplete (fees, slippage, execution, margin), and because rules are often tuned to fit historical data without a strict hold-out period for testing. Markets also move through different regimes, so what worked in the sample may weaken later. The sections below explain each point, how out-of-sample checks reduce the gap, and how SPAIKE targets these failure modes directly.
Many traders see a gap: a strategy looks clear and strong in a backtest, but live results and day-to-day experience do not match. Markets do change, but the main reason is often different: the strategy was fitted to historical data so that it describes that period well, without a clean split between what is used to build and what is used to validate.
This article explains why such gaps are common and how a reserved time window and out-of-sample logic make the process stricter.
Why backtests and live trading diverge
A backtest reflects your assumptions: data quality, fees, slippage, margin, condition order, execution. If assumptions are too optimistic or incomplete, simulated performance will sit above what is realistically achievable.
Overfitting adds to this when you change many parameters, filters or windows until history looks good. The model may learn patterns in noise that do not repeat.
Markets also shift in character (volatility, liquidity, trends). A rule set that worked in one phase can be weaker in another without any bug in the code.
The missing step: data that must stay out of the build
Core method: you split the timeline. One part of history is used to develop and optimize the strategy. Another part stays untouched at first and is used only for later evaluation. That mimics not knowing the future while you design the rules.
One concrete workflow (example): you exclude the last five months from the period you optimize on. You build rules and parameters on the earlier window. Then you test the same fixed logic on the next five months: does it still hold there without those months being part of the optimization? If not, the fit was probably too specific to the first window.
The exact month count can vary; the rule matters: whatever is marked as reserved must not be folded back into parameter search. That is the idea of out-of-sample testing and a simple walk-forward structure.
What this split gives you
Stricter tests rarely produce the highest simulated curves. They lower the risk of overrating a strategy that only fits one slice of history. You get a clearer answer on whether the rules remain viable outside the optimization window.
How SPAIKE solves exactly these problems
The two main failure modes - over-optimistic assumptions and overfitting - cannot be wished away, but they can be contained methodically. That is what SPAIKE is built for: more realistic execution at tick level, plus a built-in separation of development and validation data.
Tick-level backtests instead of coarse candles
SPAIKE does not compute entries and exits on coarse OHLC candles or smoothed closing prices. It works on real NBBO quote ticks (National Best Bid/Offer) from historical options data. The trigger is fixed at the actual tick, and the engine uses the bid/ask spread that was really available instead of a convenient mid fill that never existed in the market. This removes a large share of the over-optimistic assumptions before they appear: what counts as executable in the test was executable in the tick stream.
Realistic slippage simulation (latency-touch model)
Instead of a flat fixed slippage per trade, SPAIKE models execution through a latency window. The exit timestamp and the theoretical mid exit stay fixed at the trigger tick; for slippage, the NBBO tick window from the trigger up to trigger + latency is loaded (default five seconds, configurable per leg or leg group). The fill is taken at the executable side of the spread on the last tick in the window: a sell leg closes by buying back at the ask, a buy leg closes by selling at the bid. Slippage is the adverse difference between the theoretical mid exit and the real fill - and it is never negative, so it does not flatter the result. The test reflects the delay between signal and actual execution conservatively instead of ignoring it.
Out-of-sample as part of the workflow
No fill model alone fixes overfitting; only a clean split of the timeline does. SPAIKE supports exactly this logic: you optimize on one window and validate the same fixed logic on a reserved period that does not flow back into parameter search. Realistic execution and out-of-sample validation together give you a more honest expectation for live trading.
Conclusion
When live and backtest diverge strongly, start by checking methodology: assumptions, overfitting, and whether an independent test phase is missing. Reserving part of the data strictly for later evaluation while also computing on tick level with realistic slippage - as SPAIKE does - tests the idea more severely than a single optimized curve on coarse prices.