Historically, the cybersecurity conversation in banking and fintech has centered on detection: can we spot the intrusion, flag the anomaly, catch the fraud pattern before it does damage? We developed incredibly sophisticated tools that can sift through thousands of ‘signals’ every time a customer makes a payment, ranging from how long it took them to type their card number to, sometimes, their social media activity.
That framing assumed a certain tempo: human attackers probing and exploiting at human speed, or automated scripts operating faster but without the intelligence to adapt dynamically or discover novel vulnerabilities. AI changes that assumption.
PYMNTS reported this month that OpenAI could not rule out its highest cybersecurity warning level for its upcoming Astra model, a threshold that signals a model may be able to independently discover and develop working zero-day exploits, or carry out attacks with minimal human direction.
Around the same time, the International Monetary Fund reached a similar conclusion in a note on artificial intelligence and cybersecurity in the financial sector.
The IMF’s argument is the one banks should be listening to: AI does not need to invent a whole new type of attack to change the risk equation. AI-enabled attacks may not look fundamentally different from attacks carried out by humans.
What changes is their speed, scale and capacity to adapt. It changes the equation by accelerating vulnerability discovery and exploitation across shared technologies, turning what used to be isolated incidents into correlated disruptions that hit several institutions at once.
Why AI cyberattacks are so dangerous
Banking has never run on bespoke, siloed technology. It runs on shared foundations: core banking platforms, cloud infrastructure, payment rails, identity systems and a long chain of third-party software. Few of these systems are built entirely from scratch. Modern financial infrastructure relies on layers of commercial software, cloud services and open-
That makes development faster and can strengthen security through shared scrutiny, but it also creates common dependencies. In the wrong circumstances, that can become analogous to thousands of doors relying on the same key.
An attacker who needs weeks to find a working exploit gives defenders time to patch, monitor, and respond. An AI system can potentially find that same exploit in seconds, and in the most autonomous cases execute a multistep attack with limited ongoing human involvement – 27 seconds is the current record.
The IMF frames this as a dual-use problem: the same capabilities that let AI find vulnerabilities faster for defensive purposes are the ones that let it find them faster for offensive purposes.
This is not a hypothetical for payments specifically. Payment infrastructure has so many overlapping systems at the intersection of common software, cloud dependency, and dense third-party integration that a single exploit becomes an ecosystem-wide issue.
A vulnerability in a widely deployed component can therefore propagate risk far beyond a single institution, particularly where common cloud services, software libraries or third-party platforms are involved.
Why prevention alone isn’t enough
For a long time, resilience strategy has leaned heavily on prevention: patch faster, test harder and review more code before release. All of that still matters. But when discovery and exploitation can happen faster than a conventional patch cycle, prevention alone is no longer sufficient.
The answer is a shift from periodic defense towards continuous resilience: architectures designed to detect, isolate, contain and recover while an attack is unfolding.
The IMF’s recommendation points the same way the PYMNTS piece does: institutions need architectures built to limit the blast radius of a successful breach through segmentation, disciplined access controls, zero-trust design, and closer oversight of third parties. Detection, containment, and recovery need to operate at a speed that is comparable to the speed of the threat, not the speed of the last board-approved incident response plan.
That has equally important implications for how banks govern AI within their own security operations. AI tools will increasingly play a role in detecting vulnerabilities and responding to threats, but the degree of autonomy granted to those systems must be an explicit governance decision. Institutions need clear boundaries around what AI can access, what actions it can take independently and where human intervention remains mandatory.
Why boards need to make AI cybersecurity a priority
This is where the conversation has to move from the security team to the boardroom. Segmentation and access control are technical decisions, but the appetite for AI autonomy in critical infrastructure is a governance decision. Who decides what an AI system is permitted to touch? Who is accountable when it acts on a high-level objective in ways nobody fully anticipated? How quickly can exposure be contained once it is identified?
There is no vendor, platform, or piece of infrastructure that resolves this on its own. The institutions that manage this transition well will be the ones that treat architectural resilience, not just threat detection, as a standing governance priority, and that know precisely what their systems, and the AI operating within them, can reach.
The capability curve is not waiting for banks to finish their next audit cycle. Resilience now has to be designed for the speed of the attack it is meant to withstand.
We’ve featured the best AI website builder.
This article was produced as part ofTechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here:https://www.techradar.com/pro/perspectives-how-to-submit
