Bank AI Regulatory Requirements Beyond SR 26-2

SR 26-2 is one layer, not the whole program

SR 26-2, Revised Guidance on Model Risk Management, was issued by the Board, OCC and FDIC. It supersedes SR 11-7 and SR 21-8 and takes a risk-based approach tailored to a banking organization's model risk profile, size and complexity. It is expected to be most relevant to Fed-regulated banking organizations with over $30 billion in total assets, so confirm how it applies to your institution by regulator and asset size.

Model risk management answers one set of questions. Consumer protection, privacy and vendor oversight answer others, and those obligations do not depend on how an AI system is classified internally. Treasury's 2024 request for information notes that financial institutions typically manage AI risk through several existing frameworks: model risk, operational risk, compliance risk including consumer protection, and third-party risk. The table below maps each regime to the AI behavior it reaches.

• UDAAP: Reaches customer-facing outputs and agent actions. Control point: output and tool call.
• Fair lending (ECOA/Reg B): Reaches credit decisioning and adverse-action reasoning. Control point: design, validation and testing before deployment.
• GLBA privacy and safeguards: Reaches nonpublic personal information in prompts, provider egress and tool calls. Control point: input, egress and tool call.
• Interagency third-party guidance: Reaches foundation model providers, hosted AI services and tool integrations. Control point: due diligence, contracts, ongoing monitoring.

UDAAP and fair lending: outputs, decisions and agent actions

The 2023 interagency guidance states that using a third party does not diminish a bank's responsibility to operate in compliance with applicable laws, including consumer protection laws such as fair lending laws and UDAAP prohibitions. For AI, that means a vendor-hosted assistant that writes to customers, or an agent that takes an action on an account, carries the same consumer protection exposure as a human or a conventional system performing that work.

On the UDAAP side, the practical question is what the AI was allowed to say and do. Useful runtime controls include restricting which tools an agent can call, blocking outputs that fall outside approved content, and escalating consequential actions for human approval. An examiner-ready record shows the policy in force, the action taken on each interaction, and who approved any escalation.

Fair lending is different. As described in Treasury's request for information, CFPB guidance from September 2023 says creditors subject to Regulation B may not use AI, complex algorithms or black-box models they do not sufficiently understand, and that a creditor unable to accurately identify the specific reasons for an adverse action may not be meeting its legal obligations. Reason accuracy is a matter of model design, validation and pre-deployment testing. Runtime enforcement of individual interactions cannot supply it, and a fair lending program should not treat it as a substitute.

GLBA: nonpublic personal information in prompts and tool calls

GLBA Section 502, subject to exceptions, prohibits a financial institution from disclosing nonpublic personal information about a consumer to nonaffiliated third parties unless notice and opt-out requirements are satisfied and the consumer has not opted out. Under 12 CFR 332.14, disclosures necessary to effect, administer or enforce a transaction the consumer requests or authorizes are exempt from certain notice, opt-out and service-provider or joint-marketing requirements. Part 332 is the FDIC's regulation, so confirm the equivalent rule for your regulator.

For AI, the data flow is the compliance event. A prompt that contains account details and is sent to an external model provider is a potential disclosure to a third party. A tool call that retrieves customer records is an access decision. Whether a given flow falls within an exception is a legal determination, and it should be made and documented for each flow before the technical control is configured.

Once that basis is set, runtime controls can enforce it at three points: redact nonpublic personal information from prompts before they leave the bank's environment, block egress to providers without a documented basis, and restrict which tools can retrieve which data. Safeguards obligations differ by institution type, so identify the rule that governs your institution's safeguards program and map controls to that rule specifically.

Third-party risk: foundation models, hosted services and tool integrations

The 2023 interagency guidance describes due diligence as assessing a third party's ability to perform the activity as expected, adhere to the bank's policies, comply with applicable laws and regulations, and operate safely and soundly. Treasury's 2024 request for information states that these principles, covering due diligence, contract management and ongoing monitoring, may apply to AI developed by third-party vendors. The guidance is supervisory and does not carry the force of law, but the agencies may pursue corrective measures, including enforcement actions, for violations of laws and regulations or unsafe or unsound practices by the bank or its third party.

In practice, extend the vendor inventory beyond the model provider to hosted AI services and the tool or MCP integrations an agent can reach. Use the four due diligence elements as the review checklist for each. Ongoing monitoring is where runtime enforcement contributes: per-interaction records show whether a vendor-hosted model or tool operated within the bank's policy over time. A proposed third-party guidance document also exists, and it describes the 2023 guidance as remaining a relevant tool. Track its status as of November 2026 before revising vendor-oversight procedures.

Where runtime enforcement helps and where it does not

Runtime enforcement operates on individual interactions and tool calls. It is well suited to the controls above: allow, redact, block and escalate for human approval at the input, egress, tool-call and output points. Evidence produced by that enforcement records the policy version, the action taken and the escalation outcome for each interaction, so a risk team can show what the system was permitted to do and what it did.

It does not replace pre-deployment fair lending testing, model validation, adverse-action reason accuracy, the legal analysis behind GLBA exceptions, or vendor due diligence and contracting. Those need their own owners and processes. Because third-party use does not remove the bank's responsibility, assign accountability for consumer protection, privacy and vendor risk separately from model risk owners.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and produces audit-ready evidence from that enforcement. Insurance, a regulated financial sector, is where Trussed is deepest.