When the cardholder is the customer.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

A Lagoon Casino player deposits on a Friday, plays through the weekend, and on Tuesday the deposit comes back as a 10.4 dispute: card-absent fraud, cardholder did not authorise. The account logged in on Monday from the same phone. Tomas wants to close the account. Ines wants to know what the Monday login proves, and what it merely suggests.

What is actually being decided.

Two things, and they should be kept apart. The first is the dispute: reply or concede, and on what evidence. The second is the account: what, if anything, to do with a customer whose card has just disputed a transaction their account appears to have used. The cardholder carries the claim and, if it is false, the consequences of a false claim. The issuer carries the classification; as Visa’s dispute-resolution guidance sets out, the issuer raises the dispute and rules on the reply, and nothing in that lifecycle requires the issuer to have tested the claim before raising it. The merchant carries the loss, the fee, the analyst hour, and the risk of either error: treating a victim as a liar, or treating a liar as a victim.

First-party misuse is our term for a dispute raised by, or on behalf of, the person who actually made the purchase. The industry's older word is "friendly fraud". We avoid it because it is neither friendly nor, in many cases, fraud in the sense the cardholder would recognise. A player who regrets a weekend's losses, a subscriber who forgot a renewal, a parent whose child used the saved card: the issuer may code all three as 10.4, and the merchant's reply has to start from the code, not from a theory of motive.

The classification is not the finding.

The reason code tells you what the cardholder said to the issuer, filtered through the issuer's menu. It does not tell you what happened. Our reading, from Four families of dispute, is that the fraud family asks "who", and the honest answer on the day the dispute arrives is usually "we do not know yet".

The evidence that moves the answer is almost all behavioural, and almost all of it sits after the disputed transaction. A stolen card used on a casino account tends to be followed by silence from the account's real owner, or by a password reset, or by a support contact. A deposit the account holder made themselves tends to be followed by the account holder carrying on: logging in from the usual device, playing the balance, requesting a withdrawal to a bank account in the registered name. Neither pattern is proof. Both are evidence.

A hundred and twenty disputes, four observations.

In this illustration, Lagoon receives 120 disputes coded 10.4 on card deposits in one month. For each, Tomas looks at what the account did in the seven days after the disputed deposit, before the dispute arrived. He records four observations per account and counts them:

• 84 accounts logged in afterwards from the same device fingerprint that made the deposit.
• 66 accounts played through most of the disputed balance.
• 30 accounts requested a withdrawal to a bank account in the registered name.
• 12 accounts had at least one prior dispute on a different card.

Those are four counts, not four groups; an account can appear in several. The first is 84 / 120 = 70 per cent. Observation: in seven of ten disputed accounts, the device that deposited came back and used the account. Inference, held loosely: in those accounts, the person who deposited is the person who holds the account, which makes "I did not authorise this" a claim about the card rather than about the login.

What the inference does not cover: whether the account holder is the cardholder. A household member with access to both the phone and the card would match every one of the four observations. So would an account that was taken over before the deposit, if the attacker kept using it; the signals for that are in Three layers of a takeover. The 30 withdrawal requests to a registered-name bank account are the strongest of the four, because they tie the account to a verified identity rather than to a device, and they are the ones Tomas should look at first.

The remaining 36 accounts are 30% of the queue, not one third. A missing return visit warrants investigation, but theft remains possible in both groups: a compromised or shared device can recur. Do not decide motive or account action from device recurrence alone.

Two decisions, two cost tables.

For a CE3.0 response, confirm the current pathway, eligible prior transactions, date anchor and required matching elements with the acquirer. A familiar account alone is not the evidence test. Compelling evidence in practice explains how to keep those checks separate.

For the account, the cost table has the two errors in it. Close an account that was genuinely taken over, and a victim loses access while the attacker has already left. Leave open an account whose holder has learned that disputes may be accepted without adequate review, and the next deposit arrives next week. the action that survives both errors is scoped and reversible: consider proportionate verification or a limited review under the applicable authority, with a named owner and prompt reassessment. Any delay affects legitimate customers and needs a justified duration. It interrupts the misuse for as long as it takes to look properly. Neither is free, and the note should say which cost was chosen and why. Volume 01's false positive case is the same trade from the other side.

A failure mode to watch.

Deciding the motive from the reason code and the merchant's own frustration, then gathering evidence to support it. The 10.4 arrives, the analyst sees the Monday login, the account is closed and the dispute is conceded in the same minute. Two decisions, one piece of evidence, no record of the alternative. Three months later the same cardholder is a VAMP event in a month that matters, and nobody can reconstruct what was known at the time. The second mistake is the mirror: conceding every 10.4 because replying is work, and never learning which cases involved theft and which remained unresolved.

A way to work it.

1. On arrival, do not act on the account. Record the dispute, the code and the date.
2. Pull the seven days of account activity after the disputed transaction. Note device, logins, play or usage, withdrawals, support contacts.
3. Write the observations as observations. Then write the inference separately, with the alternative explanation beside it.
4. Test the dispute reply against the countable standard that applies. If it cannot be met, concede early and spend the hour elsewhere.
5. Choose the account action from the scoped, reversible end of the list: withdrawal hold, method limit, re-verification. Name an owner and a review date.
6. Once a month, count how many disputed accounts fell into the "device returned" group and how many did not. If the split moves, ask why before the acquirer does.

Take it to the desk.

What would we need to see, after a disputed transaction, to be confident the cardholder was the customer, and how often do we actually look?

Try it: Card deposits, minimal play, withdrawal elsewhere and, from Volume 01, False positive. Look up: first-party misuse, compelling evidence, dispute.

Fictional scenario. Synthetic data. No real customer records.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.