Capital One outage, January 2025: a vendor data centre failure and the posting backlog it left

The public timeline of the Capital One outage

This is a retrospective: the outage ran from 15 to 19 January 2025, and we published this post on 14 April 2026. Every entry below comes from press reports that quote Capital One, FIS, or BOK Financial, and we re-read each report on 2026-09-22. We found no public post-mortem from either company and no regulator or congressional letter about the outage.

PIX11 dates the FIS "restored access" statement to Thursday; NBC News reported it on Friday afternoon. Neither report changes the sequence: applications first, posted transactions later.

The failure class: one vendor core down, then a posting backlog

The sources describe two phases. In the first, applications at an FIS data centre went offline, deposits, ACH payments, and transfers were delayed at Capital One, and Bank of Oklahoma counted itself and 26 other banks as affected. In the second, access returned on Friday, but posting the transactions from the offline window ran into Saturday, and full functionality for all Capital One customers came back on Sunday.

The money risk sits in the second phase. A backlog of payroll credits, ACH debits, and card activity posts after the fact, and every fee rule, balance display, and customer retry that runs during that window sees an incomplete ledger. BOK Financial's promise to refund fees "incorrectly assessed" is the public trace of that window. The sources report no duplicate postings at Capital One; duplicate and out-of-order postings are the defects we look for in any backlog replay, and the tests below are our practice, not a rule.

A regulatory marker falls in the same week. The EU Digital Operational Resilience Act (DORA) applied from 17 January 2025, the Friday of the outage, as American Banker noted. Our DORA testing requirements page lists the third-party and continuity clauses; a US bank sits outside DORA, while an EU credit, payment, or e-money institution on a hosted core falls within it.

Why a hosted core outage is a testing problem

A bank or fintech on a vendor core does not control the vendor's data centre. It does control three things that decide the customer outcome, and each one breaks a money flow.

• Payroll credits and early release. A product that releases direct deposits before settlement credits the customer on receipt of the payroll file, then posts the settled entry later. When both arrive from one recovery backlog, a posting job that treats them as two credits pays the wage twice, and the reversal lands on a customer who already spent it.
• Fees against a stale balance. Overdraft, returned payment, and late fees evaluated while inbound credits wait in the backlog charge customers whose true balance was positive. Each fee becomes a refund, a manual adjustment, and a complaint; American Banker reports customers sharing the Consumer Financial Protection Bureau complaint link during the outage.
• Customer retries. A bill payment or transfer that shows as failed during the outage gets sent again from the app. When the original also posts from the backlog, the customer pays twice. The payment idempotency testing guide covers the retry cases at the API level.

PIX11 reported small business and commercial accounts among those affected, and for them the same pattern hits payroll runs and supplier payments; the business banking segment page maps the ACH and wire flows.

What to test before your core vendor fails

Vendor failover drills

Run the drill in staging with the core or processor connection behind a fault injection proxy, and schedule it across a synthetic payroll file arrival.

1. Refuse connections to the core stub, then time out after the core accepts a request. Pass: card authorisation follows the stand-in mode in the continuity plan, and no transfer with an unknown outcome reads "failed".
2. Keep the core down past the payroll file cut-off. Pass: inbound entries queue with their original effective dates, and nothing posts twice when the core returns.
3. Restore the core. Record time to first successful transfer and time to a drained backlog, per function.

The operational resilience testing service runs the full fault set for every provider; this drill is the hosted core case.

Replay and idempotency of postings after recovery

We seed a synthetic backlog and replay it twice. Our key for an inbound ACH entry is the 15-digit trace number from the Nacha file together with the settlement date, and the check is one posting per key.

After each run, the ledger reconciles against the synthetic file totals; the ledger reconciliation testing guide sets out the break report.

Status and balance consistency across channels

A Friday customer quoted by Banking Dive wrote that the paycheck was "still not deposited or showing as pending". The test compares what each channel shows at the same moment during the drill and after recovery.

• Available balance and pending list match across the mobile app, web banking, card authorisation, and the support agent's tool.
• An expected payroll credit shows as delayed with a reason, and never disappears from the pending list.
• The outage banner and status page switch on from the vendor health signal, and switch off only after the backlog drains.
• Statements and transaction exports for the outage window reconcile with the ledger after recovery.