In Ukraine’s bank DDoS, the rumor outran the outage

The week

On February 15, 2022, with Russian troops massing on the border, Ukrainians who opened their banking apps found that many would not load. Then text messages arrived saying the cash machines had stopped working.

The moment was already tense. Well over 100,000 Russian troops had gathered near Ukraine’s borders over the winter. On the same day, Russia’s defense ministry said some units were returning to their bases, a claim Western officials said they could not confirm. Ukrainians were living with daily uncertainty about whether war would come, and many were watching their bank balances and cash access closely.

Attackers had launched what are called distributed denial-of-service attacks, or DDoS for short. The targets were the websites of Ukraine’s Ministry of Defense and armed forces and the online services of two large state-owned banks, PrivatBank and Oschadbank. A denial-of-service attack does not break into anything. It floods a website or app with so much junk traffic that real customers cannot get through. “Distributed” means the traffic comes from many machines at once, which makes it harder to block.

The banks were among the country’s largest. PrivatBank alone served more than 20 million Ukrainians, according to contemporary reporting. From mid-afternoon local time, their mobile apps and online payments were unavailable for around two hours, and the banks reported their websites working normally again by the evening. PrivatBank warned that further attacks were possible. The central bank’s own website was not affected.

Ukrainian officials described the attacks as the largest of their kind the country had seen. Yet the technical damage was limited. No accounts were reported emptied and no data was reported stolen. The attack had made the front door unreachable for a few hours and nothing more.

The more striking part was what happened alongside the outage. Text messages circulated falsely claiming that PrivatBank’s ATMs had stopped working. The bank said it had not sent them. Ukraine’s cyber police noted that the messages carried no phishing links, so they were not trying to steal credentials, and described them as an information attack meant to sow confusion. Authorities publicly denied the claims. The combination was the clever bit: a real, visible disruption made a false story about cash machines feel believable, at a moment when people were already frightened.

The attacks did not come out of nowhere. A month earlier, on January 14, about 70 Ukrainian government websites had been defaced with a message telling Ukrainians to be afraid and expect the worst. Around the same time, Microsoft reported destructive malware disguised as ransomware on systems in Ukraine, designed to wipe data rather than hold it for ransom. Each episode tested a different part of the country’s resilience: public websites, internal systems and now consumer banking.

Three days later, on February 18, the White House and the UK government publicly attributed the bank attacks to Russia’s military intelligence service, the GRU. Attribution, meaning a government formally naming who was responsible, is a significant step; it is usually made only when officials are confident in the evidence and want to send a message. The US deputy national security adviser for cyber and emerging technology, Anne Neuberger, said the United States had technical information linking GRU infrastructure to the attack traffic. The speed of this attribution, days rather than months, was itself unusual and signaled how seriously Western governments read the moment. That same month, the US Cybersecurity and Infrastructure Security Agency launched its Shields Up campaign, urging US organizations to prepare for disruptive cyber activity linked to the crisis.

On February 23, another wave of DDoS attacks hit Ukrainian government and bank websites, and security researchers found destructive wiper malware on hundreds of computers in Ukrainian organizations. Early on February 24, as the full-scale invasion began, an attack on a satellite communications network disabled thousands of modems in Ukraine.

Seen in that light, the bank attacks look less like an attempt to steal money and more like an attempt to shake public confidence in the institutions people rely on. The episode raises a simple question for any bank. If your digital channels went dark for an afternoon during a period of public fear, what would your customers believe, and who would be telling them?

Denial-of-service attacks are old and blunt. They flood a service with traffic rather than breaking in, and banks in many countries have contracted protection against them for a decade. Technically, the February attacks on Ukrainian banks were unremarkable, and service came back within hours. What made them instructive was the pairing. A visible outage arrived alongside false messages telling people that cash machines had failed, during a period of acute public fear. The apparent aim was a loss of confidence, with the outage as a prop.

For a bank, that means availability has to be judged by what customers can do and what they believe they can do. A system can be technically healthy while customers are convinced their money is out of reach, and the second problem can do more damage than the first. A sound response has three parts: keeping critical services up, keeping customers informed, and keeping other channels open.

