Back to All Posts

Inside India’s Banking Cyber Threat: AI, APIs and the ₹1 Test

Inside India’s Banking Cyber Threat: AI, APIs and the ₹1 Test

Introduction: India’s Digital Banking Security Challenge

India’s banking system no longer stops at the branch door. Payments, loans, settlements and customer verification increasingly run through application programming interfaces—APIs—that connect banks to fintech apps, non-banking financial companies, payment aggregators and cloud platforms. That connectivity has made everyday banking faster. It has also created a large, distributed attack surface.

On November 4, 2026, the Indian Computer Emergency Response Team (CERT-In) issued an advisory that deserves attention beyond security teams. It named an AI-assisted financial threat actor tracked as “Crafty Falcon,” linked the campaign to an earlier October 9 warning about payment and disbursement APIs, and described techniques that exploit the seams between connected systems. The advisory is notable not because it predicts future risks, but because it documents techniques already observed in reported incidents.

Abstract digital representation of interconnected banking and payment systems, with code projection representing API connections
Fig. 1 — India’s banking ecosystem runs on connected APIs across banks, fintechs, NBFCs and payment aggregators. (Photo: Ron Lach / Pexels, free to use)

Why the Latest CERT-In Advisory Matters

CERT-In’s advisory CIAD-2026-0058 is an update to an October 9, 2026 advisory, CIAD-2026-0046. The earlier warning covered threat actors exploiting payment and disbursement APIs for unauthorised fund transfers in BFSI entities. The November update says analysis of incidents reported by affected organisations revealed a significant escalation.

The affected organisations include non-banking financial companies, digital lending platforms, fintech entities, payment aggregators, payment service providers and cryptocurrency exchanges or virtual digital asset service providers. CERT-In describes the threat as “active and ongoing” and says successful attacks continue to be reported, including from entities that had received the earlier restricted advisories and undertaken remediation.

Two details stand out. First, some entities were deliberately re-targeted, including after incomplete remediation. Second, attacks were timed to coincide with holidays, weekends and other low-monitoring windows to delay detection and response. That does not mean every financial institution has been breached. It means the advisory describes a continuing campaign against specific types of connected financial systems, and that closing one entry point has not always been enough.

What Makes AI-Assisted Cyberattacks Different?

Traditional automated attacks follow predetermined steps. A script tries the same exploit, in the same order, until it succeeds or fails. AI-assisted workflows change that pattern in ways that matter for defence.

CERT-In’s advisory says the tools used in this campaign can execute complete attack chains autonomously, generate and refine large numbers of tailored attack scripts in rapid succession, and adapt payloads based on how a target system responds. The supporting infrastructure rotates IP addresses within hours to days.

That combination creates three practical challenges. Attack scripts can be produced and modified faster than a human team can manually review and block each variant. The attack logic can change when a target responds, rather than repeating a fixed sequence. And the infrastructure itself moves, making conventional IP-based blocking less reliable.

It is important not to overstate what this means. The advisory describes AI-assisted offensive tooling, not a fully autonomous system that independently performs every stage of every intrusion without human involvement. The distinction matters: AI is accelerating specific parts of the attack workflow, particularly script generation, adaptation and scale.

Abstract green matrix code on a dark computer screen, representing automated attack scripts and AI-driven code generation
Fig. 2 — AI-assisted tooling can generate and refine attack scripts faster than manual review cycles. (Photo: Markus Spiske / Pexels, free to use)

How Banking APIs Become Security Weak Points

An API is a set of rules that lets one software system request data or actions from another. When a fintech app checks a customer’s balance, initiates a loan disbursement or triggers a payment settlement, it is often calling an API exposed by a bank or payment provider. APIs are essential plumbing, but they are also entry points.

CERT-In’s advisory identifies several ways attackers reached production systems through connected infrastructure. Internet-exposed non-production environments—UAT, staging and testing systems—were used as entry points, followed by movement to production using shared credentials, tokens or network paths. Cloud management services, including AWS Systems Manager and Lambda, were abused to execute commands and deploy malicious files while blending into legitimate administration channels.

