API-led integration that leaves the broker in control

What does a broker actually have to give up?

Nothing that matters. Brand, client relationship, identity, entitlements, risk policy, OMS/RMS and market connectivity remain broker-owned. Stretus occupies one layer, strategy creation, validation, testing, activation, monitoring and governance, and has no exchange connectivity of its own.

This is the first question in every broker conversation and it deserves a structural answer rather than a reassuring one. The boundary is not a policy commitment that could be revised; it is the shape of the system. Orders leave through the broker's own connection, under the broker's own exchange membership, using credentials the client authorised.

Deployment ownership, column by column

The shared column is where integration work concentrates, and it is the one worth scoping first.

Where does this sit inside the regulatory framework?

SEBI's circular of 4 February 2025 on safer participation of retail investors in algorithmic trading, extended by circular SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/132 of 30 September 2025, became applicable to all stockbrokers on 1 April 2026. It places the broker at the centre of API-based algo access, with exchange-defined procedures for registration, identification, traceability and approved connectivity controls.

Under that framework an algo provider is empanelled by the broker and treated as the broker's agent, and cannot connect to an exchange directly. NSE circular NSE/INVG/67858 of 5 May 2025 states that brokers are fully responsible and liable for all orders emanating through their IBT, STWT, Client API and Vendor API systems.

Broker and exchange procedures remain authoritative for each production rollout. That sentence is not a hedge. It is the rule that actually applies, and any vendor telling you their integration overrides it has not read the circular.

What does the connector layer cover today?

Implemented Indian broker adapters include Upstox, Zerodha, Angel One and Dhan. Production availability for any given deployment depends on the broker API, account and segment permissions, credentials, instrument coverage, and deployment approval.

An implemented adapter and a live route are different facts, and the distinction is worth being precise about. Implemented integration paths do not imply universal live certification. F&O rollout in particular remains broker-, segment-, catalogue-, account- and tenant-dependent, and BSE F&O requires additional enablement.

Third-party names are shown only for identification and do not imply endorsement.

What does the integration require operationally?

Client and account mapping, scoped API credentials, an approved endpoint set, and, where required, broker-whitelisted static IPs. Each deployment establishes its own topology, capacity targets, security boundaries, observability, rollout phases and operating ownership.

The static IP requirement carries a constraint teams routinely discover late. Under NSE/INVG/67858 a client's mapped addresses may be updated at most once per calendar week, with secondary addresses permitted for redundancy. Any failover design that assumes an address can be re-registered reactively does not hold up against that rule, so registration and failover have to be planned together rather than sequentially.

What if a broker has no client-facing API today?

Then the project is not "add a strategy layer". It is a larger piece of work with a different timeline, and it should be scoped that way at the start.

Framed honestly at the beginning, that is a bigger and better project. Discovered in week six of a proof of concept, it becomes a failure attributed to the vendor, and fairly. Naming it early is the more useful thing to do even when it slows a conversation down.