Building a compliant retail algo

From 1 Apr 2026 SEBI's retail algo framework applies to every stock broker. A retail algo can send up to ten orders a second to an exchange without registering, and that ceiling is 600 orders a minute and 2,25,000 in a six and a quarter hour session. No hand clicks that fast. Under the rules, every order a program sends through the broker's API is an algo order whatever its rate: tagged, traced to a key and a static IP, risk checked by the broker and open to a kill switch. This lesson takes the framework as the circulars set it and turns it into an architecture. It is education about design and rules. It is not a strategy to run, not a view on any contract and not a list of vendors.

The idea, plainly

Who does what under the framework?

The circular of 4 Feb 2025 splits the roles. The investor writes or buys the logic. The broker is the principal: it holds the API, answers for every order that comes through it and handles the grievances. An algo provider is the broker's agent and must be empanelled with the exchanges. The exchange registers algos, tags orders, runs surveillance and keeps a kill switch for orders from one algo identifier. The circular describes that switch as the last level of defence against an algo malfunction, expected to halt trading on pre-defined conditions.

What changes at the ten orders a second line?

Every order that reaches the broker through a client's API is an algo order and carries an exchange tag. The line decides registration, nothing else. The NSE standards of 5 May 2025 set the threshold, "not exceeding 10 orders per second" per exchange and segment to begin with, applied on the calendar second of the broker's server, and the exchange may change it after notice. A broker may set a lower limit for a client.

• At or below the line: the investor's own algo runs through the broker's API without registration. Its orders carry a generic tag from the exchange. Above the line the broker rejects the excess.
• Above the line: the algo is registered with each exchange where it will trade, through the broker. The exchange issues a registration ID and the orders carry it. The same registered algo may serve the investor's family: self, spouse, dependent children and dependent parents, and no other investor.
• For others: giving an algo to people outside the family is the provider route, which needs exchange empanelment. A black box, whose logic the user cannot see, also needs the provider to register as a research analyst and keep a research report for each algo. A change of logic makes it a fresh algo.

What does the connection itself need?

The broker may allow no open API. Access is through an API key specific to the client and a static IP the broker has whitelisted, with OAuth and two factor authentication. The NSE standards add that a client may give one primary and one secondary static IP, may change them no more than once in a calendar week, and shares an IP with another client only inside one family. A client may hold several API keys, but unregistered algos run only through one predefined key. API sessions are logged out every day before the next trading day. Algo orders may not be market orders. The broker keeps an audit trail for at least five years and is liable for every order through its systems.

When did all this apply?

The dates moved more than once, so name the circular a page relies on. The circular was due to apply from 1 Aug 2025. NSE issued its detailed operational modalities on 22 Jul 2025 and SEBI moved the start to 1 Oct 2025 on 29 Jul 2025. A circular of 30 Sep 2025 let brokers who were ready go live on 1 Oct 2025 and gave the others three milestones, with those missing them barred from onboarding new API algo clients from 5 Jan 2026. From 1 Apr 2026 the framework applies to all stock brokers. Exchanges update operational details by circular, so check the NSE page before relying on one.

What should the investor's own layer add?

The framework puts risk management on the broker and the kill switch on the exchange. Neither knows your intention. A design that follows the rules still needs its own guards, written before the first live order: a size limit per order, a loss limit per day that stops the program, a rate limiter set well under the threshold, a guard against sending the same order twice, a check of positions against the broker's at each start, and a log of every order and every rejection. The daily logout means the program must log in again each day and must not trade on a stale session.

What does one trading day look like?

Before the open the program logs in again, because its session was logged out the evening before, and it checks that the static IP the broker has mapped is still the one it runs from. It reads its positions and open orders from the broker and compares them with its own records. It starts with the rate limiter live and the loss limit armed. Each order goes out with a limit price and never as a market order, and every response, fill and rejection is written to a log with a time stamp. If the loss limit trips or the data feed fails, the program cancels what it can, stops sending and tells its owner. After the close it reconciles again. Only the login, the static IP and the order type come from the circulars. The rest is practice, and it turns the broker's audit trail into a record the owner can read too.

Worked example: why a risk layer sets the size

Take a rule with an assumed edge, made up for the model and not found in any market: it wins 55% of the time and each win equals each loss. The Kelly fraction of such a rule is 10% of the account. The model below runs 250 trades on 2,000 simulated paths and counts how often the account falls by half at four sizes of risk per trade.

What about testing and claims?

Test on dated data first, as in the backtest biases module, with the costs of each date. The exchanges run a standard procedure for testing algos and mock sessions, and the NSE FAQ says an individual tech savvy client is not required to join the monthly mock sessions. Claims are a separate rule. SEBI allows only registered advisers, research analysts and empanelled algo providers to state past performance, as risk and return figures verified by a recognised verification agency. That agency has operated since 4 May 2026. A backtest chart posted in a group is not that.

The common mistake

The belief: My algo stays under ten orders a second, so it is outside the rules. The line decides only whether the algo is registered with the exchange. Below it, every order through the API is still an algo order. It still comes from a static IP the broker has whitelisted, through a client key, after OAuth and two factor login, with a daily logout, an exchange tag and a trail the broker keeps for five years, and the broker answers for it. Selling or sharing the algo outside the family is a different step again. Read the circular and the exchange standards, name their dates, and keep your own risk layer.

Key takeaways

• The broker is the principal. The algo provider is its agent.
• Ten orders a second per exchange decides registration, not whether the rules apply.
• Every API order is tagged. Static IP, client key and two factor login apply.
• Algo orders may not be market orders. Sessions log out daily.
• The exchange keeps a kill switch. The size limit is yours to design.
• Only registered firms may state past performance, as verified figures.

Before you trade. Derivatives trading carries a high risk of loss. SEBI's study "Profitability of Individual Traders in the Equity Derivatives Segment (FY25 to FY26)" (August 2026) found that 87.7% of individual traders in equity F&O made net losses in FY26, with aggregate net losses of Rs 91,685 crore. Read the SEBI study