A design tool for teams building AI systems inside a bank. Ten questions, then a brief: whether a model should do this at all, how the work splits between the model, existing systems and people, which pattern fits, which control layers carry the weight, which of the tracker's documents apply, the evals to write, the human gates, the questions an examiner will ask, and five lines for the board. The taxonomy comes from public engineering guidance and the rules from the regulation tracker on this site; the brief never names a vendor, because the controls are the same whichever model sits behind them.
Five decisions in the order supervisors think about them. The first one is the one teams skip.
What should this system look like?
01 · The use case
What is the system for?
Answers customers' questions and completes simple tasks in a chat or voice channel. Picking a use case loads its typical answers; change any of them below.
02 · Who is affected
Who does the output reach?
The system answers, decides or acts toward a customer
03 · Reversibility
If it is wrong, can it be undone?
Rework, an apology, a correction notice
04 · Stakes
What does a wrong call cost?
Customer harm, a loss, a complaint
05 · Knowledge
Where does the truth live?
Documents to reason with, systems to check against
06 · Verifiability
How is a good output recognised?
A reviewer or a judge model can score it against a rubric
07 · Steps
Are the steps known before you start?
A known frame with branches
08 · Jurisdiction
Which supervisors are in the room?
Federal agencies plus state law
09 · Delivery route
How will the model be reached?
The bank's existing cloud provider hosts the model
10 · Your bank (optional)
Which bank is this for?
Adds the bank's regulators and its AI record to the brief.
The pattern moves as you answer. Predictability against model autonomy, after public engineering guidance on agents.
Customer-facing chatbots: 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.
Which steps belong to a person, the model and a system?
| # | Step | Owner | Note |
|---|---|---|---|
| 1 | Identify the customer and the intent | A system | Authentication in the channel; intent classification with a confidence. |
| 2 | Answer a knowledge question | The model | Retrieval over product terms and policies, with the source shown. |
| 3 | Answer an account question | A system | A tool call to the system of record; the model formats, never invents. |
| 4 | Execute a low-value task | A system | Within an envelope, by rule, confirmed with the customer. |
| 5 | Escalate | A person | Complaints, disputes, hardship and anything the classifier is unsure about. |
Which control layers carry the weight?
Each layer is described, with its controls and documents, on the control plane page.
- Governance and accountability: core for this design.
- Identity and entitlements: core for this design.
- Action gateway: core for this design.
- Data and knowledge: core for this design.
- Models and vendors: core for this design.
- Human oversight and escalation: core for this design.
Which rules and guidance does this design answer to?
| Document | Authority | Why it applies here | Status |
|---|---|---|---|
| CFPB Chatbots in Consumer Finance (issue spotlight, 2023) | CFPB | Inaccurate answers and blocked access to a person can violate consumer law. | Final |
| Regulation (EU) 2024/1689 | EU AI Act | Article 50: people must be told they are talking to an AI system. | In force |
| NIST AI 600-1 (Generative AI Profile) | NIST | Confabulation named as a generative-AI risk, with suggested actions. | In force |
| DFS Virtual Currency Customer Service Guidance (May 2024) | NY DFS | New York's expectations for customer service, including a route to a human. | In force |
| SR 26-2 | Federal Reserve | US model risk management as revised in April 2026. | In force |
| SR 23-4 | Federal Reserve | US third-party risk management, including the model provider. | In force |
| SB 26-189 | Colorado AI Act | Colorado: notice, explanation and human review for consequential automated decisions from Jan 1, 2027. | Final |
| BCBS Third-Party Risk Principles (Dec 2025) | Basel Committee | Nth-party supply chains and concentration on cloud providers. | In force |
| BCBS ICT Risk Management Report (June 2026) | Basel Committee | How supervisors look at ICT and cloud dependencies. | Final |
| OCC Bulletin 2026-13 | OCC | For a national bank, the OCC's copy of the 2026 model-risk guidance. | In force |
| NIST AI RMF 1.0 | NIST | The 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?
- 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.
- The customer is told they are dealing with an AI system and can reach a person in one step.
- Retrieval used for live state, producing confident wrong balances.
- No disclosure that the customer is talking to an AI system.
- Escalation buried behind repeated attempts to keep the customer in the bot.
What will a validator or an examiner 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?
- Show me how a customer reaches a person, and how long it took the last ten who tried.
What it does: answers customers' questions and completes simple tasks in a chat or voice channel; the model prepares and may act within limits; a person approves anything that reaches a customer or cannot be undone.
Pattern: workflow (routing, 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?
01
Augmented call
One model call with retrieval, tools and a structured output, inside code you control.
The task is well defined and the output can be checked. Most bank use cases should start here.
02
Workflow
Several model calls orchestrated by your code, in a sequence or a graph you designed.
Your code lays out the steps, the cost of error is real, and you need to observe every step.
03
Bounded agent
The model plans its own path through a set of tools toward a goal, inside a turn budget and an action envelope.
The path cannot be fixed in advance and the stakes allow it. Autonomy is kept in check by limiting tools, turns and what an action may touch.
Which workflow shapes are there?
| Shape | What it does |
|---|---|
| Prompt chaining | Each step's output is the next step's input, with a programmatic check between them. |
| Routing | Classify the input first, then send it to a specialised path: a knowledge answer, a transaction on a live system, or a person. |
| Parallelization | Independent sub-tasks run at the same time, or several attempts run and are compared, then results are aggregated in code. |
| Orchestrator and workers | One model decomposes the task and hands scoped sub-tasks to workers; the orchestrator resolves gaps and conflicts when results return. |
| Evaluator and optimizer | One model produces, another checks against explicit criteria, and the loop repeats until the check passes or a person is called. |
Source: public engineering guidance on building effective agents (anthropic.com/engineering); the same shapes appear under similar names in every major provider's documentation.
What are the building blocks, and what do they mean in a bank?
| Primitive | What it is | In a bank |
|---|---|---|
| Tools | Functions the model can call, with a typed schema; your code executes them and returns the result. | Every touch of a bank system is a tool. The action gateway sits between the call and the system. |
| Connectors (MCP) | An open protocol for exposing tools, data and prompts to models through a standard server interface. | One governed server per system of record beats ad hoc integrations; entitlements live on the server side. |
| Structured outputs | The model returns data in a schema you define, so code can validate and route it. | Anything that feeds a system or a decision record is structured, never free text. |
| Retrieval | Relevant passages from a document set are placed in the model's context before it answers. | For stable knowledge only. Live state comes from tools. |
| Subagents | Separate model contexts given scoped sub-tasks by an orchestrator, which merges their results. | Each subagent gets its own identity and tool set; the orchestrator resolves conflicts, not the workers. |
| Hooks | Deterministic code that runs on events: before a tool call, after an output, on completion. | Where policy checks, logging and blocking live; they do not depend on the model agreeing. |
| Packaged instructions (skills) | Reusable folders of instructions, scripts and references the model loads when a task matches. | How a bank's own procedures become repeatable; version them like code. |
| Turn and cost budgets | Limits on how many steps and how much compute an agent may use before it must stop or ask. | The simplest autonomy control there is; supervisors will ask for it. |
Connectors follow the open Model Context Protocol (modelcontextprotocol.io), adopted across providers.
01
Provider API
A direct contract with the model provider.
One third party to diligence; data residency and retention terms are yours to negotiate.
02
Through a cloud platform
The bank's existing cloud provider hosts the model and the bank's data stays inside that boundary.
Two third parties in the chain and a concentration question; often the faster route through security review.
03
Mixed
Different routes for different tiers or regions.
Exit plans per route; the same evals across both so a switch can be judged.
How do bank teams prove an AI system works?
An eval is a structured test set that checks whether the system returns the expected output. It defines success in measurable terms, exposes design assumptions early, and is the gate that shows whether a prompt change, a model swap or a new retrieval strategy made things better or worse. In model-risk language it is outcomes analysis and ongoing monitoring, run by engineers on every release. Five stages: define the task in specific terms, build the golden dataset, run automated checks, score with a judge where interpretation is needed, act on what you find.
01
Code-based
Deterministic checks in milliseconds: schema, required fields, reconciliation, forbidden content.
Every output, every run. The floor for anything that touches a system.
02
Model-based
A judge model scores outputs against a written rubric.
Interpretive tasks: summaries, narratives, answers. Calibrate against human scores monthly.
03
Human review
Experts score a stratified sample, or everything, by hand.
High stakes or novel behaviour, where neither code nor a judge can be trusted alone.
Method after public documentation on developing test cases (platform.claude.com). Thresholds in a brief are starting points; the bank's own human-scored sample sets the real ones.
Where do I start for my use case?
01
Credit scoring & underwriting
A system that assembles and checks a credit application, and explains a decision.
02
Fair lending & discrimination
A system that tests models and decisions for disparate treatment and impact, and documents the results.
03
AML / KYC
A system that triages alerts, assembles cases and drafts investigations for AML and KYC teams.
04
Fraud detection
A system that scores and triages suspected fraud, and helps investigators and customers respond.
05
Customer-facing chatbots
A system that answers customers' questions and completes simple tasks in a chat or voice channel.
06
Model risk management
A system that documents, validates and monitors models, and drafts the artefacts examiners read.
07
Generative & agentic AI
A system that runs a bounded agent on internal tasks: research, drafting, operations exceptions.
08
Third-party & vendor AI
A system that buys or configures a vendor's AI system and runs it under the bank's controls.
09
Cybersecurity
A system that supports detection, triage and response in the security operations centre.
10
Data & privacy
A system that classifies, governs and answers questions about personal and risk data.
11
Trading & capital markets
A system that supports research, surveillance and client communication in markets businesses.
12
AI governance (general)
A system that runs the AI inventory, policy and reporting that the board and supervisors ask for.
13
AI-generated code & coding agents
A system that writes, reviews and ships code with AI assistance under the bank's architecture rules.
Is this advice on what our bank must do?
No. It is a design tool that maps common architecture choices to what regulators and public engineering documentation say, with dates and sources. Your compliance, risk and legal teams own the conclusions.
Why is the pattern taxonomy vendor-neutral?
The three patterns and the workflow shapes come from public engineering guidance and appear, under similar names, in the documentation of every major provider. The brief never names a vendor because the controls are the same whichever model is behind them.
Where do the documents come from?
From the regulation tracker on this site: 19 authorities, 164 documents, each linked to the official text and updated as rules change. A brief cites only documents that exist there.
How do I use the brief?
Copy it into your intake or architecture-review template, keep the links, and treat the examiner questions as the test of whether the design is finished.
Build with the rules in view. We'll tell you when they move.
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