By separating preparing a payment from releasing it. The agent can gather the details, build the instruction and check it against the rules, but the release is a different capability with its own bound. Above a set limit, to a new payee or on an unverified instruction, the payment is held for a named person, and every verdict is filed.
Why is "the agent has no payment permission" not enough?
Many banks start by giving the agent no access to payment systems at all. That stops direct transfers, but money can still move indirectly. An agent that can change a payee's bank details, raise a credit limit, reverse a fee or approve a standing order has a path to move value without ever touching the payments screen.
So the question is not "can it pay?" but "which of its capabilities change where money goes?" Each one needs to be listed and bound, including the ones that do not look like payments. The wider map of what agents may touch is in AI agents in banking: what they may and may not do.
What controls actually stop the money?
The controls that work are enforced outside the agent, at the moment it tries to act. A prompt instruction saying "never pay without approval" is guidance, not a control.
| Control | What it stops | Where it sits |
|---|---|---|
| Release as a separate capability | The agent preparing and sending in one step | Permission layer, per capability |
| Amount limit set by the bank | Any single payment above the threshold | Checked at the moment of action |
| New-payee hold | First payments to an account never paid before | Checked against the payee record |
| Source check on the instruction | Payments triggered by an emailed or pasted request | Provenance of the fact behind the action |
| Daily and cumulative caps | Many small payments adding up | Aggregated per agent and per customer |
| Platform floor | Actions no agent may take, such as reversing a settled payment | Applies to every agent at every depth |
When any of these blocks the action, the result should be "held", meaning drafted and waiting for a named person, or "refused", meaning outside the agent's bounds. Both should record which control decided.
What does the agent do, and what stays with a person?
The agent does the slow part of payment work well. It finds the instruction, matches it to the account, checks the payee name, checks the balance, flags anything unusual and drafts the payment with its evidence attached. A person reviews a ready case rather than building one.
What stays with a person:
- releasing payments above the bank's limit or to new payees;
- any payment whose instruction arrived from outside, by email, letter or phone;
- changes to payee bank details, which a person verifies by call-back on a known number;
- reversals, recalls and anything that cannot easily be undone;
- the decision to raise the agent's own limits.
An illustrative example
Take a business bank whose operations team receives payment requests from corporate clients. A client's finance contact emails asking for 40,000 to go to a supplier, with new bank details attached.
The agent reads the email, finds the client's account and drafts the payment. It then hits three bounds at once: the amount is above the agent's limit, the payee is new, and the instruction came from an email, which is an external source. The verdict is "held", and the filed record names all three. A person calls the client on the number already on file. The client knows nothing about the request. The email was a fraud attempt, and nothing moved.
That pattern is the heart of whether a fraudster can trick a bank's AI agent into moving money. The agent is not expected to spot every scam. It is bounded so that a scam it misses still cannot complete.
How do banks know the controls are working?
They test them and read the record. Before go-live, the agent is replayed against the bank's own past cases, including attempted frauds, to show it holds the right ones. After go-live, every verdict is filed in an append-only record, so a reviewer can pull every held payment and check the reason.
Held payments a person rejected show the hold doing its job. A payment that went through unheld and later proved wrong shows a gap.
Agents that sit near customer money, such as one helping to investigate suspected money mule accounts, need the same discipline even though their main job is reading, not paying.
Where Pryme fits
In Pryme, moving money is depth 4, and an agent reaches it only for a capability certified on the bank's own cases. Every action meets five bounds at once: role scope, certificate, sources, the bank's own limits and the platform guardrails. The lowest wins. An external claim, such as an emailed invoice, cannot authorise a payment, and the verdict names the bound that decided.
Questions people ask
Can the agent approve payments another agent prepared?
It should not. Approval by a second agent does not add a person's judgement, and two agents can share the same blind spot. Release above the limit stays with a named person.
Does strong customer authentication cover agent payments?
Strong customer authentication proves the customer is who they say they are when they instruct a payment. It does not govern what an internal agent may release on the bank's side, so the bank still needs its own limits.
Are these controls a legal requirement?
Banks have general duties on operational risk, fraud prevention and, in some markets, AI oversight, which the EU AI Act for banks deploying AI agents covers. The specific controls are a design choice that lets the bank show those duties are met.