Large payments are hard to recall once settled, so every check happens before release. A high-value payment release checklist covers the instruction's source, the payee's identity and bank details, limits, sanctions and fraud status, duplicates and cut-off. An AI agent can run and document most checks; named people release the payment.
Why does release need its own checklist?
Once a high-value payment settles on another party's rail, getting it back depends on the receiver. That makes release the irreversible moment, and everything before it is preparation. The checklist puts all the preparation in one place, so the people releasing see the whole picture rather than a single approve button.
The most common loss in high-value payments is not a technical fault. It is a convincing instruction to pay a familiar supplier at new bank details. The checklist is built around catching that.
Who uses it, and at what point?
Payment operations, treasury and finance teams use it on any payment above their high-value threshold, and on any payment, whatever the amount, to new or changed bank details. The agent completes it once the payment is in a file and before it is queued for approval. The broader process for building files is in how to prepare bank payment files for release with an AI agent.
The agent works at depth 2 here. It checks, records and flags. It does not release. Releasing payments held for fraud review is a separate question, answered in whether an AI agent can release a payment held for fraud checks, and the usual answer is no.
How do you complete each item?
Record pass, fail or not applicable for each, with the evidence and its provenance. Three items carry most of the weight.
- Instruction source. Where did the payment instruction come from? A signed record from your purchasing system is different from an emailed request. An external claim cannot authorise a payment on its own.
- Payee verification. Does the account name match the payee? In the EU, the Instant Payments Regulation requires payment service providers to verify the payee's name, and the result should be recorded here. The method is set out in how to verify new payees on high-value payments with an AI agent.
- Changed details. If bank details changed, was the change confirmed by calling a number already on file, not one supplied in the change request?
The high-value payment release checklist
| No. | Check | Agent may | Evidence |
|---|---|---|---|
| 1 | Instruction source and its provenance | Identify and stamp | Source reference |
| 2 | Supporting document: invoice, contract or approval | Match amount and payee | Document reference |
| 3 | Payee name matches account name | Run check, record result | Verification result |
| 4 | Payee is new or bank details changed in the last 90 days | Flag | Payee master history |
| 5 | Changed details confirmed by call to number already on file | Confirm a call is logged | Call record by a person |
| 6 | Amount within approver's limits | Check | Limit table |
| 7 | Sanctions screening clear | Confirm result | Screening reference |
| 8 | No fraud hold on payment or payee | Confirm status | Fraud system status |
| 9 | Not a duplicate of a payment in the last 30 days | Check same payee and amount | Ledger search |
| 10 | Cut-off time and value date | Show to approvers | Calendar |
| 11 | First approver | Not applicable | Name and time |
| 12 | Second approver, independent of the first | Not applicable | Name and time |
Items 11 and 12 belong to people. Item 5 does too: a call to a known number is the one check an agent must not perform alone, because the whole point is a human voice on a channel the fraudster does not control.
A filled example: supplier payment with changed details
A hypothetical manufacturer's finance team is paying 250,000 to a long-standing supplier.
| No. | Result | Note |
|---|---|---|
| 1 | Flag | Invoice from purchasing system (signed); covering email with new bank details (external) |
| 2 | Pass | Invoice matches purchase order and goods received |
| 3 | Fail | Account name returned does not match supplier's registered name |
| 4 | Flag | Bank details changed two days ago |
| 5 | Not done | No call logged |
| 6 to 9 | Pass | |
| 10 | Shown | Cut-off at 3pm |
| 11, 12 | Not released | Payment held |
The agent did not decide anything. It surfaced two flags and a fail on one screen. The first approver called the supplier on the number held for five years; the supplier had not changed banks. The payment went to the original account the next day, and the change request went to the fraud team.
Where Pryme fits
In Pryme, facts reaching a payment agent arrive stamped through the Pryme Context Protocol, so an emailed change of bank details is marked external. An external claim cannot authorise a payment, at any depth. Release is held for named approvers. See the guide to AI agents in banking for how this fits the wider rules.
Questions people ask
What counts as a high-value payment?
Your own threshold, set by treasury and risk. Many businesses also apply the full checklist to any payment to new or changed details, whatever the amount, because that is where losses concentrate.
Can the agent make the confirmation call?
No. The call exists to put a person on a channel an attacker cannot control. An agent that calls is one more automated step an attacker could imitate or manipulate.
Is this the same as an affordability check?
No. Release checks protect the payer from paying the wrong party. Lending teams use a different set of checks, such as the affordability assessment checklist.