Category: Fraud Typologies
Card-Not-Present (CNP) Fraud
Also known as: CNP Fraud, Card-not-present fraud, CNP fraud
Simply put
Card-not-present (CNP) fraud is a type of payment card fraud that happens when someone uses stolen or compromised card information to make an unauthorized purchase without the physical card being present. It typically occurs in remote transactions, such as those made online, by mail, or over the phone, where the card is not swiped, tapped, or inserted into a physical reader. Because the card itself does not need to be handled, these transactions tend to be more vulnerable to fraud than card-present ones.
Formal definition
CNP fraud is a category of card fraud carried out specifically against card-not-present transactions, meaning purchases completed remotely without processing a physical card through a card reader or terminal. Perpetrators use compromised cardholder data to authorize unauthorized remote purchases across channels such as e-commerce, mail order, and telephone order. CNP transactions are generally considered more exposed to fraud than card-present transactions because in-person authentication mechanisms tied to the physical card are absent; note that liability allocation and chargeback handling for such fraud are governed by card brand and network rules, which vary by region and change over time, and specific fraud rates depend on source, period, and methodology.
Why it matters
CNP fraud matters because it targets the transaction channels where in-person authentication tied to the physical card is absent. In remote purchases made online, by mail, or over the phone, the card is never swiped, tapped, or inserted, so the merchant cannot rely on the physical card or its chip to help verify that the legitimate cardholder is present. This makes CNP transactions generally more exposed to fraud than card-present transactions, and it shifts the burden of detecting unauthorized use onto data-driven and remote authentication controls rather than physical inspection.
Who it's relevant to
E-commerce and remote merchants
Merchants that accept online, mail-order, or telephone-order payments process card-not-present transactions and therefore carry direct exposure to CNP fraud. Because they cannot inspect a physical card, they depend on remote authentication and risk-screening controls, and they are affected by network chargeback rules that vary by region and change over time.
Fraud analysts and merchant risk teams
These teams design and tune the detection controls used to identify unauthorized remote purchases. They must balance catching fraud against incorrectly declining legitimate customers, since detection controls involve false-positive and false-negative trade-offs rather than certainty.
Acquirers and payment processors
Acquirers and processors handle the authorization and settlement of CNP transactions and are affected by how liability and chargebacks are allocated under card brand and network rules. Because those rules vary by region and change over time, they need to confirm current requirements rather than assume fixed terms.
Compliance officers
Those responsible for payment security programs need to understand CNP fraud as a distinct fraud category affecting remote channels, so that controls governing cardholder data and remote transaction risk are applied appropriately to the environments most exposed to it.
Inside CNP Fraud
Card-Not-Present Transaction
A payment transaction in which the card is not physically presented to the merchant, such as e-commerce, mail order, or telephone order (MOTO) purchases. Because the physical card and its EMV chip are not read, the controls that authenticate a card-present transaction are unavailable, shifting reliance to data-based verification.
CNP Fraud
Fraud committed in a card-not-present environment, typically using stolen or compromised cardholder data (such as PAN, expiration date, and cardholder name) to make unauthorized purchases. It is distinct from card-present fraud, which generally involves counterfeit cards or physical card theft used at a point of interaction.
Compromised Cardholder Data as Input
CNP fraud commonly relies on cardholder data obtained through breaches, phishing, or other means. Note that sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization even when encrypted, whereas some cardholder data may be stored under defined controls; the presence of stored data can affect the exposure available to attackers.
Authentication Controls Applicable to CNP
Controls such as 3-D Secure and, in applicable regions, strong customer authentication address CNP authentication risk. These operate differently from EMV chip authentication, which applies at a card-present point of interaction, and from multi-factor authentication generally. No single control eliminates CNP fraud.
Liability and Chargeback Context
Whether the merchant, issuer, or acquirer bears the cost of a fraudulent CNP transaction is governed by card brand and network rules, including any applicable liability shift provisions. These rules change over time and vary by region, so outcomes should be confirmed against current network rules.
Detection and Screening
Fraud screening tools and risk scoring are used to flag suspect CNP transactions. Such detection controls involve false-positive and false-negative trade-offs: overly strict rules may decline legitimate orders, while permissive rules may allow fraud through.
Common questions
Answers to the questions practitioners most commonly ask about CNP Fraud.
Does 3-D Secure eliminate card-not-present fraud?
No. 3-D Secure is intended to help reduce certain card-not-present fraud by adding a cardholder authentication step during checkout, and in many card brand programs it can shift chargeback liability for eligible transactions. However, it does not eliminate CNP fraud. It does not address all fraud vectors, such as account takeover where a legitimate credential is compromised, or first-party and friendly fraud where the genuine cardholder disputes a transaction they authorized. Authentication outcomes, exemptions, and liability treatment are governed by card brand and network rules that vary by region and change over time. 3-D Secure is best treated as one layer among several controls.
If the EMV chip liability shift covers card-present fraud, does it also protect card-not-present transactions?
No. EMV chip authentication addresses risks in card-present transactions where a physical chip card interacts with a terminal. It does not authenticate card-not-present transactions, where no chip interaction occurs. The card-present liability shift associated with EMV does not extend to CNP fraud. CNP transactions rely on different controls, such as 3-D Secure, verification of CVV2/CVC2/CAV2/CID values, address or fraud-scoring checks, and other risk signals. Liability and chargeback rules for CNP are governed separately by card brand and network rules, which vary by region.
Which data element should be verified during a CNP transaction, and can it be stored to speed up future checks?
Merchants commonly request the card verification value printed on the card (CVV2, CVC2, CAV2, or CID depending on the brand) to help confirm the customer has the physical card. This value is sensitive authentication data and must not be stored after authorization, even when encrypted, under PCI DSS. Storing it to speed future checks is not permitted. Other cardholder data such as the PAN may be stored only under the defined PCI DSS protection controls; confirm applicable requirements against the current published standard, since numbering and wording differ between versions.
How does tokenization affect handling of CNP transaction data and PCI DSS scope?
Tokenization replaces a PAN with a surrogate value that has no exploitable meaning outside the tokenization system, which differs from encryption (which transforms data reversibly with a key) and from truncation, masking, or hashing. For CNP flows such as recurring billing or card-on-file, tokenization can reduce the systems that store or process actual cardholder data, potentially reducing PCI DSS scope. The actual scope effect depends on implementation and validation, not on the label alone. Note that card verification values are sensitive authentication data and must not be retained after authorization regardless of tokenization.
How should teams balance fraud-detection scoring against customer friction in CNP checkout?
Detection controls such as fraud scoring and rules-based screening involve trade-offs between false positives (legitimate transactions declined or challenged) and false negatives (fraudulent transactions approved). Tightening thresholds or applying step-up authentication like 3-D Secure may reduce fraud but can increase declines and cart abandonment. Many teams calibrate risk-based decisions so that authentication or additional review is applied to higher-risk transactions rather than all traffic. The right balance depends on the merchant's risk appetite, transaction mix, and applicable card brand and network rules, which vary by region and change over time.
Which fraud types remain difficult to address with CNP transaction controls, and why?
Controls that authenticate the cardholder or verify card data are less effective against fraud that uses legitimate credentials or involves the genuine cardholder. Account takeover can pass authentication when an attacker controls the victim's credentials or device. First-party or friendly fraud and chargeback fraud involve the actual cardholder disputing a transaction, so authentication does not prevent the dispute. Synthetic identity fraud may establish accounts that appear legitimate. These cases typically require additional signals such as behavioral analytics, dispute handling, and identity verification, and no single control eliminates them.
Common misconceptions
Requiring the CVV2/CVC2/CID on a checkout page prevents CNP fraud.
Requesting the card verification value helps reduce certain CNP fraud by indicating the purchaser has the physical card data, but it does not prevent fraud where that value has also been compromised. It is not a guarantee, and it does not eliminate the need for other controls. Note also that this value is sensitive authentication data and must not be stored after authorization.
EMV chip adoption stops CNP fraud.
EMV chip authentication addresses card-present risk at the point of interaction and does not apply where the card is not physically read. Chip technology may influence where fraud migrates but does not by itself mitigate CNP fraud, which relies on data rather than the physical card.
3-D Secure eliminates CNP fraud and always shifts liability away from the merchant.
3-D Secure is intended to add authentication in the CNP flow and may reduce certain fraud, but it does not eliminate it. Any associated liability shift is governed by card brand and network rules that change over time and vary by region, so the effect on liability should be confirmed against current rules rather than assumed.
Best practices
Layer multiple controls for CNP transactions rather than relying on any single measure, combining authentication approaches such as 3-D Secure (and strong customer authentication where applicable) with risk-based screening.
Never store sensitive authentication data after authorization, including CAV2/CVC2/CVV2/CID, full track data, and PIN blocks, even in encrypted form, and apply defined controls to any stored cardholder data.
Reduce the data available to attackers by applying appropriate data-reduction techniques such as tokenization, truncation, or masking, recognizing that each transforms data differently and that any effect on PCI DSS scope depends on implementation and validation.
Tune fraud detection rules and scoring with explicit awareness of false-positive and false-negative trade-offs, monitoring both declined legitimate orders and missed fraud rather than optimizing for one alone.
Confirm liability shift and chargeback handling against the current card brand and network rules for each region in which you operate, since these rules change and vary.
Verify all applicable controls against the current published PCI DSS and any relevant separate standards, confirming requirement wording and numbering against the version in force rather than assuming a fixed reference.