Three MFTs. Same Crew. 8,000 Orgs. The Lesson Banks Keep Missing.

If you ask a community-bank CIO in 2026 what they spent the most time worrying about over the past three years, "ransomware" is probably the answer. If you ask which specific product class drove the most consequential breaches in financial services, the honest answer is more uncomfortable. It was the product class designed to make file transfer safer.

Between December 2020 and May 2023, the ransomware crew known as Cl0p (sometimes stylized CL0P or Clop) executed three back-to-back attacks against centralized managed-file-transfer products. Each attack used a different zero-day vulnerability. Each attack compromised the customer base of a different vendor. And each attack succeeded for the same architectural reason.

This is a post about that architectural reason. It is not a post about Cl0p, who they are, or what their next move is. There is plenty of forensic and law-enforcement reporting on that topic; CISA's joint advisory AA23-158A is a good public starting point. This is a post about why centralized file transfer kept getting hit, what the pattern means for community banks and credit unions still running these products in 2026, and what the alternative architecture actually looks like.

The 30-month timeline

The CVEs were different. The architecture wasn't.

It is possible to read the three breaches as three unrelated security failures. Different vulnerabilities. Different products. Different vendors. A clever incident-response writeup will tell you the technical fix in each case: patch the chain, restrict the admin console, sanitize the SQL parameter. All three are correct. None of them addresses the actual lesson.

The actual lesson is that all three products had the same architecture, and that architecture is what made each of them an 8,000-organization breach instead of a single-customer breach.

Centralized managed file transfer works like this: customer A and customer B both connect to a vendor-operated (or customer-operated, but vendor-architected) server. Files move through that server. Files often sit on that server, encrypted at rest under the server's keys. The server has authentication, audit logging, encryption-in-transit, and (if the customer pays for it) encryption-at-rest. By every checkbox in the FFIEC IT Examination Handbook, this is a defensible architecture.

Until someone gets root on the server. Then every file in transit, every file at rest, every authentication credential, every audit log, and every encryption key custody record becomes the attacker's. Not for one customer. For every customer connected to that server.

This is what security architects call a high-value target: a single point at which a successful compromise yields outsized return relative to the effort to compromise it. The phrase is older than ransomware; it predates Cl0p by decades. The Accellion FTA, the GoAnywhere admin console, and the MOVEit Transfer web UI were each a high-value target by definition. A ransomware crew motivated by extortion economics correctly identified them as such and went to work.

The vendors did not architect these products to fail. They architected them to do exactly what their customers asked: receive files, hold files, apply encryption to files at rest, and forward files on. The architecture that supports those features is the architecture that creates the high-value target. You cannot have one without the other if the design is centralized.

Why financial services felt this most acutely

Healthcare, manufacturing, and federal-government victims got more press from the Cl0p campaigns. Financial services got the most regulatory exposure. Three reasons.

First, the disclosure timeline. The FTC's amended Safeguards Rule, with the 30-day breach-notification provision effective May 13, 2024, applies to non-bank financial institutions and creates a tighter clock than the SEC's 4-business-day Form 8-K standard for materially significant cyber incidents. Banks that learned of MOVEit exposure through a service provider in 2023 had to map a chain of contractual notification obligations they hadn't war-gamed. NY DFS Part 500 imposes a 72-hour breach-notification clock for state-regulated banks and insurers. Several of the institutions caught in MOVEit's blast radius missed at least one of these clocks.

Second, the named victims. The Pension Benefit Information disclosure alone exposed records for several state retirement systems; CalPERS news release to California members named PBI as the source. Putnam Investments, TIAA, and several Vanguard service-provider relationships disclosed exposure. None of these institutions ran MOVEit themselves. Their data sat on someone else's MOVEit instance. Customer-level breach notifications still had to go out.

Third, the cost framing. IBM's Cost of a Data Breach 2025 report puts the financial-sector average at $5.56 million, with banking specifically at $9.28 million. That is the per-incident average. The aggregate cost of MOVEit-attributable breaches across the financial sector , settlements, class actions, notification, regulatory penalties, customer-support cost, brand harm , is not yet fully known three years on, but credible third-party estimates have put the global aggregate of Cl0p's three campaigns north of $10 billion.

What the FFIEC handbook actually says

The frustrating part of this story for compliance officers and ISOs is that the FFIEC IT Examination Handbook has been clear about transmission security for a long time, and the language is principle-based rather than device-specific. The Information Security booklet requires institutions to "use encryption to protect information in transit" and to "implement controls to manage access to systems handling sensitive customer information." The booklet does not enumerate which products implement that requirement, and it does not distinguish between an architecture in which the data sits on a centralized vendor server and an architecture in which it does not.

An examiner reviewing a bank's MFT deployment in 2022 would have correctly concluded that GoAnywhere was a defensible answer. An examiner reviewing the same deployment in 2024 would have less to work with , not because the regulations changed, but because the threat record changed. Three centralized MFT vendors have now demonstrated, in production, that the architecture creates a single point of mass failure. That is no longer a hypothetical. It is the public record.

