India's central bank has reportedly told banks to audit, inventory and fence in the API clients that connect to their payment rails. The text of the advisory has not been published, so its contents are known only through press accounts. MediaNama, relying on an exclusive from The Head and Tale, reported on 6 November that the Reserve Bank of India (RBI) issued a confidential advisory dated 3 November 2026 after a meeting with banks. Everything below about its contents is therefore secondhand, and should be read that way.
What the advisory reportedly requires
According to MediaNama's report, banks must build an inventory of their API clients. It would record business profile, services used, integration details, transaction limits and security contacts. NBFCs that use bank APIs must be audited by a CERT-In-empanelled auditor, before onboarding for new clients and by 3 February 2027 for existing ones. Audits are then annual, and repeat after any material incident.
The report also describes payout controls. Banks should pre-register verified beneficiary accounts per client, reject unregistered payouts, and allow changes only through a separate multi-factor channel. API debits would need maker-checker or out-of-band confirmation. At least one such safeguard is required for existing integrations by 3 December 2026. Per-transaction and daily limits apply immediately, and intra-day velocity limits within a month. Non-NBFC clients such as payment aggregators and fintechs reportedly face periodic audits within three months.
The strongest case for the mandate
The case for acting is real. CERT-In's advisory CICA-2026-3651, issued on 4 November 2026, describes a threat actor tracked as "CRAFTY FALCON" targeting payment and disbursement APIs at BFSI entities. Attackers reverse-engineer client apps and call APIs with modified packages. They bypass IP allow-lists by routing through whitelisted third-party fetcher IP pools. They probe with Re 1 test transfers before moving large sums. Inc42 reports that the Indian Cyber Crime Coordination Centre's analysis unit issued its own warning on 3 November about agentic AI systems exploiting compromised financial systems for unauthorised transactions "running into crores of Rupees." Inc42's account adds that funds are moved through mule accounts and cashed out over IMPS and NEFT.
If the weak point is the client-side integration rather than the bank's core systems, then a bank cannot be secure while its API customers are not. Whitelisting beneficiaries and requiring a second approval channel are controls that stop a stolen credential from becoming an instant payout. Regulators are right to push them down the chain.
Where the design looks right
Several reported measures are proportionate. Whitelisting and maker-checker are cheap compared with the losses involved. MediaNama's banker source put individual frauds at Rs 3 crore to Rs 15 crore. The reported exception route, a written application with a documented risk assessment for highly automated payment flows, also acknowledges that one control does not fit every business. Risk-based limits calibrated to a client's declared profile are better than flat caps.
The approach also fits the framework NBFCs already operate under. RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, dated 31 July 2026, already require board-approved cybersecurity policy, an annual IT risk assessment, and reporting of cyber incidents on RBI's DAKSH platform within six hours of detection. An API audit requirement extends that logic to the integration layer rather than inventing a new one.
Where it risks going wrong
First, the process. Binding obligations with dates attached, here 3 December and 3 February, are being communicated through a confidential advisory. The NBFCs that must commission audits reportedly learn of them through their banks, not through a public RBI document. Entities cannot comment on requirements they cannot read, and nobody can check whether the press accounts are accurate. A short public circular, with a comment window even if brief, would cost RBI little and would let industry flag the unworkable parts before the clock starts.
Second, the audit bottleneck. Tying NBFC compliance to CERT-In-empanelled auditors concentrates demand on a limited pool of firms. With a February 2027 deadline for existing clients, auditor capacity and pricing become the binding constraint, and smaller NBFCs and fintech-adjacent lenders will feel it most. Audits also test a point in time. CERT-In's own advisory points to continuous controls: mutual TLS, signed requests with nonce and timestamp, app attestation, and rapid patching. A checklist audit that passes in February does not stop a new exploit in March.
Third, the cost of bank gatekeeping. If banks are made responsible for tracking every client's audit and acting on non-compliance, the rational response is to offboard riskier or smaller clients rather than manage them. That would push fintechs toward fewer banking partners and raise concentration risk, which works against the competition and inclusion goals that India's digital-payments policy has pursued.
Fourth, the threat model is shifting. CERT-In's advice to replace IP allow-listing with cryptographic request authentication shows that static controls decay quickly. Beneficiary whitelisting has a similar limit. It works against fresh mule accounts, but it can be gamed if attackers compromise the channel used to add a beneficiary, which is why the reported separate multi-factor channel matters.
What would make it work
- Publish the requirements, or at least a summary, and state which obligations bind banks and which bind clients.
- Allow a path for audits to be accepted from a wider set of qualified assessors if empanelled capacity runs short, or extend the February date for entities that have commissioned an audit in good faith.
- Prefer outcome-based tests, such as demonstrated signed-request enforcement and limit controls, over documentation-heavy audits.
- Publish anonymised loss and incident data so the proportionality of these costs can be judged against real evidence.
The direction of travel is defensible: control the API perimeter, limit the blast radius of a stolen credential, and make banks accountable for who plugs into their rails. The execution should be public, the deadlines should account for auditor capacity, and the controls should be tested on outcomes. Otherwise the compliance burden will land hardest on the smaller firms that India's digital lending and payments ecosystem depends on.