Payment validation is the set of checks a payment must pass before release: the message schema, the network's usage rules, the bank directory, account formats, limits and duplicates, then sanctions screening. A payment that fails goes to repair, and the repaired payment is validated again. That second validation is necessary but it is not a measure of accuracy, because a repair can satisfy every rule and still send money to the wrong account. To test payment repair software, including Botminds' Payment Repair, an agentic solution that diagnoses each failed payment and proposes a proven fix for a person to approve, plant known errors in a copy of last month's real failures and count three things per error type: caught, missed and wrongly changed.
The cause counts below come from the solution's sample data, a fictional Corvane National Bank's October. The validation measures are the BIS's, the testing duty the FFIEC's, and the sample-size arithmetic ours, shown so it can be checked.
What a seeded-error test has to answer
3counts
per planted fault type: caught, missed, and wrongly changed
32.6%
of the sample month's repairs were party name or address format, the largest family
2.95%
the most a miss rate can be, at 95% confidence, after 100 planted faults are all caught
0
wrong changes to tolerate on who is paid or how much; a candidate or a return is the right answer when proof is missing
What is payment validation?
Payment validation is the automated checking of a payment message against what the network, the bank and the law require before the payment is sent. It has layers. The schema check asks whether the message is well formed; the network's usage rules ask whether the right fields are present and in the right form, such as a structured postal address; reference-data checks ask whether the bank identifier exists and the account format fits the country; business checks look at limits and duplicates; and screening asks whether any party or place is sanctioned.
The earlier these checks run, the cheaper the failure. The CPMI argues that identifying banks with global standard identifiers "could facilitate pre-validation and thus reduce the risk of costly rejections late in the life cycle of a cross-border payment" (CPMI, Harmonised ISO 20022 data requirements, February 2026). A rejection at the bank's own hub costs a repair; the same fault found by a correspondent two banks down the chain costs an investigation or a return.
What errors cause payment rejections?
Data the network cannot use causes most of them. The sample bank's October shows the usual families, and their order is a sensible starting weight for a test until a bank has measured its own.
Why payments needed repair in the sample month: the mix a seeded test should mirror
Two features of the chart matter for testing. The largest family is the least dangerous: structuring an address or splitting a name from an address line fails loudly if it is wrong. The orange bars are smaller and riskier, because a wrong account, bank or amount can pass every rule. A test weighted only by volume would spend most of its effort where errors are cheap. Weight it by volume for the catch rate, and over-sample the orange families for the wrong-change rate.
The mix will move. In May 2026 the BIS recorded November 2026 as the point from which a postal address in a cross-border message must be fully structured or hybrid (CPMI Brief No 13, May 2026); that removal of free-text addresses was delayed in August 2026, and the deadline that moved is now expected a year later. The Federal Reserve tells Fedwire senders to keep preparing for the removal of the unstructured format, having moved the release that brings the hybrid address to November 2027 (Fedwire November 2027 release FAQs). A test built now should include address faults in the forms the networks are about to reject, not only the ones they reject today.
What is a validation failure rate?
A validation failure rate is the share of messages rejected for breaking the schema or the usage rules. The BIS proposes it as a measure for payment systems after an ISO 20022 migration and defines it in its own words: it "Measures the percentage of messages rejected due to schema or usage rule violations, ensuring compliance with ISO 20022 standards" (CPMI Brief No 11, April 2026, Table A.1).
For a bank, the same idea works at two points. Before repair it is the share of outgoing payments that fail the hub's checks, which is the complement of the straight-through rate. After repair it is the share of repaired payments that fail again: re-validation failures, network rejects and returns. The second number is the one that tells you whether repairs are good, and a bank should track it by repair type and by repairer as well as overall.
Neither number measures accuracy. A repaired payment with a valid, wrong account passes validation, settles, and fails nobody's rule until the beneficiary calls to ask where the money is.
Valid is not right: the repair that passes every rule
The most dangerous repair is the one that validates. Article 4A lets the beneficiary's bank, unless it knows otherwise, rely on the account number as the beneficiary's identification without checking it against the name (UCC 4A-207(b)). So a repair that puts a valid account in a payment will be paid to that account, whatever name sits beside it.
When the evidence is not enough: candidates, not a proposal
This is why a seeded test needs cases that have no right repair. Plant a payment whose name and account point to two different payees the client has used before, and the correct output is not a fix at all; it is a refusal, a set of candidates or a return to the client. A tool that "repairs" those cases at high confidence has failed the most important test in the set, however well it does on the rest.
How do you test payment repair software? Seed last month's queue
Take a copy of last month's failed payments, with the client history and reference data as they stood at the time. Plant known faults of each type in otherwise clean payments, hide which ones they are, run the tool, and compare its output with the answer key. Add clean payments it should leave alone and unprovable payments it should refuse. The table is a plan a bank can adapt.
A seeded-error test plan for payment repair software
| Planted fault | How to plant it | Right outcome | Counts as a wrong change |
|---|---|---|---|
| Two digits transposed in an account | Swap two digits in a payment to a beneficiary the client has paid before | The account from the client's credited history, sent to a checker | Any other account; a fix with no cited history |
| Retired or merged bank identifier | Replace a BIC with one that has a published successor | The successor, from the directory as it stood that day | A bank named from memory, or from a stale directory |
| Free-text address | Collapse a structured address into one line | Town and country in their fields, from the client's beneficiary data | A town guessed from a street name; a dropped address line |
| Missing purpose code | Remove it where the corridor requires one | The code the client uses on that beneficiary, or a return | A plausible code with no history behind it |
| Intermediary repeating the receiver | Copy the receiving bank into the intermediary field | Remove the duplicate, as the Fedwire format guidance describes | A new intermediary not in published settlement instructions |
| Possible duplicate | Resend an earlier payment with the same amount, payee and invoice | Held and the client asked | Released, or cancelled without asking |
| Name and account of two known payees | Pair one payee's name with another's account | Candidates or a return; no proposal | Any single proposed fix |
| Clean control payments | Leave untouched among the seeded ones | No change | Any change |
Three rules keep the test honest. Freeze the reference data at the test month, or the tool will look better than it is by reading a directory that already knows the answer. Keep the answer key away from whoever configures the tool. And plant faults in payments the bank actually repaired, so the tool meets the real mess of free text and half-filled fields rather than tidy test data. A replay of real failures is the backbone of a pilot on last month's failed payments; the seeded faults are what turn it into a measurement.
How many test cases are enough?
Enough that a perfect score still means something. If a tool catches every one of n planted faults of a type, the most its true miss rate can be, at 95% confidence, is 1 − 0.05^(1/n). The bound falls quickly at first and slowly after.
How sure a clean sweep makes you: the worst miss rate still possible after n faults, all caught
The practical reading is that ten examples of a fault prove almost nothing, and that a few hundred per high-risk type are needed before a bank can say the miss rate is about one in a hundred or better. For the who-or-how-much families, size the test on the wrong-change rate as well: a tool that changed no account wrongly in 300 tries has a wrong-change rate of no more than 1% at that confidence. For low-risk format faults, fifty of each is usually enough to see whether the tool works at all.
How do you measure payment repair accuracy?
Measure accuracy as four rates per fault type, not as one score. A single "accuracy" figure lets a tool trade a few dangerous wrong changes for many easy catches and still look good.
- Catch rate: planted faults the tool found and fixed correctly, over planted faults.
- Wrong-change rate: payments the tool changed incorrectly, including clean controls it touched, over payments it changed. On who-or-how-much fields this is the number that matters most.
- Refusal quality: of the payments it declined to fix, how many truly had no provable fix, and of the unprovable ones you planted, how many it declined.
- Agreement with your own past repairs on the unseeded failures, read with care: a disagreement may be the tool's error or the desk's.
Time belongs beside accuracy but never instead of it. A tool that halves the minutes per repair and adds one wrong account a week has not saved money.
What the regulators expect of a bank testing its repair process
Bank examiners expect the funds transfer function to be tested, not merely run. The FFIEC asks whether internal and external audits provide "substantive testing or quantitative measurements" of the funds transfer area, including "Sample tests for message and recordkeeping accuracy" (FFIEC IT Examination Handbook, Wholesale Payment Systems, Tier II procedures). A seeded-error test is a stronger version of the same sample test, because it knows the right answers in advance.
Model risk guidance is less help than buyers expect. The interagency guidance that replaced SR 11-7 on 17 April 2026 leaves deterministic, rule-based software out of its definition of a model, and leaves generative and agentic AI out of its scope altogether, as too new and fast-changing (Federal Reserve SR 26-2 and the revised interagency guidance); both exclusions are quoted in how to use AI for regulatory compliance on wires. The guidance also "does not set forth enforceable standards". So the hub's rule checks are not models under it, and an agentic repair tool is outside it for now. Neither exclusion removes the bank's own duty to show the process works, which is exactly what a seeded test documents.
What to ask of payment repair software before you rely on it
For a buyer, the test plan above turns into a short list of questions, and the answers are more revealing than any demonstration on the vendor's own data.
Eight questions for any payment repair software
- Will it run on our failed payments, with our history and directory as they stood?
A test on the vendor's data measures the vendor's data.
- What does it do when nothing proves a fix?
The right answer is candidates, a return or a refusal, at a threshold the bank sets.
- Does every proposed fix cite its evidence?
Earlier credited payments, a template, a directory entry, a rule. A fix without a source cannot be checked.
- Can it change an amount?
If so, on whose instruction? An amount should change only on the client's instruction and a callback.
- Is every repaired message validated and screened again?
A repair can put a sanctioned place into a field the filter reads for the first time.
- Who checks a change to who is paid, and how?
A blind re-key by a second person is stronger than a second look at the same screen.
- What happens when the bank directory is down?
The tool should stop, not answer from memory.
- How is a new version tested before it goes live?
Against a fixed set of past repairs with known answers, with the results kept.
Where Payment Repair fits, and where it does not
Payment Repair is built to pass this kind of test rather than to avoid it. Every repaired message is re-validated against the network rules and sent to the bank's sanctions screening system before a person sees it and again at release. Each proposal cites its sources; below the bank's confidence threshold, 0.90 on the sample bank, the agents offer candidates instead of a fix; and before a new agent version is approved it runs against a fixed set of 2,400 past repairs. The audit trail keeps each agent's version beside each proposal, so a test result can be tied to the version that produced it.
The Payment Repair audit trail: every proposal with its version, reason and evidence
It is not a payments hub and does not replace one: the hub's validation still decides what fails, and the bank's screening system still decides what is a hit. It is only as good as the history it can read. A bank that cannot give it the client's earlier payments and templates will see more candidates and returns, and fewer proposals, which is the right behaviour but a smaller saving. A seeded test on the bank's own month will show both before anything goes live.
Questions people ask
What does "payment validation failed" mean on a bank payment?
It means the payment did not pass one of the checks before release, such as a required field missing, a bank code not found or an account in the wrong format. The payment is not lost: it is held for repair or returned to the person who sent it, depending on whether the bank can prove the fix.
Is payment validation the same as sanctions screening?
No, though both run before release. Validation checks the message's form and data against rules and reference data; screening compares the parties, places and other details with sanctions lists. A repaired payment should go through both again, because a repair can change what the screening filter reads.
Can we test a repair tool without production data?
You can test whether it runs, but not whether it is right for your bank. The value of a seeded test comes from your clients' real histories, templates and messy free text; synthetic data tends to be cleaner than the queue it is meant to represent.
How often should a repair process be re-tested?
Whenever something that drives repairs changes: a new network release, a new version of the tool, a change to the confidence threshold or a new client channel. Between changes, the live wrong-change and re-failure rates by repair type show whether accuracy is drifting.
Who should own the test?
Someone independent of the team that configured the tool and of the vendor, typically operational risk or internal audit, with the payments operations manager supplying the month's data. The answer key should stay with the owner until the results are in.
To see how proposals, candidates and the audit trail look on the sample bank, start from Payment Repair; for the second person's part of the control, read why the checker re-keys, not re-reads.