Bank LLM Provider Strategy: Standardize on One Provider or Approve Several

Why provider count is a control question, not only a procurement question

Banks often frame this choice as a vendor consolidation exercise. The more useful framing is what has to be built, validated and evidenced for each provider that is approved.

The supervisory baseline has changed. The OCC, the Federal Reserve Board and the FDIC issued revised interagency model risk management guidance on April 17, 2026 (OCC Bulletin 2026-13 and SR 26-2). It rescinds earlier guidance, including OCC Bulletins 2011-12 and 2021-19. As of November 2026, the guidance is risk-based and tailored. It sets no enforceable standards, and non-compliance will not result in supervisory criticism. It is expected to be most relevant to banking organizations with over $30 billion in total assets, and may also apply to smaller banks with significant model risk exposure.

Two consequences follow. Each bank is responsible for adopting practices suited to its own risks, so the bank has to document its own rationale for validation scope and provider count. And the guidance stresses that adequate documentation supports effective model risk management, so the evidence design matters as much as the vendor selection. OCC material on bank AI use adds that accountability generally remains with the bank, and it names aggregate exposure from shared providers, data, permissions, infrastructure and control vendors as a consideration.

Evaluating single-provider and multi-provider approaches

Use the same five criteria for both paths and record the reasoning. The table summarizes where the trade-offs usually fall.

• Concentration and exit risk: Single: exposure is concentrated, and exit means re-validating and re-platforming at once. Multiple: exposure is spread and substitution is available, provided policies and evidence are not tied to one provider's tooling.
• Validation and ongoing monitoring scope: Single: one validation and monitoring program, but depth is needed. Multiple: each provider and model adds validation, change monitoring and retesting when functionality changes.
• Data handling and residency: Single: one set of terms to review. Multiple: processing location, retention and data use terms must be reviewed per provider and kept consistent with bank policy.
• Use-case fit: Single: one model family may fit some use cases poorly. Multiple: use cases can be matched to the model, at the cost of more approvals.
• Evidence consistency: Single: evidence comes from one source, which is simple but provider-bound. Multiple: evidence formats diverge unless captured independently of each provider.

What the approval process must cover for each additional provider

Every added provider enlarges the approval workload in predictable places. Validation has to be scoped to the provider and to each use case, in proportion to risk. Due diligence has to cover how the provider notifies the bank of new functionality or model changes, and what triggers reassessment or retesting. OCC material notes that a bank may require notice and transparency of new provider AI functionality and may reassess the relationship or retest the model when changes are made. Where a vendor model is customized to the bank's needs, the guidance says effective policies define expectations for that customization.

Two parts of this work can be standardized. The first is the inventory: NIST guidance includes the action to inventory third-party entities with access to organizational content and to establish approved provider lists. The second is the use-case policy. NIST notes that mitigations for model-level or system-level risks may differ from those for use-case-level risks. That supports a clean split. Provider-specific work covers model validation, contract terms, native safety tooling and residency settings. Use-case work covers what an application may send, what a model may return and which actions require a person.

The main failure mode is letting controls drift into each provider's own tooling. Policies are then written several times, enforced differently and evidenced in different formats. That raises the cost of every change and makes a later substitution a control rebuild.

Applying one provider-independent policy layer at runtime

A runtime policy layer sits in the execution path between applications and models. Policy is enforced at runtime, not reviewed after the fact, and the same policy applies whichever approved provider handles the request. The actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls.

This maps to the OCC language on provider agents that interact with bank systems and data. A bank may define scope of authority, identity, permitted tool use, data use and escalation limits, and may monitor and potentially limit what those agents do. Those definitions belong to the bank and can be written once per use case rather than once per provider.

Evidence follows the same logic. When enforcement itself produces the record, each approved model's permitted behavior and actual behavior are captured in one consistent format. That gives model risk management and internal audit a common basis for comparing providers and answering the question of what each approved model was allowed to do and what it did.

Trussed enforces policy in the execution path across more than 100 models under one policy plane and produces audit-ready evidence from that enforcement. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Any shared control layer is itself part of aggregate exposure, so the bank should assess it as it would any other dependency.

Choosing between the paths

A single provider is reasonable when use cases are few and similar, validation capacity is limited, and the bank can document why concentration is acceptable and how it would substitute if it had to. The condition that matters is that policy and evidence are not locked to that provider's tooling.

A multi-provider list is reasonable when use cases differ materially in risk, data sensitivity or model fit, or when the bank wants a practical substitution option. The condition is that the bank has the capacity to validate and monitor each provider, and a consistent way to enforce and evidence behavior across them.

In both cases, record the rationale against the five criteria. Because the revised guidance is risk-based and tailored, a documented, bank-specific rationale is the stronger position than adopting either path by default.