Product Activation: API and Algo Access

Why this page is structured this way: Since the February 2025 retail-algo framework, “give me an API key” is no longer one request but a fork: below a defined order rate the client is a fast manual trader, above it the client is running an algo that must be registered with the exchange and tagged on every order. The page therefore establishes the threshold first, then walks the two paths, then covers the controls that apply regardless — static IP, key hygiene, order-to-trade ratio, pre-emptive rejection. Broker-side approval, audit trail and vendor empanelment are covered in the retail-algo deep dive and only summarised here.

TL;DR

• The framework is SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/0000013 (4 Feb 2025): API access only through the broker, every algo order carrying an exchange-issued unique identifier, no open APIs, vendor-specific or client-specific keys, broker-whitelisted static IP, OAuth-based authentication and mandatory two-factor authentication.
• The threshold is an exchange number, not a SEBI number. SEBI delegated it; NSE fixed it at ten orders per second per exchange and segment in NSE/INVG/67858 (5 May 2025), and reserved the right to change it.
• Below the threshold, nothing needs registering — the order still receives a generic exchange algo identifier, so it is still visibly machine-originated. Above it, the client registers the algo through the broker, per exchange used.
• Registered algos are family-scoped. The client may use a registered algo only for self, spouse, dependent children and dependent parents; the same boundary governs static-IP sharing.
• Dates slipped twice. The 1 August 2025 go-live moved to 1 October 2025 by SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/108 (29 Jul 2025), and SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/132 (30 Sep 2025) [not yet in index] set a milestone glide path ending in full applicability for all brokers from 1 April 2026.
• Third-party algo platforms are permitted but never independent. A vendor is empanelled with the exchange and acts as the broker’s agent; the broker remains principal and owns the client’s grievance.

Conceptual overview

Programmatic order access used to be a quiet corner of retail broking: a developer-facing key, a rate limit in the documentation, and an implicit understanding that whatever the client built was the client’s business. The February 2025 framework ended that. Its organising idea is principal-agent — the broker is the principal for every order that reaches the exchange through its systems, including orders generated by software the broker did not write and cannot read. Everything else in the framework follows from that: if the broker answers for the order, the broker must know which software produced it, must be able to switch that software off, and must be able to show a regulator the trail.

For the client, the practical consequence is a fork that did not exist before. Someone who fires a handful of orders a day from a script is treated as a manual trader with a convenient interface. Someone whose software can fire ten or more orders a second is treated as an algorithmic trader, must have that algorithm registered with each exchange they trade on through the broker, and gets a unique identifier stamped on every order the algorithm sends. Both paths need an API key, a static IP in most configurations, and two-factor authentication. Only the second path needs exchange paperwork.

The second consequence is scope. A registered algo is not a product the client can share, resell or run for friends. The circular confines its use to the client’s own family — self, spouse, dependent children, dependent parents — and the exchange implementation applies the same boundary to static-IP sharing. A client who wants to run strategies for other people is describing a regulated activity, not an API configuration.

1. Regulatory framework

• SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/0000013 (4 Feb 2025) — the retail-algo framework. Part I(a) confines API access to the broker’s own channel and casts the algo vendor as the broker’s agent; Part I(b) requires a unique exchange-issued identifier on every algo order; Part I(c) requires registration of client-coded algos once a specified order-per-second threshold is crossed, and confines a registered algo’s use to the client’s family; Part I(d) prohibits open APIs and prescribes vendor-specific or client-specific keys, broker-whitelisted static IP, OAuth and two-factor authentication; Part III places algo providers on exchange empanelment rather than direct SEBI registration; Part V(a) separates white-box from black-box algos and requires black-box providers to register additionally as research analysts with a per-algo research report.
• SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/108 (29 Jul 2025) — moves the effective date from 1 August 2025 to 1 October 2025 (paragraph 2).
• SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/132 (30 Sep 2025) [not yet in index] — sets the milestone path: registration application by 31 October 2025, registration complete by 30 November 2025, mock session by 3 January 2026, no new retail API-algo onboarding by non-compliant brokers from 5 January 2026, and full applicability for all brokers from 1 April 2026 (paragraphs 4, 5 and 8). See Circulars — SEBI MIRSD.
• NSE/INVG/66524 (5 Feb 2025) — NSE’s originating circular taking the SEBI framework into exchange process.
• NSE/INVG/67858 (5 May 2025) — implementation standards. Fixes the threshold at ten orders per second per exchange and segment (Section B.2 and F), confirms that sub-threshold orders still receive a generic exchange algo identifier (Section B.3), requires registration per exchange used and routed through the broker (Section C.1 to C.2), prescribes static-IP requirements by originator (Section A.1 to A.7) with one static-IP change per week and family-only sharing, allows multiple API keys while confining non-registered algos to one predefined key (Section A.3 to A.4), and mandates daily API logout (Section A.8).
• NSE/INVG/69255 (22 Jul 2025) — detailed operational modalities; Annexure I paragraph 14 requires strategies to run on the broker’s servers with orders originating from the broker’s server, the exception being a tech-savvy client’s own algo hosted on the client’s own static IP.
• NSE/INVG/69289 (24 Jul 2025) [not yet in index] — corrigendum establishing the thirteenth-digit scheme on the non-neat-front-end identifier that marks an order as algorithmic and maps originator categories.
• NSE/FAOP/69296 (24 Jul 2025) — extends pre-emptive rejection of algo market orders to futures and options, and rejects orders where the identifier digit and the algo-identifier field disagree; effective 4 August 2025.
• NSE/SURV/45016 (14 Jul 2020) — the order-to-trade ratio framework and its per-order penalty slabs, cooling-off and repeat-offender provisions; historical baseline for the 2026 revision.
• SEBI circular on revision of the order-to-trade ratio framework, 4 Feb 2026 [not yet in index] — effective 6 April 2026; permits exchanges to set steeper slabs and excludes near-the-money options and designated market-maker algo orders from the ratio computation. Clause-level figures were corroborated from secondary sources only. [AI inference — verify before acting]

