Fintech API Attacks Surge as CERT-In Warns of Payment Heists

The number behind the headline

A figure has been circulating widely in fintech coverage: 96% of firms are said to be dealing with attacks on their application programming interfaces (APIs). Commentary built around the number describes a security crisis that ordinary users rarely see, sitting underneath instant payments, digital lending and automated investment tools.1 The statistic deserves a closer look, both because of where it comes from and because events this week give it practical weight.

The 96% figure appears to come from Akamai's State of the Internet security research. That research found that 96% of financial services organisations worldwide had at least one API security incident in the previous 12 months, the highest rate of any industry it surveyed.23 So the viral version stretches the finding in two ways. The survey covered financial services in general, not only fintech startups. And it counted security incidents, which is a much wider category than confirmed breaches.46 That does not make it a minor result. When almost every financial institution reports an API problem in a single year, the issue is no longer a rare failure. It is the normal state of the industry.

What happened this week

The discussion moved from survey data to live incidents on October 9, 2026. On that day India's Computer Emergency Response Team (CERT-In), working through its financial-sector unit CSIRT-Fin, issued a critical advisory. It warned non-banking financial companies (NBFCs), fintechs, digital lenders, payment service providers and wallet operators about campaigns that abuse payment and disbursement APIs to move money without authorisation.7 One outlet gave the advisory's identifier as CIAD-2026-0046.13

The reported attack chain explains why API weaknesses in finance turn into losses so quickly. According to the advisory, attackers first break into internet-facing applications or exposed APIs. They then steal credentials for payment gateways, payment aggregators and partner banks, and use those credentials to call fund-transfer APIs directly from the victim's own whitelisted infrastructure.18 Because the calls skip the application layer, they avoid the checks that would normally govern a payout. Those include loan creation, KYC verification, loan sanction, beneficiary validation, balance checks and per-transaction limits.7

The money then moves fast. CERT-In described several high-value transfers carried out in quick succession over IMPS and NEFT. The transfers used dummy transaction or loan reference numbers and went to mule accounts at multiple banks, where the funds were withdrawn.7 One report adds that the attackers then deleted logs and tampered with endpoint security tools to hide what they had done.13

The agency listed several likely entry points. They include vulnerable middleware, deprecated or unauthenticated APIs, unrestricted file uploads, static API tokens hard-coded in source code, plaintext credentials in configuration files, remote services without multi-factor authentication, and possible supply-chain compromise of code repositories through forged commits.18 Most of these are long-known basic security failures, not new techniques.

The AI accelerant

The newer element is speed. CERT-In said the gap between first compromise and fraudulent transfer has shrunk significantly in recent incidents. It also flagged the possible use of AI-assisted offensive tools and large numbers of custom scripts, with attacker traffic coming mostly from hosting infrastructure.7

That matches what happened in South Korea shortly before. Since late September, seven South Korean financial firms have reported breaches, including Shinhan Bank, KB Kookmin Bank and Hana Bank. Data on more than 67,000 people was exposed.13 Investigators reportedly found traces of ARTEX, a Chinese-language autonomous penetration-testing tool that can connect to large AI models, on a server linked to the attacks. Korean officials stressed that a human was operating the tool and that its presence does not prove the attacks came from China.13 The method is the important part. The attackers reportedly avoided the core banking systems, which are protected by fraud-detection tools. Instead they went through peripheral APIs used by loan brokers and staff support pages, where identity checks were weak.13

The two cases differ in what the attackers took. In Korea they mostly took data, and regulators are now warning about follow-on phishing. In India they went straight for funds.13 Both point to the same conclusion: AI does not need to invent new exploits to change the economics of attacks. It makes testing endpoint after endpoint cheap enough that the one forgotten interface eventually gets found.

Visibility is the real gap

If there is a single cause behind the 96% figure, it is that institutions think they can see their APIs better than they actually can. Akamai's research found that 77% of financial services IT and security leaders in Asia-Pacific believe they have a complete view of their API estate, but only 27% know which APIs return sensitive data.3 Akamai's Reuben Koh made the point directly: an institution that does not know which APIs exist, which expose sensitive data, or how they are supposed to behave is already operating at elevated risk.2 He also noted that many banks are adding new digital services on top of legacy systems that are hard to patch.2

Other research points the same way, although the methods and timeframes differ. A 2023 Salt Security report found that 92% of financial services and insurance respondents had a significant security issue in production APIs over the previous year. About 17% reported an actual API-related breach, and outdated or "zombie" APIs were their top concern.10 In 2025, Raidiam assessed 68 organisations outside regulated environments such as Open Banking and found that 84% had insufficient API protections.5 Indusface's banking report recorded more than 742 million attacks on financial web and API applications in six months, with API-layer attacks up 60%.8

The headline percentages differ: 92%, 84% and 96%. They also measure different things, from incidents to weak controls to raw attack volume. The direction is the same in every case, and over three years the reported rates have stayed close to universal.

Some widely shared aggregate statistics should be read with more caution. One compilation claims that 99% of organisations had an API security issue and that fintech startups name API vulnerabilities as a factor in nearly half of their security incidents.9 These roundups bring together many underlying sources of uneven quality and are useful mainly for showing direction. The Akamai and CERT-In material rests on firmer evidence.

Not just an Asian problem

Asia-Pacific is currently the most targeted region. Akamai found that it accounted for 52% of global application-layer DDoS attacks on financial services in 2025, the fourth year in a row it led. Within the region, banking took 44% of those attacks and fintech 38%.34 The underlying weakness is not limited to one region, though. A March 2026 incident at Lloyds Banking Group showed customer data in sessions belonging to other customers across multiple subsidiaries, and it led to a UK Treasury Committee inquiry. One API-tooling vendor attributes the root cause to an API-layer misconfiguration.16 That is the vendor's own analysis, not an official finding. In a separate case in early 2026, researchers used an autonomous AI agent to find 22 unauthenticated endpoints in McKinsey's internal AI platform and gained full read and write access within two hours.16

In the US, the effects of tighter API security are showing up in consumer products. Reports describe banks restricting API access, charging new fees and raising security requirements, which has left some budgeting apps unable to retrieve transaction data. That reflects a basic trade-off for fintech. The open connections that made the sector possible are now being treated as risks.

What fixing it looks like

CERT-In's recommendations amount to a practical guide for the industry. They include enforcing MFA across payment platforms, admin portals and banking APIs; keeping a full API inventory and switching off unused endpoints; and replacing long-lived static tokens with stronger authentication.18 The advisory goes further on transaction integrity. It recommends cryptographically binding the stages of a transaction, requiring maker-checker approval for fund transfers, rejecting payouts with invalid reference numbers, and enforcing transfer limits at the API level rather than only in the application.7 It also calls for real-time monitoring, restricted outbound traffic and at least 180 days of centralised logs.7

The most important of these is enforcing limits at the API level. The Indian attacks worked because the checks lived in the application while the attackers sent requests straight to the API beneath it.13

The bottom line

The claim that 96% of fintech firms are under attack goes further than the data supports. A more accurate version is that almost every financial institution has had an API security incident in the past year.2 The revised claim matters more, not less, because recent incidents show where it leads. In 2026, AI-assisted attackers have used neglected side APIs to take data in Korea and money in India.13 The defences needed are mostly familiar ones: knowing which APIs exist, authenticating every one of them, and enforcing transaction rules where the money actually moves. The difference now is that attackers can find the gaps much faster than before.