The sections below start with how these attacks work, since the defenses follow from the mechanism. The three parts come next, in that order, with a hypothetical Saturday morning at a mid-sized lender after the first to show how the gaps appear. Then come the business cost of losing trust and the strongest objections to this way of planning. The last sections cover how the problem differs by type of institution, the habits of a prepared bank and the questions that find the weak points.

How junk traffic shuts the door

Every website and app runs on servers, which are computers that answer requests. When you open your banking app, your phone sends a request (“show me my balance”), and a server somewhere sends back an answer. Each server, and each network link leading to it, can handle only so many requests at a time. That limit is usually generous, sized for a busy payday with room to spare.

A denial-of-service attack exploits that limit. Instead of trying to steal data or break a password, the attacker sends an overwhelming volume of fake requests. The servers spend all their effort dealing with junk, and genuine customers get slow pages, error messages or nothing at all. The effect is like a prankster tying up a restaurant’s phone line with hundreds of fake calls: the kitchen is fine, but nobody can place an order.

The “distributed” version uses many computers at once, often thousands of ordinary devices such as home routers, cameras and poorly secured servers that criminals have taken over. A network of hijacked devices like this is called a botnet. Because the traffic comes from so many places, a bank cannot block one troublesome address. It has to tell good traffic from bad at very large scale, and quickly.

Three kinds of flood

Attacks come in three broad kinds, and each is stopped in a different place.

• Volumetric attacks fill the network pipe itself with more data than it can carry. They are measured in bits per second, and the only defense is to absorb or filter the traffic upstream, before it reaches the bank’s own connection.
• Protocol attacks exhaust the equipment that manages connections, such as firewalls and load balancers, by opening connections and never completing them. They are measured in packets per second.
• Application-layer attacks send requests that look legitimate, such as repeated logins or searches, each of which makes the server do real work. They need far less traffic to cause harm and are the hardest to tell apart from real customers.

A bank’s protection has to cover all three. A contract that absorbs huge volumes upstream may do little against a modest stream of expensive login requests aimed at the application itself. Equally, a well-tuned web application firewall cannot help if the pipe in front of it is full.

Why outages are so visible

Two features matter for executives. First, a DDoS attack usually does not touch customer money or data. Accounts are not emptied and records are not stolen. Second, it is highly visible. Customers notice immediately, journalists notice soon after, and the natural assumption among the public is that something much worse is going on. That visibility is exactly what made the Ukrainian attacks useful as a prop for disinformation.

DDoS attacks are also cheap to launch. Botnets can be rented, and attack tools circulate freely among politically motivated groups. The attacker spends little and risks little. The defender has to stay ready all the time, across every service a customer can see. The economics favor the attacker, which is why the defense has to be built into contracts, architecture and routines rather than assembled during an incident.

Keeping critical services up

The defenses are well understood. The first is enough capacity to absorb traffic, so that a surge does not tip systems over. The second is upstream filtering by carriers or specialist mitigation services. These are companies whose networks stand in front of the bank’s own systems and scrub out junk traffic before it arrives. The third is architecture that separates critical functions from exposed public pages, so that an attack on the marketing website does not drag down login and payments.

Always-on or on-demand

Mitigation comes in two models. Always-on protection routes all traffic through the provider’s network at all times, so filtering starts the moment an attack begins. On-demand protection diverts traffic to the provider only when an attack is detected, which costs less but introduces a delay while traffic is rerouted, often measured in minutes. For a bank’s login and payment services, minutes of outage during a tense period are exactly what an attacker wants. Many banks therefore use always-on protection for their most important services and on-demand protection for the rest.

The dependencies outside the contract

The open question for most banks is coverage. Mitigation contracts often protect the main website and online banking front end but leave other dependencies outside. A “dependency” is anything a service needs in order to work. Your mobile app depends on the servers behind it, on a system that checks who you are, and on a kind of internet directory service. Each may be run by a different team or company.

