From Backtest to Live Trading

A backtest answers one narrow question honestly: given this exact series of prices, would these exact rules have produced these exact decisions? That is worth having. It catches rules that contradict each other, entries with no matching exit, and logic that quietly looks at a price it could not have seen.

What it cannot answer is whether the prices you fed it were the prices you would actually have had, and whether an order at those prices would have been filled. Both of those are assumptions your simulator made on your behalf, usually silently. A backtest fills at the close because you told it to. The market has no obligation to agree.

So treat the report as a gate, not a verdict. It removes strategies. It never approves one.

The rollout is a ladder, and each rung answers something the one below it could not.

Paper trading — running the live code against the live feed, but sending orders to a simulator instead of the exchange — is genuinely useful, and it is useful for reasons that have nothing to do with whether the strategy makes money.

It proves the plumbing. That the system starts on its own before the pre-open, that it survives a full NSE session unattended, that it handles the 15:30 close without crashing, that a corporate action does not blow up the symbol map, that a reconnect after a dropped feed does not double a position. Those are real failures and they are cheaper to find here.

What it does not prove is anything about execution — and this is where most people lose money later.

There is exactly one way to find out what a real order does: send a real order. Forward testing means running the finished system live, with real capital, at the smallest size the market and your costs allow, for long enough to accumulate a meaningful number of fills.

Small size here does not mean small enough to ignore. It means small enough that being wrong about everything costs you a fixed, pre-agreed and genuinely tolerable amount — and large enough that every trade goes through the real path: real margin blocked, real charges deducted, real rejects, real partial fills, real square-off.

The question this stage answers is not 'does it make money'. Over a small number of trades that question has no answer worth reading. The question is: does the live system do what the backtest said it would do, trade by trade, for reasons I can name?

Before you read a single live fill, prove the two systems are even comparable. Divergence here is not an execution problem — it is a bookkeeping problem that will make every later comparison meaningless.

Run this list as a hard checklist, and fix anything that fails before the first live order.

This is the actual work of this stage, and it is the step almost everyone replaces with a glance at the P&L.

For every live trade, write down what the backtest would have assumed and what the broker actually reported, side by side, and then write one sentence explaining the difference. Not a category — a sentence. 'The order left 370ms after the bar closed and the book had moved one tick' is an explanation. 'Slippage' is not.

Take an illustrative intraday system that expects to round-trip a ₹100 instrument, 200 shares at a time, twice a day.

Suppose the backtest assumed the fill landed exactly at the signal price. Live, the average entry lands 35 paise worse and the average exit 25 paise worse. That is 60 paise per share of execution cost the backtest never charged you — ₹120 on a 200-share round trip, before any brokerage, statutory charge or GST.

Run that against the average move the strategy is trying to capture. If the strategy's typical intended move is a rupee, execution has taken more than half of the thing it was built to collect, and the backtest that looked fine was measuring a market that does not exist.

The first day the system sends real orders is not a trading day. It is an observation exercise, and you should have nothing else scheduled.

The point is not to see whether it makes money. It is to watch every assumption you have been carrying meet the market for the first time, in order, and to be present when one of them fails.

A rollout that leaves no record cannot be reviewed, and a rollout you cannot review is one you will repeat the mistakes of. Keep a deployment log alongside the reconciliation — one entry per meaningful event, written the same day.

Always. Proving the strategy and proving your capacity are two different questions, and running them together is how people convert a research problem into a capital problem.

At test size your order is invisible to the book. At ten times that size it is not — you are now part of the price you are trying to trade, and the same logic can produce a materially worse average fill for reasons that have nothing to do with whether the idea was sound. Scaling therefore needs its own evidence: re-measure the fill gap at each new size, and treat a worsening gap as a capacity limit you have found rather than a nuisance to push through.

Automated order placement through a broker's API in India sits inside a framework built by SEBI and administered through the exchanges and your broker — covering how retail algorithms are registered and identified, which strategies need approval, and what your broker is required to do before your orders reach NSE or BSE.

That framework has been revised repeatedly and continues to be. So the only responsible instruction is the shape of the obligation, not its detail: before you send a single automated order, confirm the current requirements with your broker and read the current circulars at sebi.gov.in and on your exchange's site. Do not take the specifics from any article, including this one, and do not take them from a vendor whose product depends on the answer being convenient.

Every honest process has to say what would halt it. Here is what halts this one.