Finzly Told Banks They Need Evidence, Not Trust. Then the Keys to Its Fed Firewall Went Public.

Decrypted on October 15

Somewhere in the files an extortion crew calling itself n0n published this week sits a summary note. According to American Banker, which reviewed the files, it says the secrets in the configuration "were decrypted on Oct. 15." Annotations call the configuration the "2023 config." Five of the six files appear to make up the configuration of a Fortinet FortiGate firewall. One link in it is labeled "FED."

The firewall belongs to Finzly, a Charlotte, North Carolina company whose BankOS platform connects banks to ACH, Fedwire, FedNow and other payment networks. Finzly's website listed eleven banks and credit unions as clients the week n0n first named it: Synovus, First Citizens Bank, First Horizon, EverBank, Columbia Bank, Customers Bank, Live Oak Bank, 1st Source Bank, Metropolitan Commercial Bank, United Community Bank and Wings Credit Union. American Banker reports that BankOS links Finzly's clients to the payment networks through a single connection they share, and that the leaked firewall guards the link Finzly's bank clients use to send payment instructions to the Federal Reserve. Which of the eleven use that link, and for what, has not been reported.

Three days after the decryption note, at 8:23 PM Central on Sunday, October 18, ransomware.live recorded a new entry on n0n's leak site: "Finzly Corp." The listing promised "Network configuration and access secrets for payment infrastructure" and "Cloud environment topology and access keys." Two days after that, Finzly told American Banker it was "fully operational." After n0n's extended deadline lapsed on Tuesday night, October 27, the configuration was public. By October 30, Finzly's account had changed: "an unauthorized third party accessed a single device in our backup data center containing configuration information."

A Federal Reserve spokesperson said Fed payment services "were not impacted." Finzly says it has "rotated system keys and credentials" and that "At no point were Finzly's customer operations impacted." Nobody has reported money moving. Nobody has reported customer data taken. American Banker found none in the files and did not test whether the keys work.

That is the incident, and on the facts so far it may stay small. The incident is not the story. The story is that the best-documented weakness for turning a stolen FortiGate configuration into a ring of working passwords was acknowledged by Fortinet in 2019, given an opt-in fix in 2019 FortiOS releases that ships "disabled by default," and added to the federal list of exploited vulnerabilities with known ransomware use in June 2025. It is that the FBI and Secret Service told the country on October 6, nine days before the decryption note, that a credential campaign against FortiGate firewalls had, by SOCRadar's count, compromised more than 86,000 devices. It is that Finzly announced an AI-powered "continuous assurance" layer on September 3, telling banks they "need evidence that critical controls are operating as expected," and updated the page on October 13. And it is that the federal rule written in 2021 to make bank vendors tell banks about incidents leaves it to the vendor to decide whether it applies when the service never went down.

Finzly's clients, eleven of them listed on its website, send payments through one company's shared connection, and the firewall on its link to the central bank is now described in public. The question for their boards is not whether Finzly was hacked. It was; Finzly says so. The question is what each of those banks knew, when, and from whom.

What we verified, and what nobody has

Cloudskope ran the following passive checks between 1:55 and 3:00 AM Central on Saturday, October 31. We did not visit the leak site, download the files or test any credential. Everything we say about the files' contents comes from American Banker's published description.

• The listing. At 2:02 AM, ransomware.live's API returned one record for Finzly: group "N0n," discovered 01:23:07 UTC on October 19 (8:23 PM Central, October 18), sector "Financial Services," data size blank, description ending "[NOT PAID" followed by "EXPOSED]." The listing has not been removed.
• The website. finzly.com answered normally at 2:02 AM. Its WordPress feed shows no post after October 12 and no incident statement anywhere on the site; searches of the site for "incident," "unauthorized" and "n0n" return nothing about the event. The homepage, as served tonight, names one client (Wings Credit Union, in a testimonial). We could not retrieve an archived copy to compare against the client list American Banker saw, so we make no claim about whether anything was removed.
• The assurance page. The "Finzly Introduces Assure" release carries a September 3 dateline. The site's own metadata shows it was modified on October 13 at 14:42 UTC, two days before the decryption note.
• The firewall. Finzly's careers page, posted August 7, 2026 and still live, recruits a Senior IT Administrator to "Manage and maintain Fortinet network infrastructure" including "FortiGate firewalls (policy rules, VPN tunnels, NAT, IPS/threat protection)" and to "provide audit evidence for SOC 1/2, PCI DSS, FFIEC, and NYDFS examinations." That matches American Banker's reading of the files. It does not tell us which device was taken.
• Certificates. Certificate transparency logs list 34 distinct finzly.com names. One certificate has been issued since October 1, for a content host on October 17. Firewall keys, VPN pre-shared keys and admin passwords do not appear in public logs, so Finzly's statement that it rotated them cannot be checked from outside. Only Finzly's clients can verify it, and only by renegotiating the tunnels themselves.
• Filings. EDGAR full-text search finds thirteen documents that mention Finzly, most of them Metropolitan Bank Holding Corp. (NYSE: MCB) earnings exhibits. None was filed after March 2, 2026. No client has filed an 8-K on the incident. The only Item 1.05 cyber 8-K filed between October 27 and 31 was an energy-services company.
• The company. Finzly is private. Its two Form D filings record $10.05 million sold in 2023 and $6 million in 2026, with revenue "Decline to Disclose."

