Yes, when the repair changes the format of the instruction and not its meaning. An AI agent can fix missing structure, invalid characters and identifiers it can derive with certainty, then resubmit at depth 3. Anything that would change who is paid, which account, how much or in what currency goes back to the customer or a named person.
What is the difference between format and meaning?
Payment messages are rejected for many reasons. Some are about form: an address in one free-text line when the scheme wants street, town and country in separate fields; a character the scheme does not accept; a name longer than the field; a missing purpose code that can be read from the customer's stated reason. Fixing these makes the same instruction readable to the next system.
Others are about substance: an account number that fails its check digit, a beneficiary name that does not match, an amount over a limit, a currency the receiving account does not hold. Fixing these means deciding what the customer meant, and the agent cannot know that. A repair that guesses the right account number is not a repair. It is a new payment the customer never instructed.
What decides whether the agent may repair?
The test is simple to state: after the repair, would the customer recognise the payment as exactly the one they asked for? If yes, the agent may repair. If the answer depends on an assumption, it holds.
Derivations count only when they are certain. Taking a bank identifier from a reference directory, keyed on a valid account number, is certain. Inferring a town from a postcode in a sealed address register is usually certain. Guessing that "Jon Smith" means "John Smith" is not.
What may the agent do, and where must it stop?
| Rejection reason | The agent | Where it stops |
|---|---|---|
| Unstructured address where structure is required | Splits it into fields | Ambiguous addresses |
| Invalid characters | Replaces them under the scheme's rules | Names where replacement changes meaning |
| Field too long | Truncates under the scheme's rules | Beneficiary names where truncation could mislead |
| Missing bank identifier | Derives it from a reference directory | Account numbers that fail validation |
| Missing purpose code | Maps it from the customer's stated reason | Reasons that fit several codes |
| Invalid account number | Never repairs | Back to the customer |
| Amount, currency or payee issue | Never repairs | Back to the customer or operations |
| Stopped by sanctions screening | Never repairs | The sanctions team |
The last row matters most. A payment stopped by screening is not a format problem. Changing a name, removing an address or rewording a reference so that a payment passes screening is evasion, whatever the intention. The agent has no capability to touch these.
An example: a batch of supplier payments
Take a business customer's batch of 200 supplier payments, of which 12 are rejected overnight.
Seven have addresses in a single line. The agent splits each into street, town and country using the address as written, and resubmits. Two contain an accented character the scheme does not accept; the agent replaces it with the scheme's permitted equivalent. One is missing a bank identifier, which the agent derives from the account number using the reference directory.
One has an account number that fails its check digit. The agent does not try nearby numbers. It returns the payment to the customer's finance team with the reason. The last is held by sanctions screening because the beneficiary name partly matches a listed entity. The agent does nothing to it except confirm it sits with the sanctions team.
By the morning, ten are paid, one awaits the customer's correction, and one is under review. Each repair records the field changed, before and after.
What controls make it safe?
- A list of permitted repairs. Each repair type is defined in the policy library with the rule it follows; anything not on the list is held.
- Before and after recorded. Every changed field is filed with its original value, so any repair can be checked.
- Reference data sealed. Directories and registers used for derivation come from systems of record, with provenance.
- No touching screened payments. Payments stopped by sanctions screening are outside the agent's scope entirely.
- Repeat rejections escalate. A payment rejected twice after repair goes to a person.
The full process is in repairing rejected payment messages with an AI agent. When the customer's instruction contradicts itself, the agent should follow how an AI agent should handle conflicting instructions. Payments that go out and come back are a different process: see handling payment returns with an AI agent. The general limits are in AI agents in banking: what they may and may not do.
Questions people ask
Does the customer need to be told about a format repair?
Policies differ. Many banks record repairs without notifying the customer, since the payment is unchanged in substance. Repairs that alter how the beneficiary's name appears should usually be shown to the customer.
Can the agent repair payments for its own bank's treasury?
The same rules apply. Who sent the instruction does not change whether a repair alters its meaning.
What if the repair causes a payment to go to the wrong place?
If the repair changed only format, that should not happen. If it does, the record shows exactly which field changed, and a person investigates using the bank's payment investigation case template.