How should a bank app let customers dispute a card transaction?

Illustrative situation: a customer in Dubai sees AED 1,240 paid to “KHL*TRDG 0417 DXB.” The name means nothing. The app offers one button, “Dispute,” and a form with eleven reason codes. The customer picks “Fraud,” the card is cancelled, and the replacement takes a week. Ten days later the case closes: the charge was the customer’s gym, billed under its parent company’s trading name. The scene is invented. Each step came from a default in the processor or the case system, and nobody designed the journey as a whole.

Humbleteam, a digital product design agency, publishes this guide. It covers the “I don’t recognize this payment” journey for a bank whose card processor and case system sit apart from the core: sorting the case, merchant recognition, freezing the card, regulatory clocks, evidence, temporary credit, status states and the final message. UAE rules come first, with UK and US rules for comparison. Rule and vendor behavior is described as of November 2, 2026 and can change. This is general information, not legal advice; your compliance team decides which rules apply and approves the wording.

Our guide to pending items and cut-off times on a legacy core covers how the transaction list should read. This guide starts when the customer taps a line and says it is wrong.

Why does “I don’t recognize this payment” need three paths?

Three situations hide behind the same tap, and the rules treat them differently.

• The customer did not make the payment. The Central Bank of the UAE’s Consumer Protection Standards give unauthorized transactions their own clauses, 5.1.1.43 to 5.1.1.48. The UK Payment Services Regulations 2017 and US Regulation E cover them too.
• The customer made the payment, but the purchase went wrong: goods never arrived, or a cancelled subscription kept charging. US Regulation Z counts goods not delivered as agreed as a credit card billing error. In the UK, section 75 of the Consumer Credit Act 1974 makes a credit card provider jointly liable with the supplier for breach of contract, within price limits. Otherwise these cases usually run through card network rules, applied by the bank’s processor.
• The payment is real but wrong, charged twice or for the wrong amount. Regulation E lists incorrect transfers and bookkeeping errors. Where the bank made the mistake, CBUAE clauses 5.1.1.38 and 5.1.1.39 require an immediate refund and a message to affected customers within 10 complete business days.

The first screen should sort the case without making the customer diagnose it. Our suggestion is one question with three answers: “I didn’t make this payment,” “I made it, but there’s a problem with what I bought,” and “I made it, but the amount or number of charges is wrong.” Each opens its own form and promise. A reason-code list copied from the processor’s back office tends to push people toward “fraud,” because fraud sounds like the answer that gets money back.

A payment a scammer talked the customer into is a fourth case with different rules. Our guide to scam warnings and payee checks covers the moment before it.

How do you stop customers disputing payments they made?

A claim often starts with an unreadable name. Stripe’s documentation on statement descriptors says clear descriptors can reduce chargebacks and disputes, caps them at 22 Latin characters, and notes that some banks display them incorrectly or not at all. The UK Open Banking transactions resource also defines optional merchant details: the name the merchant is known by and an ISO 18245 category code. Ask your processor which fields it sends.

Our suggestions for the transaction detail screen, shown before any claim button:

• A cleaned merchant name, with the raw descriptor underneath as “Shows on statements as …”
• Local time, the city or “online,” and the category in plain words.
• Which card and which wallet or device paid, so a family member’s phone becomes visible.
• Earlier charges from the same merchant.
• “Ask about this payment” as a separate action from “Report a problem.”

That split matters in the US. The official interpretation of Regulation E (comment 11(a)-5) treats a request for documentation or information as an error unless it is clearly for record-keeping, and Regulation Z lists a request for clarification as a billing error. When a question reaches the bank, log it as a notice, with its time.

When should the app freeze the card?

On the unauthorized path, the freeze comes first. CBUAE clause 5.1.1.43 requires round-the-clock digital and phone channels for reporting loss, theft, fraud or misuse. Clause 5.1.1.46 requires the bank to record the report’s date and time and offer three options: block the card during the investigation, close it, or cancel and replace it.

UK regulation 73 requires a way to notify at all times, proof of notification on request for 18 months, and blocking of any use once notified. Under regulation 77, except for fraud, the payer bears no losses arising after notification. Under Regulation E, liability for a lost or stolen card is capped at USD 50 if reported within two business days of learning of the loss, and USD 500 after that.

Our suggestions: offer a reversible freeze before the form, and say what stops working, including recurring payments. Show a receipt with the report time; it is the customer’s proof and the start of the bank’s clock. Keep cancel-and-replace a separate, later choice, and do not freeze by default on the other two paths.

What clocks do the rules set?

Card network rules add their own deadlines for raising a chargeback, the merchant’s answer and the decision. Stripe’s dispute documentation says the full cycle can take 2-3 months. Take exact figures from your processor.

Each clock starts at a different moment, so the case system has to record each one. The short UAE and UK money deadlines also mean money can come back before the investigation ends, and the app has to say what that money is.

What should the claim form ask, and is evidence required?

Ask only what the path needs, and never let evidence block submission. Regulation E’s official interpretation says a bank may not delay an investigation while waiting for a signed statement, and must begin promptly on an oral notice (comments 11(b)(1)-2 and 11(c)-2). UK regulation 75 puts the burden on the bank to prove the payment was authenticated, and says recorded use of the card is not in itself necessarily proof that the payer authorized it. The UAE starts from the other side: clause 5.1.1.45 treats a transaction as authorized if proper and secure validation was applied, unless the consumer provides prima facie evidence that creates reasonable doubt. So make the customer’s own account easy to give.

