How to process bulk payment files for corporate customers with an AI agent

Point the agent at the exceptions, not the clean files. Files that pass your existing straight-through rules keep flowing. For the rest, the agent finds why a file stopped, checks duplicates, control totals, unusual lines and limits, and drafts a repair or a customer query. A named person approves any repair, any partial processing and the release of held files.

What is bulk file processing, and who owns it?

Corporate customers send payroll, supplier and pension payments as files: one header, many lines, sometimes thousands. They arrive through an online banking portal or a direct host-to-host link, already authorised by the customer's own signatories. The bank validates the file, screens it, checks funds and limits, and submits the payments to the relevant scheme.

Most files pass straight through. The work is in the ones that do not: a control total that does not match, a line with an invalid account, a limit breach, a file that looks like one already processed. Payment operations owns that queue, usually under time pressure, because a stuck payroll file means people are not paid on payday.

What does the agent prepare, and what does a person approve?

1. Agent, depth 1: reads why the file stopped. The rule that fired, the file reference, the customer and the deadline.
2. Agent, depth 1: checks for duplicates. Against recent files from the same customer by reference, total, line count and content. A payroll file uploaded twice is a common and expensive mistake.
3. Agent, depth 1: reconciles control totals. Header count and sum against the lines. It identifies which lines cause any difference.
4. Agent, depth 1: reviews unusual lines. New beneficiaries in a payroll file, one account receiving several lines, amounts far outside the customer's usual run.
5. Agent, depth 1: checks limits and funding. Against the customer's daily limit and available balance.
6. Agent, depth 2: drafts the resolution. A proposed repair, a proposal to process valid lines and return the rest, or a query to the customer.
7. Person: approves. Any change to the file, any partial processing and any release of a held file. Partial processing needs the customer's agreement on file.
8. Agent, depth 2: drafts the customer report. Lines paid, lines returned and why.

Which controls apply, and what evidence do they leave?

No silent repairs. The agent never changes a beneficiary's account details, even to fix an apparent typo. A changed account number is how payments get diverted. It proposes, and the customer confirms. Evidence: the original line, the proposal and the customer's confirmation.

Customer authority for partial processing. Paying some lines and not others changes what the customer instructed. A person confirms the customer's agreement before it happens. Evidence: the agreement reference on the filed verdict.

Anomalies sent to fraud. A new employee added to payroll the night before submission, with an account opened last week, may be insider fraud at the customer. The agent's finding is held for a person, who decides whether to call the customer's authorised contact.

Screening outcomes read, not cleared. Sanctions screening runs on every line in your screening system. Hits go to analysts.

Release by a person. Held files go to the scheme only when a named person releases them. Evidence: release identity and time.

What should you measure?

• Files released before the customer's deadline. The outcome that matters for payroll.
• Time from stop to resolution drafted.
• Duplicate files caught before submission. Any duplicate that got through is an incident and, once paid out, may need payment recall requests to put right.
• Repairs the customer rejected. A sign the agent's proposals are too confident.
• Anomalies referred to fraud, and outcomes.

Where does it usually go wrong?

Speed over checking at deadline. Payroll at four in the afternoon on payday tempts everyone to release first and check later. The agent's value is that the checks are already done when the person looks; do not let the deadline skip the person.

Treating near-duplicates as duplicates. Some customers send two legitimate files with the same total, for different sites. The agent should say why it thinks a file duplicates another, and the customer confirms.

Partial processing by default. Rejecting a few bad lines and paying the rest seems helpful. For a supplier run it may be; for a pension contribution file it may break the customer's own reconciliation. Follow the customer's standing instruction.

Agent given scheme submission rights. If the agent's role can submit files to the scheme, the release step is a convention. Remove the right.

The validation habits here are close to those in processing new customer onboarding files, where the same rule applies: the agent finds the problem, a person decides what to do about it. Branch and cheque work has its own rules, set out in whether an agent can process a cheque deposit. The general bounds are in AI agents in banking.