Every failed payment stopped somewhere. The agent traces it to its last known status and names the cause, such as a limit, a missed cut-off or a rejection. It raises a trace where the status is unclear and explains the outcome. Fraud and screening holds, and failures that repeat across customers, go to people.
What is a failed payment investigation, and who owns it?
"My payment didn't arrive" covers many situations. The payment may never have left: blocked by a limit, insufficient funds, a fraud hold, a missed cut-off. It may have left and been rejected by the receiving bank. It may have arrived and not been credited to the right account. Or it may be on its way through an intermediary bank on an international route. Each has a different fix, and some look identical from the customer's side.
The head of payment operations owns investigations. Payments analysts own cases the agent passes on. Fraud and financial crime own holds in their areas. Whether an agent can do this tracing at all is answered in whether an AI agent can trace a missing or failed payment. For the wider frame, see our guide to AI agents in banking.
What are the steps, and who acts at each one?
- Agent, depth 1: identifies the payment. From the customer's description: date, amount, payee, reference. Evidence: payment matched with its internal reference.
- Agent, depth 1: reads every status event. Instruction, internal checks, submission to the scheme, acknowledgements, rejections, returns. Evidence: the event sequence.
- Agent, depth 1: finds where it stopped and why. Maps the last event to a cause from a fixed list. Evidence: cause code with the event that supports it.
- Agent, depth 1: checks for holds it may not discuss. If the payment is held by fraud or by sanctions screening, the agent stops, passes the case to the owning team, and tells the customer only that the payment is under review. Disclosing a screening hold can be a serious breach. Evidence: hand-off without disclosure.
- Agent, depth 3: raises a trace with the receiving or intermediary bank where the payment left but its fate is unclear, using the scheme's standard message. Evidence: trace reference.
- Agent, depth 2: explains to the customer. What happened, in plain words, and what they can do: correct details, resend after a limit resets, wait for a trace. It never resends for them. Evidence: message sent.
- Agent, depth 1: checks for a pattern. The same cause hitting many customers in a short window, such as a scheme outage or a bad reference data update, is raised as an incident. Evidence: incident reference.
- Person, payments analyst: resolves what the agent cannot. Unclear traces, compensation for bank errors, anything involving another bank's dispute. Evidence: resolution.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Identify | Matches the customer's description | 1 | Nothing |
| Status | Reads every event | 1 | Nothing |
| Cause | Names where and why it stopped | 1 | Unclear causes |
| Holds | Routes without disclosing | 1 | Fraud or financial crime |
| Trace | Sends the standard trace message | 3 | Traces with no reply |
| Explain | Tells the customer what to do | 2 | Nothing |
| Pattern | Raises an incident | 1 | Incident owner |
| Resolve | Prepares the case | 2 | Analyst decides compensation and disputes |
Which controls matter, and what evidence do they leave?
No resend by the agent. A payment shown as failed may have settled; a resend pays twice. The customer resends, after the agent confirms the status. Evidence: refused verdicts on resend attempts.
Holds are not explained. The agent recognises fraud and screening holds and routes them without detail. Evidence: approved holding wording.
Cause codes are fixed. A small list of causes, each with approved customer wording, keeps explanations consistent. Evidence: code and wording version per case.
Traces through the scheme. Standard messages leave a record both banks can follow. Evidence: trace references.
International routes tracked to the last bank. Payments through intermediaries can stop at any hop. The agent records each bank the payment reached, so the trace goes to the right place. Evidence: route record per payment.
Patterns escalate. Evidence: incidents raised and the number of customers in each.
What should you measure?
- Time from enquiry to explanation.
- Failures by cause, over time. A cause that grows points to a fix: clearer limit messages, better cut-off warnings.
- Traces raised and resolved, and time to resolution.
- Customers who resend and pay twice. Target zero.
- Incidents detected by the agent before customers reported them widely.
Where does it usually go wrong?
Status is taken at face value. "Failed" in one system, "settled" in another. Read every event.
The customer is told too much. "Your payment was stopped by our sanctions screening" is a disclosure no agent should make.
Each case is solved alone. Fifty customers with the same failure get fifty explanations and no fix. Look for the pattern.
Failed attempts in a takeover are missed. A run of failed payments to new payees can be the first sign that someone else is in the account; see investigating account takeover cases with an AI agent. Repeated failures to one receiving account may point at a mule, covered in investigating suspected money mule accounts.
The agent's own errors are not investigated. If an agent prepared the failed payment, the failure is also evidence about that agent; see how to investigate an AI agent incident.
Questions people ask
Can the agent tell the customer when the payment will arrive?
Only when the status supports it, such as a trace reply confirming credit. Otherwise it gives the scheme's usual timescale and says the payment is being traced.
What if the bank caused the failure?
The agent explains plainly and passes the case to an analyst, who decides any refund of charges or compensation under your policy.
Should the agent investigate incoming payments the customer is expecting?
Yes, at read. It can check whether anything arrived and was returned or held, and tell the customer what it can see. It cannot chase the sender's bank for a payment not yet sent.