The 2024 update to NIST SP 1800-29 began to incorporate this lesson by emphasizing data-flow inventory and least-privilege transmission. The expectation an examiner is likely to bring to the next FFIEC IT exam , informally, before it shows up in the booklet revision , is that institutions can articulate why their document-transport architecture does not create the same kind of high-value target the public record now recognizes as a known failure mode.

What "stateless transport" actually means

The architectural alternative to centralized MFT is sometimes called stateless transport or secure digital transport (SDT). The naming is less important than what it does and does not do.

A stateless transport system encrypts a file at the sender's device (or, in the case of an MFP, at the device's network egress before it touches SMTP). The encrypted container moves over an authenticated, ephemeral session directly to the receiver's intended system of record. The container is not stored at a vendor-operated central server, because there is no vendor-operated central server in the data path. There is a coordination service that handles authentication, routing metadata, and audit logging , but it does not hold the document, the encryption keys, or any customer-readable data. Once the receiver's system of record acknowledges receipt, the container evaporates.

The audit log persists at both endpoints (sender and receiver) and at the coordination service for compliance purposes. The document itself does not. There is no central store to compromise, because there is no central store. The architecture removes the high-value target by removing the asset the target was holding.

This is the architecture Botdoc has been building since 2014 and the architecture SecureMFP applies to multifunction printers in regulated industries. SecureMFP is operated under a clean unqualified SOC 2 Type 2 opinion, GLBA-aligned, FFIEC-aware, FERPA-certified, and PCI- and HIPAA-compliant. The point of the certifications, in the context of the Cl0p discussion, is not the certifications themselves; certifications can be earned by either architecture. The point is that the architecture passes those certifications without creating the high-value target the Cl0p campaigns proved exists in centralized designs.

The five-question test

If you are evaluating any current MFT, "secure email," or document-portal product in your bank's stack, the questions below are the ones the public record now suggests you should be asking. You can ask them of your own IT team for any internally operated product, and you can ask them of any vendor for any vendor-operated product. They are designed to be answerable in writing inside one business day. If they are not, that itself is a finding.

1. Where do my documents sit between sender and recipient? If the answer involves a vendor-operated server (or a customer-operated server architected by the vendor), the architecture has a high-value target by design. That does not automatically mean the product is unsafe. It does mean the public record now has three case studies of this architecture being compromised at scale.
2. How long do they sit there? Even 14 days of vendor-side retention is 14 days of exposure. Compare against the 4-business-day SEC 8-K material-incident disclosure clock, the 72-hour NY DFS Part 500 clock, and the 30-day FTC Safeguards clock. A vendor whose retention window exceeds your regulatory disclosure window is a structural mismatch.
3. Who has the encryption keys? If the vendor controls the keys to data at rest on their server, the vendor , or anyone who compromises the vendor , can read your documents. Customer-managed-key offerings exist; the question is whether you are using them.
4. What is the disclosure mechanism if the vendor itself is breached? Many MFT contracts written before 2023 specify 30- to 90-day vendor-to-customer breach-notification windows. That timeline does not align with the regulatory clock running on you. A re-papered contract is a worthwhile project; an architecture that does not put you on someone else's clock is a better one.
5. What does the FFIEC handbook say about your specific transport architecture? Read the relevant section of the Information Security booklet with your transport architecture in mind. The booklet is principle-based. Your architecture is concrete. Map one onto the other in writing. If the mapping requires you to assume risks the booklet does not name explicitly, document the residual-risk acceptance and have the right approver sign it.

What banks are actually doing in 2026

The post-MOVEit response across financial services has not been a wholesale rip-and-replace of MFT. Nobody has the budget for that, and the regulators have not asked for it. The post-MOVEit response has been quieter and more practical: institutions are using vendor renewal cycles to ask the architecture questions they did not ask the first time. They are mapping document workflows that previously got bucketed as "just file transfer" , payroll exports, deal-jacket transmissions, FBAR filings, beneficial-ownership transmissions, audit-firm document exchange , and asking which of those workflows actually require a centralized server in the data path. For most of them, the honest answer is none.

Scan-to-email is one of those workflows. So is the SAR/CTR transmission pipeline that BSA officers run. So is the auditor document exchange your audit firm receives during the mid-cycle review. Each of these is a candidate for a stateless transport. Each of them is currently running on architecture that has Cl0p risk by design.

The finance vertical pillar on this site goes deeper into the FFIEC framework, the four-role buying committee, and the trace-template offer for your IT team to verify scan-to-email exposure on three devices in one afternoon. The auditor page covers the same argument in the language your audit firm and FFIEC examiner will recognize. If you have not yet read the audit-gap framework that paired with this post, the Morgan Stanley $35M case study is the most-shared piece on this blog and a useful companion.

If you are running an MFT product in your stack today, that product is not necessarily the wrong choice. It may be the right choice for your specific workflow. The question worth asking before next year's exam is the architecture question , not the CVE question. Cl0p answered the CVE question three times. The architecture question is yours to answer.