Ownership of SR 26-2 Model Risk in a Bank-Fintech BaaS Lending Program

What SR 26-2 establishes, and what it leaves open

SR 26-2, Revised Guidance on Model Risk Management, is dated April 17, 2026. The Federal Reserve describes it as an update of the model risk guidance that followed SR 11-7, based on supervisory experience and industry feedback since then. It clarifies principles and emphasizes a risk-based approach tailored to each banking organization's model risk profile and the size and complexity of its operations. As of November 2026, the guidance material reviewed here does not set out an effective date or transition period.

Two points matter for a BaaS lending program. First, the guidance recognizes that practices appropriately vary with risk profile and model usage, so a credit decisioning model and a low-impact fraud rule do not warrant the same depth of treatment. Second, each banking organization is ultimately responsible for adopting model risk practices that are appropriate and effective for its own risks.

The guidance does not allocate tasks between a sponsor bank and a fintech. The allocation below is a practitioner framework built on the guidance's accountability principle, not a prescribed division of duties.

Responsibilities that cannot be delegated

Interagency third-party guidance, published in June 2023, states that using third parties does not remove the need for sound risk management, and that its principles apply to all third-party relationships, including fintechs. The Federal Reserve's community bank guide adds that engaging a third party does not diminish the bank's responsibility to operate safely and soundly and to comply with law, including consumer protection law, as if the bank performed the activity itself. That guidance is supervisory and does not carry the force of law, but it describes how examiners are likely to frame the question.

In practice, four responsibilities stay with the bank. The bank decides which models in the program are in scope and how material each one is. It sets the standard for validation and judges whether the evidence it receives meets that standard. It owns the decision to rely on a model whose internals it cannot inspect. And it holds the examiner-facing record. The 2024 request for information on bank-fintech arrangements notes that fintechs may be assigned core lending functions such as underwriting and servicing, and that risk may be heightened when they perform them. That raises the importance of oversight at the bank rather than lowering it.

A responsibility matrix across the model lifecycle

Use this matrix as a starting point for each model in the program: credit decisioning, underwriting, fraud and pricing. Record a named individual or team on each side, not just the firm. Depth should follow model materiality.

• Inventory: Bank: owns the inventory record, materiality tier and approval to use. Fintech: supplies purpose, version, inputs and outputs, and known limitations for each model it operates.
• Validation: Bank: sets the validation standard, reviews results and challenges gaps. Fintech: provides validation reports and independent testing results it holds.
• Ongoing monitoring: Bank: reviews outcomes and performance data on a defined schedule and escalates exceptions. Fintech: runs day-to-day monitoring and delivers the data feeds.
• Change control: Bank: defines which changes need advance notice or approval. Fintech: notifies the bank, implements approved changes and records what changed.
• Documentation: Bank: maintains the examiner-facing file and its completeness. Fintech: provides model documentation to the extent its contract and intellectual property position allow.
• Third-party oversight: Bank: performs due diligence and monitors the relationship. Fintech: demonstrates its risk management and independent testing or audit coverage.

Where runtime AI behavior creates evidence gaps

Traditional model risk artifacts describe a model as built and tested. They do not necessarily show what an AI component did on a specific interaction. If a fintech uses an LLM-based assistant or agent in a lending workflow, for example to summarize an application, draft a customer communication or call a tool that retrieves data or triggers an action, an examiner can reasonably ask which of those outputs or actions could affect credit, fraud or pricing outcomes, and what record exists of what each one did. This is an evidence question the guidance does not answer directly, so treat it as a gap to close rather than a settled expectation.

Three questions help expose the gap. What policy governed the AI component when it ran, and who set it? What actions did it take, and were any held for human approval? And can the bank obtain that record from the fintech without relying on a narrative after the fact? If the answers live only in the fintech's systems and are not contractually available to the bank, the bank's monitoring has a blind spot in precisely the area where it may have the least direct visibility.

Where runtime policy enforcement fits, and where it does not

Trussed enforces policy in the execution path of AI interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. It is enforced at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence of what the AI was permitted to do and what it did for each individual interaction. For a bank reviewing a fintech's AI-assisted workflow, this kind of record can support examiner-facing documentation on runtime behavior and give monitoring teams something concrete to review. Deployment is self-managed in the customer cloud, with configurable retention and data residency, which matters when the bank and fintech must agree where evidence lives.

The scope is deliberately narrow. Trussed does not replace model inventory, validation or the bank's accountability under SR 26-2. It does not provide model lineage, dataset provenance or transaction-level governance. Its evidence covers enforcement on individual interactions and tool calls, and it would complement, not substitute for, the validation reports and outcomes data described above. Trussed's deepest experience is in insurance, another regulated sector, and it does not claim bank or fintech deployments.