Those dependencies are where outages hide. The mobile app’s back-end services, the machinery behind the screen, may be hosted elsewhere. Authentication, the step that confirms you are who you say you are, may run through a separate identity service. Payment and open banking interfaces may live at a different address. These interfaces, often called APIs, are the agreed doorways through which other systems and partner apps talk to the bank’s systems. DNS, the internet’s address book that turns a name like a bank’s web address into the numeric location of its servers, may be served by a provider without mitigation. If the address book goes down, customers cannot find the bank at all, even if every server is healthy. Third-party components, such as a digital banking platform or a status page, may be hosted by vendors with their own protections.

A map of every customer-facing dependency, with its mitigation status and owner, usually finds gaps. Periodic tests with simulated attack traffic, coordinated with providers, show whether the protection works under load. A plan that has never been tested is a hope, not a control.

Triage rules agreed in advance

Priority also matters. During an attack, a bank may need to shed less important traffic to protect login and payments. Rules for that triage are easier to agree in advance than during an incident, when every business line wants its page kept up. Typical tools include rate limits, which cap how many requests one source can make per minute, and geographic filters, which temporarily refuse traffic from certain regions. Challenge pages, the “prove you are human” screens, stop many automated attack tools.

The rules should name who can switch them on, out of hours, and how long they may run before a senior review. Without that, a mitigation that blocks legitimate customers abroad can outlast the attack itself, and the bank ends up doing the attacker’s job for them. A short runbook for each rule, with the expected effect on genuine customers, lets the on-call engineer act in minutes and lets the reviewer judge whether to keep it.

Exercising the whole response

Technical tests of mitigation are necessary but cover only part of the problem. A tabletop exercise that combines a DDoS on online banking with false messages about the bank, run with communications, legal, operations, the contact center and a vendor representative in the room, tests the rest. It shows who decides, how long the first message takes, whether the status page can be updated and whether staff hear the news before customers do. Running it once a year, with a different scenario each time, keeps the plan current as people and vendors change.

Measuring from the outside

Internal monitoring can show servers as healthy while customers cannot reach them, because the failure is upstream. Synthetic monitoring, which runs scripted logins and balance checks from several outside locations every few minutes, sees the service as customers do. It gives the earliest warning and the clearest evidence of when service was restored. Service-level reporting to the board should use those outside measures, not server uptime.

A Saturday morning at a mid-sized lender

Suppose a mid-sized lender pays a well-known provider to protect its website and online banking. On paper, it is covered. One Saturday morning, its app stops working. The protected website is fine. The trouble is that the app talks to a separate set of servers run by a software vendor, and that vendor’s protection is weaker. Nobody at the bank had written that link down.

The on-call engineer can see the problem but does not have authority to switch on geographic filtering, which would block some genuine customers traveling abroad. The person who does have authority is at a family event. By the time a decision is made, two hours have passed, social media is filling with complaints, and a rumor is spreading that the bank has been hacked and accounts are frozen. In fact cards and ATMs are working normally throughout, but nobody has told customers so.

The contact center opens at nine with a skeleton weekend staff. Within minutes, every line is busy. The bank’s own status page is hosted on the same platform as the app, so it is down too. A local reporter emails the press office, which has no one on duty until Monday. The vendor’s support desk opens a ticket and promises an update within four hours under its contract.

Nothing in this story involves a sophisticated attacker. Every weakness is organizational: an unmapped dependency, an unclear decision right, a vendor contract with the wrong response time, and silence. Those are the weaknesses the Ukrainian episode exposed, and they are the ones leaders can fix without a large technology budget.

The same morning goes differently with preparation. The dependency map lists the vendor’s servers, and the vendor’s contract requires the same level of protection as the bank’s own. The on-call engineer has authority to apply a pre-approved filter for up to two hours. A pre-approved message goes out by text within fifteen minutes saying the app is slow and that cards and ATMs work normally. The status page, hosted separately, says the same, with a time for the next update. The contact center has a recorded message ready. By the time the rumor starts, the bank’s account of events is already the one customers have seen.

Keeping customers informed

