How to backtest a trading strategy in India

The word "backtest" makes it sound like a measurement, something you perform on a strategy the way you weigh a parcel. That framing is the root defect. A backtest is an experiment, and an experiment is defined by its structure rather than its result. If you cannot say in advance what outcome would make you abandon the rule, you are not running an experiment. You are generating a picture and then deciding how to feel about it.

The distinction has teeth because of a specific asymmetry. A trading rule has many free parameters: the lookback, the threshold, the stop distance, the holding period, the universe, the date range. Historical data has a great deal of noise. Given enough freedom over the parameters and enough looks at the same history, you can always find a combination that produced a pleasing curve, and you can always find it whether or not the rule has any edge at all. That is not a risk of the method, it is a guarantee of it. The only thing standing between you and a beautiful, meaningless result is a structure you imposed before you started looking.

So the discipline is front-loaded. Almost everything that determines whether your answer means anything happens before the first bar is processed, and almost none of it involves software. The figure below puts the two processes side by side, because seen together the defect in the common one is obvious in a way it never is from inside.

Every backtest is a claim about what would have happened, and it inherits every flaw in the record it reads. In India the free and cheap datasets most retail testers use are weak in three places specifically, and each weakness biases results in the same direction: toward flattering them. Knowing which three lets you either fix them or, at minimum, state honestly how much of your result is an artefact.

The first is corporate action adjustment. Indian exchanges publish the traded price, and the traded price mechanically drops on the ex-date of a split, bonus or rights issue while shareholder wealth is unchanged. An unadjusted series therefore contains cliffs that no trader ever experienced. To a trend rule those cliffs look like crashes, to a stop they look like triggers, and to a volatility filter they look like regime changes. The fix is arithmetic and well defined, but you must confirm your source applies it rather than assuming it does. Many free sources do not, and the ones that do are often silent about which actions they cover.

The second is the point-in-time universe. If your test runs over the current constituents of an index, it runs over the set of companies that survived and got promoted, which is a set selected by the very outcome you are trying to predict. Every company that was delisted, demoted or absorbed has been quietly deleted from history. The correct object is the membership as it stood on each historical date, delistings included, and it is genuinely hard to obtain cheaply in India. This is the single most common reason an Indian small-cap or mid-cap backtest is overstated.

The third is volume and its consequences. Price data is abundant; honest liquidity data is not, and it is the liquidity that decides whether the fills your backtest assumed were available. A rule tested at ten times the size the counter could absorb is not a strategy, it is a fantasy with a chart attached. This one is under-discussed relative to the other two, so it gets its own section below.

Read the right-hand column as a whole and the pattern is uncomfortable: with one exception, every weakness pushes the result in the same direction. That is what makes data quality a first-order concern rather than housekeeping. Random errors would widen your uncertainty and leave the centre roughly right. These errors are systematic, they all point the same way, and no amount of additional history corrects them. A larger sample of a biased record is a more confident wrong answer.

A backtest fills every order instantly, completely, and at a price the market printed. Real books do none of those things. The gap between the two is not a rounding error to be sprinkled in at the end; on a rule that trades often or trades thin counters, it is frequently the entire result. And the constraint is not the average day. It is the thin day, which is when your rule will often want to act.

The measurement to run is participation: your intended order value as a fraction of the counter's traded value that session. It is a crude proxy for market impact but a useful one, and it has the great advantage that you can compute it from data you already have. Broadly, an order that is a small fraction of one percent of the day disappears into normal flow. An order approaching or exceeding one percent of the day is a meaningful part of what traded, which means your own order is part of the price the backtest assumed you got. Past that, the simulation is describing a market that includes you as a participant while pretending you were not there.

This produces a rule of thumb worth carrying: a strategy has a capacity, and capacity is part of the strategy. The same rule can be entirely real at five lakh and entirely fictional at one crore, and nothing in a standard backtest output will tell you which side of that line you are on, because the standard output does not know your size. You have to ask the question separately, and you have to ask it against the thin sessions rather than the median one.

