Split every payment into two acts: preparing it and releasing it. The agent prepares, which is most of the work. A named person releases, which is where the authority sits. That split keeps money movement under someone accountable, lets agents carry the heavy lifting, and gives every payment a clear answer to the question a regulator or customer will ask: who decided to send this?
Why split preparation from release?
Payments in banks have always been split this way between people. One person keys, another authorises. The control is old because the risk is old: a single person who can both create and send a payment can make a mistake, or commit a fraud, with nobody in a position to see it first.
An agent does not change the risk. If anything it concentrates it, because an agent can prepare and send at a speed and volume no person can. A flaw in its reasoning, a manipulated instruction or a corrupted source can produce many wrong payments before anyone notices. Keeping release with a person puts a check between the agent's output and the money leaving.
The split also makes accountability legible. "The agent sent it" is not an answer anyone can act on. "The agent prepared it, and this person released it at this time, having seen these facts" is.
What does preparing a payment involve?
Preparation is far more than filling in a form. Done well, it is where most errors are caught.
| Preparation step | What the agent does |
|---|---|
| Gather the instruction | Collects the request and records where it came from, with its provenance class |
| Verify the payee | Checks the payee against records held, payee name checks and any recent changes |
| Check the purpose | Matches the payment to an invoice, contract, loan agreement or customer request |
| Screen | Runs sanctions, fraud and limit checks and records results |
| Assemble the release pack | Presents the payment, its basis, check results and any anomalies to the approver |
For complex payments such as cross-border wires, preparation includes routing, charges and correspondent details. The playbook on preparing outbound international wires for release with an AI agent covers those steps.
What does a person need at release?
A release is only a control if the person releasing has what they need to say no. Too often, the approver sees an amount, a payee name and an approve button. That is not a decision; it is a click.
The release pack should show, at a glance, the facts that matter: the payee and how it was verified, the purpose and the document it matches, anything unusual compared with past payments to this payee, and the provenance of the instruction. If the instruction came from an email, the approver should see that. A high-value payment release checklist sets out what a release should confirm.
The approver also needs time and authority. If they are expected to release hundreds of payments an hour, they will not read the packs. Volume is a design question: low-risk, routine payments may suit a different route, discussed below, so that people can concentrate on the ones that need judgement.
Are there payments an agent may release?
There can be, within narrow limits. Depth 4 covers moving money, and a firm may grant it for a specific payment capability once the agent has earned it on the firm's own cases. Typical candidates are routine, low-value, repeat payments to verified payees under standing arrangements, where the facts all come from strong sources and the customer's limits are tight.
Some releases should never be delegated, whatever the evidence:
- Payments held for fraud checks. The hold exists because something looked wrong; releasing a payment held for fraud checks is a judgement about that concern.
- Loan disbursements, where the release is also the moment the borrower becomes liable; see whether an AI agent can release loan funds to a borrower.
- Any payment whose instruction rests on an external claim, such as an emailed change of bank details.
- Payments above the customer's limits for that capability.
The same principle reaches beyond payments. In trading, an agent can stage trades for a person to release, with the same split and for the same reasons.
What goes wrong with this model?
Three failures are common.
Rubber-stamping. Approvers release everything because the agent is usually right. The fix is better release packs, sensible volumes, and monitoring of approval patterns: an approver who never rejects anything is a signal.
Batch release. A person releases a batch of hundreds in one action. The control then covers the batch, not each payment. Batches should be grouped by risk and any anomalous payment pulled out for individual release.
Self-approval through the back door. The agent prepares, and another agent "approves", or the person who raised the request also releases. Separation must be checked by the platform, not assumed.
Where Pryme fits
In Pryme, preparing a payment and releasing it are separate capabilities. Release returns the verdict "held" for a named person unless the agent holds a current depth 4 certificate for that exact capability and the payment sits inside every bound. The release, its approver and the facts shown are filed. See AI agents in banking: what they may and may not do.
Questions people ask
Does a person releasing every payment slow things down?
Preparation is where the time goes, and the agent takes most of it. Release becomes faster because the approver gets a complete, checked pack instead of assembling it.
Can the approver be in a different team?
Often that is better, as long as they have the authority and context to decide. What matters is that they are named, independent of the preparer, and able to refuse.
What happens if the approver rejects the payment?
The rejection and its reason are filed, and the agent routes the payment back for correction or closes it. Rejections are useful evidence for improving the agent's preparation.