Banks Can't Out-Patch AI and Don't Need To
The Atlantic ran a piece this month on AI agents and cyber risk in the financial system, and I was one of the interviewees. I contributed the defensive side of the argument: firms are using AI to strengthen anomaly detection, early-warning systems that flag potential threats, and other data-monitoring tools. It’s a good piece, and I’m glad Aequora’s name is in it.
The last line of the article is one I keep thinking about, though: that not every institution can handle these threats equally, and AI may expose the gap between those who can afford to prepare and those who can’t.
I agree with the premise but disagree with what most people will take from it. The assumption is that preparation means keeping pace with disclosure volume, and that keeping pace costs resources smaller banks don’t have (which only follows if the first half is true). Here’s why:
September’s Microsoft Patch Tuesday put roughly 900 CVEs in front of many security teams worldwide at once. For a mature organization with dedicated staff, triaging that likely consumed hours of tedious, low-value work across multiple research tools, advisory formats, and third-party sources, all to determine which items warranted attention. For a community bank with a two-person security team, or a one-person team that also runs IT, no version of that exercise ends well.
Security experts found that most of those 900 were not novel attacks. They were repeated instances of vulnerability classes we have seen before, the same weakness patterns newly detected in more products, likely through AI-assisted discovery. AI is surfacing issues from known vulnerability classes far faster than it can produce new attack techniques. This means volume is growing much faster than diversity.
If that holds, and I believe it will accelerate rather than hold, then measuring yourself on patch volume and speed is measuring the wrong thing. Patching is absolutely important, and as I’ve written before, we can’t delay it; fourteen days to patch won’t work anymore. Just look at the NetScaler/Citrix issue that consumed many firms (and ruined many people’s plans) over last weekend. Many firms had to pull the plug on this key system for hours until a patch arrived. The sector was lucky the incident occurred over a weekend; it could have had a far greater impact during a workweek.
Using patch throughput as the benchmark hides what actually reduces risk: architectural changes, compensating controls, segmentation, and more. Those are the investments a small institution can make, rather than trying to keep pace in patching with a G-SIB. The question a smaller bank, therefore, should be asking is not “which of these 900 do I patch first?” It’s “what is my exposure to these classes of attack, and what controls do I have in place against them?” Answering that for a technique covers every instance of the technique, present and future. Answering it CVE by CVE does not scale, and for a small team it never will.
Separately, a firm’s risk depends as much on what its providers run as on what it runs itself. For a community bank or credit union, that’s nearly the whole story. Third parties provide the core platform, online and mobile banking, card processing, and often a managed security service. Vulnerability management, as commonly practiced, focuses almost entirely on first-party asset inventory, which for these institutions is the smaller part of the attack surface.
Only a handful of these core providers exist, creating concentration risk. One provider falling behind becomes a sector-wide problem. But the upside is scale: when one of those providers deploys AI-driven anomaly detection or compresses its patch cadence, every client benefits at once. Smaller institutions then need to hold their providers to that standard and require evidence. Institutions should ask for detection coverage, patch cadence, and how the provider governs its own AI use, then write the answers into contracts and due diligence rather than accepting them on a quarterly call.
NB: This is also where information sharing earns its keep. Join sector groups like FS-ISAC (or similar for other industries), plus your trade association’s cyber programs (e.g., ABA, ICBA). When attacks move at machine speed, an attack seen at one institution is an early warning for everyone else on the same platform. A small bank that participates in its sharing community gets detection capability it could never build, and the community gets better when smaller institutions contribute what they see. Attackers often test techniques on softer targets first.
Degraded operations, planned and unplanned outages, and then recovery/reconnection used to be exceptional events. Now they are becoming almost routine; last weekend’s NetScaler/Citrix incident was, I fear, the tip of the proverbial iceberg. For a community bank, resilience is more in your control than patching, because it’s about your business rather than your vendors’ code: which services must stay up, what you do when a provider goes dark, and much more.
If I were advising a smaller institution today, this is the order of operations:
- Know what you have and include which provider operates what. No amount of better vulnerability data helps an organization that can’t determine where an affected component runs.
- Consider shifting board reporting from patch counts to exposure by attack class. Show the board the controls in place to thwart ransomware, DDoS, API vulnerabilities, etc. It’s a tough initial conversation, but it gets way easier thereafter, especially when the focus is on resilience.
- Work with your providers. Put things like detection coverage, patch cadence, and AI governance in the contract. Don’t let them surprise you.
- Plan for degraded operation. Learn from incidents like NetScaler/Citrix. Assume you’ll be running vulnerable for a window. Decide now what runs, what stops, and how you’ll know if something bad happened in that window. Practice and plan for what happens if critical services go down, including backups or alternate services.
- Defense in depth is more important than ever, now that frontier AI is finding bugs at unprecedented rates. Network segmentation, least privilege access, and multi-factor authentication can help contain and defuse attacks.
In conclusion, large banks are as ready as they can be. But as we’ve seen, regardless of size, we as a sector can no longer rely on patching alone. What will matter more is managing posture, holding providers accountable, and planning to operate while vulnerable. The financial services sector is built on trust; together, overcoming the challenges and changes that frontier AI poses is absolutely achievable.