Why Most Backtests Lie

Everyone loves a beautiful equity curve.
Smooth returns.
Tiny drawdowns.
An impressive Sharpe ratio.

Then the strategy goes live.

Within a week, the returns disappear.

The usual conclusion is:

“The market changed.”

In my experience, that’s rarely the real reason.

More often, the backtest was lying from the beginning.

Over the last four years, I’ve built an algorithmic trading platform from scratch—from market data ingestion to an event-driven backtesting engine, a live paper trading framework, and finally a production order execution system. One lesson became impossible to ignore:

Most backtests don’t fail because the strategy is wrong. They fail because the simulator isn’t realistic enough.

The Backtest Is Only as Honest as Its Assumptions

A backtesting engine answers one simple question:

“What would have happened if these rules had been followed in the past?”

The problem is that the answer is only as good as the assumptions built into the simulator.

If those assumptions don’t match reality, every performance metric becomes questionable.

The strategy may not be profitable.

It may simply be benefiting from unrealistic execution.

Lie #1: Assuming Every Order Fills at the Candle Price

This is probably the most common mistake.

A strategy buys at ₹100 because the candle touched ₹100.

But that’s not how markets work.

Did enough liquidity exist?

Was your order first in the queue?

Did the market move before your order reached the exchange?

Did your broker introduce additional latency?

A real exchange doesn’t know what your backtest wants.

It simply matches available buyers and sellers.

Ignoring execution quality often makes a mediocre strategy look exceptional.

Lie #2: Ignoring Slippage

Many developers either ignore slippage completely or subtract a fixed value from every trade.

Reality is far more complicated.

Slippage depends on:

• Market volatility
• Spread
• Order size
• Liquidity
• Time of day
• Market events
• Exchange microstructure

During calm markets, slippage may be negligible.

During fast markets, it can completely erase the edge your strategy appeared to have.

A realistic backtest should model different slippage behaviours rather than treating every trade identically.

Lie #3: Assuming Zero Latency

A backtest often assumes this sequence:

Signal generated → Order placed → Order executed

Instantly.

Production systems don’t work like that.

There are delays at every step:

• Market data arrives.
• Indicators are calculated.
• Strategy decides.
• Order is created.
• Broker API receives it.
• Exchange acknowledges it.
• Matching engine executes it.

Even delays measured in milliseconds can change execution for short-term strategies.

Ignoring latency creates performance that never existed.

Lie #4: Using Perfect Historical Data

Historical datasets are usually much cleaner than live feeds.

Missing ticks are removed.

Duplicate events disappear.

Corporate actions are already adjusted.

Bad packets never existed.

Live markets are messy.

Production systems spend enormous effort handling bad data because bad data is normal.

If your strategy only works on perfectly cleaned datasets, it may not survive a live market.

Lie #5: Looking Ahead Without Realising It

Look-ahead bias is surprisingly easy to introduce.

Examples include:

• Using the day’s closing price before the market closes.
• Calculating indicators with information not yet available.
• Using revised data that traders couldn’t have seen at the time.

The strategy appears predictive.

In reality, it has accidentally travelled into the future.

Lie #6: Ignoring Transaction Costs

Brokerage is only one cost.

Real trading also includes:

• Exchange transaction charges
• STT
• GST
• Stamp duty
• SEBI charges
• Bid-ask spread
• Slippage

Small costs accumulate.

Strategies that trade frequently often lose their entire edge after realistic costs are included.

Ignoring them is one of the fastest ways to overestimate profitability.

Lie #7: Treating Backtests as Proof Instead of Hypotheses

This is the biggest mistake.

A backtest is not evidence that a strategy works.

It’s evidence that the strategy might work.

That’s an important distinction.

The real validation starts after the historical simulation.

Why I Built a Virtual Trading Layer

This is exactly why my platform doesn’t stop at backtesting.

Between historical simulation and live capital sits an entire virtual trading framework.

The strategy receives real-time market data.

Orders flow through the same execution pipeline used for production.

The system experiences live spreads, latency, broker behaviour, and market conditions—but without risking capital.

This stage regularly exposes problems that historical testing never revealed.

Sometimes the strategy is still profitable.

Sometimes the edge disappears completely.

Finding that out before going live is far cheaper than discovering it with real money.

Engineering Matters More Than Most People Think

People often spend months searching for a better indicator.

In many cases, the larger improvement comes from building a more honest simulator.

A realistic execution engine won’t make your strategy more profitable.

It will make your expectations more accurate.

And accurate expectations are what separate research from production.

Final Thoughts

Backtests are essential.

I use them every day.

But I don’t trust them blindly.

They’re the first checkpoint—not the final verdict.

The goal isn’t to produce the prettiest equity curve.

The goal is to build a system whose behaviour in simulation is as close as possible to its behaviour in production.

Because when live results differ dramatically from historical results, the problem is often not the market.

It’s the assumptions hidden inside the backtest.