The console where a broker governs everything that happens

Why does a broker need its own console?

Because under the framework the broker carries the responsibility, and responsibility without an operating surface is unmanageable. 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.

A vendor that accepts that allocation and then gives the broker no way to see or stop what is happening has handed them a liability with no controls. The console exists so the party who answers for the orders is the party who can approve, throttle and halt them.

The operating surfaces

Module availability depends on tenant configuration, plan entitlements, connector readiness and deployment policy.

What does the approval queue actually gate?

Activation. A strategy that has been built, validated and backtested is not live. It is pending, and a broker reviewer decides whether it proceeds. The dashboard surfaces the queue, the oldest pending item, and the rejection context for anything refused.

That gate is where broker-defined eligibility and policy are applied, and it is the reason activation is not a client-side action. A strategy can be excellent and still be refused because the account lacks a segment permission, the exposure would breach a cap, or the tenant does not permit the instrument class.

Refusals carry their reason and are retained. An approval workflow that records only what was approved leaves the more interesting half of the record missing.

How does algo authorization relate to exchange registration?

It is the operational side of it. Under NSE/INVG/67858 an algorithm placing more than 10 orders per second per exchange and per segment must be registered with the exchange, which assigns the identifier that every algorithmic order then carries.

The broker registers; the exchange assigns; the console is where that identifier is administered and attached, and where the live execution snapshot shows client and algo identifiers side by side. That pairing is what makes an order traceable to a registered algorithm during an inspection rather than merely logged.

A vendor cannot register anything, because a vendor has no route to the exchange. What the console does is make registration and tagging operationally possible and visible.

Who administers users and publishers?

The broker. User administration, Research Analyst verification and role activation, notification policy, strategy templates, custom indicator governance, AI configuration, terms acceptance and invite codes all sit inside the broker's own console.

Research Analyst administration is the most important of these. Broker or admin teams create the profile, capture declarations, review registration documents, and activate the role with an audit event, and can suspend, reject or deactivate it afterwards. Registration alone does not create publication authority.

AI configuration is where a tenant's own provider credentials are governed, so a broker can satisfy its own AI-governance policy rather than inheriting an arrangement with a third party it never evaluated.

What can be stopped, and how fast?

New F&O exposure, at global, tenant or strategy scope, through HALT-NEW, which fails closed if its state cannot be verified and leaves expiry handling, fill processing, reconciliation and eligible exit workflows running.

Blocking entries while keeping exits available is the only asymmetry that reduces risk during an incident. It requires no deploy and no strategy-code change, which is the property that matters when the decision is being made under pressure.