BLOCKRIVER AG RECEIVES SRO MEMBERSHIP: VIEW INFO
14.8.26
arrow up rightarrow up right

New York's Vendor Liability Rule Exposes a Treasury Blind Spot: If Your Banks Can't Audit Their IT Providers, Neither Can You

New York regulators just told bank boards they're personally liable for security flaws in software their institutions never bought and may not know exists. For corporate treasurers managing multi-bank relationships, this isn't just a banking compliance story, it's a signal that the infrastructure underlying your fee opacity problem is less controlled than you assumed.

On Tuesday, the New York Department of Financial Services issued an industry letter naming a specific software product. N-central, sold by N-able, and directing every bank it oversees to determine whether that software runs anywhere in their supply chain. The product is used by managed service providers to monitor, patch, and remotely control client systems. Attackers have been exploiting it since late July.

What makes this alert different from previous NYDFS vulnerability notices isn't the software itself, it's the regulatory posture. The alert highlights the growing responsibility New York places on banks, and sometimes their boards, for security flaws anywhere in their supply chains, including in software they never bought, cannot patch and might not know their IT providers use. Previous alerts, covering SolarWinds, Log4j, MOVEit, gave banks something to fix on their own systems. In those cases, banks had an opportunity to patch their own systems in response. In the case of N-central, banks cannot respond by applying patches.

The letter explicitly invokes "senior governing bodies and senior officers," language that tracks directly to the 2023 amendment to NYDFS's cybersecurity regulation, 23 NYCRR Part 500. That amendment renamed Section 500.4 from "Chief Information Security Officer" to "Cybersecurity Governance" and clarified that the Senior Governing Body must be allocated sufficient resources to implement and maintain an effective cybersecurity program. The amendment added a requirement that the Senior Governing Body exercise oversight of the entity's cybersecurity risk management, including by having sufficient understanding of cybersecurity matters.

In practice, this means bank boards now carry explicit accountability for vendor technology failures, including those occurring at what regulators call "fourth parties," the vendors that serve their vendors. In the 12 months between N-central vulnerability disclosures, the department's vendor-risk guidance has changed. Issued in October 2025, it says regulated firms stay accountable for vendor failures and should examine the vendors their vendors use, which it calls fourth parties.

Here's where treasury exposure begins. Only 58% of community and mid-size banks require their cybersecurity vendor to grant them some kind of auditing rights, which ensures the bank can directly observe the vendor's cybersecurity practices. Nearly all banks (99%) rely at least partly on outside firms for cybersecurity work, according to a survey of 125 executives at banks with less than $50 billion of assets, conducted in July 2024 by the law firm Jones Walker.

The arithmetic is stark: virtually all banks outsource critical IT functions, but fewer than six in ten have contractual rights to audit what their vendors actually run. How much a bank can demand comes down to its contract. A bank's ability to monitor the software its vendors run is "almost totally dependent upon any monitoring and audit rights it negotiates through its agreement with the vendor."

This matters for treasury teams because banking fee opacity, the chronic inability to attribute costs across relationships, reconcile charges against contracts, or explain month-to-month variance, is itself a symptom of limited visibility into bank operations. Account analysis statements, which provide detailed breakdowns of the fees charged for banking services, can sometimes contribute to confusion due to multi-layered pricing across different bank accounts. Each bank in different geographies may have a different description for their portfolio of services along with different fee structures, making it difficult for corporate treasuries to maintain a clear overview of their banking costs.

If banks themselves lack contractual visibility into their own technology stack, the opacity you experience on fee attribution reflects a deeper structural gap. The same institutional blind spots that prevent your bank from knowing whether N-central runs somewhere in its IT chain also explain why your account analysis statements remain opaque, why pricing changes appear without explanation, and why cost allocation across entities proves so difficult to reconcile.

The regulatory response compounds the exposure. Under Part 500, covered entities must notify NYDFS within 72 hours of determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider. Part 500 now requires that covered entities promptly provide the superintendent with any information requested regarding a reported incident. But a bank that cannot see what software its vendors run cannot determine whether an incident has occurred, and cannot make that determination independently.

As Lisa Sotto of Hunton Andrews Kurth noted in response to the alert, banks cannot claim ignorance as a defense. The regulation requires banks to maintain programs capable of detecting and responding to cybersecurity events. Playing possum, as she put it, won't fly if there is a vendor issue brewing that is reasonably likely to impact the covered entity.

For multi-entity treasuries operating across several banking relationships and jurisdictions, the implications extend beyond cybersecurity. If 42% of your banking partners lack the contractual right to audit their own IT vendors, your inability to trace fee attribution isn't merely an operational annoyance, it's evidence that you're operating on infrastructure your banks themselves don't control.

The question treasury teams should now be asking is not whether their banks are NYDFS-compliant, most will certify that they are. The question is whether, across your banking relationships, you can identify which counterparties have genuine vendor oversight capabilities and which are operationally blind to their own supply chain.

As digital transformation becomes inevitable for community and mid-size banks, these institutions are increasing their reliance on third-party solutions. Jones Walker's 2024 survey found that 90% of respondents use third-party vendors to provide critical support functions. The dependency is growing, not shrinking. And the regulatory pressure to surface that dependency is intensifying.

This isn't a call to abandon banking relationships over vendor risk posture. It's a recognition that fee opacity, which treasury teams have long treated as an annoyance to be managed through benchmarking tools and account analysis software, may be a surface indicator of a deeper governance gap. If your banks can't tell you what software their IT providers run, they probably can't tell you with precision what's driving your fee variance either.

The NYDFS rule makes vendor oversight a board-level fiduciary matter for banks. For treasury teams, the corresponding question is whether counterparty risk assessments should now include vendor governance capabilities, not as a cybersecurity checkbox, but as a proxy for operational visibility. The banks that can answer the regulator's question can probably answer yours. The ones that can't are operating in a fog that extends well beyond IT.

References

[1] New York Department of Financial Services, Cybersecurity Alert: N-central Vulnerability (August 11, 2026)

[2] New York Department of Financial Services, Second Amendment to 23 NYCRR Part 500 (November 1, 2023)

[3] Jones Walker LLP, 2024 Community and Mid-Size Banks Cybersecurity Survey (November 2024)

[4] New York Department of Financial Services, Guidance on Managing Risks Related to Third-Party Service Providers (October 21, 2025)

Stay informed.
<NEWSLETTER REGISTRATION CONFIRMED>
<ERROR>