Payment repair with the fix on the same line as the original, its proof one click away, and a second person who re-keys it
Every failed payment fixed with its proof, checked by a second person, before the cutoff.
See one case, screen by screen ↓Payment repair is the work of fixing a wire, CHIPS, SWIFT or RTP payment that failed validation, such as a swapped digit in an account number, a retired bank code or an address the network no longer accepts, so it can be released before its cutoff. Payment Repair puts seven agents in front of the repair queue: they diagnose each failed payment, find the evidence, propose the fix with its sources, and re-check and re-screen the repaired message. A specialist approves it, and a checker approves any change to who is paid or how much.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Payment repair is the work of fixing a wire, CHIPS, SWIFT or RTP payment that failed validation on its way to the network: a swapped digit in an account number, a retired bank code, a free-text address the network no longer accepts, a missing purpose code. Each one lands in a repair queue with a cutoff behind it, and since the rails moved to ISO 20022 a message has many more fields that can fail.
Today the specialist opens the message, then the client's payment history in another system, then the bank directory, then the rulebook, and types the fix by hand. A second person re-reads the same screens or, under time pressure, glances at the first person's value. The evidence is kept nowhere, the same client's template fails again next week, and a repaired address can name a sanctioned place that nobody screened again. Payment Repair puts seven agents in front of that queue, so the specialist decides on a proven, re-checked fix instead of building one.
Estimated split of one tier 2 repair (an account change) worked by hand, against the same repair in the working solution, where the agents have diagnosed, proposed, re-validated and re-screened it before a person opens it. Our arithmetic, kept modest; the second person's blind re-key still takes real time.
Seven agents diagnose each failed payment, prove the fix from the client's history and the bank directory, re-check and re-screen it; a repairer approves and a checker re-keys every change to who is paid.
Thursday, October 22, 2026. Brightwater Coffee Roasters, Inc., a business client of Corvane National Bank, sends USD 72,900.00 to its green-coffee supplier, Van der Meulen Koffiehandel B.V. in Rotterdam. At 2:32 p.m. the payments hub rejects it. Here is what happens next, screen by screen, in the working solution.
The desk bar reads 186 open repairs and the next cutoff, 4:00 p.m. for SWIFT USD same-day value. Each failed payment is one line: who pays whom, why it failed, the fix the agents propose, the amount and the time left. Of the 1,604 payments sent to repair so far today, the agents had a checked proposal for 1,436.
The bank directory service is not answering (since 2:38 p.m.). 3 repairs are paused; the agents will not name a bank from memory.
RPR-48213 failed its ISO 13616 IBAN check digits. The beneficiary account reads NL58 HVSD 0417 9238 56 as received and NL58 HVSD 0417 2938 56 as proposed, on one line, with the swapped digits marked. The repaired message has already passed the CBPR+ rules, 41 of 41, and been screened for sanctions again, with no match; confidence 0.98.
Digits 9 and 2 are swapped: the client's six earlier payments to this supplier all used …2938 56, which passes the check and is the account Havenstad Bank holds for Van der Meulen.
She clicks "Six earlier payments". The passage behind it lists Brightwater's 2026 payments to the same supplier, March 12 to September 15, USD 64,800.00 to USD 73,100.00, each credited to NL58 HVSD 0417 2938 56. She verifies the fix without leaving the repair.
Because the fix changes who is paid, it is a tier 2 repair. Marisol approves and it goes to a checker. Renata Okafor sees the account as received and the evidence, while Marisol's proposed value stays masked.
Approve unlocks when your re-key matches.
Renata types the account from the earlier payments. It matches, the proposed value is revealed with the corrected digits marked, and Approve and release unlocks. The second approval is a real check, not a glance at the first person's answer.
Your re-key matches the proposed fix, character for character.
On the way out the repaired message is validated against the CBPR+ rules once more, screened again by the sanctions screening system, released to the payments hub and accepted by the network. Repairer and checker are named, and both versions of the message are kept five years.
Made the 4:00 p.m. cutoff with 1 h 14 m to spare.
Brightwater's portal template for this supplier was re-keyed on September 30 with the same swap and has failed three times since: October 5, 14 and 22. The agent drafts FIX-0412, the corrected account beside the current one. Hannah Lindqvist, the treasury management implementation manager, confirms it with the client, and Douglas Pryor, the manager, approves it before the record changes.
5 corrections drafted this month would have prevented 29 repairs.
At the team's current pace the 4:00 p.m. SWIFT lane would clear at 4:09 p.m., and six repairs worth USD 412,300 would lose same-day value. The cutoff agent proposes moving Keiko Brandt and Tomasz Wilk from Fedwire until 3:45 p.m., forecasts 3:41 p.m. on a median of 3 min 40 s a repair, and Douglas decides.
The trail shows Renata's re-key and release at 2:46 p.m., Marisol's approval at 2:44 p.m., the hub routing RPR-48213 to repair at 2:32 p.m., and the repair agent v3.2 proposing the account at confidence 0.98. Internal audit and the manager build a masked, sealed audit pack for examiners from it.
The same repair, seen by the five people who carry it: what their afternoon looked like, and what it looks like now.
Seven agents diagnose each failed payment, prove the fix from the client's history and the bank directory, re-check and re-screen it; a repairer approves and a checker re-keys every change to who is paid.
Reads the hub's rejection and the message, and names why it failed in one sentence, with the rule.
Finds the client's earlier payments to the beneficiary, its portal templates and their change log.
Confirms banks, BICs, routing numbers, IBAN formats, successor BICs and settlement instructions.
Proposes the fix with a one-sentence reason and its sources, sets the repair tier, and shows candidates when unsure.
Re-checks every repaired message against Fedwire and CBPR+ rules, check digits, duplicates and limits, and sends it for re-screening.
Orders the queue by cutoff and value, forecasts each lane's clearing time at the current pace, and proposes reassignments and escalations.
Drafts the return-to-client message and, when the same repair repeats, the client record correction for the relationship team.
Re-keys every account, bank, name or amount change from the evidence; the manager too above $1,000,000. The agents propose; a named person decides.
The assistant answers from the repair queue, the payments hub, the bank directory and the audit trail, cites every source, and takes you to the work.
Why did RPR-48213 fail, and what proves the fix?
It failed the IBAN check digits: two digits are swapped (…92 38 56 instead of …29 38 56). Brightwater's six earlier payments to Van der Meulen all went to …2938 56 and were credited; Havenstad Bank's code HVSD matches the bank directory; and the corrected number passes the ISO 13616 check. The cause is the client's template, re-keyed on September 30.
Which repairs will miss the 4:00 p.m. cutoff at this pace?
Six in the SWIFT same-day lane, worth USD 412,300: at today's pace of 3 min 40 s per repair the lane clears at 4:09 p.m. The cutoff agent proposes moving Keiko Brandt and Tomasz Wilk from Fedwire until 3:45 p.m.; the lane then clears at 3:41 p.m. Douglas Pryor approves it.
Which clients keep needing the same repair this month?
Five records cause 29 repairs: Brightwater's Van der Meulen template (3, since a September 30 re-key), Cobaltline's Meridian Tank Lines routing number (4), Lakemont's 11 free-text addresses (9), Pinecrest's merged bank (2) and the bank's own settlement instructions for one Vietnamese bank (11). A correction is drafted for each.
Build the examiner pack for this month's account repairs
Ready to build: every account repair since October 1 with its before and after, the repairer, the checker, the re-key, the cited evidence and the re-screen result; account numbers masked to the last four, and no suspicious activity report references. Internal audit or the manager builds it.
13 screens from the working solution, on its sample data. Pick one to see it large.
The tiers, thresholds, cutoffs and reason codes every repair is held to are settings. The administrator proposes a change and the manager approves it before it takes effect.
| Setting | Default | Choose from |
|---|---|---|
| Tier 1 · Format and route | Structured address, purpose code, intermediary from published instructions, character set | One approval: the repairer |
| Tier 2 · Who or how much | Beneficiary name, account, bank, amount, currency | Repairer approves, a checker re-keys and approves |
| Manager checks too | Over $1,000,000 | $1,000,000 or $500,000 |
| Tier 3 · Cannot be proven | Return to client | An amount is never changed without the client's instruction and a callback to a number on file |
| Show a proposal at confidence | 0.90 and above | 0.80 to 0.99; below it, candidates only |
| Cutoffs (Eastern) | SWIFT USD same-day 4:00 p.m. · CHIPS 5:00 p.m. · Fedwire 6:00 p.m. · RTP 15 minutes | Escalate to the manager 30 minutes before, to the head of payments operations 10 minutes before |
| Reason codes | OV-01 to OV-05 edits · CK-01 to CK-04 rejections · RC-01 to RC-04 returns | Every override, rejection and return carries one |
| Retention and redaction | Five years, then deleted on a logged schedule | Account numbers masked in exports; no suspicious activity report references |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
"demo" = seen in the working solution on its sample data · "target" = the design goal, measured in the live solution · "estimated" = our arithmetic, used only for the minutes split above · "typical" = a published figure: a February 2023 industry survey of 400 payment executives (the $12.10 average cost of a rejected or repaired payment; beneficiary name and address problems as the most common cause, 21%; 72% confirming those details by hand) and the same publisher's study of failed payments (cross-border account-to-account straight-through rates as low as 26%). Corvane National Bank, its clients and suppliers, the people named on this page, and every account, IBAN and BIC are characters and sample data in the working solution. Rules named as context: ISO 13616 (IBAN check digits), SWIFT CBPR+ and the Fedwire Funds Service ISO 20022 formats, UCC Article 4A, OFAC reporting under 31 CFR part 501, and five-year record retention under the Bank Secrecy Act (31 CFR 1010.430).
Payment repair is the work of fixing a wire, CHIPS, SWIFT or RTP payment that failed validation, such as a swapped digit in an account number, a retired bank code or an address the network no longer accepts, so it can be released before its cutoff. Payment Repair puts seven agents in front of the repair queue: they diagnose each failed payment, find the evidence, propose the fix with its sources, and re-check and re-screen the repaired message. A specialist approves it, and a checker approves any change to who is paid or how much.
In the working solution's sample month, the largest cause was beneficiary name or address format (9,410 of 28,904 repairs, 32.6%), then an invalid account number, the bank identifier, purpose or regulatory information, the intermediary or route, closed or blocked accounts, and amounts or possible duplicates. The reports screen counts each cause and every edit by reason code.
The payment fails validation and lands in the repair queue. The agents look for the client's earlier payments to the same beneficiary and the bank directory: in the hero case, six earlier payments all used an account with two digits the other way round, and that number passes the ISO 13616 check. The fix is proposed with those sources, and because it changes the account, a checker re-keys it before release.
Yes. Every repaired message is re-validated and sent to the sanctions screening system before a person opens it, and again at release. A match stops the payment and hands it to the sanctions team; payments operations cannot release, return or cancel it, and the client sees only "In process".
Structuring a free-text address is a tier 1 format repair: the repairer approves it alone. Because a structured address can reveal what free text hid, the repaired message is screened again; in the working solution, a structured town field named a sanctioned region and the re-screen stopped the payment.
Yes. The agents diagnose, prove, propose, re-check and draft; they never release a payment, change an amount, clear a sanctions hit, send anything to a client or edit a client record. The repairer approves, edits with a reason code or returns each repair, a checker re-keys every change to who is paid or how much, and the manager approves record corrections and settings changes.
Yes. Repair tiers, the manager-check amount, the confidence threshold, lane cutoffs and escalations, reason codes, and privacy and retention are settings. A change waits for the manager's approval and goes on the audit trail with its change request number.
The Agentic Solution Engine builds and deploys it from your requirements and documents, such as your repair procedures, cutoffs and a sample of past rejected payments, and it goes live once every quality gate has passed. We will walk you through it on your own repairs first.
Every return inside its window, and every originator caught before it crosses a level.
1-min demoISO 20022 Structured Address RemediationEvery client and payee address structured, proven and signed twice before 14 November.
1-min demoFunds Transfer Recordkeeping & Travel RuleEvery wire’s travel rule data checked for meaning, and every gap chased to a fix.
1-min demoWe'll run Payment Repair on a sample of your own rejected payments, client history and directory data.