Your chargeback rate is a composite metric. It counts disputes that represent third-party fraud, first-party friendly fraud, legitimate service failures, merchant processing errors, and customers who genuinely did not receive what they paid for. Lumping all of those into a single "chargeback" bucket and feeding the result into your fraud model as a fraud label is one of the more consequential data quality problems in payment risk, and it is widespread.
The reason it matters is not just operational tidiness. It goes to the core of how your model learns what fraud looks like. If your training labels mix five different dispute types together under a single fraud classification, your model is learning a corrupted signal. It will not converge on a coherent definition of fraud because the labeled examples do not share coherent properties.
The Chargeback Reason Code Taxonomy
Card network chargeback reason codes provide a starting taxonomy, but they are not a reliable fraud attribution mechanism on their own. Cardholders choose reason codes through a dispute flow that is optimized for consumer ease, not for accurate categorization. "Item not received" and "item not as described" are customer-service disputes, not fraud. "Unauthorized transaction" is the fraud code, but it is used both for genuine third-party fraud and for friendly fraud where the cardholder is misrepresenting an authorized purchase as unauthorized.
Visa's dispute resolution framework distinguishes between fraud chargebacks (where the cardholder claims they did not make the transaction), authorization chargebacks (where the merchant made a processing error), and service chargebacks (where the customer has a legitimate service complaint). These are conceptually distinct, but at the data ingestion level, many risk operations merge all dispute records into a single labeled fraud dataset without classifying by dispute type.
The practical consequence: if your platform has a meaningful volume of service failures (shipping delays, out-of-stock items, poor customer experience), those transactions will be misclassified as fraud in your training data. Your model will then learn to associate whatever features those transactions shared with fraud, even though they were not fraud. If service failures cluster around certain merchant categories, certain product types, or certain transaction sizes, your model will penalize those dimensions inappropriately.
How Mixed Labels Corrupt a Fraud Model
Consider a simplified example. Suppose your platform processes digital goods purchases that occasionally fail to deliver (a service error, not fraud) and also experiences compromised card transactions targeting high-value digital goods. Both types of transactions end in chargebacks with the "unauthorized transaction" reason code.
The service-failure chargebacks will cluster around a specific merchant ID, a specific product category, and possibly a specific time window when you had a delivery system issue. The compromised-card chargebacks will cluster around unusual device characteristics, velocity spikes, and behavioral anomalies.
If you train on both without separation, your model will learn a feature mix that is part service-failure pattern and part actual fraud pattern. When you deploy it, it will generate false positives on legitimate transactions that happen to look like the service-failure pattern, and it will miss fraud transactions that do not trigger the service-failure features it learned. The model is accurate according to its training data, but the training data was not an accurate representation of the concept you were trying to learn.
Separating Dispute Types: A Practical Approach
The most reliable separation method uses a combination of reason codes, merchant-side evidence, and customer communication records. The goal is to produce a three-way classification: confirmed fraud (third-party unauthorized use), suspected first-party fraud (authorized transaction with a misrepresented claim), and legitimate dispute (genuine service failure or merchant error).
For confirmed fraud, the signals are the absence of any merchant-side evidence of authorized engagement: no customer account login from a known device around the transaction time, no delivery confirmation to a known customer address, no historical pattern of similar purchases. If the card-network investigation confirms unauthorized use, that is your cleanest fraud label.
For legitimate disputes, the inverse applies: delivery confirmation exists, customer contacted support before filing the dispute, the transaction characteristics match the customer's established purchase history. These should be excluded from fraud training labels and tracked separately as service quality metrics.
Suspected first-party fraud sits between these and is the hardest to classify. The signals from the first-party fraud piece discussed in a separate post apply here: post-delivery timing on the dispute, account-level dispute rate versus platform median, and pre-dispute behavioral signals. Transactions in this category can be labeled with lower confidence as suspected first-party fraud and used in a separate model specifically trained for friendly fraud detection, or they can be held out of training entirely until you have enough behavioral signal to classify them more definitively.
The Merchant Relationship Dimension
Getting attribution right matters not just for model quality but for merchant relationships on marketplace and platform models. If you are a payment facilitator or marketplace, your merchant risk management depends on being able to distinguish fraud-driven disputes from service-driven disputes on a per-merchant basis.
A merchant with a high service-dispute rate has a customer experience problem. A merchant with a high fraud dispute rate has a product or channel that is being targeted. These require completely different interventions. Presenting a combined chargeback rate to your merchant risk team obscures both signals. You cannot tell whether a 2% chargeback rate reflects a merchant who is terrible at fulfillment or a merchant whose product category is being systematically targeted by fraud rings.
Separated dispute attribution allows you to have a direct conversation with the merchant about what is actually happening, which leads to better remediation. A merchant with a service-dispute problem needs operational support. A merchant with a fraud-dispute problem needs help understanding how their product is being used as an exit vehicle for fraudulent funds.
When Separation Is Not Possible
We are not suggesting that every team has the resources to manually audit dispute classifications at scale. At very high dispute volumes, full manual classification is not feasible. The practical middle ground is to apply rule-based pre-classification using the signals above, manually review the ambiguous middle tier, and use the resulting classified dataset for model training even if a fraction of it remains uncertain.
An imperfect separation is better than no separation. If you can correctly classify 70% of your disputes as confirmed fraud, suspected friendly fraud, or legitimate disputes, and hold the remaining 30% uncertain cases out of your primary training set, you have substantially improved your training data quality compared to treating all 100% as a uniform fraud label.
The most damaging scenario is not uncertain labels at the margin. It is confidently mixing large volumes of service disputes into your fraud labels without any separation attempt. That is the case where the training signal degradation is systematic and consistent, and it is also the most common pattern we see in fraud operations that have not explicitly addressed the attribution problem.