What nobody outside Finzly has established: when the backup-site device was first accessed; how; whether the 2023 credentials still worked in 2026; whether the device held anything beyond the configuration; when Finzly told the Federal Reserve; when it told its clients; and whether rotation happened before or after the files went public. Finzly's two statements give no dates for any of them. American Banker's Carter Pape asked several on October 20 and reported that the company did not say.

One distinction to keep straight: n0n has not published customer data, bank data or transaction data, and nobody credible has said it has. What it published is a map and a set of keys. That distinction matters, and it cuts in both directions. A map is not a heist. It is also not nothing.

What Finzly said, in order

Finzly has made two public statements, both through a spokesperson and both to one reporter. There is nothing on its website, nothing on its newsroom, nothing from its chief executive. Read in order, they tell a story by what changes between them.

As reported October 20. Finzly "recently learned that a cyber extortion group has named Finzly in an online claim." It is "actively investigating the claim with external cybersecurity experts." It is "fully operational."

Read closely, that statement is about the claim, not the intrusion. It does not say whether anything was accessed. It does not say whether a ransom demand arrived. It does not say whether clients were told or keys were changed. "Fully operational" answers a question nobody had asked. The listing did not say Finzly was down. It said Finzly's secrets were for sale.

As reported October 30. Finzly has "rotated system keys and credentials." An "unauthorized third party accessed a single device in our backup data center containing configuration information." "The possession of the compromised configuration information alone does not provide access to our systems or data." There is "no evidence that customer data or access information related to our banking customers' systems was compromised." "At no point were Finzly's customer operations impacted." "We continue to work closely with regulators and our customers." The spokesperson also told American Banker that Finzly has notified law enforcement, hired outside legal and forensic experts and begun communicating with customers.

That is more than Finzly said on October 20. Here is what it still does not contain.

• No date of access. "Accessed a single device" has no when. The decryption note says October 15. The files say 2023. Either the device was reached around mid-October, or it was reached earlier and the work happened later. Finzly has not said which.
• No date of rotation. "Rotated" is past tense with no clock. If rotation followed the October 18 listing, the window was days. If it followed the publication after the October 27 deadline, the window was longer. If the 2023 secrets had never been rotated before October 2026, that is the finding.
• No mechanism. Not how the device was reached, not whether the secrets were decrypted with a published key or cracked, not whether the device was internet-facing.
• A conditional where a fact should be. "Possession of the compromised configuration information alone does not provide access" is true of almost any configuration file. The word doing the work is "alone." A configuration plus one reachable management interface, or plus one stolen employee password, is a different sentence. Finzly did not write it.
• A scope limit on the reassurance. "No evidence that customer data or access information related to our banking customers' systems was compromised" is a statement about client systems. It is not a statement about Finzly's own systems, its own domain or the trust relationship between Finzly and the Fed.
• No notification dates. "Begun communicating with customers" and "work closely with regulators" say contact exists. Neither says when it began. That is the question that matters most to Finzly's clients, and the answer is the cheapest thing in this incident to give.

Set the two statements side by side and the arc is plain. On October 20, Finzly was investigating a claim. By October 30, the claim was a confirmed intrusion into a device holding the configuration of the firewall in front of its Fed link. What it knew on October 20, and when it learned the rest, is not in either statement.

The map is the product