There is a second consequence that catches people later. Because capacity binds, a strategy that works cannot simply be scaled up with the account. As the account grows, participation grows, impact grows, and the net edge shrinks. A rule validated at one size needs re-validating at the next, which is an unwelcome discovery to make after the capital has arrived rather than before.

Here is the part that most guides get subtly wrong. They present backtesting as a list of steps, which implies the steps are interchangeable chores. They are not. The steps have a required order, and the ordering carries almost all of the method's protective power. Do the same six things in the wrong sequence and you have done nothing at all, even though every individual step was performed correctly.

The order is: specify the rule, seal the held-out block, build the cost model, run in-sample, decide against the thresholds you declared, and only then open the seal. Every one of those precedes measurement of the thing it protects. Specification precedes testing so that hindsight cannot leak into the rule. Sealing precedes running so that the held-out block is genuinely unseen. The cost model precedes the result so that you are not tempted to choose the cost assumption that makes the answer come out well, which is a real and very human failure. Declaring thresholds precedes seeing the number so that the number cannot set the threshold.

The sealing step deserves particular attention because it is where the most common and most invisible error lives. A held-out set is not defined by its position on the calendar. It is defined by what you did not know when you chose it.

Two practical notes on sealing. First, seal by writing the split date into your configuration before you load anything, not by remembering to ignore the tail. Memory is not a control. Second, if you have already explored the full history informally, which is often true because the idea came from looking at charts, then be honest that you have no clean held-out block in that data at all. The remedy in that case is time: the genuinely unseen data is the data that has not happened yet, which is what forward testing is for, and it is one of several reasons the process does not end at the backtest.

The rolling generalisation of a single split, where you repeatedly fit on one window and test on the next unseen one across the whole timeline, is a stronger version of the same discipline and is covered as a defence in the companion piece. The ordering principle here is identical and prior to it: whatever scheme you use, each test block must be sealed before the model that will be tested on it is chosen.

Costs are the step where a backtest is most often quietly wrong, not because people forget them but because they estimate them with a single round number. India's statutory stack is knowable to several decimal places, and its structure has a feature that catches people: the largest line by far is Securities Transaction Tax on delivery, which is levied on both legs, while the intraday equivalent is levied on the sell alone. That single asymmetry makes the statutory cost of a delivery round trip roughly six times that of an intraday one.

The rates below are the framework as of 18 July 2026. Statutory rates change with each Finance Act and exchange charges change by circular, so verify at source before you rely on them for anything that matters.

Three structural points follow from that table, and each changes how you build the cost model rather than merely how large it is.

The statutory floor is asymmetric by holding period. At 0.2225% versus 0.0355%, a delivery round trip starts more than six times deeper in the hole than an intraday one. A rule that holds for days needs a materially larger gross edge to clear its costs than one that closes the same session, and that is a design constraint you should know before you build the rule, not after.

GST does not apply to the two biggest statutory lines. It applies at 18% to brokerage, exchange charges, the SEBI fee and depository charges, but not to STT or stamp duty. Modelling GST on the whole stack overstates costs, while modelling it on brokerage alone understates them. Both errors are common, and both are avoidable by keeping the lines separate in your cost function instead of collapsing them into one percentage.

Only one line is an assumption. Every statutory charge is a published number you can look up. Slippage is the sole line you have to estimate, and as the next section shows, it is also the line that usually decides the answer. That is an uncomfortable combination and it deserves to be treated as the central modelling problem rather than a footnote.

Now the arithmetic, and it is worth doing slowly because the shape of the answer is more instructive than its size. Take a plausible intraday rule with a gross edge of 0.25% per round trip on a liquid counter, running about 250 round trips a year. Subtract the verified stack line by line and see what survives.

Sit with the right-hand panel, because it is the most important thing on this page. The rule did not change. The history did not change. The statutory rates did not change. The only thing that moved was a single estimated input, across a range that any two careful people could disagree about, and the sign of the entire conclusion moved with it. This is what it means to say the cost assumption is the result rather than an adjustment to it.

Three consequences follow, and they are the practical content of this section.

