# Building a system that buys or configures a vendor's AI system and runs it under the bank's controls inside a bank

Source: https://www.bankingnewsai.com/agentic-banking/build/third-party-vendors
Last updated: Sep 17, 2026

Most bank AI is bought, not built, and the buyer's job is the controls around the purchase: due diligence on the model and its data, contract terms on change notice and exit, ongoing monitoring, and validation of a system the bank did not write. The patterns matter less than the wrapper: the bank owns the evals, the logs and the escalation route regardless of who built the model, and the same third-party guidance applies whether the model comes from a provider directly or through a cloud platform.

## The brief (default answers)

| Choice | Answer |
| --- | --- |
| Who is affected | Customers, via a person |
| Reversibility | With cost |
| Stakes | Material |
| Knowledge | Both |
| Verifiability | By judgment |
| Steps | Known |
| Jurisdiction | United States |
| Delivery route | Through a cloud platform |

- **Pattern:** Workflow — Several model calls orchestrated by your code, in a sequence or a graph you designed.
- **Tier:** 2, Tier 2: act with approval — Material but recoverable. The model may prepare and, within limits, act, with a person approving anything that leaves the bank or touches a customer.
- **Workflow shapes:** Parallelization, Evaluator and optimizer
- **Human involvement:** The model prepares and may act within limits; a person approves anything that reaches a customer or cannot be undone.
- **Knowledge:** Retrieval over the governed document set, with a citation on every answer and a refusal when nothing relevant is found.; Tool calls to the system of record for anything live. Never retrieval for a balance, a case status or a limit.; Documents to reason with, systems to check against: the workflow decides which question goes where before the model answers.

## Decomposition

| Step | Owner | Note |
| --- | --- | --- |
| Due diligence | human | Model documentation, data provenance, security, subcontractors, concentration. |
| Contract | human | Change notification, audit rights, data use, exit and portability. |
| Wrap | system | The bank's own identity, action gateway, logging and evals around the vendor system. |
| Validate | human | Outcomes analysis on the bank's data, as for any model the bank did not build. |
| Monitor | model | Drift and quality summaries drafted from the logs for the owner. |

## Control layer weights (0–4)

| Layer | Weight |
| --- | --- |
| governance | 1 |
| identity | 1 |
| actions | 0.9 |
| data | 1 |
| models | 1 |
| runtime | 0.8 |
| observability | 0.7 |
| oversight | 0.6 |

## Documents that apply

- [SR 23-4](https://www.bankingnewsai.com/ai-regulation/documents/fed-sr-23-4) — Due diligence, contracts, monitoring and exit for vendor AI and foundation-model access.
- [BCBS Third-Party Risk Principles (Dec 2025)](https://www.bankingnewsai.com/ai-regulation/documents/bcbs-third-party-risk-principles-2025) — Nth-party chains and concentration, where cloud-hosted models are assessed.
- [FSB AI monitoring report (Oct 2025)](https://www.bankingnewsai.com/ai-regulation/documents/fsb-monitoring-ai-adoption-vulnerabilities-2025) — Provider concentration named as a vulnerability to monitor.
- [SR 26-2](https://www.bankingnewsai.com/ai-regulation/documents/fed-sr-26-2) — Purchased models are still the bank's to understand and validate.
- [SB 26-189](https://www.bankingnewsai.com/ai-regulation/documents/co-sb26-189) — Colorado: notice, explanation and human review for consequential automated decisions from Jan 1, 2027.
- [BCBS ICT Risk Management Report (June 2026)](https://www.bankingnewsai.com/ai-regulation/documents/bcbs-ict-risk-management-range-of-practices-2026) — How supervisors look at ICT and cloud dependencies.
- [OCC Bulletin 2026-13](https://www.bankingnewsai.com/ai-regulation/documents/occ-bulletin-2026-13) — For a national bank, the OCC's copy of the 2026 model-risk guidance.
- [NIST AI RMF 1.0](https://www.bankingnewsai.com/ai-regulation/documents/nist-ai-100-1) — The voluntary Govern, Map, Measure, Manage frame for everything model-risk guidance leaves out.

## Evals

- A golden dataset of at least 150 real cases with expected outputs, including adversarial inputs: wrong documents, unusual formats, prompts that try to change the task.
- A judge model scoring against a written rubric (accuracy, completeness, tone, citation present), calibrated against a human-scored sample every month. Threshold set from the human sample, not guessed.
- Citation checks: every factual claim resolves to a passage in the governed set; unsupported claims below 2% of answers.
- Escalation evals: the cases that must reach a person do, on a held-out set, with precision and recall both reported.
- Trace evals per step, not only end to end: which step fails, how often, at what cost, so a prompt or model change can be judged step by step.
- The same suite reruns on every prompt change, model version change and retrieval change; a regression blocks the release. That is what ongoing monitoring and outcomes analysis mean in model-risk terms.

## Human gates

- Per-action approval by a competent reviewer for anything customer-facing or irreversible; sampled review for the rest.
- Validation proportionate to materiality, with monitoring for drift on inputs and outputs.
- An escalation route to a person that the customer can reach in one step.
- Monthly review of the evals and the exception log by the accountable owner.

## What an examiner will ask

- Where is this system in your inventory, what tier did you assign, and who signed it off?
- What counts as a model here, and what does your validation cover for the parts that are not?
- Show me the data lineage behind the retrieval set and the training or tuning data.
- What can the system do without a person, and where is that written down?
- How do you know it is still working: which evals run, how often, and what happened the last time one failed?
- What did you do about the vendor: due diligence, contract, exit plan, concentration?
- Walk me through one wrong output from production and what the customer, if any, saw.
- Who can switch it off, and has that been tested?

## What the board should hear

- What it does: buys or configures a vendor's AI system and runs it under the bank's controls; the model prepares and may act within limits; a person approves anything that reaches a customer or cannot be undone.
- Pattern: workflow (parallelization, evaluator and optimizer); tier 2: act with approval.
- Rules it answers to: 4 documents across US, each linked in the brief.
- How we know it works: a golden dataset, automated checks on every release, and human review at the level the tier demands.
- What could go wrong and who answers: the accountable owner, the kill switch, the escalation route.

## Pitfalls

- Trusting the vendor's evals instead of running the bank's own.
- No exit plan from a model the business now depends on.
- Nth-party blind spots: the vendor's own model supplier and cloud.

Change any answer on the interactive map: https://www.bankingnewsai.com/agentic-banking/build/third-party-vendors

---

Canonical page: https://www.bankingnewsai.com/agentic-banking/build/third-party-vendors
Part of [BankingNewsAI](https://www.bankingnewsai.com/) — a free daily brief on AI in banking, an AI regulation tracker (19 authorities, 166 documents) and AI-strategy profiles of the 100 largest US banks. Markdown versions of every reference page: append `.md` to the page URL; index at https://www.bankingnewsai.com/llms.txt.