Sort every repair by whether it changes the payment's meaning. Format-only fixes, such as moving data to the right field or replacing characters the receiving system cannot read, the agent can make at depth 3 once certified. Anything that changes the beneficiary, the account or the amount needs a fresh instruction from the customer, and a person approves it.
What is payment repair, and who owns it?
Payments get rejected for many reasons: a mandatory field is empty, a bank identifier is invalid, the name contains characters the next system cannot handle, the address is in the wrong field, the receiving bank says the account is closed. Repair means fixing the message so the payment can go, or finding out from the customer what they meant.
Payment operations owns the repair queue. It is repetitive, deadline-driven and full of small judgements. Most repairs are harmless. A few are the moment a fraudster's changed instruction slips through, because "fixing" an account number is indistinguishable from changing it. The decision on what an agent may do is set out in whether an agent can repair rejected payment instructions. This piece covers how.
What are the steps?
- Agent, depth 1: reads the rejection. The reason code, the rejecting party, the original message and the original customer instruction.
- Agent, depth 1: classifies the repair. Format-only, enrichment from reference data, or change of substance.
- Agent, depth 3: makes format-only repairs. Field placement, character replacement under your rules, truncation within allowed lengths. The beneficiary, account, amount and currency are unchanged, and the agent checks they are.
- Agent, depth 2: drafts enrichment. A missing bank identifier looked up from your reference data, or a structured address built from the customer's own instruction. A person approves until this capability is certified at depth 3.
- Agent, depth 2: drafts the customer query for changes of substance: invalid account, closed account, name mismatch. A person or an approved channel sends it.
- Person: approves substantive repairs once the customer's new instruction is on file.
- Agent, depth 1: requeues repaired payments into the normal payment flow, where your existing limits, screening and release controls apply again. It never sends a repaired payment around them.
- Agent, depth 2: drafts returns where a payment cannot be repaired in time, for a person to release.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read | Reads rejection and original | 1 | None |
| Classify | Labels the repair type | 1 | Disputed labels |
| Format fix | Repairs without changing meaning | 3 | Spot checks |
| Enrich | Drafts identifier or address fill | 2 | Approval until certified |
| Query | Drafts customer contact | 2 | Sending; new instruction |
| Substantive repair | Nothing until instructed | 2 | Approving the repair |
| Requeue | Returns to normal flow | 1 | Release controls as usual |
| Return | Drafts return of funds | 2 | Release |
Which controls apply, and what evidence do they leave?
Invariant fields. Before any depth 3 repair is saved, the agent compares beneficiary name, account, bank, amount, currency and value date with the original. If any differ, the repair is refused. Evidence: the before-and-after field comparison filed with the verdict.
Character rules written down. Which characters are replaced by which is a table your operations team owns. The agent applies the table version on file and records it.
Reference data, not guesses. Enrichment comes from your maintained reference data. If the data has no answer, the agent asks the customer rather than choosing the nearest match.
Customer instruction for substance. A changed account or name needs a fresh instruction through an authenticated channel. Evidence: the instruction reference on the repair.
Patterns reported upstream. If one customer's payments keep failing for the same reason, the agent reports the pattern so operations can fix the customer's template or channel, instead of repairing the same fault every day. Evidence: the pattern report and the upstream change it led to.
No bypass. Repaired payments rejoin the normal flow. Evidence: the payment's path through screening and release after repair.
What should you measure?
- Repairs by type. If most are format-only, fix the upstream channel that produces them.
- Time from rejection to repaired payment sent.
- Payments rejected a second time after repair. The best measure of repair quality.
- Refused repairs, where the invariant check stopped the agent. Each is worth reading.
- Payments returned unrepaired, and the customer impact.
Where does it usually go wrong?
A typo fix that is a redirect. The account number looks one digit off, so someone corrects it. If the "corrected" number belongs to someone else, the money goes there. The agent must never change an account number, however obvious the error looks.
Name truncation that breaks matching. Shortening a long name to fit a field can cause a payee name check to fail at the receiving bank. Truncation rules should keep the parts that matter for matching.
Instant payments repaired too slowly. Instant schemes reject in seconds and customers expect a result in seconds. Repair is rarely possible in that window. Handling instant payment exceptions covers how to fail cleanly instead.
Confusing repair with reversal or recall. A rejected payment never left; a repaired one is sent for the first time. A payment reversal undoes a payment within your own systems, and a payment recall asks another bank to return one already made. Different capabilities, different controls.
The general bounds for bank agents are in AI agents in banking.
Questions people ask
Can the agent tell the customer their payment was rejected?
Yes, through an approved template, once the rejection is confirmed. If the customer needs to give a new instruction, the message says exactly what is needed.
What if the rejection reason is sanctions-related?
That is not a repair. The case goes to financial crime, and the agent takes no further action on the message.
Can repairs be learned from past fixes?
Past fixes are a good source of certification cases. They are not a source of rules on their own, because a past fix may itself have been wrong. Rules come from operations, and certification proves the agent applies them.