2. The fork: fast manual versus registered algo

	Sub-threshold API use	Registered algo
Trigger	Order rate stays below ten orders per second per exchange and segment	Order rate reaches or exceeds the threshold
Registration	None	Client registers the algo through the broker, once per exchange used
Order tagging	Generic exchange algo identifier applied	Unique exchange-issued algo identifier applied to every order
API keys	One predefined key for non-registered use	Keys may be multiple; each registered algo maps to its own
Where the strategy runs	Client’s own environment calling the broker’s API	On the broker’s servers, except a tech-savvy client’s own algo on the client’s own static IP
Who else may use it	Nobody — a key is client-specific	Client’s family only: self, spouse, dependent children, dependent parents
Grievance owner	Broker	Broker, including for vendor-supplied algos

The threshold is a design parameter, not a badge

Ten orders per second is an exchange-set number that the exchange may change, and it is measured per exchange and segment rather than across the client’s whole activity. Two design mistakes follow. First, do not hard-code it: read it from configuration so an exchange revision is a settings change rather than a release. Second, do not let a client cross it by accident — a retry loop, a basket order fanning out, or a naive cancel-replace pattern can breach the rate without the client intending anything algorithmic. Warn at a margin below the threshold and throttle rather than letting the breach become a registration failure.

3. Activation walkthrough

1. Client requests programmatic access. The broker establishes what the client intends: a personal script, a vendor platform, or a hosted strategy. The three have different registration and hosting consequences, so this is a real question rather than a checkbox.
2. Eligibility and disclosure. The client’s existing segment activations bound what the API can reach — an API key does not create derivatives entitlement, which comes from the segment activation covered in F&O activation. Risk disclosures for automated order entry are presented and recorded.
3. Static IP registration. The client supplies the static IP from which requests will originate. NSE’s implementation standards tie whose IP is required to who generated the algo, allow one change per week, and confine sharing to the family boundary. A client on a domestic dynamic connection has to solve this before anything else works.
4. Key issuance. The broker issues a client-specific or vendor-specific key with OAuth-based authentication and two-factor authentication on the login flow. Keys are not transferable, and non-registered algo activity is confined to a single predefined key.
5. Algo registration, if applicable. For a client crossing the threshold, the broker submits the registration to each exchange the client trades on, and the exchange issues the unique identifier that will be stamped on the orders. White-box algos disclose their logic; black-box algos carry the additional research-analyst obligation on the provider’s side.
6. Tagging verification. Before live use, confirm that orders carry the correct identifier and that the identifier digit and the algo-identifier field agree — a mismatch is a pre-emptive rejection at the exchange rather than a warning.
7. Ongoing hygiene. Daily API logout, key rotation on any suspicion of compromise, and revocation on client request or on the broker’s risk trigger. The kill path must work: the broker has to be able to stop a client’s automated order flow without stopping the client’s ability to square off.

3.1 Field-level view of the access record

name	type	length	mandatory	source-system	destination-system(s)	notes
client_code	string	varies	yes	Client master	Order management, exchange	The existing trading code; API access never creates a new identity
api_app_name	string	varies	yes	Client request	Broker developer console	One application per intended use; not a display alias
api_key_id	string	varies	system	Broker key service	Client, order management	Client-specific or vendor-specific; never shared or reissued to another party
api_secret_reference	string	varies	system	Key service	Secure store only	Never rendered in support screens or logs
auth_mode	code	varies	yes	Broker configuration	Order management	OAuth-based authorisation flow with mandatory two-factor authentication
static_ip	string	15	conditional	Client declaration	Broker whitelist, exchange records	One change per week under the NSE standards; family-scoped sharing only
originator_type	code	varies	yes	Activation workflow	Registration record	Client-generated, vendor-supplied or broker-provided; drives whose static IP applies
algo_registration_status	code	varies	conditional	Exchange	Client status screen	Applied, registered, rejected; per exchange, not global
exchange_algo_id	string	varies	conditional	Exchange	Order tags, audit trail	The unique identifier stamped on every order from the registered algo
algo_type	code	varies	conditional	Registration	Surveillance, audit	White-box or black-box; black-box carries the provider’s research-analyst obligation
ops_limit_configured	integer	varies	yes	Broker risk configuration	Order gateway	Client-level order-rate cap, set at or below the exchange threshold
kill_flag	flag	1	yes	Risk desk	Order gateway	Stops automated flow; must not block a manual square-off

