Payment repair: what it is, and why the fix needs a second person

Payment repair is the work of correcting a wire or cross-border payment that failed validation on its way out, so it can be released before its cutoff: a swapped digit in an account, a bank code that no longer routes, a free-text address the network will not take, a missing purpose code. It sits between the client's instruction and the network, which is why it is hard. The fix has to be right, fast and provable, and some fixes change who gets paid. Botminds' Payment Repair is an agentic solution for this queue: agents diagnose each failed payment, gather the evidence, propose the fix and re-check it, and people approve it, with a second person re-keying any change to the beneficiary, the account, the bank or the amount.

The examples on this page come from the solution's sample data: a fictional Corvane National Bank, its clients and its repair desk on Thursday, 22 October 2026. The rules and figures about the payment system come from the Federal Reserve, the FFIEC and the BIS, linked where they appear.

What is payment repair? The fix made before the payment leaves

Payment repair is correction before release. A payment instruction arrives from a client channel, a branch or a business line; the bank's payments hub checks it against the format rules of the network it is going to, the bank's own reference data and its limits; and anything that fails is set aside for a person instead of being sent. What the person does next is repair: work out why it failed, find out what the client meant, change the message, and send it on.

The checks that send a payment to repair have grown since the large-value systems moved to ISO 20022. Fedwire made that move on 14 July 2025 (Federal Reserve Financial Services), and an ISO 20022 customer transfer carries separate, typed fields for the debtor, the creditor, their agents, their accounts and their postal addresses, where the old formats carried a few lines of free text. More structure means more that can be checked, and more that can fail. The BIS describes the validation as a chain, "from early formatting checks during payment initiation to system-level checks against XML schemas, market practice rulebooks and network-specific rules" (CPMI Brief No 11, April 2026). Repair is what happens to the payments that fall out of it.

Two things make repair different from ordinary data clean-up. The first is the clock: a wire that misses its cutoff waits for the next business day, and the Fedwire Funds Service stops taking customer transfers at 6:45 p.m. Eastern. The second is that a payment order is a legal instruction. Under Article 4A of the Uniform Commercial Code, which Regulation J makes federal law for Fedwire, the bank that executes a payment order is obliged to issue one that complies with its sender's order (UCC 4A-302), so a repair that changes the substance of an instruction is not a cosmetic edit.

What is the difference between payment repair, a payment investigation and a payment return?

The short answer is timing. Repair happens before the payment has left the bank; an investigation happens after it has left and something has gone wrong downstream; a return sends the money back once the receiving side cannot or will not apply it. The three are often run by the same exceptions team, which is why they are confused, but each has its own messages, deadlines and risks.

The table also shows why repair is the cheapest of the three to get right. Once a payment is out, every question about it involves another bank and another queue, and a payment sent to the wrong beneficiary has to be clawed back. Before it is out, the bank still owns the whole problem. A desk that repairs well creates fewer investigations and fewer returns; one that repairs on guesses creates both. The returns that do come back have a repair problem of their own, which the return nobody can post follows from the pacs.004 to the suspense account.

What causes payment exceptions?

Most payment exceptions are data the network cannot use, not money the client does not have. The CPMI, the BIS committee that wrote the harmonised ISO 20022 requirements for cross-border payments, puts the cost of one cause plainly. Missing or non-unique account identifiers can send payments to the wrong place or back to the sender, and "Remediation usually involves manual intervention to identify the person or entity to be credited, resulting in slower processing and potentially increased costs" (CPMI, Harmonised ISO 20022 data requirements, updated report, February 2026). What that costs once the payment has left is followed in the guide to an international wire transfer not received.

In practice the causes fall into a handful of families, and every repair desk sees the same ones in different proportions:

• Party names and addresses that are free text where the network now wants structured fields, or that put the town in the street line.
• Account identifiers that fail a check, are too short, carry a transposition or belong to a different party from the name.
• Bank identifiers: a BIC that has been retired or merged, a routing number that is no longer valid for wires, a branch code missing from an 11-character BIC.
• Regulatory and purpose information that the receiving country requires and the client did not supply.
• Routing: an intermediary bank that duplicates the receiving bank, or a correspondent whose settlement instructions have changed.
• Amounts and duplicates: a payment that matches one sent earlier the same day, or exceeds a limit.

On the solution's sample month the first family led, with 9,410 of 28,904 repairs, followed by invalid account numbers and bank identifiers. Those are fictional counts, but the order is a useful prior for any desk measuring its own, and a pilot on last month's failed payments is the quickest way to find yours.

What is a repair queue, and why is it ordered by the clock?

A repair queue is the list of payments that failed validation and are waiting for a person, and a good one is sorted by cutoff, not by arrival. On the sample bank's desk, a payment for the SWIFT same-day lane that closes at 4:00 p.m. matters more at 2:45 p.m. than a Fedwire payment with three hours left, whatever order they failed in.

The idea is old in messaging engineering. The BIS describes "dead letter handling" as a pattern that "moves messages that cannot be processed to a dedicated queue for investigation and controlled reprocessing" (CPMI Brief No 11). A payments repair queue is that pattern with money and deadlines attached: the reprocessing is controlled because a person decides it, and it is investigated because the fix has to be proven.

A payment repair queue ordered by cutoff, with the diagnosis on every line

