Concentration Risk Examination Expectations for Single-Vendor AI Banking Deployments

Single-vendor AI banking deployments call for more than a sound contract. They require evidence that the bank understands its dependencies, can oversee automated decisions, and can stop or replace a service when something goes wrong. Concentration risk examinations hinge on whether banks keep control as well as buy protection. The practical task before the next supervisory cycle is to make oversight, exit contingencies, and auditability part of the deployment itself.

Why single-vendor AI dependency in banking is a concentration risk problem, not just a procurement one

Moody's describes the danger as a “systemic dependency”. Most financial firms rely on a relatively small set of foundation AI model and cloud computing providers. If one major provider goes down, the outage could spread quickly across its customers and the sectors they serve. What looks like a manageable vendor relationship inside one bank can become correlated disruption when viewed across the financial system. The concentration lies in the shared point of failure.

Banks have long used shared cores and shared switches, so the careful objection is that this dependence is hardly new. AI providers supply decision logic as well as infrastructure. A model update can change the institution's risk posture without a change order, while common providers or similar training data can lead institutions toward similar decisions. The Financial Stability Board identifies service-provider concentration and third-party dependencies as AI vulnerabilities with the potential to increase systemic risk. Supervisors must consider both how well a supplier performs and whether banks can control a dependency that affects others beyond the bank.

How the core-banking layer is concentrating AI dependency faster than most banks realize

Three core providers serve most U.S. banks, so their AI partnerships shape far more than their own product lines. FIS announced its Anthropic partnership on May 4, 2026, with a Financial Crimes AI Agent in development with BMO and Amalgamated Bank. General availability was set for the second half of 2026. FIS describes an agent-first governed environment in which every agent decision is traceable and auditable, powered by its “Orchestrated Intelligence” architecture. An established core relationship now also carries a foundation-model relationship.

Fiserv launched agentOS on May 14, 2026, with OpenAI and AWS as strategic collaborators. First Interstate Bank and Boulder Dam Credit Union were already piloting, while Salem Five, City National Bank, Bank OZK, and SouthState were co-developing the next wave. Boulder Dam Credit Union said its Daily Operational Analysis and Reporting agent sharply cut the time it took to produce reports. Those time savings help explain how quickly AI can become part of day-to-day work. Banks can come to depend on one supplier as they take up services that help them do their work, without ever making a single, explicit choice to concentrate AI there.

Jack Henry extended its Google Cloud collaboration in June 2026 into an agentic security platform for its network of community institutions. All three major U.S. core providers have thus committed publicly to distinct foundation-model relationships. This means that a core provider's AI roadmap can become a bank's AI strategy by default. For community banks adopting that roadmap without building their own governance first, the dependency precedes the controls.

What the 2026 regulatory architecture actually requires — and the deliberate gap it leaves

The U.S. supervisory response does not place every AI system under one updated model-risk framework. On April 17, 2026, the OCC, Federal Reserve, and FDIC issued revised interagency Model Risk Management guidance, replacing the 2011 framework. The issuances are OCC Bulletin 2026-13, Fed SR 26-2, and FDIC FIL-15-2026. They describe generative and agentic AI models as “novel and rapidly evolving” and explicitly exclude them from scope. The agencies have signaled a separate request for information on AI, including agentic systems, but it has not yet been issued.

That exclusion is not an exemption from vendor oversight. On September 11, 2026, the Federal Reserve, FDIC, NCUA, and OCC proposed new third-party risk management guidance, published in the Federal Register on September 15, 2026. Its proposed approach is principles-based and risk-tailored, but proposed guidance is not an in-force requirement. Separately, the Basel Committee's December 2025 Third-Party Risk Principles address board accountability, due diligence, contracts, monitoring, continuity, and exit. Their coverage includes concentration and nth-party chains.

APRA, MAS, and CBUAE have also issued AI model risk expectations, while HKMA's primary GenAI governance circular predates this period. These are not yet binding prudential standards, although multinational institutions already face the supervisory expectations in the relevant jurisdictions. That distinction matters to counsel assessing what is formally required and to compliance teams preparing evidence. The practical consequence of the SR 26-2 exclusion is not that examination has paused. Scrutiny of agentic AI instead arrives through third-party risk, operational resilience, and BSA/AML channels.

What examiners are actually asking in the room, regardless of what the guidance formally covers

Examiners are asking whether a bank can stop an AI system and disentangle itself from a compromised vendor. A contractual termination right does not answer either question. The evidence they seek includes kill switch documentation, clear ownership, and an exit plan that has been tested. These questions now arise in routine examinations at the Federal Reserve, OCC, and FDIC as well as in dedicated AI reviews.

The inquiry also reaches behind the contracted vendor. Examiners want documented oversight of vendor decisions and the subcontractors on which the service depends. APRA's April 30, 2026 letter, following a targeted supervisory review of large banks, insurers and superannuation trustees, found that few entities had demonstrated tested exit and substitution strategies. APRA also found that contracts often left out audit rights and clauses that require notice of a model-update or incident. Its expectation to map foundation models, training data sources, and fourth-party service providers addresses upstream dependencies that can otherwise remain opaque.

