AI agent · Retail banking · Sort & route
Card dispute intake
Cardholders describe disputes in their own words, through whichever channel is nearest. The agent turns each message into a structured case: the right transaction, a proposed dispute category, and a specific question to the cardholder when something is unclear.
Typical volumes for this process, not a client figure.
Customer writes in; an agent re-types the claim into the dispute system.
The claim is structured, the transaction found, the case opened automatically.
Where the time goes today
Disputes arrive through every channel you offer: the app, secure messages, email, web forms, branch notes and call centre summaries. A customer writes that they were charged twice, that the goods never arrived, that they cancelled a subscription months ago, or simply that they do not recognise a payment. Someone on the disputes team reads the message, searches the card account for the transaction, re-types the details into the dispute system and picks a category.
Each of those steps loses time or accuracy. Customers give approximate amounts and dates, and merchant names that bear little resemblance to what appears on the statement. Some describe several transactions in one message. Picking the wrong transaction or the wrong category builds the case on the wrong basis, and it may be rejected later, after the scheme's time limits have run down. The same customer often writes twice through two channels, and two cases get opened.
Meanwhile the messages that need a fast response, such as suspected fraud where the card should be blocked, wait in the same queue as a question about a pending refund.
How the agent works
- Read the messageThe agent reads the customer's message in whatever channel it arrived and extracts the claimed amount, date, merchant, number of transactions and the reason in the customer's own words.
- Find the transactionIt searches the card account for candidates, matching on amount, date range and merchant descriptor, and records how well each candidate fits.
- Check for duplicatesIt compares the claim with open cases for the same card and customer, and links the message to the existing case when it is the same dispute.
- Propose a categoryIt maps the reason to your dispute categories, which follow the card scheme's reason codes, and lists the evidence that category will need.
- Open or askWhen one transaction fits clearly and the category is settled, it opens the case. When the fit is uncertain, it sends the cardholder one specific question, such as which of two payments they mean.
What stays with a person
A person decides anything that affects the customer's money or the bank's position: provisional credit where your rules leave it to discretion, blocking or reissuing a card, and whether to pursue a chargeback or absorb a small loss. Messages that mention fraud, threats, financial difficulty or a complaint about the bank itself go to a person at once, not into the dispute queue.
The dispute analyst still builds and submits the chargeback. The agent's work ends at a correctly opened case with the transaction identified, the category proposed and the evidence list started.
What it reads, what it produces
| It reads | It produces |
|---|---|
| Customer messages from the app, email, web forms and call notes | A structured dispute case: transaction, amount, category and the customer's account of events |
| Card transaction history for the account | Links between duplicate messages and the existing case |
| Open and recent dispute cases for the customer | Specific clarification requests to the cardholder |
| Your dispute categories and the scheme reason codes they map to | An intake queue ordered by time left before the scheme deadline |
| Merchant descriptor reference data, where you hold it | A list of messages routed to fraud or complaints, with the reason |
Controls that come with it
- A case is opened only when a single transaction matches above an agreed confidence; otherwise the cardholder is asked.
- Any mention of fraud or unauthorised use goes to the fraud team immediately, whatever else the message contains.
- The agent never grants provisional credit where your rules call for a decision.
- An analyst checks a daily sample of opened cases for the right transaction and category.
- Every case keeps the original message, the candidates considered and the reason for the choice.
- Merged duplicates can be split again from the case history.
How you know it works
- Cases opened on the correct transaction and category, tested on past disputes
- Time from customer message to open case
- Duplicate cases opened, before and after go-live
- Cases lost to missed time limits or a wrong category
- Clarification requests sent per case
Is your process ready?
- Written rules: your dispute categories, their mapping to scheme reason codes and the evidence each needs are documented.
- Systems: the card platform exposes transaction history, and the dispute system accepts new cases through an interface your licence permits you to automate.
- Cheap check: an analyst can see at a glance whether the right transaction was chosen.
- Volume: hundreds of disputes a week across several channels repays the build.
- Consistent process: intake staff in different channels categorise the same claim the same way.
The five candidacy checks are explained, with an exam, in the free Module 01.
What goes wrong
- Merchant descriptors that look nothing like the name the customer uses, which need a reference table rather than guesswork.
- One message covering several transactions or several reasons, which must become several cases.
- Asking the cardholder too many questions, which delays the case more than an analyst would.
- Treating scheme reason codes as fixed; they change, and the mapping must be versioned.
Questions we get
What if the customer gives no amount or date?
The agent works with what is there: the merchant, rough timing, the customer's description. If it finds one clear candidate it proposes it. If it finds several, it asks the cardholder to choose, listing each with the date, amount and merchant name exactly as they appear on the statement. It does not open a case on a guess.
Does it decide whether a dispute is valid?
No. It proposes a category and lists the evidence that category requires, which shows the analyst early on whether the claim is likely to hold. Whether to pursue a chargeback, contact the merchant first or decline the claim is the analyst's decision, made with the scheme rules and the customer's history in view.
How does it keep track of time limits?
Each case records the transaction date and the deadline that applies to its category under the scheme rules, as configured by your team. The intake queue is ordered by time remaining, and cases nearing a limit are surfaced to a person. The limits are configuration your team maintains; the agent does not infer them.
Can it reply to customers?
Clarification requests are drafted from templates your team writes and approves, with the transaction details filled in. The agent does not compose free-form replies about the outcome of a dispute. Anything beyond a factual question about which transaction or which date goes through a person or an approved template, and every message sent is kept on the case.
Want this agent on your process?
Tell us about your version of this process — volumes, systems, what goes wrong. A person answers with an approach and a price, usually within two working days, or tells you it is the wrong project.