When a service fails, customers look for an explanation. If the bank provides none quickly, they find one elsewhere, and in a crisis that may be rumor or deliberate falsehood. The false ATM messages in Ukraine filled exactly that gap. Disinformation, meaning false information spread on purpose, works best in a vacuum. The fastest way to shrink the vacuum is to fill it with accurate information first.

What the first message says

Effective outage communication is fast, plain and consistent across channels. It says what is affected, what still works, what customers should do and when the next update will come. It must be published through channels that do not depend on the affected systems, such as a status page hosted separately, the bank’s social media accounts, and text messages from a registered sender. A notice posted only inside the app that is down is no notice at all. It works best when drafted in advance, with templates already approved by legal and communications staff, so that the first message goes out in minutes rather than hours.

A small set of templates covers most cases: online banking slow or unavailable; card payments affected; a wider outage affecting several channels; and a rebuttal for false messages circulating about the bank. Each template has blanks for the affected service, the working alternatives and the time of the next update. The approval chain for filling those blanks during an incident should be one or two people, named in advance.

Speed against certainty

Speed is a trade-off. Early messages may later prove incomplete. A bank that waits for certainty, however, leaves the field to others. A short first statement that names the problem and promises the next update by a stated time is safer than silence. Executives should agree that rule before an incident, because the instinct during one is to wait. Lawyers worry about admitting fault, technical teams want to understand the cause, and communications staff want a polished message. All of those instincts are reasonable, and all of them slow things down.

The first message need not say what caused the problem. Saying that a service is degraded, that the bank is working on it, that money is safe if the bank knows it to be, and that cards and ATMs work, is enough. Attribution to an attacker can wait for evidence. A bank that speculates about causes early risks having to correct itself, which damages credibility at the worst moment.

Telling real messages from fakes

Customers also need a way to tell the bank’s messages from fakes. That depends on habits set long before a crisis: a small number of official channels, a known sender identity, and a stated rule that the bank will never ask for passwords or codes. A bank that has taught those habits can point to them when fakes appear. One that communicates through a shifting mix of vendors and formats cannot. If customers are used to receiving texts from five different short codes and emails from three different domains, a sixth fake one does not stand out.

Technical measures help at the edges. Email authentication standards such as DMARC, set to reject unauthenticated mail, make it harder to send email that appears to come from the bank’s own domain. Registered sender identities for text messages reduce some spoofing, though protections vary by country and carrier. Neither stops a fake message sent from an unrelated number. So the main defense is the customer’s habit of checking the bank’s official channels, which only works if the bank uses them consistently.

Speaking alongside the authorities

In Ukraine, public denials by the authorities helped counter the false ATM messages. A bank’s message carries more weight when regulators, the central bank or industry bodies say the same thing. That coordination works best when contacts are established in advance. They include the regulator’s incident line, the national computer emergency response team, an information sharing body such as FS-ISAC, and law enforcement. Sharing indicators with peers during an attack can also help other institutions prepare, since campaigns of this kind often hit several banks in a sector at once.

Staff as a channel

Branch staff and contact center agents are themselves a communication channel. During an outage, customers ask them what is happening. If staff learn about the incident from social media, they cannot reassure anyone. An internal alert that goes to every customer-facing employee at the same time as the first external message, with a short script, keeps the bank speaking with one voice.

Keeping other channels open

If online banking is degraded, customers need other ways to reach their money: cards, ATMs, branches and phone banking. These often run on different infrastructure. Card authorization, the split-second check that approves a card payment at a till, and ATM networks frequently keep working when a bank’s web and app front ends are under attack. Saying so, clearly and quickly, answers the question that the false messages raised. “Our app is slow; your cards and cash machines are working normally” is a sentence that can calm a great deal of fear.

The channel matrix

That requires the bank to know, for each disruption scenario, which channels stay up. A matrix links scenarios such as a DDoS on online banking, a core processor outage or a regional telecommunications failure to each channel’s status. It is a short document with large value. The core processor is the central system that keeps the official record of every account and balance; many banks rent it from a specialist provider. The matrix tells the communications team what to say and the operations team where to send staff.

