Paper Trading vs. Backtesting: Which One Do You Need?
Before a trading strategy touches real capital, it should survive two distinct validation stages: backtesting and paper trading. They're often confused or treated as interchangeable. They're not — they test different failure modes, and a strategy that passes one can still fail the other.
What Is Backtesting?
Backtesting is running a strategy against historical price data to simulate how it would have performed in the past. You feed in OHLCV klines, run your entry/exit logic, and produce a performance report — return, drawdown, Sharpe ratio, win rate.
What backtesting tests:
- Whether the strategy had statistical edge over the historical period
- How the strategy behaves across different market regimes (trending, ranging, volatile)
- Whether the strategy is overfit to the specific data window
What backtesting does not test:
- Real-world execution (slippage, partial fills, order queue position)
- Whether your live code actually works
- How the strategy behaves on data it hasn't seen yet (unless you walk-forward test)
For a deeper dive on backtest methodology, see Backtesting 101.
What Is Paper Trading?
Paper trading (also called simulation trading or forward testing) runs your strategy in real time against live market data — but executes no real orders. You observe what the strategy would do and track its hypothetical performance.
What paper trading tests:
- Whether your live code executes correctly
- Real spreads, real order book depth, real market timing
- How the strategy behaves on genuinely unseen data
- Execution latency and fill mechanics
What paper trading does not test:
- Multi-year performance history (you have to wait real time)
- Behaviour across historical market regimes
The Key Differences
| Backtesting | Paper Trading | |
|---|---|---|
| Data | Historical OHLCV | Live market feed |
| Speed | Test years in seconds | Real-time only |
| Look-ahead bias | Possible if implemented poorly | Impossible — data arrives sequentially |
| Fill simulation | Approximated | Real order book, real spreads |
| Code validation | No — tests logic, not live code | Yes — runs your actual production code |
| Market regime coverage | High (years of history) | Low (weeks or months of live data) |
| When to use | Strategy development | Pre-deployment validation |
Why You Need Both
Backtesting Catches Strategy Problems
A strategy with no historical edge isn't worth deploying — period. Backtesting tells you this fast, before you spend weeks paper trading something that was never going to work.
It also exposes strategy design flaws: too-tight stop losses that get hunted, indicator settings that work in trending markets but blow up in ranging ones, position sizing that creates unacceptable drawdowns.
Run backtests early and often during development. They're cheap.
Paper Trading Catches Implementation Problems
A strategy that looks good in a backtest can still fail in production because:
- Your live execution code has a bug the backtest didn't exercise
- Your assumed fill prices don't match real order book depth
- Network latency to the exchange causes timing issues
- The strategy behaves differently on unseen recent data
Paper trading is your last line of defence before real capital is at risk. Run it for at minimum 2–4 weeks — long enough to see the strategy make several complete trade cycles.
Common Mistakes
Skipping paper trading after a good backtest. This is the most expensive shortcut. The backtest validated the logic; it didn't validate the code or the execution.
Paper trading without backtesting first. You'll spend weeks watching a strategy that had no edge to begin with. Backtest first to filter out dead ends.
Comparing paper trading P&L directly to backtest P&L. They'll differ because backtests use simplified fill models. What you're looking for is directional consistency — does the strategy make money in paper trading? Is the win rate in the same ballpark?
Too-short paper trading windows. A strategy that trades once a day needs 30+ trades to have any statistical significance. That's 30+ days minimum.
The Validation Workflow
A rigorous pre-deployment workflow:
- Backtest on in-sample data (e.g. 2022–2024) to confirm edge exists
- Walk-forward test on out-of-sample data (e.g. 2025) to check it generalises
- Paper trade for 4+ weeks on live data to validate live code and execution
- Deploy small — start at 10–20% of intended size
- Scale up only after live results track paper trading results closely
Paper Trading in Wisp
Wisp strategies are structurally identical regardless of whether you're paper trading or live. The same StartWithRunner pattern, the same domain APIs, the same Emit() call. The only difference is whether your exchange credentials route to a real account.
A paper trading setup in Wisp is a live strategy with a logging wrapper around signal emission — you observe exactly what the strategy would do without executing:
func (s *MyStrategy) run(ctx context.Context) {
ticker := time.NewTicker(1 * time.Minute)
defer ticker.Stop()
pair := s.wisp.Pair(s.wisp.Asset("ETH"), s.wisp.Asset("USDT"))
s.wisp.Spot().WatchPair(connector.Binance, pair)
for {
select {
case <-ctx.Done():
return
case <-ticker.C:
price, ok := s.wisp.Spot().Price(connector.Binance, pair)
if !ok {
continue
}
klines := s.wisp.Spot().Klines(connector.Binance, pair, "15m", 20)
rsi, err := s.wisp.Indicators().RSI(klines, 14)
if err != nil {
continue
}
if rsi.LessThan(numerical.NewFromInt(35)) {
signal := s.wisp.Spot().Signal(s.GetName()).
Buy(pair, connector.Binance, numerical.NewFromFloat(0.1)).
Build()
s.wisp.Emit(signal) // routes to real exchange when live; log-only in paper mode
}
s.EmitStatus(strategy.StrategyStatus{
Summary: "Monitoring ETH/USDT",
Metadata: map[string]interface{}{
"price": price.String(),
"rsi": rsi.String(),
},
})
}
}
}Wisp's built-in TUI shows live P&L, positions, and strategy status — so during paper trading you can observe the strategy's behaviour in real time from the monitoring dashboard without touching a browser.
Paper trading mode (with a simulated executor) is on the Wisp roadmap alongside backtesting for 2026. Full setup guide: usewisp.dev/docs