Field names are the semantic labels a broker’s integration layer typically carries rather than an exchange-prescribed schema; verify against the current exchange file and API specifications before building. [AI inference — verify before acting]

Never surface a secret in a support tool

The single most damaging design error in this area is an internal support screen that can display an API secret so an agent can “help the client”. Secrets belong in a store the support path cannot read; the support path should be able to revoke and reissue, never to reveal. The same rule applies to logs, screenshots in tickets, and any customer-facing error message that echoes a request header.

4. Rate limits, order-to-trade ratio and rejection

Three different limits act on an API client, and conflating them produces support answers that are confidently wrong.

The order-rate limit is the orders-per-second ceiling the broker enforces at its gateway. It exists to protect the broker’s own connection and to keep the client below the registration threshold when the client is not registered. It is a broker parameter.

The order-to-trade ratio is a surveillance measure at the exchange: too many orders per executed trade attracts a per-order charge, escalating through slabs, with cooling-off for repeat breaches. The 2020 framework set the original slabs; the February 2026 revision, effective 6 April 2026, lets exchanges set steeper ones and takes near-the-money options and designated market-maker algo orders out of the computation. A client running a quoting strategy will meet this before they meet anything else.

Pre-emptive rejection is not a limit but a validation. Algo market orders are rejected pre-emptively in the segments where that control is live, and an order whose identifier digit disagrees with its algo-identifier field is rejected at the gateway. Clients read these as outages; they are working controls, and the error mapping should say so in words a developer can act on.

5. Alternatives

Client need	Option A	Option B	When to pick which	Who uses what
Automate a personal strategy	Own code against the broker’s API	Vendor platform empanelled with the exchange	Own code for control and no third-party dependency; vendor platform to avoid hosting, registration and compliance work	Developer-clients versus strategy-subscribers
Stay below the threshold	Throttle deliberately and keep to one predefined key	Register the algo and accept the tagging	Throttling when the strategy genuinely does not need the rate; registration when it does	Occasional automation versus systematic traders
Hide proprietary logic	Black-box algo through a provider	White-box execution algo	Black-box only where the provider accepts the research-analyst obligation; white-box for everything else	Vendors versus execution-focused clients
Run strategies for others	Not available on retail API	A registered intermediary route	The family boundary is a hard limit; anything wider is a different regulated activity	—
Data only, no orders	Market-data subscription	Full trading API	Data-only where the client is researching; trading API only when orders will actually be placed	Analysts versus traders

Practical notes

• [gotcha] A static IP requirement collides with reality for retail clients on consumer broadband. The one-change-per-week rule in the NSE standards means a client whose IP moves cannot simply keep updating it. Expect a support pattern here, and document the cloud-hosting route rather than improvising per client.
• [gotcha] Segment entitlement and API entitlement are independent. A client with an API key and no derivatives activation will get order rejections that look like API faults. Map exchange rejection codes to plain causes in the API error payload, or your support queue becomes the mapping layer.
• [risk trade-off] Multiple API keys are allowed and are good hygiene — one per application, revocable independently. They also multiply the surface a compromise can use. Cap the number, show last-used timestamps, and expire dormant keys. [industry practice — unverified]
• [industry practice] Brokers that publish the exact threshold, the current order-rate cap and the rejection-code mapping in developer documentation report materially fewer registration surprises than brokers that treat the numbers as internal. The rules are public; the configuration should be too. [industry practice — unverified]
• [gotcha] Daily API logout is a requirement, not a convenience. A client whose process assumes a permanent session will break at the reset boundary. Say so in the quick-start, not in a footnote.
• [risk trade-off] The kill path is the control a regulator will ask about after an incident. It must be exercisable by the risk desk within the session, must be logged, and must leave the client able to close positions. A kill switch that also blocks square-off converts a client’s problem into the broker’s exposure.
• [AI inference — verify before acting] The order-to-trade ratio revision’s clause-level figures, and NSE’s 2026 circulars in this area, were not confirmed from primary documents in this pass. Check the exchange’s current circular listing before quoting a slab or a penalty to a client.

Cross-references

• Retail algo framework deep dive — broker-side approval, categorisation, vendor empanelment and the audit trail an inspection will open
• OMS internals — where order tagging, throttling and rejection actually happen
• Surveillance norms, GSM and ASM — the surveillance overlay that automated flow attracts
• System audit — the audit regime covering trading software and API infrastructure
• CSCRF deep dive — the cyber-resilience obligations that key management and authentication sit inside
• Security and compliance architecture — secret handling and access control in the platform design
• F&O activation — the segment entitlement an API key cannot substitute for
• Trading preferences — where segment choices are captured at onboarding
• Compliance blueprint — the obligation rows this framework adds
• Circulars — NSE — implementation standards, operational modalities and pre-trade controls

Verified through

2026-09-11

---

AI-generated and not legal, financial, or compliance advice. See the project README for full disclaimer.