What the IFSCA Algorithmic Trading Guidelines Mean for IFSC Broker-Dealers, RTPs and Exchanges

What IFSCA has published

IFSCA's 16 October 2026 Guidelines for Algorithmic Trading on the Stock Exchanges, circular IFSCA/CMD-DMIIT/ALGO/2026-27/01, set requirements for IFSC exchanges and market participants.

The subject matter is stated plainly: testing of trading algorithms, risk controls around algorithmic order flow, and auditability — of the algorithms themselves and of the connectivity that carries their orders to the exchange. For a broker-dealer, a Remote Trading Participant (RTP) or an exchange operating in an IFSC, that combination touches engineering, operations, compliance and internal audit at the same time.

Scope: IFSC exchanges, broker-dealers and RTPs

The guidelines apply to IFSC exchanges, broker-dealers and RTPs. They are not addressed to every broker registered in India, and firms outside the IFSC should not read them across by default. Conversely, a firm inside the IFSC that had assumed algorithmic trading guidance was a domestic-market matter now has a specific document to answer.

Three scope questions are worth settling before anything else: whether each algorithm you deploy or facilitate is caught; what facilitation means in practice for an exchange's onboarding and connectivity arrangements; and which entity in a group carries the obligation where technology and trading sit in different legal entities.

Two clocks: three months and immediate effect

Paragraph 12 gives exchanges three months from issuance to ensure initial conformance testing, if not already undertaken, of systems already deploying, offering or undertaking algorithmic trading. Paragraph 45 gives exchanges three months for the specified implementation steps. Paragraph 46 brings the circular into force immediately.

The guidelines are in force, with a three-month implementation period for the specified activities. The practical task is to map your own obligations to the paragraph governing each one, and identify the applicable transition provision. Where the allocation is not clear on a first reading, record the interpretation you have adopted and the reasoning behind it; that record is itself part of the audit trail.

The annual system audit: paras 36 to 40

Paragraphs 36–40 require an annual system audit of a market participant's algorithmic trading system. For broker-dealers it forms part of the system audit specified in the applicable master circular; exchanges may set RTP terms of reference. The auditor must hold CISA, DISA, CISM or CISSP, or have at least ten years' experience auditing algorithmic trading systems. An auditor may conduct at most three successive audits, followed by a two-year cooling-off period before reappointment. Findings must be reported immediately on completion and no later than one month from completion; corrective action is immediate and the closure/compliance report is due within two months from completion.

Four consequences follow for anyone commissioning the work. First, eligibility is a gating condition instead of a formality, so check the auditor against the criteria in the guidelines before scoping. Second, rotation means the incumbent is not automatically next year's auditor, which makes handover quality a live issue. Third, the one-month reporting window runs from the audit, not from a convenient internal milestone, so evidence has to be assembled during fieldwork rather than afterwards. Fourth, the two-month closure window sets the real deadline for remediation and therefore shapes how findings are prioritised and resourced.

Check these specific system-auditor eligibility rules alongside any separately applicable sector or audit requirements. A supplier's general security credentials do not establish competence across the full algorithmic-trading scope.

Algorithms, connectivity and the limits of a penetration test

Technical API and code security form part of conformance and part of the system audit. They are only part of it.

A well-run penetration test of an order gateway, or a code review of a strategy's execution path, produces useful evidence. It does not, on its own, demonstrate that algorithms were tested to the standard the guidelines describe, that risk controls operated and were monitored, that connectivity arrangements were documented and reviewed, or that the audit trail lets a reviewer reconstruct what happened. Presenting a standard VAPT report as satisfying the annual system audit is a claim we would not make, and firms should be wary of suppliers who make it.

The honest description is narrower and more useful: security testing is one component of the evidence base, alongside testing records, control design and operation, change history, and the auditability of the logs themselves.

Agree the evidence and testing boundary

Ask the exchange and auditor which tests and records they expect for your system. Map the order-entry APIs, pre-trade checks, change approvals, kill switch and audit trail to named owners. Keep conformance testing, algorithm behaviour testing and cybersecurity testing as explicit parts of the plan, with their limits recorded.

A sequence that holds up

• Confirm scope entity by entity, and record the reasoning behind each decision.
• Map obligations across the full circular; identify the relevant transition and annual-audit provisions separately.
• Inventory algorithms and connectivity paths, each with a named owner.
• Establish the evidence trail: test records, control logs, change history, deployment approvals.
• Select an eligible auditor with rotation in mind, and agree the evidence pack before fieldwork begins.
• Plan remediation capacity against the two-month closure window, not against optimism.