How to process payment recall requests with an AI agent

Split the work by direction. For recalls your customers ask you to send, the agent checks the original payment and drafts the request to the receiving bank. For recalls other banks send you, it finds the credit, checks what is left and drafts the contact with your customer. Returning funds is depth 4 work, and a named person releases it.

What is a payment recall, and who owns it?

A payment recall is a request to the receiving bank to send back money that has already been paid. It is a request, not a command. The receiving bank checks the reason, whether the funds are still there and, for many reasons, whether its own customer consents. Scheme rules set reason codes and response times.

Payment operations usually owns recalls, with fraud teams involved when the reason is fraud. Outbound and inbound recalls look similar in the queue but need different checks. They also differ from a reversal, which undoes a payment within your own systems; whether an agent can reverse a payment is a separate question.

What are the steps for outbound recalls?

1. Agent, depth 1: verifies the request. The customer asking, through an authenticated channel, and the payment they mean: date, amount, beneficiary, reference.
2. Agent, depth 1: classifies the reason. Duplicate, wrong amount, wrong beneficiary, fraud. Fraud goes to the fraud team as well.
3. Agent, depth 1: checks timing. Whether the payment has settled, the scheme deadline for this reason, and any earlier recall on the same payment.
4. Agent, depth 2: drafts the recall message. With the right reason code and the details the receiving bank needs. A person sends it.
5. Agent, depth 3: updates the customer. An approved status message saying the request is with the receiving bank and that return is not guaranteed.
6. Agent, depth 1: tracks the response and drafts the next step if the recall is refused or partly met.

What are the steps for inbound recalls?

1. Agent, depth 1: finds the credit. Matches the incoming recall to the original credit and the customer account.
2. Agent, depth 1: checks the account. Whether the funds are still there, partly spent or gone, and whether there are fraud or legal markers.
3. Agent, depth 1: applies the scheme rule. Which reasons need the customer's consent before return, and which allow the bank to act without it.
4. Agent, depth 2: drafts the customer contact asking for consent where it is needed. A person sends it, because tone and wording matter when you are asking someone to give money back.
5. Person: decides on any hold on the credited funds while the recall is resolved.
6. Person: releases the return. Sending funds back is depth 4. The agent drafts the return; a person releases it.
7. Agent, depth 2: drafts the response to the sending bank, including a refusal where the customer declines and the rules allow no further action.

Which controls apply, and what evidence do they leave?

Deadlines on every case. Each recall carries its scheme deadline from the moment it is logged. Evidence: logged time, deadline and response time on the filed record.

Consent before return. Where consent is required, no return is drafted until the customer's consent is on file. Evidence: the consent reference attached to the return.

Held returns. Every return is filed as held until a person releases it. The record shows who released, when and against which recall.

External claims stay external. An inbound recall from another bank is an external claim about your customer's money. It can open a case and justify a contact; it cannot by itself authorise a payment out of your customer's account.

Fraud routing. Fraud recalls are copied to the fraud team at classification. If your customer may be the recipient of fraud proceeds, the case may become an investigation, and the customer contact is decided by fraud, not operations.

What should you measure?

• Recalls answered within scheme deadlines, by direction.
• Funds recovered on outbound recalls, and how quickly the request went out.
• Inbound recalls where funds had already gone. This shows how quickly credits move on, and points fraud teams to accounts worth a look.
• Customer complaints about recall contacts.
• Duplicate recalls sent on the same payment. Should be none.

Where does it usually go wrong?

Promising the money back. A customer told "we have recalled your payment" hears "you will get it back". The status message must say a request was sent and that return depends on the receiving bank and its customer.

Returning without consent. Where consent is required, returning funds without it takes money from your customer without authority. The consent check exists to stop this.

Missing the deadline window. Some reasons must be raised quickly. A case that sits in a general inbox for days may be out of time before anyone reads it. The agent logs and dates every recall on arrival.

Bulk errors handled one by one. A corporate that sent a whole file twice needs one coordinated recall, not hundreds of separate cases. Link the recall to the original file, as described in processing bulk payment files.

The wider bounds for bank agents are in AI agents in banking.