Why is RBI asking banks for proof of cybersecurity compliance?
Most banks can show an auditor a cybersecurity policy. Fewer can show, on demand and with timestamps, that an API credential issued to a fintech partner was rotated, scoped and monitored last quarter. That gap is what the Reserve Bank of India is now probing.
On October 30, Reuters reported that the RBI has warned banks about rising attacks on financial infrastructure and asked for proof of compliance with existing rules and details of their preparedness for AI-related risks. In recent meetings it also asked lenders to probe weaknesses in the APIs they use to connect with non-bank lenders and fintechs.
What RBI Expects from Banks on Cybersecurity Compliance
Are banks cyber ready? On paper, mostly yes. In practice, readiness is uneven, and the regulator knows it. One consultant working with leading banks told Reuters that implementation of existing RBI directives remains uneven. The weak points are not core banking systems. They are the connections around them: partner APIs, vendor access, stolen credentials and unmanaged AI tools.
For IT leaders, the practical meaning is simple. Compliance is now judged by evidence of operation, not documents of intent. Treat the next 90 days as an evidence-gathering exercise.
What happened this month
Three developments landed within weeks of each other.
First, CERT-In’s financial sector unit issued an advisory on October 9. It describes attackers breaking into internet-facing applications, stealing credentials linked to payment gateways, payment aggregators and partner banks. According to the advisory summary, they then call disbursal and fund transfer APIs directly from the entity’s own whitelisted infrastructure, which skips application-level controls. CERT-In also noted the likely use of AI-assisted offensive tooling, and a shortening time from first compromise to fraud.
Second, the RBI’s proof request followed. The regulator was reportedly told that smaller lenders, NBFCs and third-party vendors are seen by hackers as “softer targets”.
Third, the threat is not only domestic. In early October, South Korea’s financial regulator convened banks after a breach at Shinhan Bank and, according to a Cloud Security Alliance research note, ordered banks and card companies to check all their defences. Reporting says investigators stressed that a human directed the attacks and used AI as a tool. Treat that as early evidence, not a final finding.
What the 2026 Directions require
The proof request sits on top of a rulebook rewrite. On July 31, 2026, the RBI issued the Commercial Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions. According to the FinBox summary, they run to 233 paragraphs and took effect immediately, replacing the 2016 Cyber Security Framework. They cover commercial banks. Separate entity-specific directions were issued the same day for small finance banks, payments banks, and local area banks, and others followed for different classes of regulated entity. Check which one binds you.
The headline requirements for commercial banks, as summarised by FinBox:
The sixth row matters most this month. Under the third-party provisions, the bank is accountable for security risks in outsourced and partner arrangements. That is exactly where the October attacks landed.
Case study: the API fraud wave of October 2026
This is an analysis of public reporting, not a client engagement.
Reports describe roughly 20 financial institutions affected by attacks involving stolen credentials and vulnerable payment APIs. The numbers vary by outlet, and CERT-In’s own advisory text should be treated as the primary record.
The pattern CERT-In described is worth reading slowly. Entry came through static API tokens hard-coded in source code, plaintext credentials in configuration files or databases, and remote services without multi-factor authentication. After entry, intruders planted web shells and backdoors, studied payment databases and harvested what they needed to start payments.
My reading: none of these are exotic. They are hygiene failures in places where ownership is blurry. A token hard-coded by a developer in 2022 does not appear in anyone’s risk register. The attacker needs it only once. And because the fraudulent call comes from whitelisted infrastructure, a firewall rule cannot tell it apart from legitimate traffic.
What would have changed the outcome, in order of likely impact:
Short-lived, scoped credentials in a secrets vault instead of long-lived static tokens
MFA on every remote service
Independent checks on payout APIs, such as velocity limits and out-of-band confirmation above a threshold
Logging that can show who called a disbursal API, from where, and with which credential
Detection that watches API behaviour, not just network perimeter events
Why proof is harder than policy
Banks tend to fail the evidence test in three predictable places.
Inventory. You cannot prove controls on APIs you cannot list. Shadow and legacy endpoints are common, especially after fintech integrations built under deadline.
Continuity. The Directions describe an operating rhythm: six-monthly scans, annual penetration tests, half-yearly recovery drills. A single clean report from last March proves little. Regulators look for a trail of repeated, remediated findings.
Vendors. A bank can demand VA and penetration reports from partners, but only if the contract says so. The FinBox analysis observes that RBI names the bank, yet enforcement reaches the vendor through contract clauses.
The Parliament figures show the scale of noise that detection must sort through. The government told Parliament that CERT-In recorded 5,70,108 banking sector incidents in 2025 and 3,48,607 between January and June 2026. Most were scanning and probing. The same reply put targeted intrusion campaigns at 39 in 2025 and 17 in the first half of 2026. The lesson is that volume is mostly background, and the dangerous events are few and quiet.
A separate industry report cited by news agencies says Indian BFSI faces attacks at 1.6 times the global average, with incidents more than doubling over four years. The report’s methodology was not detailed in the coverage I found, so I treat it as directional.
AI governance is now part of the same exam
The RBI asked about AI preparedness in the same breath as API security. It makes sense, because AI shows up on both sides.
Offensively, CERT-In’s advisory on frontier AI risks says next-generation systems let attackers operate with unprecedented speed, scale and autonomy. Defensively, banks are adopting AI tools, copilots and agents, often without central visibility.
IBM’s 2025 India study quantifies the internal risk. Shadow AI added ₹17.9 million to the average breach cost, yet only 42 percent of organisations have policies to manage AI or detect shadow AI. Only 37 percent reported having implemented AI access controls.
A bank’s AI governance answer should cover five things: an inventory of AI tools, models, extensions and agents on endpoints; least-privilege access for any AI that touches enterprise systems; rules on what data may reach external and internal models; connections such as MCP servers reviewed like any other integration; and continuous monitoring of usage and data access. This also aligns with DPDP obligations, since customer data flowing into unapproved tools is a disclosure risk before it is an AI risk.
The cost side
IBM’s 2025 report puts the average data breach in India at INR 220 million, about 13 percent higher than 2024. Financial services ran higher still, at ₹28 crore per incident. The common causes in India were phishing at 18 percent, third-party or vendor compromise at 17 percent, and vulnerability exploitation at 13 percent.
Two numbers argue for earlier detection. Indian organisations that contained breaches in under 200 days saved ₹4.3 crore on average, and those using extensive AI and automation for detection saved ₹3.1 crore. The average lifecycle was still 263 days.
What to do now: an evidence-first checklist
Map your obligations. Confirm which 2026 Directions apply to your entity class and list the paragraphs that need evidence.
Build an API inventory. Include partner, payment, KYC and disbursal endpoints, with an owner for each.
Hunt hard-coded secrets. Scan repositories, configs and databases for static tokens and plaintext credentials. Rotate and vault what you find.
Enforce MFA on every remote access path, including vendor and service accounts.
Add independent controls on payout APIs: limits, anomaly alerts, out-of-band confirmation.
Prove the test cadence. Keep dated VA, penetration test and recovery drill reports with remediation closure evidence.
Rehearse the six-hour clock. Run a tabletop that ends with a DAKSH and CERT-In submission, timed.
Rewrite vendor clauses. Right to audit, shareable test reports, incident notification times, escrow where relevant.
Stand up AI governance. Discovery, access rules, data rules, monitoring.
Decide your SOC model. If 24x7 coverage with tiered analysts is not sustainable in-house, evaluate co-managed or managed detection and response.
Outlook (forecast and analysis)
Expect inspection requests to become more specific, with questions about particular APIs, credentials and vendors rather than general attestations. This is my inference from the direction of the proof request, not an RBI statement. Expect vendor contracts to tighten across the sector, because banks have no other way to discharge accountability they cannot delegate.
On managed services, MarketsandMarkets forecasts the global MDR market growing from USD 6.28 billion in 2026 to USD 19.01 billion by 2031. That is a vendor-side market forecast, but it matches what banks tell consultants: 24x7 detection is hard to staff, and the Directions raise the bar. Providers such as Proficio describe co-managed models where a hosted platform or the client’s existing security tools are monitored by a provider SOC. Whatever model a bank picks, the Directions’ accountability principle still applies. Outsourcing detection does not outsource responsibility.
NS3TechSolutions on RBI’s Cybersecurity Compliance Requirements
The recurring theme in this article is that the gaps sit between systems: between a bank and its partner, between a developer and the risk register, between a firewall and an API gateway. That is where infrastructure and security work needs to be joined up.
NS3 works across enterprise networking, network security, cloud, managed services and SOC and NOC operations, and with OEM platforms from vendors such as Fortinet, Cisco and Palo Alto Networks. For a bank or a bank’s technology partner, the useful starting points are typically a gap assessment against the applicable Directions, segmentation and API exposure review, monitoring coverage design, and evidence pipelines that make audits a report rather than a scramble. NS3 is also building capability in AI infrastructure, AI security and AI governance, so enterprises can adopt AI while keeping it visible and controlled.
FAQ
Q. What is the RBI asking banks to do right now?
A. According to Reuters sources, it wants proof of compliance with existing cybersecurity rules, details of AI risk preparedness, and a review of API weaknesses.
Q. What replaced the 2016 RBI Cyber Security Framework?
A. Entity-specific Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions issued on July 31, 2026, effective immediately.
Q. Do the Directions apply to NBFCs?
A. The commercial banks Directions do not. NBFCs and other entity classes fall under separate RBI directions, so confirm which one binds you.
Q. What is the six-hour reporting rule?
A. Commercial banks must report cyber incidents on DAKSH within six hours of detection and also notify CERT-In.
Q. How often must banks test?
A. For critical and internet-facing systems, vulnerability assessment at least every six months and penetration testing at least every twelve months.
What readiness really means
The RBI’s request is not an accusation. It is a reminder that a control you cannot evidence is, to a regulator, a control you do not have. Banks that can produce clean inventories, dated test trails and tested incident clocks will treat this as routine. Banks that cannot will find out which of their connections are the soft ones. Better to find out in a drill than in a CERT-In advisory.