U.S. Bank

U.S. Bank was listed by LockBit on August 20, 2026. The listing has not been independently verified, the bank has not publicly confirmed an incident, and no data types have been disclosed as of this writing.

U.S. Bank is among the largest banking institutions in the United States. As with every leak site claim in this series, the listing is a claim rather than a finding.

Not disclosed. No sample, no volume claim, no field list has accompanied the listing.

What a bank of this size holds, labeled as inference: core banking account and transaction records, card issuing and processing data, mortgage origination files containing income and employment verification, wealth management holdings, treasury services data for commercial clients, and Social Security numbers across effectively the entire customer base.

Mortgage files deserve specific mention. A mortgage application is one of the most complete financial dossiers a consumer ever assembles — income, employment, assets, debts, and identity documents in a single package.

If unsubstantiated, no customer is harmed and the cost falls on the bank as response effort and brief reputational noise.

If substantiated, retail customers face account takeover and new-account fraud, and the Social Security numbers involved make that harm durable rather than transactional. Commercial treasury clients face a different exposure: knowledge of payment patterns and authorised signatories is the raw material for business email compromise, which targets the company rather than the bank.

Wealth management data adds a targeting dimension, since it identifies high-net-worth individuals and what they hold.

Banking is the most prescriptively regulated data security sector in the United States. GLBA safeguards, OCC supervision, FFIEC examination, state financial regulators, and card network requirements all impose overlapping obligations, and large institutions maintain security programmes sized accordingly.

Regulation of this density produces genuine capability, and it also produces a specific assumption: that compliance depth equals response readiness. The two diverge under time pressure. An examination cycle measures whether controls exist and operate. It does not measure how fast you can establish what was in a named system when an extortion group posts your logo.

A bank of this scale is not one data estate. It is core banking, card processing, mortgage origination and servicing, wealth management, treasury, and the accumulated records of dozens of acquired institutions whose systems were migrated across three decades at varying levels of care.

Acquisition is the underrated source of uncertainty. Every merger brings a data estate that was inventoried, if at all, to the standards of the acquired institution, and post-merger integration prioritises the systems that must keep running. Archives migrate last or not at all.

So the question "what would have been in that system" has an answer that depends on which acquisition it came from, and that answer usually has to be reconstructed rather than retrieved.

The federal banking agencies' computer-security incident notification rule requires a banking organisation to notify its primary federal regulator as soon as practicable and no later than 36 hours after determining that a notification incident has occurred.

Thirty-six hours is not a scoping window. It is barely a triage window, and the clock starts on determination — which means the determination itself must be made quickly and be defensible afterward. Deciding too early risks notifying on a false claim; deciding too late risks a supervisory finding that the bank should have known sooner. GLBA customer notification, state statutes, and card network requirements all run on separate tracks behind it, and for a public company the SEC materiality assessment runs alongside.