Third-Party Risk Management for AI Banking Vendors

Buying an AI product puts a bank into a third-party relationship the moment the contract is signed, and U.S. supervisors expect that relationship to be managed across its full life, from planning through due diligence, contracting, ongoing monitoring, and eventual termination. The playbook for that lifecycle was built for software vendors who sold something static: a core processing system, a document platform, a reporting tool whose behavior didn't change month to month. AI products don't hold still, and that one fact strains every stage of the old playbook.

Banks have managed third-party risk for decades, but AI vendor risk pulls away from it in three ways. The first is subprocessor opacity. The model providers a vendor calls behind the scenes are subcontractors in the regulatory sense, and a subprocessor list that leaves them out fails the first question an examiner will ask about data flow. The second gap is harder to see coming: commercial foundation models, fraud-detection APIs, and copilot features get embedded inside software a bank already uses, and those components need the same inventory and risk-tiering as anything built in-house, except banks frequently don't know the AI is there at all. The third gap sits in the space between policy and proof. A well-written vendor policy can answer every question on a due-diligence questionnaire, but ongoing monitoring asks for something different: evidence that the product actually behaves the way the policy says it does.

None of this would matter as much if banks had the staff to chase it down. Most don't. Ncontracts' State of Third-Party Risk Management Survey found that 63% of third-party risk programs run on just one or two dedicated employees, even as their vendor portfolios keep growing. AI adoption is accelerating faster than those teams can scale, so the gap between what's expected and what's staffed keeps widening instead of closing.

The regulatory framework banks are now operating inside

Banks aren't working without rules here, but the rules don't come from one place, and the ones that matter most are still moving. Banks don't get one instrument that governs AI vendor risk, and examiners cite two U.S. frameworks most, both updated or proposed in 2026.

The foundation is the Interagency Guidance on Third-Party Relationships: Risk Management, issued jointly by the Federal Reserve, FDIC, and OCC in June 2023. It lays out the five lifecycle stages and states the principle everything else in this piece rests on: using a third party doesn't lower a bank's responsibility to operate safely and within the law. A proposed replacement arrived on September 11, 2026, as OCC Bulletin 2026-46, published in the Federal Register on September 15, 2026, with comments due November 16, 2026. Until that process produces final guidance, the 2023 version governs.

The second pillar is SR 26-2, issued April 17, 2026, as OCC Bulletin 2026-13, which replaced the long-standing SR 11-7 on model risk management. Section VII of SR 26-2 reaches vendor products directly: model risk management principles apply even when the bank never sees the vendor's code, data, or methodology. That's a meaningful expansion of what "model risk" covers, and it closes off the argument that a purchased model is somehow less the bank's responsibility than one built internally.

SR 26-2 addresses generative and agentic AI by calling these systems "novel and rapidly evolving" and placing them outside its formal scope, but it still directs institutions to govern them using existing risk-management principles, including third-party risk management. Out of scope doesn't mean exempt. Agentic AI vendors have to be evaluated as third parties subject to the same full lifecycle framework that applies to any external provider touching financial operations, not as some new category regulators haven't gotten around to yet.

Beyond those two instruments sits a stack of adjacent obligations. CFPB Circular 2026-03, from May 2026, makes clear that lenders using machine-learning underwriting models remain fully responsible under ECOA and Regulation B for giving specific, accurate adverse-action reasons, and that model complexity or a vendor relationship is not a defense. The EU AI Act's Digital Omnibus, provisionally agreed May 7, 2026, and formally adopted that summer, pushed the Annex III high-risk compliance deadline for credit scoring and anti-money-laundering monitoring from August 2, 2026, to December 2, 2027, which buys institutions operating across borders more time, not a way out. NYDFS Part 500 requires covered institutions to apply their existing cybersecurity program, including risk assessments, access controls, and audit trails, to AI systems, and NYDFS guidance clarifies this reaches any AI system touching nonpublic information.

One voluntary framework helps tie these together. The U.S. Treasury released the Financial Services AI Risk Management Framework in February 2026, and it adapts the NIST AI RMF to financial services with a detailed set of control objectives. If a vendor organizes its evidence against that structure, it hands the bank's reviewer something regulators already recognize, and that saves time on both sides of the table.

What the Five-Stage Vendor Lifecycle Demands of an AI Product

The five stages from the 2023 interagency guidance, planning, due diligence, contract negotiation, ongoing monitoring, and termination, don't change their names when the vendor sells AI. What changes is what counts as satisfying them, and the gaps between expectation and practice are widest at due diligence and ongoing monitoring.

Planning asks a question that has to be answered before the vendor relationship starts: does this AI product touch a "critical activity," meaning something that could expose the bank to significant risk if the vendor fails, materially affects customers, or materially affects the bank's financial condition or operations. If an AI product reads customer data, executes transactions, or shapes what a customer sees or receives, it will almost always fall into the higher tiers, which carries a heavier review obligation.

Due diligence is where the guidance's general factors turn into a specific list of evidence you need in hand. Data handling comes first: a data-flow diagram, a data inventory, and access controls, including multifactor authentication and encryption, that show what data the product touches, where it moves, where it sits, and who can reach it. Subprocessors come next, and the list has to be complete. The model providers and other service providers that touch bank data need to be named, along with their locations, because if a subprocessor list leaves out the foundation models the vendor calls underneath, it fails the question before it's even asked. Banks evaluating AI vendors should press on this early: which model providers or external APIs does the product call, and are they documented in the vendor's own data-flow diagram?

Model documentation is the third evidence category: vendor model cards, audit logs, and independent validation data, because SR 26-2 Section VII requires the bank to understand conceptual soundness, design, development data, and performance even when it never sees the vendor's underlying code. The fourth category is one that trips up more procurement teams than it should: SOC 2 scope verification. A procurement team has to confirm, explicitly, that the SOC 2 scope includes the transaction layer itself, not just the systems around it.