Attackers also reverse-engineered application codebases to develop tailored exploits, then initiated unauthorised API calls using altered or modified application packages. This defeated controls that assumed only the legitimate client application would call the APIs. IP allow-listing was bypassed by routing traffic through shared third-party fetcher IP pools, such as content-acceleration and app-store review services.

The common thread is that a weakness in one connected system—a staging server with shared credentials, a cloud role with broad permissions, an API that trusts a modified app package—can become a path into another. Securing the bank’s core ledger is not enough if the surrounding mesh of integrations is weaker.

Understanding the ₹1 Transaction Technique

Among the techniques described in the advisory is the use of micro-value test transactions, sometimes as low as one rupee, to validate unauthorised fund flows before attempting larger transfers.

A small transaction can serve as a low-noise test. If a payment route, beneficiary setup or API call succeeds with a minimal amount, the attacker learns that the path works without immediately triggering high-value fraud alerts. If it fails, the attacker can adjust and try again. The ₹1 transfer is not the attack itself; it is a probe.

This does not mean every low-value transaction is suspicious. Small transfers are a normal part of testing, settlements and customer behaviour. The security implication is about patterns: a micro-value transaction followed by a larger transfer, or repeated low-value probes to newly added beneficiaries, deserves attention. CERT-In recommends monitoring micro-value transactions followed by high-value transfers, implementing beneficiary cooling periods and enforcing maker-checker approvals for merchant settlements.

AI Tools Mentioned in the Campaign

CERT-In’s advisory identifies multiple publicly available AI-driven offensive security tools used in the campaign: the ARTEX family of large language model-based tools, PentAGI (described as an autonomous multi-agent AI penetration testing system), the Cairn attack search engine, and the CyberStrikeAI framework.

These are publicly available or open-source offensive-security tools. Their presence in the advisory indicates that the threat actor used them; it does not mean that the tools themselves are inherently malicious or that every user of these tools is an attacker. The significance is that these tools lower the expertise barrier for automating parts of an attack workflow—reconnaissance, script generation, payload adaptation and repeated testing—that previously required more specialised human effort.

For defenders, the lesson is not to focus solely on blocking specific tool names. Tools change. The more durable response is to reduce the opportunities that any automated offensive workflow can exploit: exposed staging systems, shared credentials, weak API authentication and unmonitored cloud administration.

Server room with rows of network equipment and blinking lights, representing cloud infrastructure targeted by API attacks
Fig. 3 — Attackers targeted cloud infrastructure and API connections, not just customer-facing apps. (Photo: Pexels, free to use)

What the Cyberattack Statistics Reveal

India’s BFSI sector recorded 2.9 million cyberattacks in 2025, more than double the 1.4 million recorded in 2021, according to the Digital Threat Report 2025–26 prepared by MeitY and SISA. The same report found that Indian BFSI entities faced 1.6 times more cyberattacks per organisation than global peers, and that the average cost of a data breach rose 7 per cent to USD 2.5 million.

A separate BioCatch survey offers a view from banking leaders. The survey covered 1,440 fraud-management, AML, risk and compliance leaders across 25 countries. In India, 100 banking and financial crime prevention leaders were surveyed. Among Indian respondents, 84 per cent reported higher fraud losses over the past year, and 93 per cent said AI has increased the sophistication of fraud and scam schemes. Ninety per cent said fraud attempts had increased, compared with a global average of 81 per cent.

These are self-reported survey findings from a vendor-commissioned sample, not audited loss figures. They are useful indicators of concern and direction, but they should not be combined with the MeitY/SISA attack-volume figures as if they measure the same thing. The BFSI report counts reported cyberattack cases; the BioCatch survey captures perceptions and reported loss trends among a specific group of leaders.

RBI and CERT-In’s Security Priorities

The Reserve Bank of India has been tightening cybersecurity supervision. In late October and early November 2026, the RBI asked banks to document how they meet cybersecurity rules and to describe their plans for dealing with AI-related risks, with a specific focus on API weaknesses that connect banks to fintechs and non-bank lenders. A consultant quoted in reporting on the RBI’s scrutiny said some lenders had yet to fully implement existing cybersecurity directions.

