How to confirm suspicious card transactions with customers with an AI agent

The fraud system flags the transaction; the agent contacts the customer through a channel already registered to them, shows the merchant, amount and time, and asks one question: was this you? A clear yes lifts the restriction. A no freezes the card and opens a claim. Silence, hesitation or signs of coaching go to a fraud analyst.

What is the process, and who owns it?

Card fraud systems decline or hold transactions that look unusual, then need the cardholder to confirm. Most flagged transactions are genuine, so the cost of the process is mostly friction for honest customers: a declined payment at a till, a booking that fails. Speed matters on both sides. The faster a genuine customer confirms, the sooner they can pay; the faster a fraud is confirmed, the less the fraudster spends.

The head of fraud operations owns the process. The fraud strategy team owns the rules that flag transactions. A named fraud analyst takes every case the agent cannot settle. For the wider limits on agents in banking, see our guide to AI agents in banking.

What are the steps, and who acts at each one?

1. Fraud system: flags and restricts. The transaction is declined or held and a case is created. The agent does not decide what is suspicious.
2. Agent, depth 1: reads the case. Transaction details, recent card activity, contact details on file, any open fraud or scam markers. Evidence: facts used, with sources.
3. Agent, depth 2: contacts the customer through a registered channel. An in-app message or a text to the number on file, with no links to enter card details. Evidence: message sent and channel used.
4. Agent, depth 1: presents the transaction and asks for a yes or no. Merchant, amount, date and time, last four digits of the card. It never asks for a full card number, PIN, security code or one-time passcode. Evidence: the exchange.
5. Agent, depth 3: on a clear yes, lifts the restriction. It may also mark the merchant as recognised for this card if your rules allow. Evidence: release event with the confirmation.
6. Agent, depth 3: on a clear no, freezes the card. Then, at depth 2, opens a fraud claim and lists other recent transactions for the customer to review. Evidence: freeze event and claim reference.
7. Person, fraud analyst: takes unclear cases. No reply within the set time, a hesitant or changing answer, a customer who says yes but describes being told to make the payment by someone else, or a high-value transaction above the agent's limit. Evidence: hand-off with the reason.
8. Agent, depth 2: drafts the closing message. What happened and what to expect next. Evidence: message sent.

Which controls matter, and what evidence do they leave?

Registered channels only. The agent never uses a phone number or email supplied in the conversation. Evidence: channel source on each contact.

No secrets requested. Scammers impersonate exactly this flow. If your genuine process never asks for codes, customers can be told so plainly, and the agent's messages can say it. Evidence: message templates reviewed by fraud.

Masked card data. The agent sees and shows only the last four digits. Whether there is ever a case for more is discussed in whether an AI agent should ever see full card numbers, and the security standard that applies is covered in PCI DSS and AI agents that handle card data. Evidence: masked values in logs.

Release limits. Above a set amount, even a clear yes is reviewed by an analyst. Evidence: held verdict on high-value releases.

Scam screening on a yes. "Yes, I made it" does not mean the customer is safe. If they mention an investment, a caller from the bank, a delivery fee or pressure to pay, the case goes to a person. Evidence: screening result recorded on each yes.

Connections scoped. The agent's rights in the card system are limited to reading, releasing and freezing. The integration is set out in connecting an AI agent to your card management system. Evidence: grants per capability.

What should you measure?

• Time from flag to customer contact, and from contact to answer.
• Confirmed genuine, confirmed fraud, and unanswered, as counts per day.
• Released transactions later reported as fraud. Each one is reviewed: the yes may have been coached.
• Cases handed to analysts, by reason.
• Customers reporting impersonation of this flow. A rise means fraudsters are copying your messages.

Where does it usually go wrong?

The message looks like a scam. It contains a link, asks the customer to log in, or uses an unfamiliar sender. Customers ignore it, or learn to trust messages that look like it.

A coached yes is accepted. The customer is on the phone with a fraudster who tells them to confirm. Look for the signals, and slow down where they appear.

The agent decides suspicion. It begins to clear flags without contacting anyone because the transaction "looks normal". The fraud system flags; the customer confirms; the agent does neither job alone. Whether an agent should ever block on its own is covered in whether an AI agent can block a suspicious transaction.

No reply is treated as yes. Silence keeps the restriction in place until someone confirms.