NSE’s new retail algo trading circular is finally out, laying down a clearer framework for how APIs and automation can be offered to retail traders. You can find the circular from the exchange here.
Whether you’re coding your own strategy, building on a vendor platform, or using broker-offered automation, this lays out what’s allowed, what needs registration, and how responsibilities are shared across participants.
We’ve put together a comprehensive overview covering all of this in this Z-Connect post:
We at Zerodha have offered APIs for retail users and startups on http://kite.trade for Rs 2000 per month. With this new clarity, the regulatory risk in offering the product is greatly reduced, and so we’re bringing the price down to Rs 500 per month for the data (real-time + historical) APIs. The order placement and account management APIs (view holdings, positions, etc.) have been made free since March of 2025.
So yeah, pricing now looks like this:
₹500/month for real-time + historical data APIs
Free access to order placement and account-related APIs (like viewing holdings, positions, funds, and order history). Read more here.
Specifications Comparison
This table summarizes the key requirements for each type of algo:
Aspect
Broker-Generated Algos
Algo Provider Algos
Client-Generated Algos
Definition
Algorithms created and offered by brokers to clients, registered with exchanges.
Algorithms developed by empanelled third-party providers, registered with exchanges, and offered via brokers.
Algorithms created by clients (or through third parties), used via broker’s trading systems.
Registration Requirement
Must be registered with exchanges; assigned unique algo IDs.
Must be registered with exchanges; assigned unique algo IDs usable across brokers.
Unregistered if ≤10 orders/sec (OPS); registered with unique algo ID if >10 OPS.
Static IP Requirement
Static IP can be broker’s or client’s for API access.
Static IP can be vendor’s or client’s for API access.
Static IP mandatory (client’s or vendor’s if via empanelled provider); mapped to API keys.
Order Threshold (OPS)
No specific OPS limit mentioned; subject to broker’s risk management.
No specific OPS limit mentioned; subject to broker’s risk management.
Capped at 10 OPS for unregistered algos; exceeding requires registration.
Algo ID Tagging
Orders tagged with exchange-specific algo ID.
Orders tagged with exchange-assigned unique algo ID.
Orders tagged with generic ID (unregistered, ≤10 OPS) or unique ID (registered, >10 OPS).
Change Management
Brokers report algo logic changes to exchanges for approval updates.
Providers report changes via brokers; exchanges update registrations.
Clients report changes to brokers, who notify exchanges for registration updates.
Broker’s Role
Create, register, and offer algos; provide algo details to clients; ensure compliance.
Facilitate integration with provider’s platform; conduct due diligence; notify exchanges of arrangements.
Provide API access; monitor OPS limits; forward registration details to exchanges; ensure compliance.
Provider Involvement
None; brokers develop algos independently.
Empanelled providers develop algos; brokers may have commercial/technical arrangements.
Optional; clients may use third-party developers (treated as client algos).
Security Requirements
OAuth/2FA, password expiry, no open APIs; hosted on broker’s cloud servers.
OAuth/2FA, password expiry, no open APIs; hosted on broker’s cloud servers.
OAuth/2FA, password expiry, no open APIs; hosted on broker’s cloud servers.
Risk Management
Brokers ensure RMS checks, compliance with IBT/STWT, and algo trading guidelines.
Brokers ensure RMS checks, compliance with IBT/STWT, and algo trading guidelines.
Brokers ensure RMS checks for unregistered algos (≤10 OPS) and compliance with IBT/STWT guidelines.
Broker Liability
Fully liable for all orders; exchanges can terminate rogue algos.
Fully liable for all orders; exchanges can terminate rogue algos.
Fully liable for all orders; exchanges can terminate rogue algos.
Exchange Oversight
Exchanges assign algo IDs, approve changes, and can terminate rogue algos.
Exchanges empanel providers, assign algo IDs, and can terminate rogue algos.
Exchanges assign algo IDs (generic or unique), approve registrations, and can terminate rogue algos.
Para E (sub para 1), on page 4 of the NSE circular, mentions all algo providers must get empaneled with exchanges in accordance with guidelines set by each exchange.
Trying to find out what the process and eligibility criteria is to get empaneled as a third party algo provider with the NSE, for example, and what technology/system requirements need to be fulfilled-- where do we find all this? Any help is greatly appreciated. Thank you so much in advance
@nithin@nithin_kumrr@siva@ShubhS9 - I have several questions. If I remember correctly these algo rules come into effect on August 1, 2025 and there are still many unresolved questions IMO:
for falling below the retail/client registration requirement, is the 10 orders per second rule enforced at api_id level or Zerodha client level or PAN level? I don’t remember reading about this basic and important point in the circular.
(api_id level = can we just buy another api_id for 500rs if it looks like 10 o/sec is getting close?)
(PAN level = 10 o/sec across all brokers, which would suck)
Has Zerodha created any portal for algo registration if I want to go beyond 10 o/sec?
If I register an algo, does that effectively mean I cannot run any unregistered algos after that? i.e. will orders from any unregistered algo trades (within 10 o/sec) for strategies created after that FIRST registration also be ATTRIBUTED TO the registered algo?
Will I then face scrutiny if the unregistered algo’s trades dont match the registered strategy with the exchange/regulator? (even if, as I said, the unregistered algos or regular manual trades will all be within 10 o/sec - I am more of a fundamentals-based trader anyway)
Will one iceberg order be counted as 1 order or multiple orders towards the 10 o/sec limit?
Will order modifications count towards the 10 o/sec limit (i.e. do only fresh orders count towards the limit)? What if the order is partially filled and then modified - is that 1 order or 2?
How much % margin of safety should I incorporate in the 10 o/sec limit, given that the clocks at the broker or exchange may differ from my device clock? Or will excess orders be cancelled or delayed at the broker’s end if it exceeds 10 o/sec?
An even simpler question yet important question that’s left unanswered in the circular - Is just the basic strategy required to be registered with the broker/exchange/regulator or the detailed strategy including code? I am extremely afraid about alpha degradation and any other serious trader should be too. It only takes one leak to f*** up your entire livelihood (and possibly career).
It’s odd how our dear regulator came up with this registration rule for alpha strats that earn money (unmatched anywhere else in the world, and I highly doubt the actual HFTs will simply hand over their alpha like good boys and girls). It seems SEBI is either ignorant or malicious in disregarding the potential for misuse after registration. I don’t see any post-registration safeguards in the circular.
Beyond the practical, implementation-related questions above, it’s interesting how SEBI is positioning itself as a bottleneck in the market instead of a facilitator. Reviewing MANUALLY EACH new algo strategy will take weeks of bureaucracy, and the time taken is liable to increase to multiple months unless the regulator plans to scale up its reviewing staff proportionally to the ever increasing numbers of market entrants for the next few decades, which we know will not happen. Who wants to bet strategies of bigger players will be approved faster than strategies of smaller players?
All the while every single participant in the chain knows what your strategy is. RIP Profits. The 94% retailers who lose money will become 99%. India will become front running heaven.
Definition of algo is orders originating from machines only and not manual. So in this case irrespective of id if one places manually then it is not algo.
Waiting for SOP circular from exchanges, only after that we know the procedure.
You register only if algo fires more than 10 orders per sec, if other algo fires less than 10 per sec then no need to register it. You can run both.
One only.
Yes, order modification also counts.
Rejection above 10 will happen at broker end.
We are also waiting for the answer but we believe they may just need a small write up in brief, no code will be required.
This is sooo late for anyone who needs to register algos.
Otherwise, assuming we just need static ip, then requirement has been known for a lot of time.
