Third-Party AI Model Risk for Banks: the 2023 Interagency Guidance

A bank that buys an AI model is in two supervisory frameworks at once: model risk management, and third-party risk management. They are different documents with different structures, and the second one was rewritten in 2023 in a way that makes citing the old bulletin numbers a reliable tell that somebody has not read it.

Which document this is

On 6 June 2023 the Federal Reserve, the FDIC and the OCC issued Interagency Guidance on Third-Party Relationships: Risk Management. It appears as OCC Bulletin 2023-17, Federal Reserve SR 23-4 and FDIC FIL- 29-2023. The OCC publishes Bulletin 2023-17; the Federal Reserve publishes SR 23-4.

It replaced the agencies’ separate predecessors, including OCC Bulletin 2013-29 and its 2020 frequently-asked-questions supplement. Those are rescinded. A vendor management programme still citing 2013-29 as its authority is describing a framework that no longer exists, and the substantive change is not cosmetic: the 2023 guidance is consciously risk-based and repeatedly says that not every relationship warrants the same treatment, whereas the FAQ-driven old regime had accreted a great deal of de facto checklist.

In May 2024 the three agencies followed with a Guide for Community Banks, which is illustrative rather than a new set of expectations. The Federal Reserve publishes the community bank guide.

Deciding whether the relationship is critical

The guidance turns on a threshold judgement: whether a third-party relationship is a critical activity, meaning one that could cause significant risk if the third party fails to perform, that could have significant customer impacts, or that requires significant investment to implement or significant expenditure to replace.

AI relationships are classified badly at this step more often than at any other, for a structural reason: they start small. A tool adopted by one team for drafting becomes, over eighteen months, the thing that summarises every complaint before it is triaged. The criticality assessment was performed at the start and never revisited. The guidance contemplates periodic reassessment; in practice, the trigger to reassess has to be a change in use, and somebody has to own noticing it.

One useful discipline is to classify by the decision the output touches rather than by the contract value. A four-figure annual subscription that influences adverse action decisions is a more consequential relationship than a seven-figure one that does not.

The lifecycle, applied to an AI vendor

The guidance organises expectations around five stages, plus governance themes of oversight and accountability, independent reviews, and documentation and reporting. For each stage there is a question an AI vendor raises that a payments processor or a print supplier does not.

Planning

Before selection, articulate what the activity is and what could go wrong. The AI-specific question is whether the bank has defined what the system is allowed to decide. A planning document that describes the capability and not the decision boundary produces a relationship nobody can later scope.

Due diligence and selection

The guidance lists the areas to assess: strategies and goals, legal and regulatory compliance, financial condition, business experience, qualifications and backgrounds of principals, risk management, information security, management of information systems, operational resilience, incident reporting, physical security, human capital management, reliance on subcontractors, insurance and contractual arrangements with other parties.

The AI-specific difficulty is that the substantive question — does this model work for our population — cannot be answered by diligence on the vendor. It can only be answered by evaluation on your own data, and the guidance does not require that; model risk management does. This is the seam where the two frameworks have to be joined explicitly, or the model gets a clean vendor file and no validation. See effective challenge under SR 11-7.

Contract negotiation

The guidance enumerates contract provisions to consider: nature and scope, performance measures and benchmarks, responsibilities for providing and receiving information, right to audit and remediation, responsibility for compliance, cost and compensation, ownership and licensing, confidentiality and integrity, operational resilience and business continuity, indemnification, insurance, dispute resolution, limits on liability, default and termination, subcontracting, foreign- based third parties, and regulatory supervision.

For an AI vendor, four of those carry unusual weight: ownership and licensing (who owns outputs, whether inputs may be used for training), right to audit (frequently resisted, and increasingly substituted by a third-party attestation, which is a negotiation the bank should enter deliberately rather than by default — see right-to-audit clauses), subcontracting, and regulatory supervision, meaning the vendor’s obligation to permit examination by the bank’s regulators under the Bank Service Company Act.

Ongoing monitoring

Conventional vendor monitoring watches financial condition and service levels. An AI relationship also requires watching the thing itself: output quality on your own traffic, model version changes, and changes to the vendor’s own upstream providers. A vendor that silently switches the foundation model underneath its product has materially changed the service without changing the contract, and no financial- condition review will surface it.

Termination

Exit planning has to answer where the data goes, whether prompts and fine-tuning artefacts are portable, and how quickly the activity can be moved or brought in-house. For a product built tightly around one vendor’s tooling, the honest exit plan is longer than anyone wants to write down, and writing it down is the point.

The subcontractor chain

The guidance is explicit that a banking organisation’s use of third parties does not diminish its responsibility to operate in a safe and sound manner and to comply with applicable law, and that this extends to the third party’s own subcontractors.

This is where AI vendors differ structurally from most other vendors. A great many software products described as AI-powered are wrappers over another company’s hosted model. The bank has a contract with the vendor; the data goes to the model provider; and the bank frequently does not know which provider, because the vendor treats it as an implementation detail. The correct diligence question is therefore not “do you use subcontractors” but “name the model providers you send our data to, tell us the retention and training terms you have with them, and tell us how we learn when that list changes”. A vendor that cannot answer that has not, in the guidance’s terms, given you what you need to assess reliance on subcontractors.

Concentration risk

The guidance asks institutions to consider concentration risk arising from reliance on a single third party for multiple activities, and from industry-wide reliance on a small number of providers. The second form is the one that is unresolved in AI and worth naming as such: a large share of financial-sector AI capability currently depends on a small number of model providers running on a small number of cloud platforms and a very small number of accelerator suppliers. No agency has issued a concentration expectation specific to that stack, and it is not clear what an individual bank could do about industry-level concentration even if it were required to. What a bank can do is avoid single-provider dependence in its own critical paths and be able to say what it would do if a provider became unavailable — which is the contingency plan SR 11-7 already asks for, arriving from a second direction.