Applying SR 26-2 to AI Embedded in Vendor Software at Community Banks

Step 1: Decide which embedded features are in scope

The guidance defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates. It excludes simple arithmetic calculations, such as those in spreadsheets, and deterministic rule-based processes and software with no statistical, economic, or financial theories underpinning their design or use.

For embedded vendor AI, the practical consequence is that scoping depends on how a feature works, not on its marketing label. A fraud score produced by a statistical method needs a different treatment from a fixed threshold rule in the same product. A vendor description of a feature as "AI-powered" or as "just rules" is an input to your determination, not the determination itself.

Build the inventory by vendor relationship: core processing, fraud, lending, BSA/AML and customer service. For each embedded feature, record whether it applies statistical or quantitative methods, whether it is deterministic, and the rationale. Document the basis for every out-of-scope call, including any position the bank takes on newer generative features, because that determination is itself something an examiner may question.

Proportionality applies here. The Fed states that practices appropriately vary by banking organization based on risk profile and model usage, so the inventory should also capture what each feature is used for.

Step 2: Divide responsibilities between the bank and the vendor

The interagency community bank guide is direct: using a third party does not diminish or remove the bank's responsibility to operate safely and soundly and to comply with laws, including consumer protection and customer information security. It also notes that reliance on third parties reduces direct operational control and may introduce or increase risks. A vendor can supply information and assurances. It cannot take over the bank's accountability.

• Scoping and inventory: Bank: owns the determination and the rationale. Vendor: describes how the feature works.
• Model understanding: Bank: reviews and challenges. Vendor: supplies documentation on conceptual soundness, design, development data and performance.
• Outcome analysis: Bank: runs it on its own data and decisions. Vendor: provides reports and data access where it can.
• Change management: Bank: reviews and approves enabling a feature. Vendor: notifies the bank of model changes delivered through updates.
• Approval and oversight: Bank: names who approves and who monitors. Vendor: no role in the bank's internal accountability.
• Evidence for examiners: Bank: holds it and can produce it. Vendor: attestations feed the bank's evidence but do not replace it.

Step 3: Set proportionate due diligence and validation

The guidance recognizes that customized vendor products may present unique validation challenges and that a bank may not receive the underlying code, data, or methodology it would have for an internally developed model. It still treats validation of vendor products, by internal or outside parties, as an important element of model risk management. Sound practice includes understanding the vendor model's conceptual soundness, design, development data and performance, and conducting ongoing monitoring and outcome analysis to check accuracy, fitness for purpose and reliability.

Without model internals, this becomes two workstreams. The first is documentary: request what the vendor can provide on conceptual soundness, design, development data and performance, and record gaps. The second is empirical: compare outputs against outcomes in the bank's own data, such as confirmed fraud against alert scores, or alert dispositions in BSA/AML, and track whether results drift after vendor updates.

Depth should follow risk. The third-party guide lists factors that make an activity higher risk, including access to sensitive or customer data, processing transactions, and providing essential technology or business services. A lending or fraud feature touching customer data and transactions warrants more documentation and tighter monitoring than a low-impact customer service feature. Typical monitoring activities in the interagency guidance include reviewing reports on the third party's performance and control effectiveness, periodic meetings, and regular testing of the bank's own controls, especially for higher-risk or critical activities.

Where bank-side runtime controls help, and where they stop

Some embedded AI can be constrained from outside the vendor model. Where an AI feature takes inputs from or acts through the bank's systems, a control point in the execution path can enforce policy on individual interactions and tool calls: allow a request, redact sensitive fields, block an action, or escalate it for human approval. This is a design consideration, not a stated requirement of the guidance, but it addresses a real gap. The bank can limit what the AI sees and does without access to model internals, and can retain records of what was permitted and what happened.

The limits matter. Runtime enforcement does not validate a vendor model's conceptual soundness, development data or internal performance, which the guidance treats as part of understanding a vendor model. It complements vendor documentation and contractual assurances rather than replacing them. It also reaches only the interactions that pass through the control point, so a feature the vendor enables through an update outside that path needs to be detected through change notification and inventory review.

The useful test is whether a control produces evidence the bank itself holds. Records showing what the AI was allowed to do, what was redacted or blocked, and which actions went to a human are bank-owned and do not depend on a vendor's reporting schedule.

How Trussed fits, briefly

Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, and escalate for human approval. It is enforced at runtime, not reviewed after the fact, and it produces audit-ready evidence from that enforcement. It does not validate vendor models or replace vendor due diligence.

Insurance is the regulated financial sector where Trussed is deepest, and the platform has run continuously in production at a regulated enterprise for more than 18 months. Banks should evaluate any control against the evidence it generates for model risk management and examiner scrutiny, and against how it behaves when a vendor changes the underlying feature.