HDFC Bank Leadership Shifts Ahead of New CEO's Arrival

Around 20 financial institutions, including banks and Non-Banking Financial Companies (NBFCs), lenders operating outside the banking system, were targeted in cyberattacks earlier this month. The Economic Times described attacks on a widely used software platform that allowed funds to be siphoned by bypassing normal security checks.

The alleged entry point was stolen credentials belonging to partner banks. That makes this an Indian banking story about connections and permissions, not simply another warning to choose a stronger password.

Think of a bank’s technology network as an apartment building with several service entrances. A familiar key does not prove that the person holding it belongs inside.

Application Programming Interfaces (APIs) are connections that let different software systems communicate. They help banks and financial technology companies connect services such as payments and loan disbursals without making customers manage each hand-off themselves.

That convenience also creates a security obligation. The receiving system must distinguish between recognising a partner’s credentials and deciding whether the particular action requested should be allowed.

In our apartment building, a maintenance contractor needs access to do useful work. But a key to the service entrance should not automatically open every flat, and recognising that key should not settle whether its holder can remove someone’s belongings.

For a banker, the equivalent distinction is between access and authority. A connection can be legitimate while a particular transfer travelling through it is not.

This is why the incident matters beyond technology departments. Operations teams depend on those connections to move money, business teams depend on them to deliver services, and customers depend on the resulting payments being authorised correctly.

The Indian Computer Emergency Response Team (CERT-In), the national cyber incident response agency, issued a critical advisory warning that attackers may be using artificial intelligence (AI) tools to find API weaknesses and execute fraudulent transfers. AI involvement is a warning, not an established finding about every attack.

The known outline is a series of attacks targeting financial institutions through a shared software platform; the account available does not establish institution-by-institution losses, the full technical sequence or the extent of any AI involvement. Those gaps matter when deciding how broadly to describe the damage.

But we do not need a dramatic claim about intelligent machines to see the underlying problem. Stolen access details and insufficient checks on what they permit are enough to make partner connections a serious concern.

Return to the building. A faster way of testing doors would make a thief more troublesome, but the building’s first obligation would still be to ensure that one service key cannot unlock everything.

The sensible expectation is greater scrutiny of partner access, rather than an assumption that a new rule or a particular security product will resolve the problem. For banks, the useful response is to examine permissions and payment checks together.

Take an illustrative partner connection permitted to initiate ten transfers of ₹50,000 each before further approval is required. That represents ₹5 lakh of permitted transfers: ten multiplied by ₹50,000.

If the same connection instead permits ten transfers of ₹5 lakh each, the total becomes ₹50 lakh. These are invented inputs, not actual bank limits or details of these attacks; they show how the scope of permission changes the money exposed to a compromised connection.

The credentials need not change at all. The difference sits in what the system allows their holder to do.

Nor would a transfer limit alone establish safety. A useful review would examine the recipient, the purpose, the pattern of requests and the circumstances requiring additional approval, rather than treating a recognised partner identity as sufficient evidence.

In building terms, that means specifying which doors the contractor can open, what work is permitted and when someone must check before property leaves. The point is controlled access, not sealing every entrance and making the building unusable.

For Indian banks and their partners, this turns security into a business-design decision. Faster service and tighter permissions should be considered together, because the customer experiences the whole transaction rather than the boundary between two companies.

You can ask for a practical demonstration: show what a compromised partner credential would allow, where a suspicious transfer would be stopped and who has authority to suspend the connection. That is more revealing than reassurance that the partner is trusted.