A bank controls exactly one phase of a dispute: the phase before it is filed. After a customer files, scheme rules and regulation take over, and the process runs on reason codes, representment windows and monitoring thresholds that the issuer cannot change. Before filing there is one variable that decides whether a dispute happens at all, and it is whether the customer recognised the payment. That is where chargeback prevention for banks actually starts.
This article covers the phase nobody writes about - the moment a customer reads a line in the app, fails to place it, and reaches for the dispute button.
Where a dispute actually begins
A dispute begins in the banking app, at the instant a customer opens their transaction list, reads a line, and cannot work out what it is. Everything after that instant is downstream.
It helps to name the two phases plainly. The phase after filing is governed externally: the card networks define the reason codes, the representment windows, and the ratio thresholds that decide a bank's scheme standing. An issuer works inside those rules but does not set them. The phase before filing is different. It is owned entirely by the bank, because it happens on a screen the bank designed, showing data the bank chose to display. The only question in that phase is recognition.
This is why prevention is a product problem. The cost of disputes lands on the operations team, but the lever that moves it is the transaction detail screen, and that screen belongs to product. As Ivan Dovica, co-founder of Tapix, puts it, a dispute is the most expensive way to answer the question “what was this?". The cheapest way to answer it is to make sure the customer never has to ask.
What actually causes disputes at an issuer
Most disputes are simple confusion. Up to 70% of card disputes are friendly fraud, according to the FIS Global Report. Friendly fraud is the industry term for a customer disputing a charge that was, in fact, legitimate, usually because they did not recognise it rather than because they set out to defraud anyone.
Mastercard research with Datos Insights, published in January 2026, found that 48% of consumers have mistakenly disputed a charge that turned out to be legitimate. Mastercard links this to card-not-present transactions, which it puts at 63% of merchant transactions, and specifically to purchases made through a third-party app or service where the name that lands on the statement is not the name the customer remembers paying. The two figures measure different things: one is the share of disputes that are friendly fraud, the other is the share of consumers who have filed one by mistake. Together they describe the same failure from both ends.
Genuine third-party fraud exists and belongs in a fraud process. Set it aside. What remains, the confusion, follows three repeatable data patterns.
The first is the gateway or aggregator descriptor that hides the real business. A charge arrives as PAYPAL*ABOUTY or a similar processor string, and the customer sees the payment rail instead of a seller. The real merchant is in there; it is just buried under the gateway's name. Tapix recognises 65+ gateways, wallets and BNPL providers, including PayPal, Stripe, Paddle, Klarna, Mollie and Zettle, and resolves the descriptor to the business the customer actually paid.
The second is the recurring charge the customer forgot. A subscription renews, the customer has no memory of signing up or has lost track of the price, and the renewal reads as an unexplained debit. Around 30% of disputes start this way, per the Tapix disputes page. Surfacing the charge as a known recurring payment, with its history and its cadence, removes the surprise. This is the same signal that powers subscription management for banking apps.
The third is missing context: the statement shows a head office address instead of the store the customer walked into, or a legal entity name instead of the trading name on the shopfront. Sub-brand confusion sits here too. A customer who paid Amazon Prime sees "Amazon" and wonders about an order they never placed; a customer who used Uber Eats sees "Uber" and pictures a ride they did not take. Each of these is a data problem before it is a support problem, and each is a decision about what to write in the payment description the customer reads. The raw card message simply does not carry a clean answer, which is a limitation of what the card network transaction data actually contains.
What a dispute costs the issuing bank
The cost of a dispute for a bank sits in operations, not in a per-case fee, which is exactly why it is chronically under-measured. PYMNTS Intelligence, working with Visa Digital Processing Solutions, surveyed 500 heads of payments at US bank and non-bank issuers for The Issuer Risk Playbook. In that survey, 42% ranked fraud and disputes as their largest or second-largest platform-related operating cost, excluding employees. That is the number to hold onto.
Break a single dispute into its parts and the reason for the under-measurement becomes clear. There is the inquiry itself, the moment the customer contacts the bank. There is the call, which consumes contact-centre time whether or not it ends in a dispute. There is the refund, where the bank often credits the customer to close the matter. There is the chargeback fee once a formal dispute is filed. And there is a fourth cost that never shows up on a single case: scheme standing, pushing a bank's ratios up.
No one team sees the whole figure. The inquiry lands on the contact centre, the refund on the payments team, the fee on finance, the scheme standing on risk. Because the cost is spread across four teams and four budgets, no single owner ever adds it up, and a cost nobody totals is a cost nobody funds a fix for.
Chargeback prevention and deflection are different layers
There are two distinct layers in a bank's dispute stack, and they do different jobs at different points in time.
Scheme deflection is the later layer. A deflection programme intercepts a dispute once an inquiry has already been raised, sitting between the inquiry and the formal chargeback to catch it before it becomes a filed dispute. These programmes require merchant enrolment and scheme participation, they trigger only after an inquiry exists, and they bill per interaction, often alongside a refund. They work on the population of enrolled merchants and on the disputes that have already started forming.
Enrichment is the earlier layer. It runs on every transaction in the feed, not only on enrolled merchants. It needs no enrolment and no scheme participation, it works across markets, and it acts before an inquiry is ever raised, by making the transaction legible in the first place. The two are not rivals. Enrichment sits in front of deflection in the same stack: prevention reduces the volume of inquiries that reach the deflection layer at all, and deflection handles what still gets through. The difference that matters is coverage and timing. Deflection covers enrolled merchants after an inquiry; enrichment covers the whole feed before one. This is the argument the disputes and chargebacks proposition is built on.
What prevention looks like in production
A bank that answers "what was this?" inside the app removes the reason to call, and the pattern is already running in production. Revolut is a useful worked example of the earlier layer done well.
Follow it in the order a customer meets it. A real-time notification arrives the moment a card is used, so the charge is fresh in memory. Tapping into a transaction opens a merchant relationship view that shows every payment the customer has made at that merchant, which turns a stray line into a recognisable pattern. From there the customer can upload a receipt, add a note, or mark the charge as a subscription. And before any dispute route opens, the app prompts the customer to contact the merchant first, which resolves a large share of confusion without a chargeback ever forming.
There is one gap in that flow, however. Revolut prompts the customer to contact the merchant, but the app does not hand them the merchant's phone number or website. The customer is told to do something and then left to find the contact route themselves. That contact route, the verified merchant phone number and URL sitting on the transaction, is precisely a data point enrichment supplies. Recognition inside the app is the foundation here, and it starts with a merchant name and logo the customer trusts.
Measuring your own exposure
There is a single number that tells a bank whether any of this is worth funding: unrecognised-transaction inquiries as a share of total inquiries. A bank can pull it from its own contact-centre tagging without buying anything or talking to a vendor.
The diagnostic runs in a few steps. Take a quarter of contact-centre records. Isolate the inquiries where the customer's core question was some form of "what was this payment?". Express that as a share of total inquiries. Then pair it with a second metric: of those unrecognised-transaction inquiries, what share went on to become formally filed disputes. The first number sizes the confusion; the second sizes how much of it moves into cost.
Once you have the number, you can read it against its causes. It is made up of the same patterns from earlier: hidden merchants behind gateway descriptors, subscriptions the customer forgot, missing transaction context such as the wrong address or sub-brand, and the scheme standing that rising preventable ratios put at risk. Those are the four levers on the Tapix disputes page, and mapping your own figure onto them tells you which lever to pull first.
If your unrecognised-transaction share is high, the fix is not a bigger dispute team. It is a clearer transaction screen, and the data to build it.
See what a dispute really costs on the Tapix disputes page.
