The bank, always, and inside the bank a named person. An agent has no legal standing and cannot be held to account. To customers and regulators, the bank answers. Internally, accountability follows who granted the agent its authority, who approved the specific action, and who owned the process. Those names should be set before go-live and recorded with every action.
Why can the answer not be "the vendor" or "the model"?
Because customers dealt with the bank, and regulators supervise the bank. A vendor contract can share costs or remedies after the fact, but it does not move the bank's duty to the customer or its standing with the regulator. Outsourcing an activity does not outsource the responsibility for it, which is a settled principle in banking supervision.
The broader legal picture outside banking is covered in who is liable when an AI agent makes a mistake. In a bank the answer is narrower and stricter.
How is accountability assigned inside the bank?
By depth, because depth decides who made the last decision.
| What happened | Who answers |
|---|---|
| Agent drafted, a person sent it unchanged (depth 2) | The person who sent it, and the owner for the quality of drafts |
| Agent acted on its own within bounds (depth 3) | The business owner who accepted that depth on the evidence |
| Agent prepared, a person approved (depth 4, held) | The approver for the decision; the owner for the preparation |
| Agent acted outside its bounds | The owner and whoever set or enforced the bounds |
| Bounds were wrong for the risk | The owner and the forum that approved them |
In the UK, the Senior Managers and Certification Regime requires named individual accountability for areas of a firm's business, and an agent working in an area falls under the senior manager responsible for it. Other markets have similar expectations, even without a formal regime.
What does the record need to show?
To assign accountability after a mistake, the bank needs to reconstruct what happened. That means every action the agent took, and every action it refused or held, filed with:
- the request and the facts the agent relied on, with their sources;
- the capability used and the depth it was allowed at;
- which limit decided the outcome;
- the certificate or approval that was current at the time;
- the name of any person who approved, edited or sent the output.
Without this, the conversation after a mistake becomes guesswork about whether the agent "should have" done it. With it, the question is factual: was the action within the bounds that a named person approved? The general principle, that people answer and records show which people, is set out in who answers for an AI agent's mistake.
An illustrative example
Take a bank whose agent closes customer-requested accounts with a zero balance at depth 3. One closure goes wrong: the customer had a regular salary credit due the next day, which then bounced.
The record shows the agent checked for scheduled payments but not for regular incoming credits. That check was not in the conditions approved when the capability went live. Accountability sits with the business owner who approved the conditions, not with the agent and not with the contact centre. The fix is to add the check, retest on past closures, and contact affected customers. The conditions that should apply are discussed in whether an AI agent can close a bank account.
A second case: the agent correctly held a payout to another bank, and a staff member approved it without the call-back the procedure required. The approver is accountable for that decision. The record shows both facts.
What about refusals?
A mistake can be a wrong "no" as well as a wrong "yes". An agent that refuses legitimate requests can harm customers through delay or lost service. Refusals should be filed and sampled like actions; how to review the refusals an AI agent makes covers how. The same owner answers for both.
How should a bank set this up before go-live?
- Name a business owner for each agent and each capability above depth 1.
- Map each capability to the senior manager or executive whose area it sits in.
- Record who approved each depth and on what evidence.
- Define who may approve held actions, by name or role, and require their identity on every approval.
- Agree how the vendor relationship handles remedies, without implying the vendor takes the bank's duty.
A useful planning aid is the bank operations depth matrix for AI agents, which shows which operations suit which depth. The bank-wide view is in AI agents in banking: what they may and may not do.
Where Pryme fits
In Pryme, every verdict is filed in an append-only record that names the capability, the bound that decided and any person who approved. Depth comes from the bank's own limits and Attest evidence, so the record also shows which approval and which certificate stood behind the action at that moment.
Questions people ask
Does a person approving every action remove the bank's risk?
No. It moves the decision to the approver, but rubber-stamping is common when volumes are high. Approval only works if approvers have time and information to judge.
Can the agent's builder be accountable?
Internally, for the quality of the build and testing. For the decision to use the agent in a process, the business owner answers.
What does the bank tell the customer after a mistake?
What happened, what it has done to put it right, and how to complain. Whether an agent or a person made the error does not change the bank's duty to fix it.