Payments operations analysts should drill the error with the shortest window to fix: a payment batch queued twice after a system retry, with the release cut-off an hour away. In about 90 minutes, the team practises pausing the agent to draft-only, escalating to the head of payments and treasury, pulling or recalling duplicates, recording each step and reporting.
What does a payments operations drill rehearse?
Payments operations teams prepare, release, monitor and repair payments. Agents typically assemble batches from approved instructions, check payee details, investigate returns and failures, and queue batches for release. Queuing may run at depth 3; release is depth 4 at most, and many firms keep it with a person. Reversing a payment that has settled on a rail the platform runs is withheld at the platform floor for every agent at every depth.
In the EU, the Instant Payments Regulation requires payee name verification, and PSD2 sets strong customer authentication rules. Instant payments leave almost no time to stop an error.
The head of payments operations owns the drill; a senior analyst facilitates. Analysts, treasury, the release approvers and IT take part. For the general format, see what an incident drill is.
The scenario
Thursday, 14:00. The supplier payment run of 1,200 payments is due for release at 15:00. An analyst notices the queue holds 2,400 items. A network timeout at 13:10 made the batching job retry, and the agent queued the batch again at depth 3. The duplicates carry new references, so the duplicate check on references did not catch them. A release approver has already released the first 300 items of the second batch.
The drill step by step
- Person (facilitator): reads the scenario and starts the clock.
- Person (analyst): stops the release approver and escalates to the team lead.
- Person (team lead): pauses the agent to draft-only. No further batching or queuing without a person. The verdicts name the firm's own limits.
- Person (team lead): escalates to the head of payments and treasury.
- Person (analysts): identify the duplicate batch from the record and remove its unreleased items from the queue.
- Person (treasury): requests recalls for the 300 released duplicates through the rail's processes. If any have settled and cannot be recalled, the firm contacts payees for repayment; no agent may reverse a settled payment.
- Person (head of payments): confirms the genuine batch releases on time.
- Person (head of payments): decides on reporting to leadership, and to the regulator if the firm's rules treat this as a reportable operational incident.
- Person (team lead): records each step; the facilitator runs the debrief.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Alert | Has queued twice | 3 | Stopping release |
| Pause | Holds batching and queuing | Dropped to 2 | Tightening limits |
| Escalate | Nothing new | 2 | Head of payments, treasury |
| Remove | Nothing | 2 | Clearing unreleased duplicates |
| Recall | Nothing; reversals withheld | 2 | Treasury recall requests |
| Genuine run | Nothing | 2 | Release on time |
| Report | Nothing | 2 | Reporting decision |
What makes this drill specific to payments operations?
Time. The drill runs against a cut-off, and the team must do two things at once: stop the damage and make sure the genuine payments still go. Splitting roles early matters more here than in most teams.
And the withheld action. Analysts sometimes expect the agent to "undo" the duplicates. The platform withholds reversing a settled payment from every agent at every depth. That is a deliberate floor, not a fault, and the recovery path runs through people and the rail's own recall processes.
The debrief usually leads to a new bound: hold any batch whose total and count match a batch already queued that day, regardless of references.
Practise the communication with suppliers too. Some of the 300 payees received money twice. A short, factual message from the firm, approved by the head of payments, asking them to return the duplicate, recovers more than chasing them one by one weeks later. Draft it in the drill so a real version takes minutes, not hours.
Which controls does the drill test, and what evidence do they leave?
The pause. Evidence: the limit change in the record.
Removal of duplicates. Evidence: the removed items with the analyst's name.
Recall requests. Evidence: each request with time and result.
New bound. Evidence: the batch-matching rule and who added it.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What should the head of payments measure?
- Time from detection to stopping release.
- Duplicates released before the stop, and the value recovered.
- Whether the genuine run met the cut-off.
- Whether the batch-matching bound was added before depth 3 returned.
Where do payments operations drills go wrong?
Everyone works on the duplicates. The genuine run misses the cut-off, and suppliers are paid late. Assign someone to the genuine run at the start.
Looking for an undo button. There is none for settled payments. The drill should rehearse recall and repayment requests.
Trusting reference-based duplicate checks. Retries can create new references. Check totals, counts and payees.
Neighbouring drills: the operations team drill covers capacity when an agent drops depth, and the legal operations team drill covers a misdirected communication. The AI agent incident drill script template gives a structure, and how to train a team to handle an AI agent incident covers the training. The full approach is in training teams for AI agents.
Questions people ask
Should an agent release payments?
Some firms allow depth 4 release within tight limits once certified. Many keep release with a person. Either way, release rights should depend on current certification for people and agents alike.
Can we recall an instant payment?
Recall processes vary by rail and are not guaranteed. Speed matters most. Rehearse the steps so nobody has to look them up.
How often should payments operations drill?
Quarterly is common, given how fast payment errors become losses.