Almost nobody fails at this because their strategy idea was bad. They fail at one of a fairly short list of recurring errors, most of which are invisible until money is involved.
These are grouped by where they happen — in testing, in risk, in code, and in judgement — because the fix is different in each case, and because people who have solved the first group often still lose to the fourth.
In testing
Leaving costs out. The most common and the most fatal. Brokerage, STT, exchange charges, GST, stamp duty and slippage together are often larger than the edge being tested. A strategy that trades several times a week and looks profitable gross is frequently a losing one net. Subtract a pessimistic figure per side before you form any opinion about it.
Look-ahead bias. Acting on information that was not available at the decision point — usually a missing one-bar shift, so you buy at a price you could only know after deciding. It makes almost any strategy look excellent and it is invisible unless you go looking.
Overfitting. Trying two hundred parameter combinations and keeping the best one. You have not found an edge, you have found the settings that best fit the noise in that particular sample. If a small change in a parameter destroys the result, you were fitting noise.
Survivorship bias. Testing today's index constituents over ten years. The companies dropped along the way are missing, so you have tested a list selected for having survived.
Too few trades. Thirty trades over six years tells you nothing. Judge by trade count, not by calendar length.
Moving the start date. Quietly beginning the test in 2020 because 2018 looked bad. The honest description then is that it has worked for a few years, which is a much weaker claim than it sounded.
In risk
Sizing by cost instead of by risk. The single most expensive habit in derivatives. An option position that costs a small premium can behave like a very large position in the underlying, so deciding size from what it cost you takes on far more exposure than intended. Size from the distance to your stop.
No daily loss limit. Per-position risk does not protect you from five positions failing on the same morning, and the instinct after a run of losses is to trade larger to recover. A limit decided in advance and enforced by code prevents that, because the code has no view on whether today feels like it might turn.
Mistaking correlated positions for diversification. Six bank stocks at 1% risk each is one position at 6%, and correlation rises exactly when it hurts. Cap risk by sector as well as per position.
Scaling up after a good month. It feels like confirmation and is usually variance. Decide the scaling rule before going live, as a condition your program can check.
Designing for a drawdown you would not actually sit through. If the backtest shows a 40% worst stretch, ask honestly whether you would still be running it four months in. A strategy abandoned mid-drawdown delivers none of the return the backtest promised.
In code
Strategy logic inside the tick callback. The ticker runs its own loop and blocks while your code executes. On a quiet day nothing appears wrong; during a fast move you fall behind and act on stale prices. Push ticks onto a queue and work elsewhere.
No reconnection handling. WebSocket connections drop routinely. Worse is the connection that stays open and stops delivering — to your program a dead feed and a still market look identical. Add a watchdog on time since the last tick.
Assuming state after a restart. If the process dies holding a position and comes back up, it must read its real position from the broker rather than assume a clean slate. Orders should be idempotent enough that a retry does not double your size.
Stops living only in your program. A stop-loss held in memory disappears when the process does, or when the power goes. Place protective orders at the exchange.
Ignoring the daily token expiry. A bot that starts with yesterday's access token connects to nothing and fails silently unless you check.
Hardcoding the calendar. Trading holidays, muhurat sessions and expiry timings need to come from a source, not from a weekday check.
In judgement, which is where most people actually lose
These have no technical fix and they account for more failures than everything above combined.
Changing a strategy while it is running. It goes live Monday, two trades lose, the stop is widened Wednesday, a filter is added Friday. Three weeks later the results cannot be attributed to anything because there was never a version. Let it run unchanged for a defined number of trades; write observations down and apply them to the next version, backtested before it goes live.
Abandoning a working strategy at the bottom of its worst stretch. The mirror image, and just as costly. If you know the backtest's worst drawdown, a bad run inside that range is expected behaviour rather than evidence of failure. Without that number written down beforehand, every drawdown feels like proof.
Automating a market you have not learned. Automation removes hesitation, and hesitation is sometimes the only thing standing between a badly designed rule and a large loss. Learn the market first.
Running a strategy you cannot explain. If you cannot say why it should work, you cannot tell the difference between it having stopped working and it having a bad month. That distinction is the entire job.
Skipping paper trading. The step everybody wants to skip, and the one that catches expired tokens, margin rejections and dropped connections — each of which costs real money if found live instead.
The three that cost the most
If you fix nothing else on this page, fix these.
Costs in the backtest. One line of arithmetic separates a strategy worth running from one that will lose slowly and confusingly for a year.
Position size from a formula. Three lines of code that make the most dangerous decision in trading non-negotiable at exactly the moment you would negotiate it.
Not touching a live strategy. Free, requires no code, and is the hardest of the three to actually do.
Everything else on this list is real, but those three are where the money is.
All of it runs against a broker account, which supplies both the historical data you test on and the orders you eventually place.
A live account, not a script-side stop
Protective orders held in your program vanish with the program. Account free to open
Every mistake above is addressed as a section rather than as advice in our Algorithmic Trading with Python course at Rs 24,900 — one payment, permanent access, free demo on WhatsApp first.
We sell no tips and no signal group, we manage nobody's money, and we promise no returns. Trading carries a real risk of loss.
Disclosure: the account-opening link on this page is under Atul Shrivastava's Zerodha Authorised Person registration (NSE AP Reg: AP2516003481; Zerodha Broking Ltd. SEBI Reg: INZ000031633) and earns a revenue share. TheFinBaba is not a SEBI-registered Investment Adviser — this content is educational, not investment advice.
Frequently Asked Questions
What is the most common mistake in algo trading?
Leaving transaction costs out of the backtest. Brokerage, STT, exchange charges, GST, stamp duty and slippage together are frequently larger than the edge being tested, so a strategy that looks profitable gross is a losing one net.
Why does my strategy work in backtest but fail live?
Usually one of three things: look-ahead bias in the code, costs and slippage underestimated, or parameters tuned on the same data used to evaluate them. Walk-forward testing exposes the third; a careful read of your shift logic exposes the first.
Should I modify my strategy while it is running?
No. Let it run unchanged for a defined number of trades, write observations down as you go, and apply them to the next version which gets backtested before going live. A strategy edited mid-run produces results that cannot be attributed to anything.
How do I know if my strategy has stopped working?
Compare the current run against the worst stretch in your backtest. Inside that range it is expected behaviour. You also need to be able to explain why the strategy should work at all - without that, a bad month and a broken edge look identical.
What coding mistakes break live trading systems?
Strategy logic inside the tick callback, no reconnection handling, assuming position state after a restart, stops held only in memory, ignoring the daily token expiry, and a hardcoded trading calendar.
Is it a mistake to increase position size after a profitable month?
Yes, if the month is the reason. Decide the scaling rule before going live - a fixed step after a set number of trades, conditional on live results tracking the backtest - so a program checks it rather than your confidence.
Related Reading
- Backtesting a trading strategy in Python
- Risk management in trading
- Setting up paper trading in India
- Live tick data with the Kite Connect WebSocket
- How to start algo trading in India
- Algorithmic Trading with Python - full syllabus
Disclaimer: TheFinBaba provides educational content only - this is not investment advice. Trading involves risk of loss.
