SR 26-2 vs DORA: Model Risk and ICT Resilience for US Banks With EU Subsidiaries

Different units of control, one production system

The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. It highlights sound principles and recognizes that practices appropriately vary among banking organizations by risk profile and model usage. Federal Reserve model risk guidance describes effective challenge as critical analysis by objective experts across the model lifecycle, from development through ongoing monitoring. The unit of control is the model.

DORA is Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector. It lays down uniform rules on the security of network and information systems of financial entities such as banks, insurance companies and investment firms. Its unit of control is the ICT system and the ICT service. A recital says the definition of ICT services should be read broadly, covering digital and data services provided through ICT systems to internal or external users on an ongoing basis.

For a US bank with EU subsidiaries, this means one AI deployment can be a model under one regime and an ICT service under the other. A model-serving endpoint, an agent and a tool integration may each fall inside DORA's ICT risk scope at an EU entity. Each entity needs a documented determination of what is in scope under which regime, with a named owner on the model side and on the ICT side.

SR 26-2 and DORA side by side

The table maps the control domains where the two regimes are most often compared. It describes expectations at the level of principle. Entity-level control design should be built from the full texts.

• Scope and unit of control: SR 26-2: the model, with practices that vary by risk profile and model usage. DORA: ICT systems and services, with a broad ICT services definition that includes internal users.
• Governance and accountability: SR 26-2: each banking organization is responsible for adopting appropriate and effective practices. DORA: an internal governance and control framework that ensures effective and prudent management of ICT risk.
• Assurance: SR 26-2: effective challenge by objective experts across the lifecycle, and policies commensurate with the magnitude of model risk. DORA: a sound, comprehensive and well-documented ICT risk management framework.
• Third-party and intra-group providers: SR 26-2: responsibility stays with the banking organization. DORA: when ICT activities are outsourced, the financial entity remains fully responsible, and intra-group ICT providers may be treated as ICT third-party providers.
• Monitoring and evidence: SR 26-2: ongoing monitoring plans may assess model limitations and set procedures for responding to issues. DORA: the register of information, or sections of it, must be available to the competent authority on request, along with any information needed for supervision.

Governance, intra-group services and shared documentation

Both regimes place accountability on the institution and not on a vendor or a tool. Under DORA, outsourcing does not transfer responsibility for verifying compliance with ICT risk management requirements. Under Federal Reserve guidance, the banking organization owns the choice of effective practices. Independence matters on the model side, because effective challenge relies on objective experts. That is a governance matter and sits apart from any runtime control.

The group structure adds a DORA-specific question. A recital says group undertakings that provide ICT services predominantly to their parent or to the parent's subsidiaries or branches should be considered ICT third-party service providers. A US parent that supplies a shared AI platform or tooling to EU subsidiaries may therefore need to treat that service as a third-party arrangement and reflect it in each EU entity's register of information. Recitals are interpretive, so legal review should confirm how this applies to a specific arrangement.

The practical design principle is to share control definitions across the group while keeping documentation at the entity level. The register must be producible on request, so records of ICT dependencies, including AI-related ones, need to be consistent and retrievable. A model inventory maintained only at the parent and an ICT register maintained only in the EU will drift apart. Agree on one list of AI systems, with attributes that serve both views.

Validation and resilience sit outside the execution path

Pre-deployment validation, independent challenge, model development standards and the organization's resilience program are not runtime activities. Effective challenge happens across the model lifecycle and depends on people with the right independence. The ICT risk management framework is a documented organizational system. Neither is satisfied by enforcing a policy on an individual request.

This boundary should be explicit in group design. Treating runtime enforcement as a stand-in for validation creates a gap that examiners and EU competent authorities are likely to find. Treating validation as sufficient for production behavior leaves a different gap, because a validated model can still be given access to data or tools that its approval never contemplated.

Incident handling shows the same split. Classification, escalation and any external reporting decisions belong to the incident process and its owners. A runtime record of what the AI was permitted to do and what it did gives that process a factual starting point. It does not make the reporting decision.

What runtime enforcement can and cannot support

Runtime enforcement operates on individual interactions and tool calls in the AI execution path. The mapping below is an analytical framing for control design, not a requirement stated by either regime.

• Access control on models, agents and tools: Addressable at runtime. Policy can allow or block a call before it executes, and the decision is recorded.
• Data handling: Addressable at runtime. Policy can redact sensitive content before it reaches a model or tool. Data residency also depends on where the enforcement layer is deployed and how retention is configured.
• Human approval: Addressable at runtime. Defined actions can be escalated for human approval, and the approval is part of the record.
• Audit evidence: Supported at runtime. Enforcement decisions produce durable records that can feed model monitoring files and ICT documentation.
• Validation, independent challenge, resilience program, register of information: Outside runtime control. These need governance, qualified people and organizational process, and runtime evidence can only inform them.