Start a project
ServicesWorkPartnersAboutBlog Contact Start a project

Regulation ·

What SEBI’s rules actually require of a stock broker’s technology function

Every circular here fixes a number some system has to meet — two hours to notice a fault, 1.5 times the quarterly peak, eight years of records. This is what those numbers mean for how an estate is built and run.

India's securities regulator does not publish an architecture guide. It publishes circulars, and each one, read closely, fixes a number some system in a broking house has to meet: how long you have to notice a fault, how much spare capacity you hold, how long a log survives, how quickly a second site carries the load. What follows is a reading of the instruments that currently bind a stock broker's technology function, written by engineers rather than lawyers. It is not legal advice. Your compliance officer owns the interpretation and the filings; our concern is the estate that has to make the interpretation true.

The five instruments, and which of them binds you

Most of the technology obligation on an Indian broker sits in five documents rather than one. Two changed in January 2026, which is enough to make an older summary wrong in its numbers.

Read them in the order a fault travels: something breaks and you have to notice it and say so; you should have made it less likely and be able to carry on without it; you have to prove afterwards what happened; and the vendor contract has to have been written so that none of the above quietly became somebody else's problem.

The technical glitch framework

Circular SEBI/HO/MIRSD/TPD-1/P/CIR/2022/160 of 25 November 2022, effective 1 April 2023, set the reporting, capacity and recovery regime for brokers' electronic trading systems. The review of 9 January 2026, circular HO/38/44/12(1)2026-MIRSD-TPD1, narrowed who it applies to and relaxed the first reporting deadline.

The Cybersecurity and Cyber Resilience Framework

Circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 of 20 August 2024 replaced the entity-by-entity cyber circulars with one framework covering nineteen categories of regulated entity, stock brokers among them. Its compliance date has passed.

The Stock Brokers Regulations, 2026

Notified 7 January 2026 under F.No. SEBI/LAD-NRO/GN/2026/291. Regulation 18 requires risk management systems, cyber security arrangements as prescribed, and compliance with the outsourcing guidelines. Regulation 16 sets retention of the records under regulation 15 at a minimum of eight years.

The system audit framework

SEBI's Stock Broker System Audit Framework sets who is audited, how often and by whom. Cadence follows what you run rather than how large you are.

The outsourcing guidelines

Circular CIR/MIRSD/24/2011 of 15 December 2011 governs what an intermediary may hand to a third party. It is the oldest document here and the one most often absent when a vendor contract is signed.

Two hours is a detection requirement, not a reporting one

The revised framework gives a broker two hours from the occurrence of a technical glitch to inform the exchange and its clients. Read that as a statement about monitoring, because a human happening to notice is not fast enough to build on.

The January 2026 review applies the framework to brokers offering internet-based or wireless trading with more than 10,000 registered clients, excluding closed accounts, as at 31 March of the previous financial year; SEBI's press release, PR No. 04/2026, says this takes roughly 60% of brokers out of it. Under the review the broker informs the exchanges and its clients within two hours of occurrence, up from one hour in 2022, with a preliminary incident report at T+1 and a root cause analysis within fourteen working days.

The clock starts at occurrence, not at discovery, and that is the whole engineering content of the clause. If the first person to know is a client on the telephone, an unknown part of the window has gone before it became visible to you, and more goes to somebody deciding whether this is serious. What the clause demands is that a degradation announces itself: synthetic transactions running continuously against the login, order-entry and position paths rather than a dashboard someone opens; alerts that reach a person who is awake and authorised; and a named owner of the decision to notify.

The fourteen-working-day analysis is retrospective, which makes it harder than it looks. You cannot reconstruct a cause from logs you were not keeping, at a resolution you did not choose in advance, from machines whose clocks disagreed.

A timeline of SEBI's technical glitch clock with four marks. Occurrence sits at time zero. Informing the exchanges and your clients falls within two hours. A preliminary incident report is due at T plus one. A root cause analysis is due within fourteen working days. The first segment is drawn dashed, with a bracket beneath it, because detection time — the gap between the fault occurring and anyone noticing — comes out of the two-hour window.
Deadlines under the revised technical glitch framework, which applies to brokers offering internet-based or wireless trading with more than 10,000 registered clients. The segments are not drawn to scale; each deadline runs from occurrence.

Capacity and failover are stated as numbers somebody has already chosen