n0n is new, and it is not subtle. American Banker reported that the group launched its leak site on September 18 and had posted 131 listings across 32 countries by October 20. SOCRadar's threat research unit, which obtained what it describes as the operator's exposed workspace, published a profile on October 28. It counted 93 victims and $283.7 million in ransom demands as of October 19, across fifteen sectors.

The profile's most important sentence is about method: "No vulnerability exploitation was identified: every documented compromise relied on weak or stolen credentials." SOCRadar documents credential stuffing against 305 FortiGate SSL VPN devices, weak RDP and WinRM passwords, exposed AWS keys and reused hosting-portal sessions. The toolkit includes a lightweight AES-256-CBC locker with Windows, Linux and PowerShell variants and an OpenSSL stage written for firewall appliances. Where the group does not encrypt, SOCRadar says, it "destroys data and backups after exfiltration." The operator ran the opencode coding agent against 154 model entries across seven providers; SOCRadar's verdict is "a human-directed operation supported by AI." The techniques map to MITRE ATT&CK T1078 Valid Accounts, T1110.004 Credential Stuffing, T1133 External Remote Services, T1485 Data Destruction and T1490 Inhibit System Recovery. SOCRadar's profile does not mention Finzly.

SOCRadar's separate page on the Finzly listing, published October 19, adds one fact that has not appeared in news coverage. Querying its infostealer telemetry for finzly.com returned 25 records, "all classified as internal employee credentials," with a freshness window running "from June 2026 through October 13, 2026." The endpoints include enterprise SaaS logins and, SOCRadar says, login.swift.com. SOCRadar is careful: "the telemetry confirms credential theft, not the specific intrusion method used against Finzly." We repeat the caution. The newest stolen credential in that dataset is dated two days before the decryption note. That is a coincidence of dates. It is not a demonstrated path.

Put the two SOCRadar documents together with American Banker's reading of the files and a working hypothesis emerges, which we label as one. Hypothesis: an operator whose documented method is stolen and stuffed credentials against FortiGate devices reached a Finzly device at a backup site, took a configuration that had been in place since 2023, and recovered the secrets inside it in mid-October. If that is right, nothing in this incident required a zero-day. It required a password, a device nobody was watching closely, and a configuration whose secrets were recoverable. Finzly can confirm or refute every part of that in a paragraph.

Why would a crew publish a firewall configuration instead of customer records? Because for a payments hub, the configuration is the valuable thing. It names the tunnels, the peers, the address ranges, the trust relationships and the credentials that hold them together. Sophos's Rafe Pilling made the point to American Banker: changing passwords does not change the network's trust relationships, so the map stays useful after the keys are rotated. Waseem Ahmed of Secure.com put it more sharply: "Network layouts, IP addresses, tunnel endpoints, and trust relationships change far more slowly than passwords." Huntress's Michael Tigges said decrypting the keys from the configuration was "absolutely plausible" and that in the worst case a leaked configuration "can lead to total domain compromise."

A firewall configuration is a blueprint of the side door. Finzly has changed the locks. The blueprint is still on the internet.

The key has been public since 2019. The fix ships switched off.