First, state the slippage assumption as a number, in writing, before the run, in basis points per side, with a reason attached. "Five basis points because our typical order is under 0.2% of median traded value on this counter" is a defensible assumption. An unstated one is not an assumption at all, it is a preference that will drift toward whatever makes the result look good.

Second, report the break-even, not just the answer. The most honest single number this analysis produces is not the net edge, it is the slippage at which the net edge becomes zero, here 9.5 basis points per side. That figure tells a reader exactly how much room the strategy has, and it is robust in a way the headline is not. A rule whose break-even is 40 basis points is genuinely different from one whose break-even is 9.5, even if both report the same net today.

Third, if the honest range of cost assumptions spans zero, the correct conclusion is that you do not know. That is a real finding and it should be reported as one. It is not a failure of the test; it is the test working. The failure would be picking the assumption that lands on the answer you wanted and describing the result as validated. If you want to see how the statutory lines move with order size and segment before fixing your own figures, the cost estimator computes the published components from your inputs.

The equity curve is the output everyone looks at and the output that carries the least decision-relevant information per square inch. It is a single path. It shows one ordering of one set of trades, and reordering the same trades produces a visually different curve with identical underlying statistics. What you actually need is the per-trade distribution and the sample size behind it.

Start with expectancy per trade, the average outcome of one application of the rule, net of costs. It is the number that scales: multiply it by the number of trades you expect and you have the strategy's contribution, which is exactly what a curve does not let you do. Expectancy also survives translation between account sizes and between instruments, which the curve does not. Measuring it properly, in R-multiples so that trades of different sizes are comparable, is its own subject and is covered in measuring a trading edge. For the purposes of a backtest report, the requirement is simply that expectancy is present, that it is net of the full cost model, and that it is reported beside the count of trades it came from.

Then trade count, which governs how much any other number can be trusted. It is not glamorous and it is not optional. A superb expectancy over eighteen trades is an anecdote. The same expectancy over four hundred trades spanning several market conditions is evidence. Report the count adjacent to every metric, not in a footnote, because a reader who sees the metric without the count will over-trust it and so will you.

Then drawdown in both dimensions. Depth is how far equity fell from its peak. Duration is how long it stayed below that peak before making a new high, and duration is the one that ends strategies, because it is the dimension a human has to sit through. A twenty percent drawdown lasting five weeks and a twenty percent drawdown lasting two years are the same number and completely different experiences. Report both or you have reported neither.

Now the honest part, which belongs on the report card rather than in a disclaimer at the bottom. A good backtest cannot show that a strategy works. It can only fail to disqualify it. This is not modesty, it is the logical structure of the thing: the test asks whether the rule would have failed on data it had not seen, and a negative answer is a failure to reject, not a confirmation. Every strategy that eventually blew up passed its backtest first. Passing is the entry requirement, not the verdict.

What follows from that is a change in what you claim rather than a change in what you do. The defensible sentence after a clean run is: "this rule was not disqualified, on a point-in-time universe, under a stated cost model, on data it had never seen, over N trades." That sentence is a great deal weaker than "this strategy works," and it is the strongest one the evidence supports.

Suppose you ran the procedure properly. You specified, sealed, costed, ran in-sample, declared thresholds, opened the held-out block, and the rule failed. What now?

The honest answer is the unpopular one: that rule is done, at least on that data. The tempting answer, and near-universal practice, is to adjust something and run the held-out block again. This feels like diligence. It is the single most effective way to manufacture a false positive, and it is worth being precise about why, because "you overfitted" is usually asserted rather than explained.

The held-out block protects you for exactly one reason: the rule was chosen without reference to it. The moment you observe the held-out result and change the rule in response, the next test is no longer independent, because the block participated in selecting what gets tested. Run it enough times and you are simply searching the held-out data for a variant that happens to pass, which is precisely the activity the block existed to prevent. The protection is not weakened by repetition. It is spent.