The gap between a control's possible existence and the bank's knowledge of it is itself important. Wolters Kluwer's Q1 2026 banking compliance AI trend report found that roughly a third of people working in banking did not know whether their bank had kill switches for AI models. The report also identified regulatory reporting of AI failures as an area of unpreparedness for another substantial share. A bank needs to demonstrate who can act, what they can stop, and how the institution will respond.

The five controls examiners expect to find documented for a single-vendor AI deployment

The first control is a complete and current AI inventory. Across the relevant frameworks, inventory expectations cover in-house models, vendor models, and AI embedded in purchased software, subject to each framework's scope. SR 26-2's inventory expectations should not be read as undoing its express exclusion of generative and agentic AI. For a concentrated AI deployment, the useful inventory identifies the product, the foundation model behind it, and the subcontractors in the supply chain.

The second control is risk tiering that treats concentration as a materiality factor. MAS proposes impact, complexity, and reliance as the dimensions of that assessment. A single-vendor dependency supporting fraud detection, payments, or AML elevates the tier because a core function rides on that relationship. The controls must be proportionate to what the bank stands to lose if the system fails.

The third control is ongoing monitoring and validation after deployment. Tests before deployment cannot show how a model will behave for as long as it is in use, so banks must monitor for drift, bias, and failures in production. Vendor-supplied models also require audit rights and model-update and incident notification clauses. Agentic systems make this harder because the same input can produce different outputs and a vendor update can change the model without a formal bank change order. Validation must address the deployed service.

The fourth control is a tested kill switch and human-in-the-loop checkpoints with documented owners. The important distinction is between having a feature and having a named person who can exercise it. Fiserv's agentOS embeds kill switches, human-in-the-loop checkpoints, permission scoping, and auditability by design, providing a documented reference for embedded controls. A bank still needs to establish ownership and test the procedure in its own deployment. This matters especially where agents initiate payments or transfers and legal questions about authorization and dispute resolution remain unsettled.

The fifth control is a tested exit and contingency plan. Evidence must show that the institution can separate from a compromised supplier. Thin vendor indemnification and insurance policies that explicitly exclude generative AI limit the protection available after a failure. The Basel Committee's December 2025 Third-Party Risk Principles place continuity and exit within a framework of board accountability that includes nth-party chains. Exit planning is both a duty of governance and an IT recovery task.

Why the agentic layer and voice channels create distinct compliance surfaces that contractual protections cannot cover

Agentic AI changes what banks must account for because it can recommend and execute work. An agent can orchestrate a cross-border payment from initiation through routing, compliance checks, settlement monitoring, and post-settlement exceptions. Each stage creates a potential point of examiner inquiry. Buying the model, API, or agent does not transfer the bank's accountability for its use. Courts are placing liability on deploying organizations, so a vendor contract cannot settle the bank's obligations to consumers or supervisors.

Calls involve non-public personal information, transactions fall under regulation, and recordings of turns in a call can become records that regulators subpoena. The FCC's February 2024 ruling treats AI-generated voices as artificial voices under TCPA. Calls subject to those requirements need at minimum prior express consent, with prior express written consent for telemarketing calls. When the voice vendor also supplies consent capture, dependence extends from delivering the service to proving that the relevant permission existed.

The sharpest concentration occurs when the same supplier provides the agent, voice interface, consent-capture layer, and audit trail. A failure within that supplier's system can then compromise both the service and the evidence used to explain it. Protections in a contract cannot bring back missing compliance evidence. Voice-first AI therefore needs integration with core banking systems for real-time authentication, transaction support, and complete audit trails. The institution must control those records and be able to produce them for an examiner.

How institutions should sequence their concentration risk response before the next supervisory cycle

Start by mapping the full AI supply chain. Start by building or updating the inventory to include vendor-supplied models, the foundation models behind them, and subcontractors, including the fourth-party dependencies APRA expects banks to map. Then flag the functions where one vendor's failure would impair a critical service, including payments, fraud detection, and AML. This gives the bank a concrete account of where concentration matters most. It also sets the scope for the contract review that follows.

Next, audit contracts for audit rights, model-update notification, incident notification, and data portability terms. These provisions support oversight and separation rather than simply allocating losses after an incident. Vendor indemnification is not a substitute because the institution's liability exposure survives a thin indemnity clause. Once the bank understands those terms, name the people who will own the kill switches and exit procedures. Schedule a tabletop exercise, record what happened, and test exit plans, because written procedures alone do not prove the bank is ready.

The next step is to make auditability independent of the vendor's availability. Every AI-driven payment, transfer, or alert needs a traceable record that the bank can get and produce without help from the vendor. When evaluating agentic deployments, favor embedded auditability, such as the approaches described in FIS's “Orchestrated Intelligence” architecture and Fiserv's agentOS governance layer, over logs the bank cannot independently verify or export. The review should also check for existing banking rails, configurable controls, full audit trails, and SOC 2 certification. These features support readiness, but they do not replace the institution's own oversight.

Finally, bring the concentration assessment to the board before the examination. The Basel Committee's December 2025 Third-Party Risk Principles put board accountability at the top of the framework. Wolters Kluwer's Q1 2026 banking compliance AI trend report found that only a small fraction of institutions described their AI strategy as well-defined and resourced. Board reporting should connect the mapped dependencies to control ownership, test results, and exit readiness. The goal is not a thicker file of assurances, but documented evidence that the bank can govern the service without surrendering control to its supplier.