Capital One Days-Long Outage and Class Action: When Banking Infrastructure Fails
BankingUS Top-10 Bank (Retail and Commercial)January 18-22+, 2025 (outage); January 29, 2025 (class action filed)

Capital One Days-Long Outage and Class Action: When Banking Infrastructure Fails

In January 2025, Capital One suffered a multi-day outage that locked customers out of accounts, delayed direct deposits, and triggered a class action lawsuit — demonstrating the legal and operational consequences of inadequate resilience.

Published

Key Metrics

Outage Duration

Multiple days

was: N/A

Started January 18, 2025; persisted through January 22+

Affected Customers

Millions

was: N/A

Core banking services inaccessible

Root Cause

Third-party vendor failure

was: N/A

Single point of failure in technology stack

Legal Consequence

Class action lawsuit filed

was: N/A

Filed January 29, 2025 via ClassAction.org

Services Affected

Mobile + online + ATM disruption

was: Normal operations

All digital channels simultaneously

The Situation

From Outage to Courtroom

The Capital One outage escalated from a technology incident to a legal crisis within days. On January 29, 2025, ClassAction.org reported that a class action lawsuit had been filed against Capital One, alleging that the bank had failed to maintain adequate technology infrastructure and had caused direct financial harm to customers through the multi-day service disruption.

The Class Action Allegations

The lawsuit alleged several specific failures that map directly to DORA requirements:

Failure to maintain resilient systems (DORA Art. 9 equivalent): The complaint alleged that Capital One's technology infrastructure was inadequate for a bank of its size and customer base. A multi-day outage affecting core banking services — account access, deposits, payments — demonstrates a level of system fragility that is inconsistent with the resilience expectations for a top-10 US bank.

Failure to provide timely customer communication (DORA Art. 17 equivalent): Customers reported that Capital One's communications during the outage were delayed, inconsistent, and insufficient. Many customers learned about the outage through social media reports rather than proactive bank communications. The absence of timely, accurate status updates prolonged customer uncertainty and increased the operational impact.

Third-party vendor risk management failure (DORA Art. 28 equivalent): The identification of a third-party vendor as the root cause raised questions about Capital One's vendor due diligence, SLA enforcement, and contingency planning. A bank that depends on a single vendor for critical infrastructure without adequate failover capability has a material gap in its third-party risk management.

Consequential customer harm: The lawsuit detailed specific instances of customer harm — delayed payroll deposits causing missed bill payments, inability to purchase necessities, overdraft fees triggered by failed transactions, and late payment penalties from creditors. These consequential damages extend the financial impact well beyond the outage period itself.

The Capital One class action establishes an important legal precedent that has implications for DORA enforcement. In the US context, class actions provide a private right of action for customer harm caused by technology failures. DORA does not directly create a private right of action, but Art. 50 empowers supervisory authorities to impose penalties, and Art. 16 establishes requirements for customer communication during incidents.

The intersection of regulatory enforcement (DORA Art. 50) and private litigation creates a dual-track accountability mechanism. Financial institutions that fail to maintain adequate operational resilience face not only regulatory penalties but also civil liability for customer harm. The Capital One case demonstrates that the legal and financial consequences of inadequate resilience can be substantial — class action settlements in banking technology failures typically run to tens of millions of dollars.

The Insurance Dimension

The Capital One outage also raised questions about cyber insurance coverage. Technology outages caused by third-party vendor failures may or may not be covered by standard cyber insurance policies, depending on the policy's definition of "cyber event" and its treatment of third-party failures. For financial institutions, ensuring that insurance coverage extends to third-party technology failures — and that coverage limits are adequate for multi-day outages — is a risk transfer strategy that complements but does not replace resilience.

The Challenge

A Bank Goes Dark

On January 18, 2025 — a Saturday — Capital One, one of the ten largest banks in the United States by assets, experienced a technology failure that would cascade into a multi-day outage affecting millions of customers. The timing was, as with many banking outages, painful: the failure struck during a weekend when direct deposit payroll processing was occurring, meaning that customers who depended on Saturday or Monday morning access to deposited wages found their accounts inaccessible.

Fortune reported on January 22, 2025 that the outage had persisted for several days, with customers unable to access mobile banking, online banking, or in some cases ATM services. The root cause, according to Capital One's public statements, was traced to a third-party technology vendor — a single point of failure in Capital One's technology stack that, when it failed, took down multiple customer-facing services simultaneously.

