Algo Authorization
Algo authorization, exchange identifiers and order tagging
Algo authorization is the broker-console surface that carries an algorithm from registration to a tagged order. The broker registers with the exchange, the exchange assigns the identifier, and the console administers that identifier and attaches it to every algorithmic order. This is what makes an order traceable to a registered algorithm rather than merely logged.
Software infrastructure only. No investment advice, no brokerage services, no guaranteed returns.
01 · Client experience
Broker digital channels
02 · The governed layer
Stretus AI Strategy Infrastructure
03 · Execution authority
Broker execution environment
What does the framework actually require here?
NSE circular NSE/INVG/67858 of 5 May 2025 requires an algorithm placing more than 10 orders per second, per exchange and per segment, to be registered with the exchange, and requires every algorithmic order to carry the unique identifier the exchange assigns.
Both halves matter and they fail differently. An unregistered algorithm above the threshold is a registration failure. A registered algorithm whose orders arrive untagged is a traceability failure, the algorithm is authorised but nobody can prove which orders it produced, which is the half an inspection actually tests.
Who does what?
The broker registers, the exchange assigns, and the platform administers and attaches. A vendor cannot register anything because a vendor has no route to the exchange, under the framework an algo provider is empanelled by the broker and treated as the broker's agent.
So this surface sits in the broker console rather than in the client workspace, and deliberately so. Registration is a broker action with a regulator-facing consequence, and a platform that let a client self-serve it would have moved a broker obligation into a place the broker cannot supervise.
The threshold, and the three ways teams get it wrong
| Misreading | What the rule actually says |
|---|---|
| One global orders-per-second counter | Per exchange AND per segment, equities and derivatives count separately, so a single aggregate limiter measures something the rule does not describe |
| Averaging over a window | The conservative reading is the peak. Forty orders in one second then nine quiet seconds averages four and peaks at forty; a regulator reads forty |
| Assuming iceberg legs are one order | Genuinely unsettled. Whether disclosed legs count individually changes whether a strategy crosses the line, so obtain it from the broker in writing rather than inferring |
The threshold is exactly 10 orders per second per exchange and per segment, per NSE/INVG/67858 of 5 May 2025.
What does the console show?
Which algorithms are authorised, the identifiers they carry, and, in the live execution snapshot, client and algo identifiers side by side against current activity.
That pairing is the operational point of the whole surface. An order row that shows a client identifier without an algo identifier cannot be attributed to a registered algorithm, and an algo identifier without a client identifier cannot satisfy the requirement to identify the actual end user. Both together are what a reconstruction needs.
How does this interact with the approval queue?
They are separate gates and both apply. Authorization establishes that an algorithm is registered and identifiable; approval establishes that a specific strategy is permitted for a specific client, account and segment. Passing one does not imply the other.
Keeping them distinct is what allows a broker to authorise an algorithm class once and then govern individual activations continuously, rather than re-litigating registration every time a client builds something.
What happens below the threshold?
Registration is not triggered, but identification and traceability still matter, and the audit obligation applies regardless of order rate. A strategy placing two orders a day still has to be attributable to an actual user for at least five years.
Building the tagging path only for high-frequency strategies is therefore a false economy: the retention and identification requirements do not scale with rate, and retrofitting attribution across a live book is considerably harder than carrying it from the start.
Surfaces
What each surface does
The product surfaces this page covers, named as they appear in the application.
Ownership boundaries
Where Stretus sits in the stack
Benefits
Business benefits
Traceable to a registered algorithm
Every algorithmic order carries the exchange-assigned identifier, so attribution is a lookup rather than a reconstruction.
Client and algo identifiers paired
The live snapshot shows both together, which is what an inspection needs and what a single identifier cannot provide.
The threshold handled correctly
Per exchange and per segment rather than as one global counter, with peak rather than average as the measure that counts.
A broker action, in a broker surface
Registration stays where the obligation sits, rather than being exposed to clients who cannot answer for it.
Use cases
Enterprise operating situations
Illustrative operating situations. Availability varies by broker, exchange, account, connector and tenant.
- Challenge
- Reconstruct which registered algorithm produced a specific order eleven months ago.
- Stretus role
- Attach the exchange-assigned identifier at order time and retain it with the actual user identity.
- Outcome
- A lookup that resolves in minutes instead of a multi-week reconstruction.
- Challenge
- Establish whether a client's strategy crosses the registration threshold.
- Stretus role
- Evaluate order rate per exchange and per segment, on peak rather than average.
- Outcome
- A registration decision that matches how the rule is written.
Security posture
Security considerations
- Identifiers are administered, not client-editable
- Algo identifiers are managed in the broker console. A client cannot assign, alter or remove the identifier attached to their orders.
- Attribution to an actual user
- Per NSE/INVG/67858 of 5 May 2025 the record identifies the end user and user ID rather than the integration that submitted the order.
- Authorization changes are audited
- Granting, altering or withdrawing an authorization is recorded as an audit event alongside approvals and role changes.
Answers
Frequently asked questions
Can Stretus register an algorithm with the exchange on our behalf?
No. Registration is a broker action with the exchange, which assigns the identifier. Under the framework an algo provider is empanelled by the broker and treated as its agent, and has no route to an exchange. What the platform does is make registration and per-order tagging operationally possible and visible.
What is the exact threshold?
More than 10 orders per second, per exchange and per segment, per NSE circular NSE/INVG/67858 of 5 May 2025. It is not a single global figure, equities and derivatives count separately.
Do disclosed iceberg legs count individually?
This is genuinely unsettled and we will not pretend otherwise. It changes whether a strategy crosses the threshold, so it is worth obtaining in writing from your broker rather than inferring from the circular.
What happens if an authorization is withdrawn?
New activations relying on it stop being eligible, and the withdrawal is recorded as an audit event. Existing positions are a separate question governed by the execution controls, blocking new exposure while leaving eligible exits available is the asymmetry that applies here as elsewhere.
Does a low-frequency strategy need any of this?
Registration is not triggered below the threshold, but identification and the five-year audit obligation apply regardless of order rate. Building tagging only for fast strategies means retrofitting attribution later across a live book.
Ecosystem
Related capabilities
Broker Console
Deployment control, algo authorization, execution control, risk and exposure, order monitoring and audit governance, the broker's own operating surface.
Monitoring & Observability
Strategy health, order monitoring, latency, exceptions and connected audit evidence, retained for at least five years and identifying the actual user.
Broker Integration
Integrate a governed strategy layer into existing broker journeys while identity, entitlements, risk policy, OMS/RMS and market access stay broker-owned.
Arrange a working demonstration
Review strategy creation, F&O contract handling, backtesting, broker controls and integration boundaries with the team. If you would rather talk to an engineer than a salesperson, say so and we will arrange that instead.
Risk and disclosure
Trading and derivatives involve risk of loss. AI output requires review. Backtests and simulations do not predict future results; live outcomes can differ because of costs, latency, slippage, liquidity, rejections, broker rules and market conditions. Availability varies by broker, exchange, account, connector and tenant. Product information only; not investment advice.