How to prepare bank payment files for release with an AI agent

The agent builds the payment file from an approved payment proposal, validates every line against the supplier master, checks totals and duplicates, and stages the file in the bank portal awaiting authorisation. Two authorised people release it in the portal. The agent never holds release credentials, and a hash taken at build is checked at upload.

What is a payment file, and who releases it?

Most businesses pay suppliers, staff and taxes by sending their bank a file: one record per payment with payee name, account, amount, reference and date, in the bank's format. The file is generated from an approved payment proposal in the ERP or AP tool, uploaded to the bank's portal or sent through a direct connection, and then authorised by people with signing rights at the bank.

The treasury or payments team owns the file. The bank mandate names who may release payments and in what combinations, often two signatories above a set value. Release is the moment money leaves; release is the step that matters, and it is depth 4.

This playbook starts after the payment run has been prepared and approved, as described in preparing supplier payment runs without releasing them.

What are the steps, and at what depth?

1. Agent, depth 1: reads the approved payment proposal. Only a proposal in approved status, with the approvers recorded.
2. Agent, depth 2: builds the file. In the bank's format, one line per payment, with control totals: count and sum by currency.
3. Agent, depth 1: validates every line. Payee account matches the supplier master at that moment; master details unchanged within the cooling period; no line duplicates a payment in recent runs; no amount exceeds the approved invoice total for that payee; value dates are valid banking days.
4. Agent, depth 2: records a hash of the file. A fingerprint that will change if any character changes.
5. Agent, depth 3 once certified: stages the file in the bank portal. Uploaded with status awaiting authorisation. Staging can be cancelled before release and moves no money.
6. Agent, depth 1: confirms what the bank received. Count and totals in the portal match the file, and the hash of the uploaded file matches the one recorded at build.
7. Person, first authoriser: reviews and authorises. Using the agent's validation report.
8. Person, second authoriser: releases. Under the bank mandate.

What stays with a person, and why?

Release stays with people, always, because it is the last point at which a fraudulent or mistaken payment can be stopped by you alone. After release, recovery depends on the receiving bank. Approval of the proposal and release of the file must also be different people from each other and from whoever configured the agent; the reasoning is in whether the same AI agent can prepare and approve a payment.

People also decide every flagged line. The agent does not remove a line it doubts; it marks it and the first authoriser decides whether to pull it from the file and rebuild.

Which controls matter, and what evidence does each leave?

Approved source only. Evidence: proposal reference and approver identities on the file record.

Line-level master check. Evidence: the master record version for each payee at build time.

Duplicate check across runs. Evidence: duplicate flags and outcomes.

Hash at build and at upload. Evidence: both hashes on the record. A mismatch stops the process.

No release credentials for the agent. The agent's portal user, where one exists, can upload but not authorise. Evidence: the bank's user rights report, checked periodically.

Payee name check where available. Where your bank offers a check of the payee name against the account, the agent reads the result and flags mismatches. In the EU, the Instant Payments Regulation requires payment service providers to verify the payee's name. Evidence: check result per line.

Where does it usually go wrong?

Files edited after generation. A file saved to a shared folder is opened and a line's account changed before upload. This is a known fraud route. The hash check catches it; direct upload from the build step prevents it.

Out-of-cycle payments. An urgent payment is added by hand to the file. Urgency is a classic fraud signal. Rebuild from an approved proposal instead.

Authorisers rely on the agent. The validation report is good, so authorisers approve without reading. Keep the report short, with flags first, and record whether each was opened.

Different formats per bank. A file valid for one bank fails at another, and someone edits it by hand. Certify the agent per bank format.

After release, confirm that what left the bank matches what you meant to pay. That is part of the daily bank reconciliation.

What should you measure?

• Hash mismatches. Should be zero; each is investigated.
• Lines flagged and pulled before release.
• Payments recalled after release.
• Files rejected by the bank for format errors.

Where Pryme fits

In Pryme, building, validating and staging payment files are separate capabilities, and release is held for named people at every depth. Payee details from your master file are sealed, and details from emails or invoices are external and cannot authorise a payment. Every file, check and verdict is filed. The finance bounds are in AI agents for finance.