AI agents in banking · The build map · Brief 08

Third-party & vendor AI: a design brief for banks.

Last updated Sep 17, 2026 · standard answers for this use case · adjust them in the map

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.

WorkflowParallelizationEvaluator and optimizerTier 2: act with approvalautonomy level 2

Third-party & vendor AI: The model prepares and may act within limits; a person approves anything that reaches a customer or cannot be undone. Several model calls orchestrated by your code, in a sequence or a graph you designed. Material but recoverable. The model may prepare and, within limits, act, with a person approving anything that leaves the bank or touches a customer.

PatternWorkflow. Your code lays out the steps, the cost of error is real, and you need to observe every step.ParallelizationIndependent sub-tasks run at the same time, or several attempts run and are compared, then results are aggregated in code.Evaluator and optimizerOne model produces, another checks against explicit criteria, and the loop repeats until the check passes or a person is called.KnowledgeRetrieval 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.Delivery routeThrough a cloud platform: two third parties in the chain and a concentration question; often the faster route through security review.

Which steps belong to a person, the model and a system?

A PERSONTHE MODELA SYSTEM1
Due diligence
2
Contract
3
Wrap
4
Validate
5
Monitor
#StepOwnerNote
1Due diligenceA personModel documentation, data provenance, security, subcontractors, concentration.
2ContractA personChange notification, audit rights, data use, exit and portability.
3WrapA systemThe bank's own identity, action gateway, logging and evals around the vendor system.
4ValidateA personOutcomes analysis on the bank's data, as for any model the bank did not build.
5MonitorThe modelDrift and quality summaries drafted from the logs for the owner.

Which control layers carry the weight?

Governance and accountabilityCOREIdentity and entitlementsCOREAction gatewayCOREData and knowledgeCOREModels and vendorsCORERuntime and orchestrationSTANDARDObservability, evaluation and auditSTANDARDHuman oversight and escalationSTANDARD

Each layer is described, with its controls and documents, on the control plane page.

Which rules and guidance does this design answer to?

DocumentAuthorityWhy it applies hereStatus
SR 23-4Federal ReserveDue diligence, contracts, monitoring and exit for vendor AI and foundation-model access.In force
BCBS Third-Party Risk Principles (Dec 2025)Basel CommitteeNth-party chains and concentration, where cloud-hosted models are assessed.In force
FSB AI monitoring report (Oct 2025)FSBProvider concentration named as a vulnerability to monitor.Final
SR 26-2Federal ReservePurchased models are still the bank's to understand and validate.In force
SB 26-189Colorado AI ActColorado: notice, explanation and human review for consequential automated decisions from Jan 1, 2027.Final
BCBS ICT Risk Management Report (June 2026)Basel CommitteeHow supervisors look at ICT and cloud dependencies.Final
OCC Bulletin 2026-13OCCFor a national bank, the OCC's copy of the 2026 model-risk guidance.In force
NIST AI RMF 1.0NISTThe voluntary Govern, Map, Measure, Manage frame for everything model-risk guidance leaves out.In force

How will you know it works, before and after launch?

CODE CHECKS30%JUDGE MODEL50%HUMAN REVIEW20%
  • 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.

Where must a person be in the loop?

  • 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.
  • 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.

What will a validator or an examiner ask?

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

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.

Which of the 100 largest US banks have put this use case on the record?

Every rule this brief cites, the morning it changes.

agent deployments, regulator positions and the day's six stories · in your inbox by 7 am ET · free

plus every tracker, bank and agent page update, the morning after · leave any morning