The vendor dependency dimension is critical to the DORA analysis. Capital One, despite being a technology-forward bank that built its reputation on cloud-native infrastructure and advanced data analytics, was brought to its knees by the failure of a single third-party component. This is precisely the kind of concentration risk that DORA Art. 28-29 was designed to address — and precisely the kind of failure that demonstrates why third-party ICT risk management is a full pillar of the regulation.

The customer impact was severe and immediate. Direct deposits — salary payments, government benefits, social security payments — were delayed or invisible. Customers could not check balances, transfer funds, or make payments. For customers living paycheck to paycheck, the inability to access deposited wages during a weekend created genuine financial hardship. Social media channels filled with reports of customers unable to buy groceries, pay bills, or access cash.

The outage also exposed the fragility of the "digital-first" banking model. Capital One had aggressively promoted its mobile app and digital banking capabilities, encouraging customers to move away from branch-based banking. When the digital infrastructure failed, customers had limited alternatives — Capital One's branch network is smaller than traditional banks, and the branches that existed could not process the volume of customers seeking in-person assistance.

The Approach

DORA's Third-Party Risk Framework Under the Microscope

The Capital One outage provides a concrete case study for DORA's third-party risk management requirements (Art. 28-44), demonstrating how vendor dependency can become a systemic vulnerability even for technology-sophisticated institutions.

Art. 28 — General Principles for Third-Party Risk

DORA Art. 28(1) establishes that financial entities must manage the risks arising from their use of ICT third-party service providers. The Capital One outage demonstrated that this management must extend beyond contractual SLAs to operational resilience testing. A vendor may guarantee 99.99% uptime in its SLA, but if the institution has no failover capability when the vendor fails, the SLA guarantee is financially compensatory rather than operationally protective.

Art. 28(2) requires financial entities to assess whether contracting with a particular ICT third-party service provider would create concentration risk. The Capital One case suggests that this assessment must consider not just the vendor's market position but the institution's own architectural dependency. If a single vendor component is a single point of failure for multiple customer-facing services, the concentration risk is at the institution level even if the vendor is not a designated critical third-party provider.

Art. 29 — Preliminary Assessment of ICT Concentration Risk

Art. 29 requires a preliminary assessment of concentration risk before entering into contractual arrangements with ICT third-party service providers. The Capital One outage demonstrates what happens when this assessment is inadequate: a single vendor failure cascades into a multi-day outage affecting all customer channels.

The concentration risk assessment must consider not just "who is the vendor?" but "what happens if the vendor fails entirely?" For critical infrastructure components, the acceptable answer must include a concrete failover strategy — not a theoretical one, but one that has been tested under realistic conditions. The Capital One case suggests that the bank's failover capabilities for the affected vendor were either inadequate or untested.

Art. 30 — Key Contractual Provisions

DORA Art. 30 specifies key provisions that must be included in contracts with ICT third-party service providers, including clear descriptions of all functions and ICT services to be provided, data processing locations, SLA performance indicators, and termination rights. The Capital One outage raises questions about whether the contractual provisions with the failed vendor included adequate provisions for:

  • Service level guarantees that covered the specific failure mode that occurred
  • Incident notification requirements that ensured Capital One received timely notice of the vendor's failure
  • Audit and testing rights that would have enabled Capital One to verify the vendor's resilience capabilities
  • Exit strategies that would have enabled Capital One to transition to an alternative provider without multi-day service disruption

Recovery Time vs. Customer Expectations

The multi-day duration of the Capital One outage — in an era when customers expect 24/7 access to digital banking — demonstrates a fundamental tension in operational resilience planning. Technical recovery time objectives (RTOs) must be calibrated not just to business requirements but to customer expectations. A 48-hour RTO that might have been acceptable in the era of branch-based banking is catastrophic in the mobile-banking era.

DORA Art. 11(6) requires financial entities to test their ICT business continuity plans and their ICT response and recovery plans "at least yearly." The Capital One experience suggests that these tests must include realistic vendor failure scenarios with full customer channel impact, and that the tested recovery times must align with the expectations of a digital banking customer base — meaning hours, not days.

The Results

The Dual-Track Accountability Model

The Capital One outage and subsequent class action illustrate what may become the standard accountability model for operational resilience failures in financial services: simultaneous regulatory scrutiny and private litigation, creating compounding consequences for inadequate resilience.

Regulatory Consequences

