What payment companies get wrong about AI agent training

Payment companies train operations staff to move fast, then put them in front of an agent whose most important feature is that it sometimes stops. Nobody explains why some actions are withheld for every agent, fraud and alert reviewers are drilled for speed but not judgement, and payee checks are treated as formalities. Risk sits where training is thinnest.

Why does "withheld" cause so much trouble?

Some actions are withheld at the platform floor: they exist and work, but are refused on purpose for every agent at every depth. Reversing a settled payment on the platform's own rail is the clearest example. No customer setting can switch it on.

Payment operations staff meet this under pressure. A merchant wants a payment pulled back, a customer says they paid the wrong account, a partner bank is chasing. Untrained staff see the agent's withheld verdict as a fault, raise tickets to have it configured, or ask the agent to draft something that achieves the same effect by another route. Training must explain the difference plainly: the company narrows what an agent may do through its own limits, which produce refusals and holds; only the platform floor withholds. The right response to a withheld reversal is the company's own controlled recall or dispute process, run by a named person. Once staff understand that, they stop fighting the control and start using the proper route.

What is wrong with training for speed alone?

Instant payments leave little time to decide. Fraud operations teams are drilled to clear alerts quickly, because a payment held too long harms a legitimate customer and one released too quickly may be gone for good.

Speed drills without judgement produce reviewers who release whatever the agent did not obviously object to. An agent can read the transaction, the account history and the device signals, and hold a payment that looks like an authorised push payment scam at depth 4. The reviewer must decide in minutes whether to release, contact the customer, or refuse. Train that decision on real past cases, including ones where the scam was well disguised, and set short, tested checklists for the most common patterns so speed comes from preparation rather than from skipping steps.

How should staff handle payee verification results?

In the EU, the Instant Payments Regulation requires payment service providers to verify the payee's name. The result, whether a match, a close match or no match, becomes one of the facts the agent weighs, and a mismatch is a common reason for a hold.

Reviewers need to know what each result means and what it does not. A close match may be a typing difference or the start of a fraud. A full match does not prove the payment is legitimate, only that the name and account agree. Training should cover how to talk to the payer about a mismatch without leading them, and when to refuse. Under PSD2, strong customer authentication proves the customer authorised the payment; it does not prove they were not deceived into it, which is the gap reviewers are there to cover.

Why do alert reviewers need more than system training?

Payment companies run sanctions screening and transaction monitoring under a risk-based approach consistent with the FATF Recommendations. Agents can triage alerts, gather context and draft a disposition at depth 2, leaving the analyst to decide.

Two things go wrong when analysts are trained only on the screens. They accept the agent's drafted disposition because it is well written, without checking the facts it rests on. A counterparty's name confirmed by a verified issuer is signed; a reason for a payment typed by the customer is declared. And they forget what must never reach the customer: a reply that hints the account is under review can amount to tipping off. Assess analysts on real alerts with known outcomes, and include cases where the agent's draft was wrong. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

What happens during an incident?

Payment companies in the EU fall under DORA, which covers ICT risk management and ICT incident reporting. An agent behaving unexpectedly, or a surge in held payments after an agent's certificate lapses at its 90-day renewal or a run that clears no depth drops it to depth 1 the same day, may be the first sign of a wider problem.

Operations staff must know how to tell a routine surge from an incident, who to tell, and what to record. Rehearse it. A walkthrough of a lapse during a busy settlement window shows quickly whether the team knows that the extra held work is expected or whether it will start releasing payments to clear the queue.

What should a payment company do instead?

1. Teach withheld, refused and held as distinct verdicts, with the proper route for each.
2. Train fraud reviewers on judgement with short, tested checklists, not speed alone.
3. Cover payee verification results and their limits in detail.
4. Assess alert analysts on real alerts, including tipping-off risks.
5. Rehearse lapses and incidents with operations and on-call staff together.

A payment company can adopt the practice of tying approval rights to a current certificate, depth by depth. The broader order is in the guide to training teams for AI agents. For detail, see what an AI agent training programme for payment companies should include, the AI agent training plan template for payment companies, and how much AI agent training costs for payment companies. Banks face similar friction with withheld actions, covered in what banks get wrong about AI agent training.

Where the Academy fits

Pryme Intelligence Academy's Operator track includes a module on when something goes wrong, and certification requires a two-week practicum of real review decisions with no missed red line, signed off by a Pryme assessor. Module tests are set in the learner's own industry and role. A payment company can make approval rights for held payments depend on a current Operator certificate.