Building the matrix forces useful checks. One is whether card authorization depends on the same network link as online banking. Another is whether phone banking uses the same identity service as the app. A third is whether ATMs fall back to offline limits if the connection to the core is lost. Each answer either confirms an independent channel or reveals a shared dependency that one attack could take down. The matrix should be checked against real incidents and exercises, because assumptions about independence are often wrong.

Branches and contact centers

It also bears on branch and contact center strategy. Banks closing branches and shifting service online have fewer fallback channels when digital ones fail. Digital migration brings real benefits in cost and convenience, and stopping it is the wrong answer. Each closure plan should instead state how customers in that area will reach cash and service during a prolonged digital outage. Contact center capacity should be sized for the surge that follows any visible disruption. When an app goes down, the phones light up within minutes. A contact center that cannot answer is, from the customer’s side, a second outage.

Contact center surge can be planned like any other capacity. A recorded message at the front of the queue, updated with each external statement, answers many callers without an agent. Overflow arrangements with another site or provider, and a list of trained staff from other departments who can be called in, add capacity. Callback options keep customers from holding for long periods. Each of these can be set up in advance at modest cost.

Cash as the last resort

In a crisis of confidence, cash is the channel customers trust most. The Ukrainian false messages targeted ATMs for that reason. A bank should know how much cash its ATM fleet and branches can dispense in a surge, how quickly it can be replenished, and what limits it would apply. Those are uncomfortable questions, but a bank that has answered them can speak calmly about cash access when a rumor starts.

Trust drains faster than systems recover

The direct cost of a few hours of degraded online banking is usually modest. The indirect costs are not. A visible outage during a period of public anxiety can trigger complaints, regulatory questions, press coverage and, in the worst case, customers moving money elsewhere because they have lost confidence. Banking runs on trust, and trust can drain much faster than systems can be restored.

Regulators increasingly look at the problem the same way. Their question is less whether the firewall was configured correctly. It is more whether customers could still do the important things, and whether the bank told them what was happening. That shifts responsibility from the technology department alone to the whole leadership team. Communications, operations, legal, branch networks and contact centers all play a part in whether an outage stays a technical nuisance or becomes a crisis of confidence.

In the United States, the federal banking agencies finalized a notification rule in November 2021, with compliance required from May 1, 2022. It requires banks to notify their primary regulator within 36 hours of a computer-security incident that has materially disrupted, or is reasonably likely to disrupt, their operations or customers’ access to services. Bank service providers must tell their bank customers as soon as possible when an incident has disrupted or is likely to disrupt services for four hours or more. A prolonged DDoS on a bank’s main channels may well meet that threshold, so the notification decision belongs in the incident plan alongside the customer message.

There is a reputational asymmetry, too. Customers rarely praise a bank for staying up. They remember vividly when it went down and nobody explained. The investment in preparation is largely invisible when it works, which is exactly why it tends to be underfunded.

The case against planning for belief

The strongest objection is that the Ukrainian case was exceptional. A country on the eve of invasion, with state-owned banks as targets and a hostile state behind the attack, is not the situation most banks face. For a regional lender in a stable country, a few hours of slow online banking will rarely cause panic. Spending heavily on communications planning for a remote scenario looks like poor use of money. The answer is that the preparation costs little. Templates, a channel matrix, decision rights and a separately hosted status page are inexpensive, and they help with every outage, including the far more common ones caused by failed software changes or vendor problems.

A second objection holds that fast communication can make things worse. Telling customers about an attack may spread alarm that would otherwise not arise, and early statements may be wrong. That risk is real for statements about causes. It is much smaller for statements about what works. Telling customers that cards and ATMs are working is both verifiable and calming. Silence about a visible outage does not prevent alarm; it surrenders the explanation to others.

A third objection holds that DDoS protection is now a commodity: buy a good provider and the problem is solved. Mitigation services have indeed become capable and widely available. But the gaps described here are not in the provider’s network. They are in what the bank chose to put behind it, who can act at 3 a.m., and what the bank says to customers. No provider can fix those for the bank.