Contract negotiation looks different for AI products because the proposed 2026 guidance states there are no universally expected contract terms, even for higher-risk relationships. So you have to negotiate terms matched to the product's specific risk profile instead of pulling a standard template off the shelf.

Ongoing monitoring is where the old annual-review model shows its limits most clearly. For an AI vendor, monitoring has to produce evidence that the product still behaves the way it was described when it was approved. A policy document can't tell you whether a model has drifted, whether a provider swapped in a new foundation model without notice, or whether outputs have started skewing in a way nobody flagged.

Termination closes the lifecycle, and for an AI vendor it has to cover more than deleting an account. The bank needs to be able to exit the relationship and recover or delete its data, including model outputs, any training data it contributed, and any copies held by the vendor's subprocessors.

Agentic AI and the Governance Model for Vendor Software

Agentic AI expands what governance has to cover. It changes what's actually being governed. The unit that needs auditing is no longer a single model output but a chain of actions, data retrieval, tool calls, record updates, case routing, that can run to completion before any human ever sees the result. A conventional vendor review can check what a model predicted. It has a much harder time checking what an agent did, in what order, and on whose authority.

SR 26-2 calls agentic AI "novel and rapidly evolving" and places it outside formal model risk guidance, a sign that regulators recognize these systems don't behave like the decisioning models the framework was originally built around, even as they still expect banks to govern them using the principles that already exist. Agentic AI vendors need to be treated the same way: not as a new category sitting outside oversight, but as third parties subject to the full lifecycle governance that applies to any external provider handling financial operations.

This isn't a hypothetical future problem. A large share of banking institutions are already running agentic AI through live deployments or active pilots, and major core providers have built agents directly into banking infrastructure: Fiserv launched agentOS, and FIS introduced a Financial Crimes AI Agent. Systems already running in production make governance a present concern, not a future one.

Agentic systems operating inside a bank's environment create three specific exposures. Identity and accountability can get murky, because the service accounts, API keys, and tokens an agent uses may not be tied to any individual, which makes it hard to answer a basic examiner question: who authorized this action, and under whose delegated authority? And audit trails fragment when one agentic workflow touches multiple tools and updates multiple records, because a defensible trail has to capture the whole chain of actions, not just the final output.

Two reference points show what disciplined governance of these systems can look like. The 2026 Singapore Consensus on AI Safety laid out ten foundational principles for agentic risk: least privilege, traceable identity, auditability, validated deployment, adversarial resilience, multi-agent stability, runtime assurance, interruptibility, legibility, and human oversight, and these map closely onto what bank examiners are starting to ask for. DBS Bank built its own version of this into a "PURE" framework, requiring every AI system to be Purposeful, Unsurprising, Respectful, and Easy to explain, a working template for what sound governance of agentic systems looks like inside a regulated institution.

None of the frameworks above mean much without a record that can reconstruct what happened. A bank cannot show compliance with the interagency guidance, SR 26-2, CFPB Circular 2026-03, or NYDFS Part 500 unless its audit trail captures each AI-influenced decision in enough detail to show what happened, who or what authorized it, and why.

CFPB Circular 2026-03 turns this into a hard test rather than a general aspiration. If a bank cannot produce a specific, accurate, human-readable reason for a machine-learning-driven credit decision that the customer can actually understand and dispute, the audit trail has failed, regardless of how many data fields sit behind it. Volume of logging isn't the standard. Usability of the explanation is.

For agentic workflows, the same rigor has to extend across the whole chain of action. Each tool call, each record update, and each handoff between agents needs its own log entry, and those entries need to link together so an examiner can follow the sequence from start to finish.

The practical test applies to any AI vendor a bank is evaluating: can it produce, on demand, a complete and tamper-evident log of every action its system took inside the bank's environment, tied to the specific version of the model that took it? If a vendor can't answer yes, it has a governance gap, whatever its marketing materials claim about transparency. A vendor's ability to show complete audit trails and configurable controls, what actions the system took, when, on whose authority, and with what output, answers the due-diligence question of whether the bank still holds meaningful oversight over a tool it didn't build. Institutions evaluating these products should treat auditability as a design feature the vendor built in from the start.

How continuous monitoring replaces the annual vendor review

An annual review was built for a vendor that didn't change much between visits. AI products don't hold to that rhythm. A foundation model can be swapped underneath a product with no customer-facing announcement, a fraud-detection API can drift as its training data ages, and an agentic workflow can expand its own permissions as new tools get connected to it. None of that waits for a scheduled checkpoint.

Continuous monitoring asks a different question than the annual review did. Instead of asking whether the vendor's policies are still on file, it asks whether the product is still behaving the way it was approved to behave. That means watching for the kind of signals that used to surface only in a formal notification, financial distress at the vendor, a regulatory enforcement action, a reputational incident, and catching them from public information weeks before any official notice would arrive. It means verifying, on an ongoing basis, that the subprocessor list from the original due-diligence review hasn't quietly grown a new model provider. It means confirming that the SOC 2 scope still covers the transaction layer after a vendor's infrastructure changes. And for agentic systems, it means checking that the identity and access controls governing what an agent can do haven't drifted from what was approved at onboarding.

None of this replaces the five-stage lifecycle. It sits inside the ongoing-monitoring stage and makes that stage do the work an annual checklist never could. A bank with one or two people running third-party risk for a few hundred vendors, the reality Ncontracts found across the industry, cannot do this by hand. The institutions that manage it well are the ones treating vendor evidence as something to verify constantly, not something to file once a year and revisit when the renewal date comes around.