So the stopping rule has to be part of the protocol, declared with everything else, and it comes in three legitimate forms. Accept the failure and abandon the rule, which is the cheapest and most under-used option. Redesign from the hypothesis, treating the failed rule as informative, and then test on data that this new rule has genuinely never touched, which usually means waiting for it or reserving a second block from the start. Or collect new data forward, which is slow, and which is the only one of the three that manufactures genuinely unseen observations rather than reusing old ones.

What is not on the list is adjusting a parameter and re-running the same block. If you find yourself reaching for it, the useful thing to notice is that you have stopped testing the rule and started negotiating with the data. The tell is easy to spot in retrospect and almost invisible in the moment: you are now searching for the version that passes, rather than asking whether this version does.

A rule that survived this procedure has earned something specific and limited: promotion to the next stage of testing. It has not earned capital at size, and it has not earned confidence proportional to how good the curve looked.

The next stage is forward testing on live data without money at risk, which is the only source of genuinely unseen observations available to you and the only stage that exercises the parts a historical simulation cannot reach: whether your signals actually fire when you expect, whether the data arrives in time to act, whether the orders you intended are the orders you place. Its mechanics, and the specific ways a simulator flatters you, are covered in the paper-trading guide. After that comes a slow live ramp at a fraction of intended size, where the question is narrow and empirical: are the fills you are getting consistent with the slippage assumption your whole result depended on? If they are not, you learned it at small size, which is the entire point of ramping.

And then the expectation, which should be set now rather than discovered later: live results typically trail the backtest. The causes are structural rather than personal. Fills are worse than assumed. Costs apply to every trade rather than to the average one. The regime drifts away from the one the rule was fitted to. If the edge is easy to find, others find it. A process that treats the backtest curve as a forecast will read this ordinary decay as failure and abandon a working rule at the wrong moment; a process that expected it sizes for the gap in advance.

None of this requires institutional infrastructure. It requires ordering the steps correctly, writing down the thresholds before you look, costing the round trip from published rates rather than a round number, and spending the held-out block once. That sequence, and the habit of preferring the narrow claim you can support to the broad one you cannot, is the substance of the method we teach.

• Securities Transaction Tax. Finance (No. 2) Act 2004, Chapter VII, section 98, Table serials 1 and 2, with the rate set by the Finance Act 2012 with effect from 1 July 2012: 0.1% on the delivery purchase and 0.1% on the delivery sale of an equity share, and 0.025% on the intraday sell. Establishes the asymmetry that makes a delivery round trip roughly six times more expensive in statutory terms than an intraday one.
• Exchange transaction charges, NSE cash segment. NSE circular NSE/FA/73061 (27 February 2026), effective 1 March 2026, setting the cash market transaction charge at ₹307 per crore per side, that is 0.00307% all in, inclusive of the revised NSE investor protection fund trust contribution. Establishes the exchange line in the cost stack. www.nseindia.com
• SEBI turnover fee. SEBI (Stock Brokers) Regulations: turnover fee of 0.0001% of turnover, that is ₹10 per crore, in the cash segment, payable on both purchase and sale. Commonly confused with the separate NSE investor protection fund trust contribution, which is a different levy with a different recipient. www.sebi.gov.in
• Stamp duty on securities. Indian Stamp Act 1899, Schedule I, Article 56A(b), as amended with effect from 1 July 2020: a uniform national rate of 0.015% on delivery transfer and 0.003% on intraday, charged to the buyer only and collected by the clearing corporation. Establishes why the two legs of a round trip are not symmetric.
• GST on brokerage and charges. Notification 11/2017-Central Tax (Rate), 28 June 2017, Serial 15, Heading 9971, with SAC 997152 for brokerage and related securities services, at 18%. GST applies to brokerage, exchange transaction charges, the SEBI turnover fee and depository charges, but not to STT or stamp duty, which the broker remits as a pure agent under Rule 33 of the CGST Rules 2017.
• Individual trader outcomes in equity derivatives. Securities and Exchange Board of India, Study on the Profit and Loss of Individual Traders Dealing in the Equity Futures and Options Segment (September 2024), covering FY22 to FY24. The figure it reports is quoted once in the body of this guide, as context for why testing discipline matters rather than as a claim about any strategy. www.sebi.gov.in