A fourth objection holds that keeping branches and phone capacity as fallbacks slows the move to digital and raises costs. The point of the channel matrix and closure plans is proportion, not preservation. A bank can close branches and still be able to say, for each area, how customers will reach cash during a long outage. Sometimes the answer is a shared ATM network or a partner, at little cost.

Where the argument is weakest is for very small institutions that rely on their core processor and digital banking vendor for almost everything. For them, much of the work falls on contract terms and vendor oversight rather than in-house capability, and the bank’s realistic role is to ask the right questions and to own the customer message.

How it plays out by institution

Credit unions and community banks

Most credit unions and community banks rent their core processing and digital banking from a small number of specialist providers. Their exposure to DDoS is largely the provider’s exposure, and an attack on one provider can affect many institutions at once. Their priorities are contractual. They need to confirm what DDoS protection covers each service they use and what notification the provider owes them, and how fast. They also need to be able to publish their own customer messages when the provider’s systems are down. Federally insured credit unions also have their own notification duty: since September 1, 2023, an NCUA rule has required them to report a reportable cyber incident to the agency within 72 hours.

Large and regional banks

Larger banks run more of their own infrastructure and can engineer protection directly. Their challenge is complexity: hundreds of customer-facing services, many owned by different business lines, with dependencies that change every month. For them, the dependency map is a living inventory tied to change management, and DDoS exercises are part of a wider resilience testing program. The largest US banks were also the audience for the agencies’ 2020 paper on sound practices for operational resilience, which asked them to identify critical operations and plan to keep them going through disruption.

Broker-dealers and wealth managers

For broker-dealers and wealth managers, an outage during market hours prevents clients from trading, which turns a service problem into a potential loss for the client. Business continuity plans required under FINRA rules for broker-dealers should address how clients can place orders and reach their assets if online channels fail, and how the firm will tell them so. Many such firms already route clients to phone trading desks during outages; the capacity of those desks in a surge is the question.

Banks operating in the UK and EU

Firms with UK or EU operations face explicit rules. The UK framework asks firms to identify important business services, set impact tolerances for each and prepare internal and external communications plans for disruption. The EU’s Digital Operational Resilience Act sets requirements for ICT risk management, incident reporting, resilience testing and oversight of third-party providers. A US bank with a European subsidiary may find those rules setting the standard for the whole group.

The habits of a prepared bank

A well-prepared bank tends to share a few traits:

• A complete dependency map. Every customer-facing service is listed with what it relies on, who owns each piece and whether it is protected against denial-of-service traffic.
• Tested protection. Mitigation is exercised with simulated attack traffic, in coordination with providers, rather than assumed from a contract.
• Clear decision rights. A named person, reachable out of hours, can switch on traffic triage rules, with a set time for senior review.
• Outside-in monitoring. Scripted checks from outside the bank show what customers see, and feed the board’s service reporting.
• Pre-approved messages. Templates for common scenarios are signed off in advance and published through channels independent of the affected systems.
• A channel matrix. For each type of disruption, staff know which ways of reaching money stay open and say so.
• Surge capacity. Contact centers and branches have a plan to handle the wave of calls and visits that follows a visible outage.

Unprepared banks are the mirror image. Banks assume the mitigation contract covers everything. They treat communication as something to sort out once the technical cause is known. They let marketing, servicing and security each send customers messages from different channels, which trains customers to trust anything that looks roughly official. And they close branches or cut contact center capacity without asking what happens on the day the app is down.

Each habit leaves evidence an examiner or auditor can review. The file includes the dependency inventory with owners, test reports from simulated attacks, the decision-rights document and on-call rota, monitoring dashboards, approved templates, the channel matrix and the surge plan. A bank that can produce these in an afternoon has done the work.

Where the next outage would hurt

• Which of our customer-facing services are covered by denial-of-service protection, and which are not? Who owns the gaps?
• Who can switch on emergency traffic rules at 3 a.m. on a Sunday, and how long can those rules run before someone senior reviews them?
• Do we have pre-approved outage messages, and can we publish them if our website and app are both down?
• How would a customer tell a genuine message from us apart from a fake one? Have we taught them?
• For a denial-of-service attack on online banking, which channels stay open? Could our communications team say that within fifteen minutes?