American Banker's article links one Fortinet document, and it is the right one to read first. Fortinet PSIRT advisory FG-IR-19-007, first versioned November 19, 2019 and titled "Hardcoded symmetric key in fips.c," describes "Use of a hard-coded cryptographic key to encrypt password data in CLI configuration in FortiOS, FortiManager and FortiAnalyzer." The National Vulnerability Database entry for CVE-2019-6693, published November 21, 2019, spells out what that key protects: "users' passwords (except the administrator's password), private keys' passphrases and High Availability password." Anyone holding a FortiGate configuration file and the key can read those secrets. The key is the same on every affected device. Public decryption tools, and the 2024 walkthrough below, have reproduced it.

Fortinet's remedy, added in FortiOS 5.6.11, 6.0.7 and 6.2.1 (2019 releases), is a setting that lets an administrator supply a private key instead:

config system global
set private-data-encryption enable /* disabled by default */
end

The comment is Fortinet's. The fix exists. It is opt-in. A device upgraded past the vulnerable versions without that line in its configuration still protects its stored secrets with the published key. Fortinet's workaround for everyone else is one sentence: "Always use a password to protect the system configuration file when performing backups."

In June 2024, the researcher Matthias Barkhausen published a walkthrough at cyber.wtf with a title that could serve as this article's epigraph: "Give Me Your FortiGate Configuration Backup and I Rule Your Network." He wrote that the key "was statically set by the manufacturer FortiNet" and that "The patch by FortiNet is no more than the recommendation to change the key."

On June 25, 2025, CISA added CVE-2019-6693 to its Known Exploited Vulnerabilities catalog. We pulled the catalog's JSON feed at 2:05 AM Central tonight. The entry is still there, with a remediation due date of July 16, 2025 for federal agencies and a ransomware field that reads "Known." CISA does not name the group in the catalog, and we will not guess.

We do not know that n0n used this key. The files are labeled 2023; a device running any FortiOS release from that year was long past the versions the advisory lists; and an administrator who enabled private-data-encryption would have defeated the published key. Equally, the decryption note says the secrets were decrypted, not cracked, and Fortinet's own advisory explains why that word fits a device where the setting was left at its default. Only Finzly knows which applies. It is the first question its clients should ask, because the answer tells them whether this was bad luck or a known, documented, six-year-old configuration choice.

FortiGate configurations have leaked before. Every time, the advice was the same.

This is not the first time a stolen FortiGate configuration has outlived the bug that exposed it.

January 2025. A group calling itself Belsen published configuration files and VPN passwords from roughly 15,000 FortiGate devices, as The Register reported on January 17, 2025. Fortinet CISO Carl Windsor wrote on January 16 that the data was "a resharing of data from previous incidents from dates prior to November 2022," most likely obtained through CVE-2022-40684, an authentication bypass patched in October 2022, with the VPN passwords tied to the older CVE-2018-13379. Each folder held "config.conf - The FortiGate configuration backup" and a VPN password file. Fortinet's reassurance carried a condition: if an organization had "consistently adhered to routine best practices in regularly refreshing security credentials," the risk was small. Configurations stolen in 2022 were being weaponized in 2025 against anyone who had not rotated.

April 2025. Fortinet disclosed that attackers who had exploited older FortiOS bugs had planted a symbolic link that survived patching, "allowing the threat actor to maintain read-only access to files on the device's file system, which may include configurations." Its instruction to customers was blunt: "Treat all configuration as potentially compromised." In July 2026, CISA added CVE-2025-68686, a bypass of the fix for that persistence mechanism, to the KEV catalog.

June to October 2026. The campaign now called FortiBleed began surfacing in June. Recorded Future's write-up, republished October 9, counted about 73,932 FortiGate firewall URLs and said the dataset "likely originated from exported FortiGate configuration files." On October 6, the FBI and the U.S. Secret Service issued joint advisory JCSA-20261006-01. It calls FortiBleed "an active, global credential-compromise campaign targeting internet-facing Fortinet FortiGate firewalls and secure socket layer (SSL) virtual private network (VPN) gateways, with SOCRadar verifying more than 86,644 compromised devices across 194 countries." The campaign, the advisory says, "exploits reused or leaked credentials and legacy SHA-256 password storage." Attackers used credential stuffing (T1110.004) and password spraying (T1110.003) "based on prior Fortinet leak dumps and infostealer logs," cracked dumped hashes offline, and sold access onward; the advisory names INC/Lynx and Payload as ransomware affiliates on the receiving end. Its key actions: lock down management access, terminate all admin and VPN sessions and reset credentials, and require phishing-resistant MFA. Its mitigations add a comparison of every configuration against a known-good baseline.

Nine days after that advisory, someone decrypted the secrets in Finzly's 2023 configuration.

Nothing in the public record ties Finzly to FortiBleed, and we are not drawing that line. The point is narrower and harder to dodge. By October 15, 2026, a payments vendor running FortiGate in front of its Fed connection had every public signal it could have wanted: a 2019 advisory about configuration secrets, a 2025 KEV listing with known ransomware use, a 2025 vendor instruction to treat all configurations as compromised, and a 2026 FBI advisory about a live credential campaign against exactly this device class. The common instruction in all four, stretching back six years, was to rotate the secrets and stop trusting old configurations. A configuration labeled 2023 was still sitting on a device at Finzly's backup site in October 2026.

One connection, eleven institutions, and a rulebook that already covers it

The Federal Reserve's rules for this arrangement are more specific than most bank boards realize. They live in Operating Circular 5, renamed "General Financial Service Provisions" in January 2026 and current in a version effective May 15, 2026.

The circular defines the role Finzly plays: "Service Provider means any entity, other than a Reserve Bank, that uses an Electronic Connection on behalf of an Institution." It contemplates exactly the shared model American Banker described, providing that a service provider "may use the same Access Control Features to act on behalf of other Institutions." It requires prior written notice to the Reserve Bank before an institution or service provider "shares the use of an Electronic Connection with another Institution or entity." And it makes clear who holds the bag: the use of a service provider "shall in no way affect or diminish any obligation or duty of the Institution."

Then there is section 3.2, which is the sentence every one of Finzly's clients should have open on Monday:

"The Institution or its Service Provider must immediately notify the Support Center by telephone at 833-FRS-SVCS (833-377-7827), with written confirmation via email at ccc.technical.support@kc.frb.org, of any suspected, threatened or known cyber event, fraud, malware detection, compromise, or other security incident or breach, that relates to or has the potential to impact an Electronic Connection, Access Control Feature, or the use of a Reserve Bank financial service, including (but not limited to) circumstances in which the Institution or the Service Provider have a reasonable basis to know or suspect that such event: (a) impacts or may impact software or hardware that the Institution or Service Provider use to engage or interface with an Electronic Connection or an Access Control Feature..."

That clause has no four-hour threshold. It has no materiality filter. It is triggered by a "suspected, threatened or known" event that "may impact" hardware used to interface with the connection. A firewall on the path labeled "FED," whose configuration an extortion group says it holds, is hard to read as anything else. The word is "immediately."

The Fed says its payment services were not impacted, which is a statement about the Fed's systems and is very likely true. It does not say when the Fed learned. Finzly says it is working with regulators. It does not say when it started. The gap between October 15 (decryption), October 18 (listing), October 20 ("fully operational") and whatever date Finzly called 833-FRS-SVCS is the most important undisclosed fact in this incident. The Fed and Finzly both know it.

The federal notice rule was written for outages, not leaks

In November 2021 the OCC, the Federal Reserve and the FDIC finalized the computer-security incident notification rule. Banks must notify their regulator within 36 hours of determining that a notification incident has occurred. Bank service providers have their own duty, and its text is identical across 12 CFR 53.4, 225.303 and 304.24:

"A bank service provider is required to notify at least one bank-designated point of contact at each affected banking organization customer as soon as possible when the bank service provider determines that it has experienced a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to such banking organization for four or more hours."

Read Finzly's October 30 statement against that sentence. "At no point were Finzly's customer operations impacted." If that is accurate, and if Finzly judged that a disruption of four hours or more was not reasonably likely, the rule's service-provider clause was never triggered. A reasonable lawyer could argue the other way, that a published configuration with keys makes disruption reasonably likely. But the rule leaves that judgment to the vendor. A vendor can lose the configuration of the firewall in front of its clients' Fed link, have it published, and conclude it owes those banks nothing under the federal notice rule, because the payments kept flowing. (Wings Credit Union sits outside that rule entirely; credit unions answer to the NCUA, whose own notification rule has its own terms.)

That is not a loophole Finzly invented. It is how the agencies wrote the rule; they scoped the service-provider trigger to disruption and left confidentiality to contracts. The banks' contracts may well require faster and broader notice; many do, and the agencies' June 2023 interagency guidance on third-party risk management tells banks to negotiate exactly that. The Bank Service Company Act, at 12 U.S.C. 1867(c), makes services a bank buys by contract "subject to regulation and examination by such agency to the same extent as if such services were being performed by the depository institution itself on its own premises." So the examiners can look. The question is whether anybody told them where to look, and when.

We noted the same structural gap two weeks ago when every bankruptcy court in the country lost its noticing contractor, and again when ConnectWise could not say which Microsoft 365 tenants a shared credential had reached. The federal rules ask vendors to report outages. The incidents that hurt banks this month were not outages.

"Ongoing evidence that critical controls are working"

On September 3, 2026, Finzly announced Assure, "an AI-powered security and assurance layer" for BankOS. The release is still on its website. Its subheading: "Continuous, AI-driven assurance strategy replaces point-in-time reviews, giving banks ongoing evidence that critical controls are working." Its central claim: "Banks need more than trust in their technology providers; they need evidence that critical controls are operating as expected." Its promised capabilities include "Continuous monitoring of attack surface risks rather than point-in-time reviews." Finzly's chief information security officer, Supro Ghose, is quoted: "Assure represents our commitment to making security and intelligence foundational elements of BankOS."

Finzly's site metadata shows the page was modified on October 13 at 14:42 UTC. Two days later, by the leaked files' own account, the secrets in a 2023 firewall configuration at Finzly's backup site were decrypted.

Earlier, in an interview Finzly published on its blog dated June 1, its CISO said that "Strong fundamentals," which he listed as secure development, layered controls, patch discipline, monitoring and identity management, "still make an enormous difference." He listed "MFA enforcement, least-privilege access, network segmentation" among the fundamentals Finzly had continued strengthening. And he warned that third-party risks "can cascade very quickly in financial services." On August 7, Finzly posted a job for an administrator to run its FortiGate estate and to "provide audit evidence for SOC 1/2, PCI DSS, FFIEC, and NYDFS examinations."

None of that is hypocrisy on its face. Companies announce security products and suffer incidents in the same quarter all the time, and a CISO's list of fundamentals is a statement of intent. It is the attestation gap, stated exactly. In September, Finzly told banks they should not have to rely on trust in a technology provider, that they need evidence. In October, the banks were asked to rely on trust: on a spokesperson's sentence that keys were rotated, with no date, no scope and no evidence. Finzly built a product whose premise is continuous proof. The proof its own clients need this week is not on its website.

Sixty-one days to sign

There is a date on the calendar that makes this concrete. The Federal Reserve's FedLine Solutions Security and Resiliency Assurance Program requires every institution using a FedLine solution to complete a self-assessment and submit an attestation "by December 31 annually." The program's own FAQ is explicit about vendors: "All institutions (each ABA and RSSD ID) utilizing a FedLine Solution, either directly or indirectly through a service provider or other agent, will need to complete an attestation." And: service-provider arrangements "do not transfer an organization's obligations or responsibility to comply with required security measures and controls." An institution that connects only through a provider "can look to its service provider to obtain information necessary to submit its attestation." The attestation is signed by "a senior management official or executive officer in charge of electronic payments operations or payments security."

From today, October 31, that deadline is 61 days away. If the Fed connection American Banker described runs over a FedLine solution, each of Finzly's bank and credit union clients will have a named executive sign a statement about the security of a connection whose firewall configuration is public, relying on information from the vendor whose device was breached. That executive is entitled to evidence. So is the board that executive reports to.

Immaterial to everyone, material to the connection

Every party here can truthfully call the incident small. The Fed's services were not impacted. Finzly's operations were not impacted. No customer data has been shown taken. None of the listed clients, several of them large regional banks, would plausibly find a vendor's leaked firewall configuration material to shareholders; none has filed. Metropolitan Commercial Bank, which told investors in March that its completed implementations include "Finzly for ACH, Wires, and real-time payments," will file its third-quarter 10-Q in the next two weeks. It is the listed client that has named Finzly in its SEC filings this year. The most likely outcome is that the 10-Q says nothing specific, which is a defensible reading of materiality.

The asymmetry runs the other way at the connection. For a private vendor whose two Form D filings record about $16 million raised, the Fed link and the clients behind it are the company. For each bank, the Finzly connection is one of dozens of vendor relationships. For the payment system, it is one more node that, if abused, would put fraudulent instructions on rails where Fedwire and FedNow payments settle with finality in seconds. Each party's materiality judgment is reasonable in isolation. Added together, nobody is required to say anything, and the one shared asset that matters most is the one nobody owns in public.

Questions Finzly has not answered

Finzly has not published a statement of its own. These are the questions its two statements to the press leave open. If Finzly answers them, this page will say so the same day.

1. On what date was the backup-site device first accessed, and on what date did Finzly detect it?
2. Was that device internet-facing? Was it a FortiGate, a management or backup host, or something else?
3. Was private-data-encryption enabled on the device whose configuration was taken? Were the secrets decrypted with Fortinet's published key or recovered another way?
4. Were the 2023 credentials still valid in October 2026? Which, if any, had been rotated before October 18?
5. On what date and time did Finzly notify the Federal Reserve Support Center under Operating Circular 5, section 3.2?
6. On what date did Finzly notify each client, and did it give them the list of rotated keys and the new tunnel parameters?
7. Does "rotated system keys and credentials" cover every secret in the leaked configuration, including VPN pre-shared keys and certificates negotiated with clients and with the Fed?
8. Did the device, or the account used to reach it, have access to anything beyond the configuration?
9. Is there any relationship between the 25 employee credentials SOCRadar found in infostealer logs and the access to the device?

What Finzly should have done by now

1. Published a dated statement. On its own website, under its own name, with the date of access, the date of detection, the date of Fed notification and the date of client notification. Four dates. None is sensitive. All are knowable.
2. Given clients evidence, not adjectives. A signed inventory of every secret in the leaked configuration, the date each was rotated, and the new parameters each client must negotiate. Finzly's own Assure release says banks need "evidence that critical controls are operating as expected." This is that evidence.
3. Re-keyed every tunnel with every client and with the Fed, jointly. A rotation done on one end only is a password change. A rotation both ends confirm is a control.
4. Enabled private-data-encryption and password-protected backups across the estate, if it had not, and said so. Fortinet's advisory has documented both for years.
5. Destroyed stale configurations. A 2023 configuration on a backup-site device in 2026 is an artifact an attacker wanted and nobody should have kept. Inventory every configuration copy, on every device and every backup target, and delete what is not current.
6. Acted on the October 6 FBI and Secret Service advisory, and said so. Terminate all admin and VPN sessions, reset credentials, restrict management interfaces to trusted hosts or remove them from the internet, and compare every running configuration against a known-good baseline. If Finzly did that before October 15, it should say so; it would answer a great deal.
7. Hunted backward, not forward. Review logs on every system reachable from the trust relationships in the leaked map for months before October 15, not just since the leak. The configuration says what an intruder could reach. The logs say whether one did.

Seven things. None requires new technology. The first costs one paragraph.

What boards should be asking this week

For the eleven institutions on Finzly's client list, five questions for Monday.

First: when did we learn, and from whom? If the answer is American Banker, that is the finding, and it belongs in the vendor file and in the minutes. If Finzly told us, get the date in writing.

Second: has our side of every tunnel to Finzly been re-keyed, and did our engineers do it with Finzly's engineers, or did we accept a statement that it was done? Ask for the change ticket. Secure.com's Waseem Ahmed told American Banker that banks should re-key and change the credentials they control "rather than waiting to be told."

Third: did we, or Finzly on our behalf, notify the Federal Reserve under Operating Circular 5, and when? The circular puts the duty on "The Institution or its Service Provider." If each assumed the other did it, nobody did.

Fourth: who in our institution will sign the FedLine Assurance Program attestation due December 31, and what evidence from Finzly will that person rely on? Get the evidence before the signature, not after.

Fifth: have we reviewed our own logs for unusual traffic from Finzly's address space going back months, not just since the leak, as Denis Calderone of Suzu Labs advised in American Banker's coverage?

For every other bank and credit union, one question. Which of our vendors holds a connection to a payment network on our behalf, what firewall sits in front of it, and when were its stored secrets last rotated? If nobody in the room knows, the vendor-management program is reviewing contracts and SOC reports while the configuration of the side door sits on a backup device somewhere, unreviewed.

For sponsors and acquirers

Payment-hub and banking-infrastructure vendors are usually diligenced on revenue retention, bank logos and SOC reports. This incident shows what those miss.

Ask the target for its network-device inventory, including backup and disaster-recovery sites, with firmware versions and the status of private-data-encryption on every FortiGate. Ask for the date every stored secret on every perimeter device was last rotated. Ask where configuration backups live, who can read them and whether they are password-protected. Ask which payment-network connections are shared across clients and how the Federal Reserve was notified of that sharing under Operating Circular 5. Ask for the target's infostealer exposure: services such as SOCRadar can show in an afternoon whether employee credentials are circulating. Ask what the target's contracts require it to tell banks about a confidentiality incident that causes no outage, because the federal rule may not require it.

For lenders and sponsors already holding such a business, the risk is not this week's headline. It is client attrition at renewal when a bank's risk committee asks why it learned from a trade publication, and examiner attention under the Bank Service Company Act. A week of work answers most of those questions. It is cheaper than the renewal conversation.

What we are not saying

We are not saying any money moved, any payment was altered or any customer data was taken; no source has said so and Finzly and the Fed say otherwise. We are not saying the leaked keys work today; Finzly says they were rotated, and American Banker did not test them. We are not saying the secrets were decrypted with Fortinet's 2019 key; we say it is one of two explanations and that only Finzly knows which. We are not saying Finzly is part of the FortiBleed campaign, or that the infostealer credentials SOCRadar found were used in this intrusion; SOCRadar itself says its data does not show the method. We are not saying any of the eleven listed institutions was compromised, uses the shared connection for any particular payment type, or has failed to meet any obligation. We are not saying Finzly failed to notify the Federal Reserve; we are saying it has not said when it did.

We are saying that a payments vendor whose clients share its link to the Federal Reserve kept a 2023 firewall configuration on a backup-site device into October 2026; that the best-documented weakness for making such a file readable was published in 2019, fixed by an opt-in setting shipped in 2019, and listed as exploited by ransomware in 2025; that the FBI and Secret Service warned about credential attacks on this exact device class nine days before the secrets were decrypted; that the vendor had announced to banks a product premised on evidence over trust six weeks earlier; and that the federal notice rule, as written, may not have required it to tell those banks anything. If Finzly would like to correct any of that, this page will be updated the same day.

Our record of these incidents

• Finzly BankOS FortiGate Configuration Leak, the verified timeline and running list of unknowns
• One Stolen Key. 300+ Companies' Email. ConnectWise 'Cannot Determine' Whose., the last time one vendor-held credential sat in front of many institutions
• BAE Was Hacked and Every Bankruptcy Court Went Silent. The Banks Are the Ones Without Notice., the same federal notice gap, from the creditor side
• 402,760 People. Nine Banks and Credit Unions. Mercadien Told Indiana in February and Fairwinds in August., a bank vendor's clock, read document by document
• PwC Won't Name the Vendor. Everest's Screenshot Does. It Says Staging., another non-production system that turned out to matter

Sources

• Carter Pape, American Banker, Extortion group leaks keys to bank vendor's Fed firewall, October 30, 2026
• Carter Pape, American Banker, Extortion group threatens to leak bank vendor's secrets, October 20, 2026
• Ransomware.live, Victim: Finzly Corp (N0n), listing discovered October 19, 2026 01:23 UTC; API checked October 31, 2026
• SOCRadar, Finzly Corp Data Breach, October 19, 2026
• SOCRadar Threat Research Unit, n0n Ransomware: Inside an AI-Assisted Extortion Operation, October 28, 2026
• Federal Bureau of Investigation and U.S. Secret Service, JCSA-20261006-01, FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts, October 6, 2026
• Recorded Future, FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems, June 24, 2026 (republished October 9, 2026)
• Fortinet PSIRT, FG-IR-19-007, Hardcoded symmetric key in fips.c, November 19, 2019 (revised through February 22, 2024)
• National Vulnerability Database, CVE-2019-6693, November 21, 2019
• CISA, Known Exploited Vulnerabilities Catalog (CVE-2019-6693 added June 25, 2025), checked October 31, 2026
• Matthias Barkhausen, cyber.wtf, Give Me Your FortiGate Configuration Backup and I Rule Your Network, June 13, 2024
• Carl Windsor, Fortinet, Analysis of Threat Actor Data Posting, January 16, 2025
• The Register, Fortinet: FortiGate config leaks are genuine but misleading, January 17, 2025
• Carl Windsor, Fortinet, Analysis of Threat Actor Activity, April 10, 2025
• Federal Reserve Banks, Operating Circular No. 5, General Financial Service Provisions, effective May 15, 2026
• Federal Reserve Financial Services, FedLine Solutions Security and Resiliency Assurance Program FAQ, checked October 31, 2026
• Electronic Code of Federal Regulations, 12 CFR 53.4, Bank service provider notification (with 12 CFR 225.303 and 304.24)
• Legal Information Institute, 12 U.S.C. 1867, Regulation and examination of bank service companies
• Board of Governors of the Federal Reserve System, FDIC and OCC, Agencies issue final guidance on third-party risk management, June 6, 2023
• Finzly, Finzly Introduces Assure, AI-Powered Security, Assurance and Intelligence Layer, September 3, 2026 (modified October 13, 2026)
• Finzly, Finzly's CISO on AI, Cybersecurity, and the New Reality Facing Banks, June 1, 2026
• Finzly, Senior IT Administrator (careers page), August 7, 2026
• Metropolitan Bank Holding Corp., 2026 Investor Day presentation, Form 8-K Exhibit 99.1, March 2, 2026
• Finzly, Inc., Form D filings, SEC EDGAR CIK 0001999250, October 31, 2023 and April 30, 2026