Installed capacity of at least 1.5 times the observed peak load, alerts before utilisation passes 70% of installed capacity, a recovery site at least 250 kilometres away, and a drill that runs a full trading day from it.

Peak load under the 2022 circular is the highest peak observed during a calendar quarter, so the figure you build against is a quarterly maximum, not a daily average. On a broking estate those differ enormously: load stacks at the open, at the close, on expiry and on the days volatility spikes. You cannot assert the multiple without measuring the peak, so capacity telemetry has to survive long enough to establish a quarterly maximum and be attributable to a component rather than to the system in general. And the 70% alert is not a figure to note in a report: the interval between 70% and saturation on a trading day is measured in minutes.

On failover, the clearest published numbers are not the broker ones. The standard operating procedure for market infrastructure institutions, circular SEBI/HO/MRD1/DTCS/CIR/P/2021/590 of 5 July 2021, requires a disaster to be declared within thirty minutes of disruption of a critical system, with a recovery time objective of forty-five minutes for restoring critical systems including from the recovery site. Those figures are not yours, but neither leaves room for a bridge call. Thirty minutes to declare means failing over cannot be a deliberation: the authority sits with someone in advance, the criteria are written before the day they are needed, and the act is rehearsed by the people who will be on shift.

For brokers the 2022 circular sets the 250-kilometre separation and the full-trading-day drill. The distance is a statement about correlated failure — a second site on the same grid, flood plain and fibre route is not a second site. The drill is the more valuable half, because it is the only test that exercises the parts which quietly do not fail over: the batch writing to a path only the primary has, the integration whose allow-list names one address, the certificate installed once. We found no SEBI-stated recovery time or recovery point objective for brokers; those sit with the exchanges, as does the rationalisation of capacity planning and drill frequency the January 2026 review directs.

Logs are evidence, and each kind runs on its own clock

Three retention periods apply to three different things and they are not interchangeable. Confusing them is the common way a defensible incident becomes an indefensible one.

The 2022 circular's logging and monitoring mechanism is API-based: specified brokers monitor key system and functional parameters, the exchanges monitor the same parameters independently, and both preserve the logs for thirty days in the normal course and two years where a glitch has occurred. The Stock Brokers Regulations, 2026 set retention of the records under regulation 15 at a minimum of eight years. CSCRF requires a documented log collection and retention policy; we did not find a period stated for brokers in the framework text, which is a reason to ask rather than assume.

So retention is a property of a class of record, decided once and enforced by the system, rather than a habit. The thirty-day to two-year transition is triggered by an event, so retention must be extensible for a set of logs after the fact — a legal hold, in effect — which is impossible if rotation has already destroyed them. An eight-year record cannot live only in the format the vendor's current version writes, because somewhere inside eight years the schema changes and a record nobody can read has not been preserved. Immutability is the part nobody asks for until an audit does: logs the administrators of the audited system can edit are worth less than logs shipped promptly to storage they cannot write to. Clocks matter for the same reason — a timeline from machines that disagree by ninety seconds cannot establish an order of events, and an order of events is what a root cause analysis is.

CSCRF sorts you into a class, and the class sets the workload

The framework is graduated. Which obligations you carry depends on a category you compute from your own numbers, and the computation itself changed in April 2025.

Circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/60 of 30 April 2025 categorises stock brokers on two parameters, total registered clients and annual clientele trading volume, with the higher of the two categories applying where they disagree. Brokers above ten lakh clients or ten lakh crore rupees of annual clientele trading volume fall in the Qualified class, and the bands step down through mid-size and small-size to self-certification; brokers under a thousand registered clients and under a thousand crore of clientele trading volume in a year are exempt from CSCRF altogether.

The dates have passed, worth saying plainly because much secondary writing still describes them as upcoming. The framework set 1 January 2025 for categories that already had a cyber circular and 1 April 2025 for the rest; the clarification of 31 December 2024 moved KYC registration agencies and depository participants to 1 April 2025 and kept data localisation in abeyance until further notification, and we found no later notification restoring it; the circular of 28 March 2025 then extended compliance to 30 June 2025 for all regulated entities except market infrastructure institutions, KYC registration agencies and qualified registrars.