Behind the first question are more specific ones. They concern whether the DNS provider, the identity service and the mobile app back end have the same protection as the main website, and when that protection was last tested. Behind the last is the contact center, and how many calls it could answer on a busy morning with the app down. So is every planned branch closure, and how customers in that area would reach cash during a long digital outage. Asking any of this takes no deep technical knowledge, and the answers show quickly whether resilience is a plan or a hope.

With hindsight

The Ukrainian banks recovered quickly, and the February attacks were modest beside what followed the invasion. Ukraine’s banks kept operating after the invasion began, under emergency measures from the central bank, despite continued attacks on the country’s networks. A banking system under sustained pressure can keep serving customers, but only with fallbacks and steady communication in place before the pressure arrives.

Over the next two years, pro-Russian hacktivist groups ran denial-of-service campaigns against banks, airports, hospitals and government websites in the United States and Europe. “Hacktivists” are groups that attack for political motives rather than money, often loosely organized and keen on publicity. In October 2022, one such group, Killnet, took several US airport websites offline for a time. In January 2023, Killnet ran a campaign against German agencies and companies, announced in advance as retaliation for the decision to send tanks to Ukraine. Their campaigns mostly caused short outages and headlines rather than lasting harm, which is itself telling: the goal was attention and unease, not theft.

Large providers were not immune. In June 2023, Microsoft said that application-layer DDoS attacks by a group calling itself Anonymous Sudan had caused temporary disruptions to some of its online services. It said it had seen no evidence that customer data was accessed. The episode showed that even the biggest platforms can be slowed by floods of requests that look legitimate, which is a reason for banks to map their dependencies on those platforms too.

Attack volumes set new records as botnets of compromised devices grew. In October 2023, Google, Cloudflare and Amazon Web Services jointly disclosed a flaw in the HTTP/2 web protocol, known as Rapid Reset, that had let attackers generate record request rates from relatively few machines. Cloudflare alone saw attacks peaking above 200 million requests per second. In the third quarter of 2025, Cloudflare reported mitigating an attack of 29.7 terabits per second from a botnet it called Aisuru. Every poorly secured camera, router or server connected to the internet is a potential recruit, and there are ever more of them. For banks, that means the raw size of what protection must absorb keeps rising, and contracts sized for yesterday’s attacks may not cope with tomorrow’s.

A different kind of event showed how fast confidence can drain in a digital banking system. In March 2023, depositors withdrew about $42 billion from Silicon Valley Bank in a single day, according to its California regulator, as worries spread on social media and customers moved money through online channels. The cause was financial, not a cyberattack. The mechanism was the one the Ukrainian attackers tried to exploit: fear spreading faster than the institution could explain itself.

Regulators, meanwhile, increasingly framed resilience as the ability to keep important services within set tolerances. A firm must decide how much disruption to a given service is acceptable, for example how long customers can go without making payments, and then show it can stay inside that limit. The UK’s operational resilience rules came into force in March 2022 and took full effect at the end of March 2025, and they include preparing internal and external communications plans. The EU’s Digital Operational Resilience Act applied from January 2025. Both direct firms to plan for disruption from the customer’s side as well as from the server room. In March 2026, the UK’s Financial Conduct Authority published further requirements for reporting operational incidents and third-party arrangements, taking effect in March 2027.

In the United States, the 36-hour notification rule for banks took effect for compliance in May 2022, and the NCUA’s 72-hour rule for credit unions followed in September 2023. Both made the decision about whether an outage counts as a notifiable incident part of every serious disruption.

By this point in 2026, the banks that handle disruptive events best treat communication, fallback channels and contact center surge as part of resilience design. Mitigation contracts alone do not reassure a frightened customer. February 2022 showed that attackers do not need to break a bank to hurt it. They only need to make people believe it is broken. Leaders who plan for the belief as carefully as for the breakage are the ones whose customers stay calm.