The RBI has also directed entities to update API inventories, deactivate dormant or deprecated APIs and implement real-time API monitoring for abnormal request spikes and suspicious account creation. Reporting indicates that the RBI’s 2026 Cybersecurity, Resilience and Assurance Framework is already in force for commercial banks, and that supervisory priorities include API security, third-party risk management, privileged-access controls, credential protection and AI-risk preparedness.

CERT-In’s recommendations in the November advisory are operational rather than aspirational. They include 24×7 monitoring with increased staffing during weekends and holidays, isolation of testing and staging environments from production, elimination of shared credentials, real-time monitoring of cloud audit logs, server-side transaction validation, API request signing, app attestation, certificate pinning and rapid patching of internet-facing applications. The advisory also recommends reporting suspicious activity to CERT-In and CSIRT-Fin.

Some of these are existing regulatory expectations. Others, such as newer AI-specific supervisory initiatives, are still evolving. The practical gap is often not a lack of written rules but incomplete implementation at the level of individual institutions and third-party connections.

Close-up of server room lights and cables, representing continuous security monitoring and infrastructure oversight
Fig. 4 — Continuous monitoring, including outside business hours, is a repeated recommendation in the advisory. (Photo: Brett Sayles / Pexels, free to use)

What This Means for Ordinary Banking Customers

Most customers do not manage APIs or cloud roles, but they interact with the systems these attacks target. A few habits reduce exposure.

  • Pay attention to transaction notifications. A small debit you did not initiate can be a probe. Report it through your bank’s official channel rather than waiting to see whether a larger transaction follows.
  • Verify beneficiaries before approving payments. If a request to add a new payee arrives through a message, email or call, confirm it independently using a known bank number or the official app.
  • Use official banking applications. Modified or unofficial app packages are part of the attack surface described in the advisory. Download apps only from official app stores and keep them updated.
  • Treat urgent payment requests with caution. Urgency is a common social-engineering tactic. A genuine bank or service provider will not pressure you to bypass normal verification steps.
  • Act quickly after an unauthorised transaction. Contact your bank through its official customer-care number or app, report the transaction, and follow the bank’s dispute process. Do not rely on contact details supplied in an unsolicited message.

These steps do not guarantee protection against every fraud. They reduce the likelihood that a customer becomes an easy entry point or an unwitting participant in a probe.

Person checking a mobile banking transaction notification on a smartphone, illustrating the importance of monitoring account activity
Fig. 5 — Transaction notifications help customers notice small unauthorised debits before they become larger losses. (Photo: Karolina Grabowska / Pexels, free to use)

What Financial Institutions Need to Improve

The advisory and the RBI’s supervisory push point to several priorities that go beyond installing another security product.

Continuous monitoring matters because attacks timed to weekends and holidays exploit the gap between business-hours staffing and round-the-clock infrastructure. Identity-based access controls and strong API authentication matter because IP allow-lists and client-side assumptions are insufficient when attackers can route traffic through trusted fetcher pools or modify application packages. Transaction-level validation on the server side matters because controls that trust the client can be bypassed.

Third-party risk management matters because the attack surface includes payment aggregators, fintech partners and cloud providers. Regular security assessments, including testing and staging environments, matter because those environments have been used as entry points into production. Incident-response preparedness matters because detecting an anomaly is not the same as containing it.

Software alone does not close these gaps. An institution can deploy an API gateway and still leave a staging server exposed with shared credentials. It can buy a monitoring tool and still under-staff the weekend shift. The advisory describes an adversary that adapts and persists; the defence has to be operated continuously, not renewed annually.

Conclusion: The Future of Banking Security in India

India’s digital financial infrastructure is expanding because APIs, cloud services and third-party integrations make payments and credit faster and more accessible. That same architecture creates seams that an AI-assisted attacker can probe at speed. The CERT-In advisory does not suggest that the entire system is failing. It shows that specific classes of connected financial systems are being tested, re-targeted and exploited through techniques that combine automation with adaptation.

The useful response is neither panic nor a single product purchase. It is a sustained focus on the unglamorous parts of security: isolating test environments, removing shared credentials, validating transactions on the server side, monitoring outside business hours and knowing what is connected to what. Convenience and innovation will continue to shape Indian banking. The security question is whether the operational discipline around those connections keeps pace.