By Tarun Wig, Co-founder & CEO, Innefu Labs 

A bank in India can be doing everything right on paper. ISO certifications in place. RBI-mandated controls implemented.

A SOC running around the clock. And it can still find out about a compromise from a customer complaint, a fraud alert on a card, or worse, a journalist calling for comment.

I have sat across the table from CISOs at exactly that moment, and the question they ask first is rarely “how do we fix this.” It is “how long has this been going on.” 

That gap between when something goes wrong and when someone notices is where most of the damage in banking cyber incidents actually happens. Closing it is no longer optional. 

Why banks stay at the top of the target list 

Financial institutions get attacked more than almost anyone else for a simple reason: the payoff is immediate and liquid.

A hospital breach yields records that need to be sold or ransomed.

A bank breach can yield money directly, or a fast path to it through fraud, account takeover, or payment fraud. 

Add to that the complexity of a typical Indian bank’s technology stack. Core banking systems that are decades old sit next to modern mobile apps.

Dozens of fintech partners, payment aggregators, and API integrations connect into the core through channels that were never designed with today’s threat landscape in mind.

Every one of those connections is a door, and someone has to watch all of them at once. 

Attackers know this. They do not need to breach the vault.

They need to find the one API endpoint, the one vendor with weak access controls, or the one employee who reuses passwords. 

Detection, intelligence, and prediction are not the same thing 

There is a lot of loose language in our industry, and I think it causes real confusion at the leadership level. Three terms get used almost interchangeably that really should not be. 

Threat detection is about noticing that something happened. A login from an unusual location, a spike in failed transactions, malware signature matching a known family. It is reactive by definition. Something has to occur first. 

Threat intelligence is broader. It is the practice of gathering and analysing information about who is likely to attack you, how they operate, and what they are after, often before they show up in your environment at all.

Good threat intelligence tells a bank’s fraud and security teams what a particular criminal group’s playbook looks like, so that when early signs appear, they are recognised for what they are instead of dismissed as noise. 

Predictive intelligence goes a step further. It uses patterns across large volumes of data, internal and external, to flag the conditions that tend to precede an incident, before any single alert would normally justify concern.

This is the shift the industry needs to make. Detection tells you a fire started. Prediction tells you the wiring was overheating. 

Catching the early indicators 

In my experience, breaches rarely arrive without warning. They arrive with a trail of small, individually unremarkable events that only look significant in hindsight. An account that suddenly queries far more customer records than usual.

A privileged credential used at 3 AM from a device that has never logged in before. A vendor’s API key generating an unusual volume of calls over a weekend. 

None of these, on their own, would trigger a serious response in most banks today. Together, and viewed as a sequence tied to a single identity or system, they tell a very different story.

The banks that catch incidents early are the ones that have built the discipline, and the technology, to connect these dots across systems that traditionally do not talk to each other: core banking, fraud engines, identity and access management, and network monitoring. 

Where AI genuinely helps, and where it does not 

This is the part where I have to be honest rather than promotional. AI is genuinely useful for one thing above all in this context: making sense of volume.

A mid-sized bank generates an overwhelming amount of security and fraud telemetry every single day.

No analyst team, however skilled, can manually review all of it with the consistency needed to catch subtle patterns.

Machine learning models are good at finding correlations across that volume that a human would miss simply because of scale. 

But I would push back hard on the idea that AI should be making containment decisions on its own in a banking environment. Automated systems can and do produce false positives, and in banking, a false positive is not a minor inconvenience.

Locking a corporate treasury account or blocking a large legitimate transfer because a model flagged it incorrectly has real financial and reputational consequences. 

The risk compounds when banks treat model output as ground truth rather than as one input among several. A model trained on last year’s fraud patterns will not automatically recognise a genuinely new technique.

It needs human judgment layered on top, particularly for decisions that affect customers directly or that could disrupt operations.

The right posture, in my view, is AI for triage and prioritisation, humans for consequential decisions, with clear thresholds for when the system is allowed to act on its own and when it must escalate. 

Before you believe a breach claim 

Not every claim of a breach is real. Extortion groups regularly claim access to systems they never touched, and employees sometimes misread legitimate activity as malicious.

Before a bank mobilises its full incident response machinery, someone needs to validate what actually happened. 

That validation starts with forensic basics: preserving logs and system images before anything gets overwritten, confirming whether the claimed data actually matches what the institution holds, and tracing the initial point of entry rather than assuming it based on where the alert fired.

I have seen organisations waste critical early hours chasing the wrong system because the loudest alert was not the same as the actual point of compromise.

Getting this sequence right, quickly, determines whether the rest of the response is built on solid ground or on assumptions. 

The perimeter is not where you think it is 

Customer data in a modern bank does not sit in one place. It moves through third-party vendors, cloud environments, and legacy systems that were never built with today’s data protection requirements in mind.

Protecting it means extending the same rigour applied to internal systems to every third party that touches customer data, with contractual security requirements that are actually enforced and audited, not just signed and filed. 

Cloud environments bring their own discipline: misconfigured storage and overly broad access permissions remain among the most common causes of data exposure anywhere, banking included.

Legacy systems are harder. Many core banking platforms cannot be easily replaced, so the practical answer is compensating controls: strict segmentation, tightly monitored access, and treating old systems as higher-risk zones that get closer attention rather than being left alone because they are difficult to touch. 

Getting the humans to work together 

Technology aside, I have watched more incidents get mishandled because of poor internal coordination than because of any technical failure. Security operations discovers the technical facts.

Fraud teams understand the financial exposure and customer impact. Legal understands regulatory notification obligations, which in India carry real timelines under RBI and CERT-In requirements.

Leadership needs a clear, honest picture to make decisions and to communicate, internally and sometimes publicly. 

When these groups operate in silos, or worse, when they only meet for the first time during an actual incident, response slows down exactly when speed matters most.

Banks that handle incidents well have already run through this coordination before anything goes wrong, with clear ownership of who decides what and by when. 

Building actual readiness 

A few things consistently separate banks that handle incidents well from those that do not. Regular tabletop exercises that simulate realistic scenarios, not generic ones, so that the specific weaknesses in a bank’s own processes surface before a real attacker finds them.

Pre-defined playbooks for common scenarios, agreed in advance so nobody is debating authority to act while data is still leaving the building. Clear internal thresholds for what can be actioned automatically versus what needs a human decision.

And a genuine post-incident review process that changes something, rather than producing a report that gets filed and forgotten. 

None of this is exotic. Most of it is discipline rather than technology. But that discipline, applied consistently, is what actually moves an institution from reacting to incidents after the fact to catching the conditions that lead to them. 

The institutions that will handle the next five years well are not necessarily the ones with the most tools.

They are the ones that treat early signals seriously, keep humans in the loop on consequential decisions, and have already worked out, before an incident happens, who does what and how fast.