SR 26-2 vs NYDFS Part 500: Model Risk and Cybersecurity Controls for New York Banks

Two regimes with different legal forms

SR 26-2 is a Federal Reserve supervisory letter, dated April 17, 2026, that issues revised Supervisory Guidance on Model Risk Management. It is written as sound principles, and it recognizes that practices appropriately vary with each banking organization's risk profile and model usage. The relevance of model risk depends on the nature, scale and use of models relative to the associated business risks, and each banking organization is ultimately responsible for adopting practices that are appropriate and effective for the risks it faces.

The guidance states that every component of the model lifecycle benefits from governance supported by clear policies and effective controls. Policies define risk management expectations and set a framework for assessing the magnitude of model risk and applying practices commensurate with it. Documentation is also central: it supports continuity of operations, including tracking of recommendations, responses and exceptions, and it helps manage model remediation.

Part 500 is a different kind of instrument. Anyone holding a DFS-issued license, or otherwise regulated by DFS, must comply. The Second Amendment took effect November 1, 2023. DFS's AI cybersecurity guidance states that it imposes no new requirements beyond Part 500. It explains how covered entities should use the existing Part 500 framework to assess and address cybersecurity risks arising from AI. For a New York bank, AI risk therefore belongs inside the existing Part 500 risk assessment and cybersecurity program, not in a separate track.

SR 26-2 and Part 500 side by side

The table compares the two regimes on the dimensions an examiner is likely to use when reviewing an AI system. Details are as of November 2026.

• Legal form: SR 26-2: supervisory guidance built on principles. Part 500: codified regulation with specific control requirements.
• Who is covered: SR 26-2: banking organizations, each responsible for practices suited to its risks. Part 500: entities holding a DFS license or otherwise regulated by DFS.
• Prescriptiveness: SR 26-2: scaled to risk profile and model usage. Part 500: named controls such as MFA, access privileges and a third-party service provider policy.
• Primary focus: SR 26-2: governance, policies, controls and documentation across the model lifecycle. Part 500: cybersecurity program and protection of Information Systems and NPI.
• Treatment of AI: SR 26-2: the bank determines practices appropriate to the nature, scale and use of its models. Part 500: DFS applies the existing framework to AI and adds no new requirements.
• Evidence emphasis: SR 26-2: documentation of recommendations, responses and exceptions. Part 500: demonstrable operation of access, authentication and third-party controls.

Where the two intersect for AI in production

The overlap is clearest at runtime, where a deployed system touches data and tools. Part 500 includes risk-based access program elements, such as promptly terminating access after a departure. It requires MFA for any individual accessing covered entity information systems, subject to a limited exemption under 500.19(a). Under that exemption, MFA still applies to remote access to third-party applications, including cloud-based ones, from which nonpublic information is accessible. DFS's AI guidance calls MFA one of the most effective access controls and says that as of November 2025 MFA applies to all Authorized Users, including customers, employees, contractors and third-party service providers. Class A companies also face privileged access management requirements under 500.7(c), and DFS lists a third-party service provider security policy under 500.11.

These controls plausibly reach AI systems that access Information Systems or NPI, including third-party AI services. A design question each bank has to answer and document is whether AI agents and tool calls inherit these access controls or bypass them.

SR 26-2 approaches the same system through governance. Clear policies, effective controls and documented exceptions all assume the bank can show how a model was used and how departures from policy were handled. Taken together, both regimes point to the same practical need: a record of what the system was permitted to do and what it actually did. That is an inference from the two texts rather than a stated requirement in either, but it is the question examiners tend to reach once an AI system is live.

Which gaps are runtime gaps and which are not

Not every obligation can be met by controlling behavior at runtime. Mixing the two leads to controls that look complete on paper but leave validation or testing unowned.

• Policy on individual interactions and tool calls: Runtime enforcement: allow, redact, block or escalate for human approval before data or actions leave the execution path.
• Evidence of each decision: Runtime evidence: the policy applied, the decision made and any human approval outcome, retained for examiners.
• Authentication, MFA and access termination: Identity and access management, with runtime enforcement checking what an authenticated caller may do.
• Independent model validation: Model risk function. Not a runtime enforcement task.
• Development standards and model lineage: Engineering and model risk owners. Outside runtime enforcement.
• Pre-deployment testing: Testing and engineering teams, before a system reaches production.

Where runtime enforcement fits, and where it does not

Trussed addresses one layer only: policy enforced in the execution path on individual interactions and tool calls, with audit-ready evidence mapped to NYDFS. Policy is enforced at runtime, not reviewed after the fact. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval, and the enforcement itself produces the evidence. The same policy applies across models, agents, tools, MCP servers, AI sites and coding assistants, and deployment is self-managed in the customer cloud with configurable retention and data residency.

Trussed does not perform model validation, does not provide model lineage, and does not deliver full SR 26-2 compliance. Those belong to model risk management, development standards and pre-deployment testing. A bank that treats runtime enforcement as a substitute for them will still have open findings.

For context, Trussed has run continuously in production at a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic and more than 100 models under one policy plane. Its deepest experience is in insurance, a regulated financial sector. The value for a New York bank is narrow and specific: when an examiner asks what an AI system was allowed to do and what it did, the answer is a record produced at the moment of enforcement rather than reconstructed afterward.