Author: Tradetron Team | Reviewed by: Tradetron Team | Published: 30 August 2026 | Last updated: 30 August 2026
Quick answer
A backtest and a live strategy diverge for nine identifiable reasons, and slippage is only one of them. The largest are fill price, costs you did not model, the intra-minute price path a backtest cannot see, and behaviour no simulation can reproduce, such as order rejections and partial fills. Most of the gap is measurable, but only once you know which of the nine you are looking at.
Every trader who has run a strategy live has had this moment. The backtest showed a clean equity curve. Six weeks in, the live account is somewhere else, and the strategy has not changed a line.
The usual explanation is "slippage", which is true and almost useless. Slippage is one contributor among many, and on plenty of strategies it is not the biggest. What follows is the full list, in rough order of how much damage each one does, and what to do about each.
One note on scope before we start. Every backtest on Tradetron now runs on the FastBT engine, which replaced the previous engine. If you are working from older guidance about what a Tradetron backtest does or does not account for, some of it no longer applies. This article describes current behaviour.
1. Fill price is the biggest single source of divergence
Start here, because there is a widespread misconception sitting on top of it.
A backtest fills your trade at a price derived from historical bar data. Live, you get what the order book gives you at the instant your order arrives. On a liquid Nifty option near the money those two numbers may be close. On a thin strike they may not be.
The misconception: many traders believe they can run a backtest assuming best price, worst price or the bid-ask average. Those three settings exist on Tradetron, but they are live order-execution settings that govern how a deployed strategy places its orders. They are not backtest configuration options. If you have been mentally applying a worst-price assumption to a backtest report, the report never had one.
Model your pessimism through the cost profile instead, which is point three. The exact mechanics of how FastBT derives a fill price from historical data are documented in Tradetron's own help centre; this article focuses on what that means for your results rather than restating the engine's internals.
2. The intra-minute price path is invisible
This one catches traders who have already accounted for slippage.
Any engine that replays bars rather than ticks sees a handful of numbers per bar. It does not see the order in which price visited them. If your stop-loss and your target both sit inside the range of the same bar, the backtest has no way to know which one price touched first.
That is a property of bar data, not a defect. But it means a specific class of strategy is systematically flattered: anything with a tight stop and a tight target, anything scalping, and anything where entry and exit conditions can plausibly trigger within the same bar. The tighter your levels relative to the instrument's typical range over one bar, the less the report is worth.
If your stop and your target are both inside a typical one-bar range for that instrument, the backtest is not testing your strategy. It is testing a coin flip with your strategy's name on it.
3. Costs you did not switch on
Set the cost profile before you run anything. It covers brokerage, slippage, STT, exchange charges, SEBI charges, GST and stamp duty, and the report shows gross and net side by side. The grade is scored on the net number.
If you have been reading a gross figure and filing it as the result, the divergence is not a mystery. It is the cost stack.
Do the arithmetic once so it stops being abstract. A two-leg Nifty option entry, one lot, at one and a half rupees of slippage per leg, is 2 × 65 × Rs 1.50, or Rs 195 per entry. Twenty sessions later that is Rs 3,900, before brokerage or taxes. A four-leg structure doubles it: Rs 390 per entry, Rs 7,800 a month.
For a strategy targeting a few thousand rupees a month, that is not a rounding error. That is the strategy.
4. A run that returns nothing is telling you something
This is the reason most traders have never considered, and it is worth understanding properly.
A backtest can complete without filling a single trade. The job runs, the report generates, and the result is empty or close to it. Under the previous engine, runs like that could come back looking finished, and a trader could reasonably read a thin report as a thin result rather than as a failure.
FastBT refuses instead. If a run cannot produce an honest report, it says so and refunds the credit automatically. No silent failures.
The practical implication is worth stating plainly, because it looks like a downgrade and is not: if a strategy that used to return a report now returns fewer results, or refuses outright, that is the engine being more truthful rather than less capable. The old number was not a better result. It was a result that should not have been produced.
If you are comparing an old report against a new one for the same strategy, that difference is the first thing to check, before you conclude the strategy has decayed.
5. Some strategies cannot be backtested at all
If your strategy fires on signals pushed in from outside, a TradingView alert, a custom webhook, a third-party API, there is nothing to replay. The historical price data exists. Your signal history does not.
There is no partial version of this. An externally triggered strategy has no meaningful backtest. Any number you produce for one describes the conditions you wrote to approximate the signal, and it is only that: an approximation standing in for something that was never recorded.
Validate those in paper trading instead, which is the only environment that exercises the actual trigger path.
6. Liquidity, partial fills and freeze limits
A backtest assumes your order fills. Live, it may fill partially, fill late, or not fill.
This bites hardest on far out-of-the-money options, on the illiquid strikes a strategy sometimes selects when volatility moves, and on anything that scales into size. It also bites at the exchange freeze quantity, above which a single order is rejected and has to be split, changing both your average price and your timing.
Multi-leg structures compound it. If one leg of a four-leg position fails to fill, you are not running the strategy you tested. You are holding an unintended position, and unless your strategy handles that case explicitly, it will carry on as though nothing happened.
7. Broker-side reality
Between your strategy and the exchange sits a broker, with its own failure modes: order rejections, margin shortfalls, token or session expiry, rate limits, occasional latency.
A backtest has none of these. Every order is accepted instantly at a known price.
The consequence is that live results contain a tail of trades that did not happen, or happened late, and those missing trades are not randomly distributed. They cluster on volatile days, when margin is tightest and order flow heaviest, which are often exactly the days your strategy depends on.
8. Overfitting, look-ahead bias, and the tells that give them away
If you adjusted parameters until the backtest looked good, you have partly fitted the strategy to that stretch of history rather than to a repeatable pattern. Three tells are worth checking specifically.
Trade count. A result built on thirty trades is noise wearing a chart. Ask whether you would bet on a coin that had come up heads that many times.
Regime coverage. If your window is six months of a trending market, you have tested one regime.
Look-ahead bias. This is the most common way a self-built or custom-coded backtest quietly cheats: a rule references information that would not actually have been available at the moment it fired, most often a value from later in the same bar or session than the decision it's supposedly driving. A no-code, rule-based strategy builder like Tradetron's constrains this by construction — you are composing conditions from a fixed set of building blocks rather than writing arbitrary code that can reach forward — but it is not a guarantee against every form of it, and a related issue, a repainting indicator whose historical values change after the fact, can produce the same symptom: spectacular backtest results that do not survive contact with live data. If a backtest result looks unusually clean, check whether any condition in it could only have been evaluated with information from the future.
The excuse for testing narrow used to be cost and time. Both are gone. FastBT is one flat Rs 20 per backtest for any date range, one day or six-plus years, with walk-forward included free. A typical run is around four times faster than before and the slowest jobs up to forty times faster, so multi-year multi-leg runs finish in seconds to minutes rather than hours.
There is no longer a reason to test six months when you can test six years for the same twenty rupees. If you have been running short windows out of habit, that habit is now just a worse test.
9. Your backtest may describe a different instrument
Contract specifications change. NSE revised index derivative lot sizes from the January 2026 series, taking Nifty from 75 units to 65 and Bank Nifty from 35 to 30 — see Nifty Lot Size Is Now 65, Bank Nifty 30 for the full checklist of what that changes on a live strategy. Any backtest run before that reports rupee figures based on the old contract size. Percentage returns remain broadly informative. Absolute per-trade profit, loss and drawdown do not.
Coverage is no longer the constraint it once was. FastBT runs across NSE F&O, cash equity, BSE, MCX, crypto and US markets, and custom Python and basket or list strategies run natively. If you previously worked around a segment the old engine did not cover, that workaround may now be adding error rather than removing it.
How to close the gap
The goal is not a backtest that matches live exactly. That does not exist. The goal is a backtest whose error you understand and can size, and that comes down to two habits before you run anything and two after.
Before you run: set the cost profile rather than reading the gross figure, and use a slippage assumption that is pessimistic rather than typical. Then widen the test window until it includes a period that should have hurt the strategy. At a flat twenty rupees a run, skipping this to save cost no longer makes sense.
After you run: forward test in paper trading long enough to accumulate a meaningful number of trades, since this is the only step that exposes rejections, partial fills, latency and external signal behaviour. Then go live at the smallest size that is still real, and compare live fills against backtest fills trade by trade before you scale up.
How to actually reconcile a live strategy against its backtest
Almost nobody does this, and it converts a vague sense of disappointment into a number you can act on. Working through these four questions in order is also the most reliable way to tell an expected gap from a problem: the first two questions catch problems, the last two separate ordinary structural drift from something that needs fixing.
Pull the positions CSV from your backtest report and your live trade log for the same period.
Did the same trades trigger? Compare entry timestamps. If live took fewer trades, you have a signal or execution problem, not a cost problem — a genuine problem, not expected drift — and no amount of adjusting cost assumptions will fix it.
For the trades that did trigger, what was the fill difference? Take the per-trade difference between live fill and backtest fill and average it. That number is your real slippage, in rupees, for this strategy on this instrument. Put it into the cost profile and re-run. Most of the gap usually closes here, and closing here is a sign the original divergence was expected (reason 1 above), not a fault in the strategy.
What is left after that? Whatever remains once trade selection and fill price are accounted for is the interesting residue, and it is usually partial fills or something structural about how the strategy is deployed — expected, in other words, provided it's small and stable.
Does the residue grow with volatility? If the gap is worst on the days the market moved most, you are looking at liquidity and broker-side effects (reasons 6 and 7). Fix that in position sizing and order handling. Rewriting the strategy logic will not touch it. A residue that stays flat regardless of volatility, by contrast, is usually just the cost profile needing another pass — expected, not a fault.
For the mechanics of reading a report properly, our detailed backtesting guide covers the metrics themselves, and the backtesting product page covers what the engine can run.
What the data says about how traders actually behave
We publish twelve months of live platform data in our State of Retail Algo Trading in India 2026 report, drawn from 32,893 analysed deployments. It is worth reading alongside your own reconciliation, because the failure patterns in it are considerably more common than most traders assume theirs are.
Frequently asked questions
Why is my backtest profitable but live trading is not?
The most common causes are unmodelled costs, fill price differences, and behaviour no simulation reproduces, such as partial fills and order rejections. Reconcile trade by trade to identify which applies rather than assuming slippage.
Does Tradetron's backtest let me assume the worst price?
No. Best price, worst price and bid-ask average are live order-execution settings that apply to a deployed strategy. They are not backtest options. Model pessimism through the cost profile instead.
Can a backtest tell whether my stop or my target was hit first?
Not if both fall within the same bar. A bar-replay engine sees the bar's price range but not the order in which price moved through it, so strategies with tight stops and targets are systematically flattered.
Does the backtest include brokerage and taxes?
It can. Set a cost profile covering brokerage, slippage, STT, exchange charges, SEBI charges, GST and stamp duty, and the report shows gross and net results side by side, with the grade based on the net figure.
Why does my strategy return fewer backtest results than it used to?
FastBT refuses to produce a report it cannot generate honestly, and refunds the credit automatically rather than returning a completed-looking run with no fills. Fewer results in that situation means the engine is being more truthful, not less capable.
How much does a backtest cost on Tradetron?
FastBT is a flat Rs 20 per backtest for any date range, from one day to six-plus years of history, with walk-forward included at no extra cost.
Can I backtest a strategy that runs on TradingView alerts?
No. Externally triggered strategies fire on signals that were never recorded historically, so there is nothing to replay. Validate them in paper trading instead.
How much slippage should I assume?
Rather than guess, measure it. Run the strategy live at small size, compare each live fill against the backtest fill, and use the average difference as your assumption.
How many trades does a backtest need before I trust it?
There is no fixed threshold, but a result built on a few dozen trades is dominated by noise. Widen the window until the strategy has been tested across more than one type of market.
What is look-ahead bias, and can it happen on Tradetron?
Look-ahead bias is when a backtest rule uses information that would not actually have been available at the time it fired. A no-code strategy builder constrains this by limiting you to a fixed set of conditions rather than arbitrary code, but it is not a full guarantee — check any unusually clean result for a condition that could only be evaluated with future information.
Are backtest results from before January 2026 still valid?
Percentage-based results remain broadly informative, but rupee figures reflect the older index derivative lot sizes and should be re-run before being used to size capital.
Which markets can I backtest on Tradetron?
FastBT covers NSE F&O, cash equity, BSE, MCX, crypto and US markets, and runs custom Python and basket or list strategies natively.
Should I paper trade even after a good backtest?
Yes. Paper trading is the only step that exposes order rejections, partial fills, latency and external signal behaviour, none of which a backtest can simulate.