What SEBI's retail algo circular means for your order layer

SEBI's 4 February 2025 circular, "Safer participation of retail investors in Algorithmic trading", is mostly a compliance document. But if you build trading software, most of it lands on one place in your code: the layer that sends orders to a broker. Here is what it changes in practice. I'm writing this as a developer, not as a lawyer, so read the circular itself before you design anything.

1. No more open API keys The circular does not permit open APIs. A broker may give API access only through an API key that is specific to the vendor and the client, together with a static IP the broker has whitelisted. The aim is traceability: the broker should be able to say which algo provider and which end client sent any order.

For your system this means API keys and IPs are per client records, not global settings, and your order traffic has to leave from a fixed, known address.

1. Orders need to be tagged Brokers have to detect and tag algo orders using identifiers the exchange specifies, and this also applies to algos a broker offers to its own clients. Where the broker's API has an order tag field, you can pass a compact tag yourself. Kite Connect, for example, accepts an optional alphanumeric tag of up to 20 characters that comes back in the order book.

A pattern that works: encode the strategy ID and version in the tag, so one look at the broker's order book tells you which rule set sent the order.

1. Versions must be frozen
   An approved algo that changes needs fresh approval. In software terms, a strategy version should become immutable once it is approved, and a change creates a new version with a new record. If your strategies are edited in place, you cannot prove later what was running when an order went out.

2. Keep an audit trail you can actually read
   For every order, store the client, strategy ID and version, the rule that triggered it, the request you sent and the broker's response. This is the record you will want when a client asks why an order fired.

3. Login is OAuth and two-factor
   The framework asks for OAuth-based authentication and two-factor authentication. Most brokers already work this way. The practical effect is a daily login step: for example, Kite Connect's access token expires at 6 AM the next day. Plan for a re-login prompt and pause live strategies for any client whose token has lapsed, instead of letting orders fail silently.

What is still moving
Secondary sources disagree on when parts of this apply, and the exchanges have issued their own operational rules (for example on static IP changes). Check the SEBI and NSE notices for the current dates before you commit a launch plan.

Where we wrote this up in more detail
We build algo trading software for brokers, strategy providers and trading educators, and we keep a longer technical guide with the Kite Connect login and order flow table, the order-layer audit design and cost drivers: Algo trading software development in India. If you are planning an app around it, the trading app development guide covers the client side.

Sources: SEBI circular text (reproduced by TaxGuru), Zerodha Kite Connect documentation on user login and orders.

Reviewed by Ranjeet, Technical Reviewer at Brandzivio.