The costs automation multiplies

In the Taxation course you met the cost stack: brokerage, the securities transaction tax, exchange and regulatory fees, GST, stamp duty, all charged on every trade, win or lose. When you traded by hand, the sheer effort of placing orders limited how often you paid it. Automation removes that limit. A program can trade a hundred times a day without tiring, and it pays the full stack every single time. This chapter shows how quickly that adds up, and why it puts a ceiling on how much any strategy can earn.

Costs scale with how often you trade

Costs are not a footnote; at automated frequency they can be the whole story. Take an illustrative round-trip cost of 0.10%, the kind of figure the Taxation and Risk courses used, and watch what it does as a strategy trades more often.

# The cost stack from the Taxation course, brokerage, STT, exchange and SEBI
# fees, GST, stamp duty, is paid on every trade, win or lose. Automation makes
# trading often easy, so the total cost scales with how much a strategy trades.
# Illustrative round-trip cost 0.10% on an illustrative trade value.
account = 1_000_000
round_trip = 0.001            # 0.10% per round-trip trade, illustrative
trade_value = 100_000         # rupees per trade, illustrative

print(f"Account {account:,}, round-trip cost {round_trip * 100:.2f}%, "
      f"trade value {trade_value:,}\n")
print(f"{'trades/year':>12}  {'annual cost':>14}  {'as % of account':>16}")
for trades in [50, 200, 1000, 5000]:
    annual_cost = trades * trade_value * round_trip
    pct = annual_cost / account * 100
    print(f"{trades:>12,}  {annual_cost:>14,.0f}  {pct:>15.1f}%")

print("\nA strategy must clear this cost hurdle BEFORE it earns you a rupee.")
print("At 5,000 trades a year the drag is 50% of the account: the strategy")
print("would need a very large gross edge just to break even.")

Account 1,000,000, round-trip cost 0.10%, trade value 100,000

 trades/year     annual cost   as % of account
          50           5,000              0.5%
         200          20,000              2.0%
       1,000         100,000             10.0%
       5,000         500,000             50.0%

A strategy must clear this cost hurdle BEFORE it earns you a rupee.
At 5,000 trades a year the drag is 50% of the account: the strategy
would need a very large gross edge just to break even.

The table is sobering. Fifty trades a year costs half a percent of the account, a rounding error. But a program trading 1,000 times a year burns 10% of the account in costs alone, and one trading 5,000 times a year burns 50%. That is not the strategy losing; that is the cost of trading, paid before the strategy makes or loses a rupee. A high-frequency strategy must first earn back an enormous cost hurdle just to reach zero, and most cannot. This is the same overtrading drag the Risk and Psychology course warned about, now at machine scale, and it is why low turnover, trading less rather than more, is a design goal for a retail algo trader, not an afterthought.

Capacity: the size that breaks a strategy

There is a second, subtler limit that grows with success: capacity. A strategy that works beautifully with 1 lakh rupees may fail completely with 1 crore, and the reason is the market impact you met with slicing. When your orders are small relative to the market, you barely move the price. When they are large, your own buying pushes the price up as you enter and your selling pushes it down as you exit, and that self-inflicted slippage eats the edge. Every strategy has a capacity, a size beyond which it stops working because you have become too big a part of the very market you are trading. For some strategies capacity is large; for the fast, thin-edge kind, it is often small. The uncomfortable truth is that a strategy which prints money on small size can be worthless at the size you actually want to trade.

Design for low turnover

Put the two together and the design guidance is clear. Costs reward trading less, and capacity rewards trading in a size the market can absorb, which usually means slower, larger-edge strategies. A retail algo trader is far better served by a patient strategy that trades occasionally, clears the cost hurdle easily, and has room to grow than by a frenetic one that looks brilliant before costs and is hopeless after them. When you judge a strategy, judge it after the full cost stack at the frequency it actually trades, and ask honestly how much money it could handle before its own size spoiled it.

What to carry forward

Every trade pays the whole cost stack, and because a program can trade often without tiring, costs scale straight with turnover: the same 0.10% round trip that is trivial at 50 trades a year becomes a 50% drag at 5,000. On top of that, every strategy has a capacity, a size beyond which your own orders move the market and destroy the edge, so a strategy that works small can fail large. Both point the same way: design for low turnover and honest capacity, and judge a strategy only after its full costs at its real frequency. The next chapter confronts the deepest reason live results fall short of the backtest, the one that fools even careful people: overfitting.