Card fraud is a catch-all term for any unauthorized use of a payment card or card account, whether the card is used in person or online. The label works as a heading, but it does not tell you how the fraud happened or who ultimately pays, so operators break it into subtypes.
What is card fraud, in plain English?
Card fraud is the umbrella. It covers every way a payment card or card account gets used without the genuine cardholder's authorization, across every channel: a counterfeit card swiped at a store, a stolen number typed into a website, a hijacked account, or a cardholder who disputes a charge they actually made. If a card or card account is misused, it falls under card fraud.
The reason the term needs unpacking is that it says nothing about method or liability. Knowing a loss is card fraud does not tell you whether a chip was defeated, a number was stolen online, an account was taken over, or a customer is abusing the dispute system. Each of those has different signals, different controls, and different rules about who eats the loss.
So in practice teams treat card fraud as a category, not a root cause. The useful work is naming the specific subtype in every case, because that is what lines up trends with the right threat and points you at the control that actually would have stopped it.
The main subtypes of card fraud
Subtype | What happens | Who usually pays |
Counterfeit | A cloned or fake card is used in person, typically via magstripe. | Least chip-compliant party. |
Lost or stolen | A physical card is taken and used before it is blocked. | Issuer or merchant, by channel. |
Card-not-present | Stolen card details used online, in-app, or by phone. | Merchant, unless 3DS authenticated. |
Account takeover | A fraudster seizes the genuine cardholder's account. | Issuer or merchant, case by case. |
First-party | The real cardholder disputes a charge they made. | Merchant, via chargeback. |
Who is involved?
Who | Their role |
The fraudster | Uses the card or account without authorization, by whatever method the subtype defines. |
The cardholder | The genuine account owner, a victim in third-party cases and the actor in first-party cases. |
The merchant | Accepts the payment and often bears card-not-present and first-party losses. |
The issuer | Owns the card, decides authorizations, and carries loss in various card-present scenarios. |
What it looks like in practice
In practice
A fraud analyst pulls a month of losses tagged simply as card fraud and finds the number alarming but useless. When she splits it by subtype, the story changes: two thirds is card-not-present from a single card-testing campaign, a fifth is first-party disputes on a specific digital product, and the rest is scattered lost-or-stolen use.
Those three buckets need three different fixes: tighter checkout risk scoring and 3DS for the CNP losses, better delivery evidence and dispute handling for the first-party abuse, and faster card blocking for lost or stolen. Reported as one lump, the trend was invisible. Named by subtype, each control lined up with the threat it was meant to address.
Why the subtype matters
Because card fraud describes an outcome, not a cause, it is easy to track it as a single number and learn nothing. Two months can show the same total while being driven by completely different problems, and the controls that fix one do nothing for the other. Reporting at the umbrella level hides the trend and misdirects the response.
Naming the subtype in every case fixes that. It lets trends line up with the right threat, tells you which control was the weak point, and clarifies liability, which differs sharply: a merchant typically owns card-not-present and first-party losses, while card-present liability often falls on whichever party is least chip-compliant. Good case notes should always record the actual method, not just the label.
What to watch in the data
- Always tag the method. Record the specific subtype on every case, not just card fraud, or trends and controls will not line up.
- Channel split. Track card-present versus card-not-present separately, since their signals and liability rules differ completely.
- First-party share. Watch how much of your card fraud is actually the genuine cardholder disputing, which needs a different response.
- Subtype shifts. A stable total can hide a swing from one subtype to another; monitor the mix, not just the sum.
- Liability alignment. Confirm each case is coded so the loss and the responsible party match the true method.
Quick questions
Is card fraud a specific type of fraud?
No, it is a category. It covers any unauthorized use of a card or card account. The specific method, such as counterfeit, card-not-present, account takeover, or first-party, is what actually describes what happened.
Why not just report total card fraud?
Because a single total hides which threats are driving it. Different subtypes need different controls and carry different liability, so an umbrella number can look stable while the real problem shifts underneath it.
Which subtype is most common today?
In chip-enabled markets, card-not-present fraud dominates, because chip cards made in-person counterfeit fraud much harder and pushed criminals online. Card-present fraud still occurs but is far rarer where chips are in use.
Who pays for card fraud?
It depends on the subtype. Merchants generally absorb card-not-present and first-party losses, while card-present liability often lands on whichever party is least chip-compliant. That is why coding the method correctly matters.
Is first-party abuse really card fraud?
Yes, it falls under the umbrella even though the genuine cardholder is the actor. Because they made the purchase and then disputed it, it needs delivery and account evidence rather than the access controls used against third-party fraud.
Go deeper
- EMVCo ↗ — Maintains the EMV chip and 3-D Secure specifications for card payments.
- PCI Security Standards Council ↗ — Security standards for handling cardholder data, including PCI DSS.