What costs engineering time rather than paperwork is the audit cadence and the closure clock. Cyber audit runs at least twice a year for market infrastructure institutions and Qualified entities, and equally for mid-size and small-size entities providing internet-based or algorithmic trading; at least once a year for the rest. Penetration testing runs at least twice in the financial year, once in each half, for entities identified as protected systems or critical information infrastructure, and at least once for the rest, with findings closed within three months of the report. Three months to close makes patching a pipeline with a queue, an owner and a measured cycle time, and it forces a test environment to exist: a broker cannot validate a patch on a live trading system, and cannot wait for a quiet week that never arrives.

The trading day is the constraint on every change these rules require

None of the above can be satisfied by a system that can only be changed at a time when it must not be changed. The session is fixed and public, which makes change control load-bearing rather than administrative.

This is the argument the BrokerHive programme makes without naming a circular: the trading day is the maintenance window, inverted. The instruments add deadlines that assume you can change things. Patching carries the three-month closure clock. System audit findings carry their own — report and management comments to the exchange within one month of the auditor submitting it, time-bound corrective action within three months, a follow-on audit within six. Cadence follows what you run: half-yearly where algorithmic trading is used or offered to clients, annual for brokers using computer-to-computer link or intermediate messaging layer facilities above the stated size or who are also depository participants, once in two years otherwise.

So there are deadlines that assume change and a session that forbids it. The resolution is not heroic weekend work, which fails precisely when volumes are high enough to matter. It is that the pipeline gets built: an environment close enough to production that a passing test means something, a deployment whose rollback is the rehearsed path rather than the theoretical one, and a change record that exists because the pipeline wrote it. SEBI's advisory of 5 May 2026 on emerging AI tools for vulnerability detection says much the same: patch immediately for known vulnerabilities, carry documentation, impact analysis, testing and secure deployment through every system change, and keep API inventories current with authentication, rate limiting and allow-list based connections.

Most of the estate is software you cannot change, and the obligation does not care

The trading terminal, the back office, the risk system and the surveillance tooling are usually licensed from specialist vendors. Every deadline above attaches to the broker regardless of who wrote the code.

The two-hour notification is owed by the broker even when the fault sits inside a vendor's component. The logging and monitoring mechanism requires key system and functional parameters to be exposed, which means obtaining them from products you did not write and cannot instrument from the inside. The capacity multiple has to be demonstrated for a stack whose internal limits the vendor may never have published.

The January 2026 review helps, in that glitches arising outside the broker's own systems and those with negligible impact are exempted. But notice what claiming that exemption requires. To show a fault was outside your systems you have to establish where the boundary was and what crossed it, at the time it happened, and that capability is built before the incident: independent measurement at each seam, request identifiers that survive a hop into a vendor product, and timing recorded on your side of every integration rather than accepted from theirs. So the work sits at the boundaries. Monitor the vendor product from outside, because you cannot monitor it from within. Keep your own record of what you sent and what came back. Reconcile continuously rather than overnight. Where a seam turns out to be structural the missing component is usually small and worth building, and that is where data engineering improves compliance posture more than a tool purchase will.

Accountability does not transfer, so write the contract as though it does not

SEBI's outsourcing guidelines are unusually direct. Core business activities and compliance functions may not be outsourced at all, and for everything that may be, the intermediary stays liable as though the work were done in-house.

Circular CIR/MIRSD/24/2011 says intermediaries shall not outsource their core business activities and compliance functions, naming execution of orders and monitoring of clients' trading activities among the examples of what is core for a broker. For the rest, the intermediary is fully liable and accountable for the outsourced activity to the same extent as if the service were provided in-house, and liable to investors for loss caused by the third party's failure. SEBI's FAQ on CSCRF carries the idea into cyber: regulated entities are solely accountable for all aspects of third-party services and responsible for their vendors' violations. The Stock Brokers Regulations, 2026 restate the obligation at regulation 18(8).

So a vendor contract has to buy evidence, not only service. The 2011 guidelines require the contract to let the intermediary, and the regulator or persons authorised by it, inspect and access all books, records and information relevant to the outsourced activity; to carry unambiguous confidentiality clauses covering proprietary and customer data during the contract and after its expiry; to specify the third party's responsibilities for IT security, contingency plans, business continuity and disaster recovery; and to provide for termination, transfer of information and an exit strategy. Read as clauses to insist on, that is short and testable.

  • Access to logs and configuration during an incident, within a stated period, without a commercial negotiation first.
  • The vendor's own recovery objectives written as numbers, and the right to observe a drill rather than be assured that drills occur.
  • Log and telemetry export in a documented format, so an eight-year record does not depend on the vendor's current version being readable.
  • Notification of the vendor's own security incidents and of vulnerabilities in components they ship you, inside a window useful against a three-month closure clock.
  • Exit that returns your data in a usable form, with a defined transition period, agreed while you still have leverage.

