Card fraud typologies — the five reportable types
Card fraud has the most granular taxonomy in EU supervisory reporting, and each of its five types names a different point in the card lifecycle. Under the EBA Guidelines on fraud reporting under Article 96(6) of PSD2, fraudulent card payments falling under issuance of a payment order by a fraudster are broken into lost or stolen card, card not received, counterfeit card, card details theft and other — and the whole breakdown is reported twice, once for strong-customer-authenticated transactions and once for non-authenticated ones.
1. The five types, and where each attack happens
| Type | Point of compromise | What a rise in it indicates |
|---|---|---|
| Lost or stolen card | After the card reached the cardholder | Physical-world exposure; the effectiveness of blocking and reporting channels |
| Card not received | Between issuance and delivery | A distribution problem, not a customer one — interception in the delivery chain or at the address |
| Counterfeit card | Reproduction of a card from captured data | Exposure at acceptance points where the technology allows it |
| Card details theft | The data, not the card | Phishing, breaches, compromised acceptance — the dominant remote-channel path |
| Other | — | A large “other” balance is usually a classification failure rather than a novel attack |
2. The authentication split
The guidelines require the fraudulent-card-payment breakdown to be reported separately for transactions authenticated via strong customer authentication and those authenticated via non-strong customer authentication. This is the most analytically useful cut in the whole framework, and it answers two different questions:
- Fraud on non-SCA transactions is, in large part, a question about exemptions — which ones are being applied, at what thresholds, and whether the risk analysis behind them is calibrated to observed outcomes.
- Fraud on SCA-authenticated transactions is a harder question. Authentication worked, and fraud happened anyway. That points at authentication compromise, at delegated or inherited authentication in the flow, or at the payer having been manipulated into authenticating.
The taxonomy anticipates the last of these: manipulation of the payer to make a card payment appears as its own line under both branches. A firm seeing that line grow under SCA has a social-engineering problem, not an authentication problem, and buying more authentication will not move it.
3. Who reports, in a four-party chain
Card payments involve more parties than most other payment types, and the guidelines allocate reporting to avoid counting the same fraud twice. The general framework requires providers — including the payment instrument issuer where applicable — to report transactions that have been initiated and executed, including acquired where applicable. In practice that means issuing and acquiring populations are reported on their own terms rather than netted, and reconciling your figures against a scheme’s or a partner’s without accounting for that will produce differences that are structural rather than erroneous.
4. Using the taxonomy as a control, not just a return
Three uses repay the mapping effort:
- Track the “other” bucket as a data-quality metric. It should be small and shrinking. Growth in “other” almost always means dispute or chargeback reason codes are being mapped mechanically rather than analysed.
- Compare the two authentication branches as a ratio, over time. The absolute numbers move with volume; the ratio moves with control effectiveness.
- Watch “card not received” against issuance volume. It is a low-frequency type whose rate is a direct measure of your delivery-chain integrity.
FAQ
What is the difference between counterfeit card and card details theft?
Counterfeit involves reproducing a usable card from captured data; card details theft covers fraud committed using the data itself, which is the dominant remote-channel path.
Why is fraud reported on strongly authenticated transactions?
Because it happens — through authentication compromise, through flows where authentication is delegated or inherited, and through manipulation of the payer, which has its own line in the taxonomy under the SCA branch.
Our “other” category is large. Is that a problem?
Usually a classification problem rather than a fraud one. It generally means reason codes are being mapped mechanically instead of assessed against the five defined types.
Related: The supervisory fraud taxonomy · SCA exemptions · Unauthorised transactions
