Every payments operation has a repair queue: instructions that failed validation, bounced off a scheme, or came back with a cryptic reason code, waiting for a human to work out what went wrong and fix it. The queue is expensive twice over. Each item costs analyst minutes, and each hour an item sits there delays a supplier payment, a payroll run, or a settlement someone downstream is watching.
The failure causes are boring and stable: missing beneficiary data, an invalid IBAN, a wrong or absent BIC, a format error, a routing problem, a compliance mismatch. What has changed in 2026 is the operating model for dealing with them. Instead of manual exception handling, banks and larger corporates are moving to repair orchestration: a layer that detects the failure, classifies the root cause, enriches the missing or malformed fields where it can, retries through the right channel, and escalates only the unrecoverable tail to a human with full case context.
The distinction that matters is between what should be deterministic and what genuinely needs a model. Get that split wrong in either direction and you build something that is both unreliable and unauditable.
Rules do the validation, models do the diagnosis
The pattern that works in production is a hybrid. Deterministic logic owns hard validation: IBAN checksum and structure, required-field presence, BIC format and directory lookup, scheme-specific format rules. These checks have a right answer, and a model that gets an IBAN check wrong 0.5% of the time is strictly worse than a rule that never does. Rules stay the first line of defence.
The model layer sits above the rules and handles the questions rules answer badly:
- Root-cause classification. A rejection often arrives with a reason code that describes the symptom, not the cause. A trained classifier reading the full instruction, the return message, and the counterparty history can distinguish “beneficiary account closed” from “beneficiary details stale in our master data” from “intermediary routing problem”, and those three route to different fixes.
- Repair recommendation. Given the classified cause, suggest the action: enrich from a specific reference source, reformat and resubmit, reroute through a different correspondent, or escalate. The recommendation is a proposal for the workflow, not an autonomous act.
- Anomaly detection. A spike of failures sharing a correspondent, a currency corridor, or a file source usually means an upstream change, a bank template edit, an ERP mapping regression, a scheme rule update. Catching the cluster early turns two hundred individual repairs into one fix at the source.
Enrichment is a reference-data problem
Most repairable failures are missing-data failures, and the repair is only as good as the sources you can enrich from. The workhorses are the IBAN and BIC directories, internal beneficiary master data, the counterparty’s own payment history, and external lookup APIs for account and institution details. A repair layer should record, for every enriched field, which source supplied the value and when that source was last refreshed. Enrichment from a stale directory is how a repaired payment fails a second time, and the second failure is more expensive because the payment is now late and flagged.
The structural shift working in automation’s favour is ISO 20022. Structured, typed fields, above all structured addresses and distinct name fields, are far easier to validate and repair than the free-text lines of the legacy formats, and the industry push through 2026 is to get address data captured in machine-readable form rather than parsed out of it afterwards. Coexistence periods and per-scheme deadlines vary by market infrastructure, so check the rulebook that governs your rails before committing dates to a project plan. The engineering direction is unambiguous either way: every field that moves from free text to structure converts a fuzzy repair problem into a deterministic check.
That also means the highest-return repair work often happens before the payment exists. If supplier legal names, addresses, and account identifiers are clean in the ERP and vendor master, the repair queue shrinks at the source. A repair layer that reports which upstream systems generate which failure classes gives you the business case for that cleanup, one root cause at a time.
Retry, route, and know when to stop
Repair without retry logic just produces a cleaner queue. The orchestration layer needs three decisions per item.
- Whether to retry at all. A payment rejected for sanctions review must never be auto-resubmitted. Classification has to separate operationally repairable failures from compliance-relevant ones, and the compliance branch goes to humans, always, with the automation contributing only the assembled context.
- When to retry. A failure caused by a beneficiary bank cutoff resolves itself next window; retrying immediately burns a submission for nothing. Timing rules keyed to failure class and scheme calendar are simple and pay for themselves quickly.
- Where to retry. Some failures are channel-specific. If the same instruction can legitimately travel a different rail or correspondent, rerouting is a repair action, and this is where repair orchestration meets smart routing rather than duplicating it.
Escalation is the other half. When automation gives up, the case handed to the analyst should contain the original instruction, the classified cause, every enrichment attempted with its source, and every retry with its outcome. The measurable win is not only fewer escalations; it is that each escalation takes minutes instead of an investigation.
The operational reality: measurement, controls, audit
Be honest about what this buys. Automation does not eliminate payment failures; it increases the share of exceptions that are recoverable without a human, and it compresses time-to-resolution on the rest. Vendors with mature enrichment and routing report client STP rates of 85–95%, with AI layers aimed at pushing above 95%. The delta between those numbers is the addressable prize, and it is worth quantifying against your own volumes before building anything: items per day, minutes per item, and the SLA cost of late settlement.
The controls are not optional. Every automated repair writes an audit record: field before, field after, source, rule or model version, confidence. Silent automated fixes are limited to deterministic, reference-backed changes; inferred values below a confidence threshold go to review. Model-recommended actions run through the same four-eyes and limit checks a human repair would, because a repair layer that can alter beneficiary details is, from a fraud perspective, an attack surface, and it should be treated as one, with change control on its reference data and alerting on unusual repair patterns.
Expect failure modes and design for them: reference data that goes stale, a classifier that drifts as counterparty behaviour changes, an upstream format change that floods the queue faster than the model was trained to handle. The teams that do well treat the repair layer as a product with an error budget, monitored recall on classification, and a monthly review of what escaped to humans and why. The queue never reaches zero. It becomes short, explainable, and boring, which is the point.
FAQ
Should the repair layer sit inside the payment engine or beside it?
Beside it, as a service the engine calls when validation fails. Embedding repair logic in the engine couples release cycles and makes every enrichment rule a payments change request. A separate service can evolve weekly, keep its own reference data, and return either a repaired instruction or a classified exception, while the engine stays a thin, certifiable pipe.
How do you stop auto-repair from introducing new errors?
Constrain what automation is allowed to touch. Deterministic fixes from authoritative reference data, a BIC derived from a valid IBAN for example, can apply silently. Anything inferred, like a beneficiary name completed from history, should carry a confidence score and route to a human below threshold. Log the original field, the repaired value, and the source for every change, and sample repaired payments in QA the way you sample manual work.
What is a realistic STP baseline before adding ML?
Vendors with mature deterministic enrichment and routing report client STP in the 85–95% range, with AI positioned to push above that. If your STP is well below 85%, the gap is usually format discipline and reference data, not missing intelligence. Fix scheme validation, IBAN checksums, and beneficiary master data first; the model earns its keep on the residual tail, not the basics.