Where AI belongs in this estate, and where it must not

This is published by an AI engineering firm, so read the exclusion first. No model belongs in the order path, the execution path, the risk checks or the margin calculation.

Those functions are deterministic by requirement: the answer must be identical every time, reconstructable to the paisa, and wrong in ways a person can trace back to a rule. A system that is right almost always is the wrong component for an action that cannot be withdrawn, and the framework above assumes a root cause analysis within fourteen working days — a much harder promise when the cause is a probability distribution. This is the position BrokerHive already takes, and reading the regulation has not softened it.

SEBI's own use of AI here is instructive, and it is entirely defensive. The May 2026 advisory asks regulated entities to include AI-based threat scenarios in periodic cybersecurity risk assessments, to direct application vendors to assess the risk arising from AI-driven vulnerability detection, to monitor vigorously through the security operations centre with automated response playbooks, and to expedite onboarding to the market SOC. The premise is that flaws are found faster than they used to be, and the answer is faster, better-instrumented defence.

What is left on the business side sits away from the money. Client onboarding is a document problem, where structured extraction returns fields with page-level provenance and a confidence score and routes low-confidence cases to a human queue. The support queue is a language problem, mostly repeated questions about payouts, statements, margin and account status. Internally the higher-value application is an answer desk over your own circulars and process notes, built so every answer cites the paragraph it came from and refuses when it is unsure. The reasoning behind the citation and refusal requirements is set out with sources on our BFSI page. None of it reduces an obligation; it reduces the manual work around obligations, which is a smaller and more honest claim.

Sources

Every regulatory or measured claim above is attributed here. Where we could not find a source we trust, the sentence says so instead of guessing.

Questions people ask about this

We have fewer than 10,000 clients. Does the technical glitch framework still apply to us?

On the face of the review circular of 9 January 2026 the framework applies to brokers offering internet-based or wireless trading with more than 10,000 registered clients, excluding closed accounts, as at 31 March of the previous financial year, and SEBI's press release says roughly 60% of brokers fall out of it. Confirm your own position with your compliance officer and your exchange rather than with this page. The reasons for building to those numbers do not disappear with the deadline: clients and exchanges behave as though an outage matters regardless of headcount.

Has the CSCRF compliance date passed?

Yes. The framework set 1 January 2025 for entity categories that already had a cyber circular and 1 April 2025 for those covered for the first time, and the circular of 28 March 2025 extended compliance to 30 June 2025 for all regulated entities except market infrastructure institutions, KYC registration agencies and qualified registrars. The recurring obligations are periodic rather than one-off: audits, penetration testing and vulnerability closure all run against the financial year.

Can we outsource the technology function entirely?

Not entirely, and not in the way the question usually means. SEBI's 2011 outsourcing guidelines say core business activities and compliance functions shall not be outsourced, naming execution of orders and the monitoring of clients' trading activities among the examples for brokers. For what may be outsourced, the intermediary stays fully liable and accountable as if the service were provided in-house. You can delegate the work and not the answerability, which is why the contract has to give you access, evidence and an exit.

Is any of this legal advice?

No. It is an engineering reading of public instruments, written to explain what they imply for how systems are built, monitored and changed. Every date and figure is attributed to a document we fetched, and where we could not verify something the text says so rather than guessing. Your compliance officer owns the interpretation and the filings, and where a sentence here and your compliance officer disagree, they are right.

Related

Where this connects

AI Engineering

Data Engineering for AI

The pipelines and quality layer every AI project stalls on.
AI Engineering

Custom Software Development

Line-of-business systems built to your process, owned outright by you.
AI Engineering

AI Consulting & Readiness Assessment

A paid diagnostic that tells you what is worth building and what is not.

Read next: What the DPDP Act actually requires of an AI system · RBI data residency and calling an external LLM

More notes on the blog index, and the practical questions about cost, IP and data residency are on the FAQ.

Bring the circulars and the estate to the same table

A scoping call is free, and for a broking house it usually starts with what is actually monitored, what a restore has proved rather than scheduled, and where the evidence would come from if a report fell due in fourteen working days. Some of these end with a short list your own team can work through without us.

Start a conversation See our work