Our suggestions per path:

• Unauthorized: where the card was, whether anyone else uses the phone or card, and where the card details were entered recently. Files optional.
• Purchase problem: what was ordered, the promised or cancellation date, and contact with the merchant. Regulation Z’s claims-and-defenses rule applies only after a good-faith attempt to resolve the dispute with the merchant, so a “Contact the merchant first” step fits here, never on the unauthorized path. Useful files: receipt, cancellation confirmation, messages, tracking.
• Processing error: the expected amount, and a receipt if there is one.

Accept photos, PDFs and screenshots, let the customer add files later, and list what the bank has received.

How should temporary credit be explained?

Regulation E is the most specific. If the bank needs more than 10 business days, it credits the amount provisionally, tells the customer the amount and date within two business days, and gives full use of the funds. If it finds no error, it must give the date and amount of the debit and keep honoring checks and preauthorized transfers for five business days without overdraft fees. The UK and UAE texts speak of refunds, not provisional credit; what happens when a refund later proves wrong is for compliance to decide.

Our suggestion: show temporary credit as its own line, linked to the case, labelled for what it is. For example: “Temporary credit for your claim. You can use it. If we find you made this payment, we’ll tell you before we take it back.” The reversal message names the date, amount and reason.

What can the app show when three systems each hold part of the state?

In the setup this guide assumes, the card processor holds the authorization, card status and chargeback stage. The case system holds the case number, owner, files and deadlines. The core holds the posting and any credit. Each updates on its own rhythm, often in batches.

The app can show what the bank has done and when. It usually cannot show what the merchant is doing, or a reason the processor does not pass back. Our suggestion is a small case-state layer that writes customer-facing states only from confirmed events, stamps each with its time and shows “Last updated.” When an event is missing, the tracker stays on the last confirmed state.

What should the final message say?

CBUAE clause 8.1.3.8 requires a final response that clearly accepts or rejects the complaint, gives detailed reasons unless financial crime obligations or law prevent it, and explains how to escalate. Clause 8.1.1.4 asks for a unique service request number for tracking and escalation. Regulation E requires a written explanation and notice of the right to request the documents relied on. The FCA’s DISP 1.6.2 requires a final response to point to the Financial Ombudsman Service, and the ombudsman gives customers 6 months from that response to bring a complaint.

In the UAE the step outside the bank is Sanadak, the financial and insurance ombudsman unit established in 2023. Its eligibility page says it may reject a complaint if the customer did not first complain to the bank or did not wait 15 calendar days. Its process page says the bank must then resolve within five working days once the customer has supplied the required information.

A dispute decision and a complaint can be separate records. Our suggestion: the “Not upheld” screen carries “Disagree with this decision,” which opens a linked complaint, shows the service request number at once, and states both clocks: the bank’s final response and the day Sanadak can take the case.

Illustrative worked example: four lines on one statement at Harbourline Bank

Harbourline Bank, its customer Rania Aziz and all figures are invented. The clocks are the UAE ones above.

On March 3, Rania Aziz finds four lines that look wrong. The first, AED 1,240 to “KHL*TRDG 0417 DXB,” opens to “Khaleej Trading (FitHouse gyms)” with five earlier monthly charges. Rania Aziz recognizes the gym, and no claim is filed.

The second is AED 2,180 to an online electronics shop abroad at 03:12. Rania Aziz taps “I didn’t make this payment,” freezes the card at 08:05 and gets a receipt with that time, which starts the 30-day reimbursement limit. On March 19 the investigation finds the payment unauthorized and the money is credited.

The third is AED 389 for a language-app renewal cancelled on February 20. Rania Aziz picks the purchase path, confirms having written to the merchant and uploads the cancellation email. The tracker shows “With the merchant” and warns this can take weeks. On April 21 the case closes in Rania Aziz’s favor.

The fourth is AED 96 from a café, shown twice a minute apart. The processor shows the second line as an authorization never captured, and the tracker says so: “This second charge is pending and hasn’t been taken. It should drop off by March 5. If it posts, tell us here.” It drops off, and no case is opened.

Where do these defaults stop working?

Business, corporate and prepaid cards may fall under different rules, and Regulations E and Z protect consumers only. The CBUAE standards must be read with Shari’ah compliance regulations, which matters for Islamic card products. Regulation Z asks for a written billing error notice; whether an in-app form qualifies is for counsel. Card network rules appear here only in general terms. Scam-induced payments and cards issued through a partner bank need their own answers, including who owns the case. The sources are regulations, an ombudsman’s pages and one processor’s documentation; none studies dispute journeys, and we found no study that does.

What can you produce now?

Before anyone draws a screen, you can have six things ready:

1. The three-answer first question, tested with customers.
2. A merchant detail spec: the fields your processor sends, the cleaned name and the raw descriptor.
3. A clock register: every clock per market, what starts it and which system records it.
4. The dispute state worksheet, filled in with your processor, case and core owners.
5. Compliance-approved copy for temporary credit, its reversal and the final message.
6. The escalation screen, with the service request number and the Sanadak step.

If you plan to bring in outside designers, ask each team to fill in two worksheet rows with your core and case owners in the room. Our comparison of design agencies used to bank compliance and legacy systems shows which studios publish that kind of work.