Detecting friendly fraud and refund abuse

Friendly fraud is a genuine customer disputing a charge they actually made and received value for. Because the real cardholder authenticates, spends, and then files the chargeback, the transaction carries none of the signals a fraud model is built to catch. You separate abuse from real disputes by modeling behavior over time and how much value the account consumed, rather than scoring the payment in isolation.

The industry name is misleading. First-party fraud covers a wide band, from a customer who forgot a subscription and disputes it in irritation, to someone running a deliberate refund-abuse operation across a dozen accounts. The controls you build have to tell those apart, and they have to do it without turning your dispute queue into a machine that denies legitimate complaints. That second failure is the expensive one. Card networks give cardholders strong rights, and a merchant that reflexively fights valid disputes accumulates representment losses and drifts toward the networks’ excessive-chargeback monitoring programs faster than it recovers revenue.

Why your fraud stack is blind to it

A transaction-fraud model is trained on the moment of payment. It looks at the card, the device, the IP, the velocity, the mismatch between billing and shipping. Those features are informative when a stolen card is being tested. They are close to useless against friendly fraud, because the person filing the dispute is the person who owns the card. Authentication passed, the device is registered to them, and the login came from the usual address.

So the transaction scores clean, clears, and delivers value. Weeks later the chargeback arrives. By then the point-in-time features that your fraud model relied on have expired, and the signal you actually needed lives somewhere else entirely: in the account’s history, in how the product was consumed, and in the pattern of prior disputes across the customer base.

This is why bolting a friendly-fraud rule onto an existing authorization model rarely works. You are asking a feature set built for one problem to answer a different one. The detection has to move downstream, to the dispute and the account, and it has to reason over a window of behavior rather than a single event.

Model the account and how value was consumed

The signal that distinguishes abuse sits in three places, and the useful features come from joining them.

• Consumption of value. Was the digital good downloaded, the streaming content watched, the API quota burned, the flight flown? A dispute for goods-not-received against an account that consumed the full value is a different object from one where delivery genuinely failed. This requires clean lineage from the order to the fulfillment and usage systems, which is often where the plumbing is worst.
• Dispute history across the entity. One chargeback is noise. A pattern of disputes filed just after value is consumed, repeated across time, is the strongest single indicator you have. This depends on entity resolution: linking accounts, cards, devices, and addresses so that a customer opening a fresh account with a new card does not reset their history to zero.
• Timing and sequencing. When in the billing or usage cycle does the dispute land? Abuse clusters at predictable points, such as right after a free trial converts, or immediately following the last usable delivery of a service. Sequence features tend to carry more information than any static snapshot.

A concrete failure mode to guard against here is lookahead. It is easy to build a feature like “customer’s lifetime dispute rate” and accidentally compute it using disputes that occurred after the transaction you are scoring. That leaks the future into the training set, your offline metrics look excellent, and the model collapses in production. Every feature has to be computed as of the transaction timestamp, reconstructed from a feature store that respects point-in-time correctness. If you cannot reproduce the exact feature values the model would have seen on a given past date, you cannot trust the eval.

Labels are the hard part

There is no clean ground truth for friendly fraud. A won representment tells you the merchant had evidence and prevailed, which is a reasonable positive label for abuse. A lost one is ambiguous, because merchants lose valid cases on process and technicalities all the time. The large middle of disputes never gets adjudicated cleanly at all.

The practical approach is to be honest about label quality:

• Treat recovered chargebacks and representment wins as strong abuse labels, and confirmed delivery failures or duplicate charges as strong legitimate labels.
• Leave the ambiguous middle unlabeled. Forcing it into a binary class to make the training set larger poisons the model with your own guesses.
• Maintain a human-reviewed eval set that mirrors the real dispute distribution, refreshed on a schedule, so you are measuring against reality rather than against the easy cases.

Because dispute behavior shifts with policy changes, promotions, and macro conditions, drift is constant. A model trained on last year’s refund policy will misread this quarter’s disputes after you change the returns window. Monitor score distributions by segment and re-check the label mix regularly, not only when someone notices the numbers moving.

Decide with a false-positive budget

Every run of this system ends in a decision about a specific dispute or refund request, not a score you file away. Make that decision under an explicit tolerance for how often you are willing to be wrong against a good customer, and set the tolerance per segment. A high-value long-tenured account should face a far higher bar for a refund denial than a two-day-old account with three prior chargebacks.

High-confidence abuse cases can route to automated representment, moving through straight-through processing with the evidence package assembled from the usage and fulfillment lineage you already joined for features. Everything ambiguous goes to human review with that evidence attached, so the reviewer starts from the consumption record rather than a bare transaction line. Every decision, automated or manual, writes to an audit trail that records the features, the score, the threshold, and the reason. When a cardholder escalates or a regulator asks why a refund was refused, that record is what defends the decision. Build it in from the start, because reconstructing it after the fact is not possible.