US banking regulators — the OCC (Capital One's primary federal regulator) and the Federal Reserve — engaged with Capital One on the outage, requiring detailed root cause analysis, remediation plans, and enhanced monitoring of the vendor relationship that caused the failure. While specific regulatory actions are typically not publicly disclosed, the pattern of enhanced supervisory attention following major outages is well established in US banking regulation.

In a DORA context, a comparable outage at a European bank would trigger multiple regulatory responses. Art. 19 would require the bank to classify and report the incident to its national competent authority. Art. 17 would require a documented incident management response. Art. 11 would be invoked to assess whether business continuity plans were adequate. And Art. 28-30 would be examined to assess whether the bank's third-party risk management framework identified and mitigated the vendor dependency risk.

The class action filed against Capital One introduces a dimension that purely regulatory systems may not fully capture: the direct financial harm to individual customers. Class actions aggregate thousands or millions of individual harm claims into a single legal proceeding, creating liability exposure that can reach hundreds of millions of dollars in settlements.

For European financial institutions, while US-style class actions are less common in EU jurisdictions, the trend toward collective consumer protection mechanisms in Europe — including EU representative actions directive (2020/1828) — creates increasing potential for collective litigation following operational resilience failures. The Capital One precedent suggests that multi-day banking outages will generate legal liability in any jurisdiction with consumer protection mechanisms.

The Technology-Forward Paradox

Capital One's reputation as a technology-forward bank made the outage particularly damaging. The bank had positioned itself as a cloud-native, digitally innovative institution — a posture that attracted customers who valued digital banking capabilities. When that digital infrastructure failed for multiple days, the reputational damage was amplified by the gap between the brand promise and the operational reality.

This paradox is relevant for all digital-first banks: the more aggressively you promote digital capabilities, the higher the expectations your customers and regulators will have for digital resilience. A traditional bank with a large branch network can absorb a digital outage — customers can walk into a branch. A digital-first bank with a minimal branch network has no fallback channel, making digital resilience not just an operational requirement but an existential one.

Vendor Dependency as Systemic Risk

The Capital One outage reinforces a broader concern about vendor dependency in banking. As financial institutions increasingly rely on third-party technology providers for critical infrastructure — cloud platforms, payment processing, authentication services, data analytics — the failure of a single vendor can cascade through the institution's entire service delivery capability.

DORA's third-party risk framework (Art. 28-44) addresses this risk at the institution level. The EU's designation of Critical ICT Third-Party Providers (CTPPs) under Art. 31 addresses it at the systemic level. The Capital One case demonstrates that both levels of management are necessary: institution-level vendor risk management to ensure failover capabilities, and systemic-level oversight to monitor concentration risk across the financial sector.

Customer Communication as Resilience

The class action's allegations about inadequate customer communication highlight an often-underestimated dimension of operational resilience: the ability to communicate effectively with customers during an incident. Customers who understand what is happening, what the bank is doing about it, and when service will be restored can make informed decisions about alternative arrangements. Customers left in the dark panic, flood call centers, and amplify the crisis through social media.

DORA Art. 17(3)(e) requires financial entities to have communication plans for incidents. The Capital One experience demonstrates that these plans must include pre-drafted customer messaging for various outage scenarios, multiple communication channels (email, SMS, social media, website), and frequent status updates even when the status is "we're still working on it." Silence during an outage is not neutral — it is actively harmful to customer trust and the institution's operational position.

Lessons Learned

  1. 1DORA Art. 28-29 third-party risk management must go beyond contractual SLAs to include operational resilience testing — a vendor uptime guarantee is financially compensatory, not operationally protective, when failover capabilities are absent.
  2. 2DORA Art. 29 concentration risk assessment must consider the institution's architectural dependency on single vendors, not just the vendor's market position — a single point of failure for multiple customer channels constitutes material concentration risk.
  3. 3DORA Art. 11(6) business continuity testing must include realistic vendor failure scenarios with full customer channel impact, and tested recovery times must align with digital banking customer expectations (hours, not days).
  4. 4DORA Art. 17(3)(e) incident communication plans must include pre-drafted customer messaging, multiple communication channels, and frequent status updates — silence during an outage actively damages customer trust and amplifies the crisis.
  5. 5Digital-first banking strategies create heightened resilience obligations — aggressive promotion of digital capabilities raises customer and regulatory expectations for digital resilience, and minimal branch networks eliminate fallback channels.
outageclass-actionthird-party-riskvendor-dependencydigital-bankingcustomer-harmpillar-ipillar-iipillar-iiiconcentration-riskcapital-one

Disclaimer:This case study is based on anonymized data from real-world DORA compliance programmes. Names, specific figures, and identifying details have been changed to protect confidentiality. The outcomes described are specific to the institution's context and may not be directly replicable.

Facing similar challenges?

See how Valendir can help your institution achieve and maintain DORA compliance with deterministic workflows, immutable evidence, and continuous assurance.