Two details in that screen are design choices worth copying even without software. The lanes are the bank's own cutoffs, set earlier than the networks' so there is time to fix and check: the sample bank closes its Fedwire customer lane at 6:00 p.m., three quarters of an hour before the Federal Reserve does. And an outage of the bank directory pauses the repairs that depend on it. A desk that keeps working through an outage from memory is how a retired BIC gets typed back into a message.

What is straight through processing, and where does repair fit?

Straight through processing, or STP, is a payment that goes from instruction to network with no person touching it. Every payment in the repair queue is, by definition, one that did not go straight through, so a bank's STP rate is the share of its payments that never reached the queue.

The rate is a property of the bank's data and workflows as much as of the client's, and the BIS is blunt that new message formats alone will not raise it; what each payment that is not straight-through costs sets out how to measure the rate and price the repairs behind it. Repair and STP are not opposites to be traded off. A repair desk that notes why each payment failed is the cheapest source of the information needed to raise STP, because each cause points to a client template, a reference table or a channel that can be fixed once.

Format repairs and who-or-how-much repairs are different kinds of work

Not every repair carries the same risk, and a desk that treats them alike either slows the easy ones or under-checks the dangerous ones. The useful line is whether the repair changes where the money goes or how much of it goes.

The right-hand column carries legal weight. Article 4A says that if a receiving bank executes a payment order by sending it to a beneficiary different from the one in its sender's order, and the transfer completes on that error, the sender is not obliged to pay (UCC 4A-303(c)). The bank that repaired the payment wrongly owns the loss and has to recover it from whoever received the money. A wrong format repair costs a resubmission; a wrong account repair can cost the whole amount.

That is also why some fixes should not be made at all. When the name and the account point to two different companies that the client has paid before, there is nothing on file that proves which the client meant, and Article 4A lets the beneficiary's bank pay on the number alone (UCC 4A-207). The safe repair in that case is no repair: return the payment to the client and ask.

Who approves a payment repair?

The repairer approves a format repair; a second, independent person approves anything that changes who is paid or how much; and people outside the payment flow review the exceptions. That division is not a product invention. The FFIEC's examination procedures for wholesale payments ask whether "Employees not involved in the receipt, preparation, or transmittal of funds review all reject and/or exception reports", alongside independent verification of key fields before transmission (FFIEC IT Examination Handbook, Wholesale Payment Systems, Tier II procedures). The same booklet lists "Clear error processing and problem resolution procedures" among the internal controls it expects (FFIEC, internal and operational controls).

The weakness in most second approvals is not their absence but their form. A checker who reads the repairer's value on the same screen, late in the afternoon, tends to confirm it. The maker checker process in banking argues for a different form: the checker re-keys the changed value from the evidence before seeing the proposal, so the approval is a check rather than a glance.

A repair adds or corrects what the evidence proves. It never removes who is paying or who is being paid, and it is screened again before it leaves.

The last clause matters because the word has a history. In 2009 Lloyds TSB agreed to forfeit $350 million after removing customer names, bank names and addresses from payment messages so they would pass U.S. sanctions filters, a practice Lloyds itself called "repairing" (U.S. Department of Justice). Legitimate repair is the opposite, and what a name repair may change draws the line field by field.

How Payment Repair works a failed payment

Botminds' Payment Repair keeps the people and the approvals above, and moves the searching and checking to agents. Seven agents work each failed payment before a person opens it: they name why it failed, read the client's earlier payments and templates, confirm the bank in the directory, propose the fix with its sources, re-validate and send it for screening, forecast each lane's cutoff, and draft the client message when the fix cannot be proven.

The fix on the same line as the original, with its reasons one click away

On the sample day the agents had a checked proposal waiting for 1,436 of the 1,604 payments sent to repair by 2:41 p.m. The others reached a person without a proposal; the queue's own counters show why, from payments with nothing on file to prove a fix to holds for screening and repairs waiting on the directory. That ratio is the point of the design. The agents remove the hunting through four systems; they do not remove the decision, and they never release a payment.

Questions people ask

Is payment repair the same as payment exception handling?

Repair is one part of it. Exception handling usually covers every payment that leaves the straight-through path: repairs before release, investigations after release, returns, and holds for sanctions or fraud review. Repair is the part where the bank changes its own outgoing message, which is why it carries the strictest approval rules.

Can a bank repair a payment without asking the client?

For format repairs that use the client's own data, a bank's procedures may allow it. For changes to the beneficiary, account, bank or amount, the evidence has to show what the client meant, because a payment sent to a beneficiary different from the client's order is the executing bank's loss under UCC 4A-303(c). Where nothing on file proves it, the payment goes back to the client.

Can a payment repair change the amount?

Only with great care, because Article 4A treats an overpayment and an underpayment as execution errors with their own consequences for the bank (UCC 4A-303(a) and (b)). In Payment Repair the agents never change an amount, and the sample bank's policy forbids a person to do so without the client's instruction and a callback to a number on file.

Does a repaired payment need to be screened for sanctions again?

It should be. A repair can put information into a field where the screening filter reads it for the first time, such as a town that was buried in a free-text address. In Payment Repair every repaired message is screened again before a person sees it and again at release, and a match stops the payment for the sanctions team.

Does ISO 20022 make payment repair go away?

No. Structured data lets more payments pass validation, and the CPMI expects structured account identifiers to cut errors, but the BIS's own migration brief says progress in straight through processing needs changes to workflows as well as messages. The fields that can fail also multiply, so the repair queue changes shape rather than disappearing.

To see the queue, the proposals and the checker's re-key together, start from Payment Repair.