I have been running my own automated trading system on Indian markets for over a year. This is everything I wish someone had told me before I started: what the law actually requires of a retail trader, what it costs to run, and the order in which to build it.
Is algo trading legal in India?
Yes. Retail investors are permitted to develop and use their own algorithms to trade their own accounts. This has been true for years, and SEBI's 2025 framework for retail algorithmic trading confirmed it explicitly while adding structure around everything else.
What the framework does is put the broker at the centre as the responsible party. Your broker is accountable for monitoring algo orders, enforcing limits, tagging orders so the exchange can trace them, and doing due diligence on any third-party algo provider it allows onto its systems. The practical rules you experience day to day therefore come from your broker's API terms, not from a form you file with SEBI.
Two boundaries matter, and both are about scale and distribution rather than about the act of automating:
- Order frequency. Once your system crosses the order-per-second threshold the exchanges have set — reported as 10 orders per second per exchange — it stops being treated as casual personal automation and falls under registration and approval requirements. Brokers monitor this and reject orders that breach their limits.
- Distribution. The moment you give, sell or subscribe other people to your algo, you become an algo provider, and a completely different set of obligations applies.
Check the current position with your broker's API documentation and the latest SEBI circular before you go live. The framework rolled out in phases through 2025 and 2026, and brokers implement on their own timelines. I update this guide monthly, but a circular can land the week after I do.
What SEBI's 2025 framework actually changed
| Who you are | What applies to you |
|---|---|
| Retail trader running your own algo on your own account, below the order-rate threshold | No registration. Use your broker's API under its terms. Static IP whitelisting, a client-specific API key and strong authentication are typically required. |
| Retail trader exceeding the order-rate threshold | Registration and exchange-level approval come into play; your broker must route and monitor the algo accordingly. |
| Anyone offering an algo to other people, free or paid | You are an algo provider: empanelment with the exchanges, onboarded through brokers that have done due diligence on you. |
| Provider of a black box algo, where the logic is not disclosed | Additionally requires SEBI Research Analyst registration, with research documentation per strategy. Material changes are treated as a new strategy. |
The security requirements change how you deploy. Expect to need a static IP address whitelisted with your broker, a key tied to your own account, and two-factor authentication on the login flow. A laptop on home broadband with a changing IP is not a stable deployment target. I run mine on a small cloud instance with a fixed IP, which also solves the "my laptop slept during market hours" problem.
Your own algo versus providing one to others
This is the line that catches people, because the two sides look similar from outside and are completely different in law.
Running your own algo means your code, your account, your money. No registration below the thresholds.
Providing an algo means someone else's account trades on your logic. Selling a bot, licensing it, running it for a friend, publishing a strategy that executes through a subscription platform — all of it puts you in provider territory, where empanelment applies and, for undisclosed logic, Research Analyst registration on top.
People ask to buy my system fairly often. I don't sell it. The compliance path for a one-person operation is heavier than the income would justify, and anything I would have to say to market it — returns, win rates, "it works" — is exactly the kind of performance claim an unregistered person should not be making.
What you need before writing a line of code
- A demat and trading account with a broker that has a real API. Not every broker does, and documentation quality varies enormously. You will live inside those docs for months.
- API access enabled, with a static IP. Sorting out whitelisting and key management before you write code saves a frustrating week later.
- Historical data you trust. Your backtests are only as good as this. Broker historical APIs are usually adequate for daily and minute bars; tick data is a separate and bigger problem.
- Python, and enough engineering discipline to test things. Not the language — the discipline. The difference between a bot that survives and one that does not is almost entirely testing, logging and error handling.
- Capital you can genuinely afford to lose. Your first live deployment will do something you did not predict. Size it so that when it does, it is a lesson rather than a disaster.
- A machine that stays awake. A small cloud instance in Mumbai, close to the exchange, with a fixed IP.
- Patience for a slow start. Mine took four months before it placed a live order. That was the correct pace.
Broker APIs compared
The landscape changed in 2025 when Zerodha made execution APIs free for personal use while keeping a charge for market data. Several brokers now offer APIs at no cost, which removes what used to be the first real expense for a beginner.
| Broker | API | Typical cost |
|---|---|---|
| Zerodha | Kite Connect | Execution free for personal use since April 2025; market data around ₹2,000/month |
| Dhan | DhanHQ | Free; data add-on around ₹500/month |
| Upstox | Developer API | Free |
| Angel One | SmartAPI | Free |
| Fyers | Fyers API | Free |
| Finvasia | Shoonya | Free |
| Kotak Securities | Neo API | Free |
Pricing and terms move, so confirm on the broker's own developer page. What I weigh more heavily than the monthly fee:
- Documentation and an active developer forum. You will be stuck at 11pm on an undocumented error code.
- Websocket stability under load. Test this in week one, not month six.
- Rate limits, and how the API behaves at them. A clear error is fine; silent dropping is not.
- Order rejection messages that tell you why. This determines how well you can classify failures, which is what keeps a bad afternoon from becoming an expensive one.
What it costs to run, including the 2026 STT change
This is the section most beginners skip, and the one that decides whether a strategy that looks profitable actually is. An automated system trades more often than you would by hand, so costs compound faster than the edge does.
Securities Transaction Tax from 1 April 2026
Budget 2026 raised STT on derivatives significantly. If you are working from an older article, your cost model is wrong.
| Segment | Rate now | Previous rate | Charged on |
|---|---|---|---|
| Equity futures | 0.05% | 0.02% | Sell side |
| Options, sold | 0.15% of premium | 0.10% | Premium, sell side |
| Options, exercised | 0.15% of intrinsic value | 0.125% | Intrinsic value |
| Equity intraday | 0.025% | unchanged | Sell side |
| Equity delivery | 0.10% | unchanged | Both sides |
Futures STT rose by 150%. If your system trades futures frequently with a small per-trade edge, rerun your numbers before anything else.
Everything else you pay
- Brokerage — typically a flat fee per executed order at discount brokers.
- Exchange transaction charges — a percentage of turnover, different per segment.
- GST at 18% — on brokerage plus transaction charges.
- SEBI turnover fees and stamp duty — small, but real at volume.
- Slippage and impact — usually the largest cost of all, and the one no statement shows you. Measure it from your own fills rather than assuming it.
Infrastructure
A small cloud instance runs roughly ₹800–2,000 a month, and market data may add ₹500–2,000. Total fixed cost for a one-person setup is usually under ₹4,000 a month, which is nothing compared with what a poorly tested deployment can cost in one afternoon.
Every strategy is profitable until you subtract costs. Build the cost model before the strategy, not after.
The build path, in order
- Get data in and store it properly. Before any strategy work. Clean, gap-checked, timestamped data is the foundation.
- Build the replay harness. The ability to rerun any past session and see exactly what your system saw. I built this late and regretted it.
- Backtest, then distrust the result. Look-ahead bias, survivorship, mid-price fills and forgotten fees each flatter your results independently.
- Paper trade against real order books. Not against mid prices. The gap between the two is where most people's live results disappear.
- Write the risk layer before the strategy layer. Daily loss cap, per-trade cap, maximum orders per signal, kill switch. Store the counters outside the code they limit.
- Go live with the smallest size the exchange allows. The purpose of the first month is to find out what you got wrong.
- Log everything, and review daily. Every decision with the state it was based on.
Five mistakes that cost me money
- Retrying rejections. One rejected order became eleven attempts in nine seconds because the retry logic treated every failure as transient.
- Trusting the backtest. My first live month underperformed the backtest by a wide margin, entirely due to fills and costs.
- Silent data gaps. Three tenths of a percent of ticks missing for a month, because I did work inside the websocket callback.
- Config drift. A threshold I changed three weeks earlier never reached the running process.
- Counting the wrong thing. A trade cap that counted orders rather than round trips let a partial fill eat the day's budget in one signal.
How your profits are taxed
In broad terms, and this is not tax advice: F&O trading is generally treated as non-speculative business income, while intraday equity trading is treated as speculative business income. Both usually mean filing ITR-3, maintaining books, and computing turnover correctly — which for F&O is not the same as the value of your trades, and is where most people get it wrong.
Business treatment does let you deduct genuine expenses: broker charges, data subscriptions, your cloud instance, and a share of your internet bill. Losses can generally be carried forward if the return is filed on time.
Turnover computation, audit applicability and loss carry-forward have real consequences and real penalties. Spend money on a CA who has handled F&O returns before. I am a developer who trades, not a tax professional.