Card-Not-Present Fraud

Card-Not-Present Fraud: Why Remote Card Payments Create a Different Fraud Problem The phrase card-not-present fraud contains an easy category error. “Card-not-present” describes how a card payment takes place. It does not tell you whether the payment is fraudulent. A legitimate customer buying online with a card saved to an account is making a card-not-present transaction. So is a customer entering card details at an ecommerce checkout. Depending on the payment context, mail-order, telephone, card-on-file and other remote card transactions can also be classified as CNP. Visa describes CNP as card payments made without the face-to-face presentation used in a conventional card-present transaction. Fraud appears when someone abuses that remote-payment environment. That may involve: * stolen card credentials; * a compromised customer account containing a stored card; * attempts to validate payment credentials; * automated payment attacks; * other unauthorized use of card information. Those are different fraud mechanisms. The practical consequence is important: CNP is a transaction environment. The fraud question is what happened inside it. Treating every ecommerce payment as inherently suspicious creates unnecessary friction for legitimate customers. Treating every fraudulent remote-card payment as the same attack makes detection less precise. The better merchant approach is to map where trust is being established—and where it can fail. What is a card-not-present transaction?

A card-not-present transaction is broadly a card payment in which the card is not presented through the conventional face-to-face card-payment environment. Visa's current materials include internet purchases, mail order, telephone order, guest checkout, virtual-card use and card-on-file payments among CNP examples. That means: CNP transaction ≠ fraudulent transaction. The distinction is foundational to this article and to the broader fraud taxonomy in the editorial brief. A merchant should therefore avoid using CNP as though it were itself a risk decision. Instead ask: Who is attempting the payment? Which credential or account is being used? How did the actor obtain access? What evidence supports legitimacy or elevated risk? What happens after authorization? Those questions reveal the actual fraud mechanism. Why remote card payments create a different trust problem A conventional card-present payment can incorporate information derived from the physical payment environment and card-present technology. A remote transaction has to establish confidence through a different collection of evidence. The merchant may see: Customer or session → device/network context → customer account → payment credential → authentication → authorization → fulfillment → post-payment behavior. The physical presence of a card at a traditional point of sale is not the central evidence source.

Instead, the merchant, payment provider, card network and issuer may need to evaluate data about the transaction, device, account, credential and authentication flow. EMVCo describes EMV 3-D Secure as a mechanism through which merchant and issuer systems exchange transaction, payment-method and device information to support consumer authentication in card-not-present ecommerce. That leads to the article's central framework. The CNP Fraud Attack Surface Map Map a remote card payment across seven stages: 1. Customer and device ↓ 2. Customer account ↓ 3. Card credential ↓ 4. Authentication ↓ 5. Authorization ↓ 6. Fulfillment ↓ 7. Dispute and post-payment evidence Fraud can enter at several points. The attack type depends on what has been compromised and what the actor is trying to achieve.

Stage 1: Customer and device Before a card is submitted, a merchant may already have contextual evidence about the session. Depending on the merchant's systems and lawful data availability, signals might include: * device consistency; * IP or network characteristics; * location anomalies; * account/session history; * unusual interaction patterns; * repeated identities or accounts; * unusually high request velocity. These are signals, not proof. A customer can legitimately: * travel; * use a new device; * use a shared household network; * use a VPN; * switch browsers; * check out from an unfamiliar location. The brief explicitly warns against turning device or network anomalies into universal blocking rules because legitimate behavior can produce the same patterns. A new device therefore means: “Investigate this in context.” It does not mean: “This customer is fraudulent.” Signal, rule and decision are different objects This distinction should remain explicit throughout the article. Signal An observed characteristic. Example: new device Rule or model Logic combining one or more signals. Decision A merchant or provider action such as: approve challenge review limit or: decline. The editorial brief specifically prohibits converting an isolated signal directly into a universal blocking decision.

Stage 2: Customer account A CNP payment can occur inside a legitimate merchant account. That does not mean the legitimate customer is operating it. If an attacker has compromised the account, the resulting payment may superficially look familiar: * known customer; * established account; * stored payment credential; * prior purchase history. But the compromised object is now the customer account, not necessarily the card credential itself. This is account takeover overlap. Potential contextual signals can include: * unusual login geography; * new device; * recent password reset; * address changes; * profile changes; * newly added payment methods; * unusual purchase behavior. Again, none proves account takeover by itself. The brief specifically requires merchants to evaluate combinations of account signals against the customer's normal behavior rather than treating a single event as conclusive. CNP fraud versus account takeover The distinction is: CNP Describes the remote card-payment environment. Account takeover Describes how the attacker obtained trusted access. An account-takeover transaction can result in CNP card fraud if the compromised account is used to make an unauthorized remote card payment. But account takeover can also target: * loyalty value; * balances; * personal information; * subscription access; * shipping details; * marketplace payout settings. So the dedicated Account Takeover Fraud article should own account compromise.

This article should show where ATO enters the remote-card-payment attack surface.

Stage 3: Card credential Another path does not require compromising the customer's merchant account at all. An actor may possess valid card credentials belonging to someone else and attempt to use them for a remote purchase. That is stolen-card fraud. The distinction matters: Stolen-card fraud The compromised object is the payment credential. Account takeover The compromised object is the customer account. Card-not-present fraud The remote environment in which either mechanism may result in an unauthorized card payment. The Payment Fraud Fundamentals brief deliberately assigns stolen-card fraud its own article because it concerns unauthorized use of valid credentials belonging to another person. A merchant diagnosing CNP fraud should therefore ask: Was the card credential compromised? or: Was the account holding the card compromised? Those lead to different evidence and potentially different controls. Card verification data is one signal—not proof of identity Remote merchants may request card-verification values as part of CNP payment processing. PCI SSC notes that card verification codes are commonly used in ecommerce and other CNP transactions to help verify possession of card information, but it also classifies these values as sensitive authentication data that cannot be retained after authorization under PCI DSS requirements. The larger fraud point is: Correct payment data does not by itself prove that the person entering it is the legitimate cardholder.

Fraud analysis needs context around the credential.

Stage 4: Authentication Authentication answers a different question from authorization. That distinction is frequently lost in ecommerce fraud reporting. Authentication Seeks additional confidence about the person initiating or participating in the transaction. Authorization Is the issuer's decision about whether the payment transaction should be approved. EMVCo explains that EMV 3DS enables merchant and issuer systems to exchange information used to authenticate the consumer in an ecommerce transaction. Visa similarly describes its EMV 3DS-based Visa Secure program as an identity-verification layer used before authorization. Therefore: Authentication failure ≠ confirmed fraud. And: Successful authentication ≠ proof that every subsequent merchant event is risk-free. Technical problems, incomplete challenges or other legitimate conditions can affect authentication. EMVCo's current documentation explicitly recognizes cases where authentication challenges may be unavailable or unsuccessful for reasons such as technical limitations or connectivity problems. This distinction protects merchants from a dangerous shortcut: “Authentication did not complete, therefore the customer is fraudulent.” That is not a defensible conclusion. Authentication should reduce uncertainty without creating unnecessary friction The merchant objective is not maximum authentication friction. It is better differentiation between legitimate and unauthorized activity.

EMVCo describes the design objective of EMV 3DS as supporting CNP fraud prevention while allowing issuers to use transaction, payment and device information to determine when additional consumer interaction is necessary. That balance matters because every additional challenge has a customer-experience consequence. The brief's wider principle is therefore: Fraud reduction should be evaluated together with legitimate approval and customer access—not as an isolated minimization exercise.

Stage 5: Authorization The card issuer may approve or decline the transaction. Neither outcome gives the merchant a perfect fraud label. An issuer decline can result from multiple causes. The editorial brief explicitly warns that issuer declines may reflect: * fraud concerns; * insufficient funds; * account restrictions; * technical conditions; * authentication requirements. Therefore: issuer decline ≠ confirmed fraud. Likewise, authorization approval does not mean the merchant should stop evaluating fulfillment or post-payment evidence. The issuer and merchant see different information. A merchant may know: * customer history; * account behavior; * product characteristics; * fulfillment destination; * previous abuse patterns. The issuer may have different cardholder and account information. Remote-payment risk therefore involves multiple participants rather than one omniscient fraud decision.

Where card testing overlaps with CNP fraud Card testing is another neighboring concept that should not be collapsed into ordinary fraudulent purchasing. Its objective is commonly credential validation. A merchant may see patterns such as: * repeated payment attempts; * multiple credentials; * unusual velocity; * clusters of declines; * automation indicators. The brief assigns the deeper mechanics to the dedicated Card Testing Attacks article. For this page, the critical distinction is: Fraudulent CNP purchase The actor is attempting to obtain merchant value through an unauthorized remote transaction. Card testing The payment endpoint may instead be abused to determine whether credentials appear usable. Those activities can overlap, but the attacker's immediate objective is different. That difference affects: * detection; * merchant loss; * useful metrics. Transaction fraud rate can miss an attack A card-testing event may generate large numbers of suspicious attempts while relatively few completed purchases occur. If the merchant watches only: confirmed fraudulent successful transactions ÷ completed transactions the attack can look insignificant. The brief therefore recommends separate operational indicators for automated/testing activity, such as suspicious attempt volume and abnormal attempt patterns, while cautioning that failed attempts should not automatically be labeled fraudulent.

Where bots fit A bot is not itself a fraud category. Automation is an attack mechanism. Bots can potentially automate: * card testing; * account creation; * login activity; * checkout; * promotion abuse; * other payment-endpoint interactions. That is why the cluster gives Bot Payment Attacks its own article: its intellectual territory is what automation changes—scale, speed, repetition and distribution—not one single fraud objective. For CNP fraud, the defensive takeaway is simple: Separate what the attacker wants from how the attacker scales it.

Stage 6: Fulfillment changes the merchant's exposure The payment decision is not necessarily the last chance to reduce loss. What happens after authorization matters. For a physical merchant, value may not leave the business until merchandise ships. For travel, service delivery may occur later. For some digital-goods businesses, value can be delivered nearly immediately and may be difficult to recover. The brief makes this a specific fraud-economics distinction: the less recoverable the delivered value, the more consequential pre-fulfillment risk confidence may become. That means identical risk signals can justify different operational responses depending on fulfillment. An ambiguous high-value order awaiting physical shipment gives the merchant different options from an instantly consumed digital product. Fraud controls should reflect the merchant's actual loss mechanism.

Stage 7: Disputes provide evidence—but not the definition A later fraud-related chargeback can provide valuable information. But chargeback data is delayed and incomplete. The editorial brief highlights two reasons: Fraud blocked before completion never becomes a chargeback. And: some chargebacks are not fraud. A dispute can arise from: * unauthorized payment; * service/product disagreement; * processing error; * first-party dispute behavior; * other causes. Therefore: Chargeback rate is not CNP fraud rate. A merchant should maintain separate labels for: confirmed unauthorized activity suspected fraud risk-engine decisions chargebacks customer reports merchant policy abuse. These labels have different evidentiary quality. The brief specifically warns against treating the risk engine's own decline decisions as ground-truth fraud labels.

The complete CNP Fraud Attack Surface Map Stage What can be targeted or abused? Possible merchant evidence Important adjacent concept Customer/device Session or device context Device consistency, network context, behavior Bot activity Account Existing merchant account Login and profile changes, account history Account takeover Card credential Card information Payment-data consistency, credential history where available Stolen-card fraud Authentication Proof of cardholder/customer legitimacy Authentication result and context 3DS/authentication Authorization Payment approval attempt Issuer result, payment context Declines Fulfillment Merchant goods/service Destination, delivery/use evidence Fraud loss Dispute Post-payment transaction outcome Cardholder report, dispute evidence Chargeback/friendly fraud No single row proves fraud. The value comes from understanding relationships across the lifecycle. CNP signals should be combined, not treated as verdicts A useful merchant risk model can potentially consider several types of evidence. Device and network context Potential signals: * unfamiliar device; * unusual network characteristics; * location inconsistency; * abnormal session behavior. Account context Potential signals: * recent account changes; * password-reset activity; * address changes; * account age; * purchasing-history changes. Payment context Potential signals: * authorization result; * authentication outcome; * payment-country relationships; * unusual retry behavior; * payment velocity. Order and fulfillment context

Potential signals: * unusual order value; * unusual product mix; * new fulfillment destination; * immediate or irreversible delivery. The brief is explicit that these are risk indicators rather than proof, and that international commerce, shared devices, VPNs, travel and ordinary behavioral changes can produce legitimate anomalies. A mismatch is a question, not an accusation Suppose billing country and current network location differ. That can occur because of fraud. It can also occur because: * the customer is traveling; * the customer relocated; * the card is issued in another country; * a corporate card is used; * network location data is imperfect. This is why CNP risk works better as evidence accumulation than as a collection of absolute rules. The merchant should ask: How unusual is this combination for the relevant customer or cohort? rather than: Did one field fail to match?

What CNP fraud costs a merchant The immediate unauthorized payment is only one potential loss. Depending on the business, CNP fraud can produce: Payment loss Unauthorized transaction or subsequent reversal. Fulfillment loss Goods, services or digital value already delivered. Fee loss Relevant processing or dispute costs. Operating cost Risk review, customer support and investigation. Growth cost Legitimate customers rejected or subjected to unnecessary friction. The broader Payment Fraud Fundamentals framework deliberately treats fraud as a growth problem because prevention can itself reduce approvals and conversion when poorly calibrated. The separate How Fraud Affects Net Revenue article should own the full financial model. Here the economic principle is simpler: A CNP fraud control is not successful merely because it blocks more transactions. It must block economically harmful activity without blocking too much legitimate demand. The false-positive problem A false positive occurs when legitimate activity is treated as fraudulent or unacceptable. Possible consequences include: * payment decline; * account restriction; * additional authentication; * manual review; * checkout delay; * customer abandonment. The brief explicitly requires false-positive opportunity cost to remain separate unless the merchant has a defensible way to measure it. That is important. Do not publish claims such as: “False declines cost us $X million” by simply multiplying declined orders by average order value.

Some customers would not have completed. Some declines were legitimate. Some customers retry successfully. Some use another method. Measurement requires a comparable cohort or another defensible causal method.

High-level controls for CNP fraud This fundamentals article should explain control layers without becoming an attacker-facing operating manual. Potential defensive layers include: Account security Reduce unauthorized access to legitimate customer accounts. Device, network and behavioral signals Add context to remote activity. Payment signals Use transaction and authorization information available through the merchant's provider or payment stack. Authentication Use appropriate cardholder/customer authentication where applicable. EMVCo states that EMV 3DS is designed to help issuers and merchants authenticate consumers and reduce CNP fraud while managing checkout friction. Velocity and anomaly controls Identify potentially abnormal concentrations of payment or account activity without assuming that a universal threshold works for every merchant. Review or step-up Apply additional scrutiny where risk and transaction economics justify it. Fulfillment controls Where operationally possible, use the gap between payment and irreversible fulfillment to investigate ambiguous high-risk transactions. Post-payment monitoring Use confirmed fraud, customer reports and disputes to improve understanding of attack patterns. The brief explicitly advises against implying that every merchant requires every defensive layer.

3-D Secure is a control, not a definition of CNP fraud EMV 3DS deserves particular treatment because it is so closely associated with remote-card security. EMVCo describes the protocol as supporting authentication through data exchange among the merchant and issuer environment, with frictionless and challenge-based flows among the supported approaches. But 3DS does not make every other fraud mechanism disappear. It does not by itself address every case of: * account abuse; * promotion abuse; * refund abuse; * friendly fraud; * marketplace abuse. Some of those may involve a genuine customer or a genuine account holder. This is why the fraud mechanism must be identified before selecting a control. Current European evidence illustrates the authentication effect—but should be scoped carefully The EBA and ECB's 2025 payment-fraud report found materially higher card-payment fraud where the payment recipient was outside the EEA, a context in which European strong-customer-authentication requirements do not necessarily apply in the same way. The agencies reported card-payment fraud in that comparison as 17 times higher outside the EEA. That does not establish a universal merchant CNP fraud multiplier. It is market-specific evidence that authentication environment and geography can materially affect observed card-fraud outcomes.

How to measure CNP fraud Start by defining the fraud label. Confirmed CNP fraud rate by count Confirmed fraudulent CNP transactions ÷ relevant CNP transactions Confirmed CNP fraud rate by value Confirmed fraudulent CNP value ÷ relevant CNP transaction value Do not compare one with the other. The brief explicitly requires every fraud statistic to identify its fraud definition, count/value basis, market, channel, payment method, period and denominator. Also monitor the attack surface Useful operational metrics can include: CNP authorization rate CNP completed-payment rate authentication outcomes manual-review rate confirmed unauthorized loss suspicious attempt volume payment-attempt velocity anomalies fraud-related dispute volume legitimate-customer approval false-positive rate where defensibly measurable support complaints related to risk controls fulfillment stopped before loss Not every merchant needs every metric. Choose the ones that reveal the fraud mechanism being managed.

Fraud rate is not financial loss rate Suppose fraudulent activity is identified but the merchant stops fulfillment before value leaves the business. That event may count in a fraud measure. Its economic loss can be very different from a fraudulent transaction in which: * goods shipped; * service was consumed; * transaction was reversed; * additional dispute costs followed. The brief therefore recommends distinguishing: Gross fraud-associated loss from: Net fraud loss after recoveries and keeping false-positive opportunity cost separate unless measured reliably. This is another reason not to optimize only the fraud percentage.

Different merchants face different CNP economics Digital goods and gaming Immediate fulfillment can reduce the merchant's opportunity to intervene after authorization. Relevant overlaps can include: * stolen credentials; * account takeover; * card testing; * automated attacks. Travel High transaction values and delayed fulfillment create a different combination of payment, authentication and post-payment evidence. Subscription businesses Stored credentials and recurring relationships can connect CNP payments with: * account takeover; * stolen-card signup; * recurring disputes; * other subscription-specific abuse. Retail ecommerce Physical delivery creates fulfillment and destination evidence not available to every digital merchant. The brief explicitly recommends using industry context only where it changes the causal fraud mechanics rather than applying one universal fraud model.

The merchant decision framework When CNP risk rises, do not begin by asking: “Which transactions should we block?” Use five questions instead. 1. What was compromised? Card credential? Merchant account? Identity? Nothing confirmed yet? 2. Where did the suspicious behavior enter? Session/device? Login? Payment credential? Authentication? Payment attempt? Fulfillment? Post-payment dispute? 3. What evidence do we actually have? Distinguish: signal from: suspicion from: confirmed fraud. 4. What merchant value is exposed? Is fulfillment: immediate delayed reversible or: irreversible? 5. What legitimate behavior could the control block? Measure: fraud effect together with: legitimate approval completion friction and: operating cost. That sequence keeps CNP fraud analysis tied to the actual attack rather than the channel label. The essential distinction Card-not-present payments do create a different fraud problem because remote commerce has to establish trust without traditional physical card presentation. But the absence of a physical card is not itself the fraud. The merchant still needs to determine whether the actual mechanism is: stolen-card misuse account takeover credential validation automation or another form of fraud or abuse. That classification tells the merchant: * which evidence matters; * which metric belongs on the dashboard; * which control is relevant; * which legitimate customers the control could affect. A mature CNP risk program therefore does not ask whether remote transactions are suspicious. It asks:

What exactly is being abused inside the remote-payment journey—and how confidently can we distinguish that behavior from a legitimate customer? Legal, privacy and security note This article provides general information and does not constitute legal, regulatory, privacy, security or compliance advice. Card authentication requirements, fraud controls, available payment data and privacy obligations vary by jurisdiction, network, merchant configuration and provider. Merchants should verify applicable requirements with qualified advisers, card networks, acquirers, payment providers and fraud specialists.

I’ve built this as Article 3 of the Payment Fraud Fundamentals cluster, whose larger merchant problem is FRAUD IS BLOCKING GROWTH. The strongest SEO differentiator is the brief’s thesis that card-not-present describes the payment environment, not the fraud mechanism. That lets the page rank for broad CNP queries without cannibalizing the dedicated stolen-card, account-takeover, card-testing, bot, or friendly-fraud articles. The largest SEO improvement here is the taxonomy discipline. Many pages answering “what is CNP fraud?” collapse CNP, stolen cards, account takeover and card testing into one generic fraud definition. This version instead establishes CNP as the remote-payment container and then explains how those separate mechanisms can enter it. That gives the page broad topical authority while preserving distinct search territory for the next dedicated articles.

Those public sources support a restrained positioning statement:

* eliminates CNP fraud; * achieves a particular fraud-reduction percentage; * guarantees a particular false-positive rate; * detects every account takeover; * prevents every card-testing attack; * guarantees higher legitimate approval.

CNP Fraud Attack Surface Map Customer / device Questions * Is the session consistent with known legitimate behavior? * Are multiple signals anomalous together? * Could ordinary travel, device change or shared infrastructure explain them? Output: contextual evidence, not fraud verdict. ↓ Account Questions * Is this an established customer account? * Did material account changes precede the payment? * Is account takeover a plausible mechanism? Output: account-risk context. ↓ Card credential Questions * Is the payment instrument new or previously used? * Is the suspected compromise the card rather than the merchant account? * Is unusual payment-attempt activity present? Output: credential-risk context. ↓ Authentication Questions * Was authentication attempted? * What was the outcome? * Was failure potentially technical rather than fraudulent? Output: authentication evidence. ↓ Authorization Questions * Did the issuer approve or decline? * Is the decline reason actually fraud-specific? * Does merchant-side context add information? Output: payment decision, not definitive fraud label. ↓ Fulfillment Questions * Has merchant value already been delivered? * Can fulfillment be delayed or recovered? * Does transaction economics justify further review? Output: loss exposure. ↓ Dispute / post-payment Questions * Was unauthorized use confirmed? * Was the event a non-fraud dispute? * What value was actually lost or recovered? Output: delayed evidence and economic outcome.

SEO package SEO title: Card-Not-Present Fraud: CNP Risk Explained for Merchants H1: Card-Not-Present Fraud: Why Remote Card Payments Create a Different Fraud Problem Meta description: Learn what card-not-present fraud is, how CNP payments differ from stolen-card fraud, account takeover and card testing, which risk signals matter, and how merchants can reduce fraud without blocking legitimate customers. URL slug: /card-not-present-fraud Primary keyword: card-not-present fraud Secondary keywords: CNP fraud; card not present transaction fraud; ecommerce card fraud; online card payment fraud; CNP payment risk; remote card fraud. Related entities: ecommerce payments, card-not-present transaction, remote payment, stolen card, account takeover, card testing, EMV 3-D Secure, card authentication, payment authorization, fraud signals, false positives. Article excerpt: Card-not-present is a payment environment, not a fraud verdict. CNP fraud occurs when remote card payments are abused through mechanisms such as stolen credentials, account takeover or credential testing. Merchants need to identify the actual mechanism before choosing the control. Suggested structured data: Article Search-intent coverage The article directly answers: What is card-not-present fraud? What does CNP mean in payments? Is every online card payment card-not-present? How does card-not-present fraud happen? What is the difference between CNP fraud and stolen-card fraud?

What is the difference between CNP fraud and account takeover? Is card testing a type of CNP fraud? How does 3-D Secure help with CNP fraud? What signals indicate CNP fraud? How can merchants reduce CNP fraud without increasing false declines? These are handled within the article rather than repeated in a generic FAQ.

Internal-link plan Anchor Destination what is payment fraud What Is Payment Fraud? types of payment fraud Types of Payment Fraud stolen card fraud Stolen Card Fraud account takeover fraud Account Takeover Fraud card testing attacks Card Testing Attacks bot payment attacks Bot Payment Attacks friendly fraud Friendly Fraud fraud and net revenue How Fraud Affects Net Revenue payment declines Relevant Decline Economics article The CNP article should remain the remote card-payment umbrella while the adjacent articles own their individual mechanisms.

Supporting visual CNP Fraud Attack Surface Map REMOTE CUSTOMER │ ▼ DEVICE / SESSION │ │ Possible signals: │ device, network, behavior ▼ CUSTOMER ACCOUNT │ │ Possible overlap: │ account takeover ▼ CARD CREDENTIAL │ │ Possible overlap: │ stolen-card misuse / testing ▼ AUTHENTICATION │ │ Evidence, not fraud verdict ▼ AUTHORIZATION │ │ Approve / decline │ ≠ confirmed legitimacy / fraud ▼ FULFILLMENT │ │ Merchant value exposed ▼ POST-PAYMENT │ ├── customer report ├── confirmed fraud └── dispute / chargeback Image alt text Card-not-present fraud attack surface map showing how risk can enter through the remote customer's device, account, card credentials, authentication, authorization, fulfillment and post-payment dispute stages.

Authoritative source recommendations EMVCo — EMV 3-D Secure: Primary technical source for explaining the authentication role of EMV 3DS, merchant/issuer data exchange, and the balance between fraud prevention and ecommerce friction. PCI Security Standards Council: Useful for tightly scoped statements about card-verification data in CNP environments and PCI handling requirements. Visa network documentation: Useful for current CNP/card-present terminology and for clearly separating remote card environments from face-to-face payment contexts. EBA/ECB payment-fraud reporting: Useful for geographically scoped evidence about authentication and card-fraud outcomes. Do not turn European aggregate statistics into universal merchant benchmarks.

Proposed author and reviewers

Primary reviewer: Fraud/risk lead. Payments reviewer: Card-payments specialist. Security reviewer: Security or account-risk specialist where account/device signals are discussed. Data reviewer: Fraud analyst responsible for label and denominator methodology. Compliance/privacy reviewer: Where device, behavioral or identity signals create jurisdiction-specific requirements. Do not state that review has occurred until the named reviewer actually completes it.

Fraud-definition fact-check For any merchant example or statistic record: CNP definition: ______ Fraud definition: ______ Confirmed versus suspected: ______ Payment channel: ______ Card/payment type: ______ Market: ______ Period: ______ Count or value basis: ______ Denominator: ______ Confirmation source: ______ Do not use: chargeback = fraud or: risk decline = fraud as automatic labels.

Attack-mechanism fact-check Before classifying a CNP event, ask: Card credential compromised? Yes / No / Unknown Customer account compromised? Yes / No / Unknown Credential testing suspected? Yes / No / Unknown Automation involved? Yes / No / Unknown Customer/cardholder intent known? Yes / No / Unknown Fraud confirmed? Yes / No If evidence does not establish the mechanism, describe the behavior as: suspicious or: consistent with rather than asserting confirmed fraud.

Signal and data fact-check For every recommended signal verify: * merchant has lawful/appropriate access to it; * data quality is sufficient; * legitimate alternative explanations exist; * merchant-specific baseline is defined where necessary; * signal is not presented as proof; * threshold is not invented; * privacy implications are reviewed where applicable. No universal device, IP or velocity threshold should be published.

Fraud-statistics fact-check Any CNP fraud statistic should identify: Fraud definition Market Channel Payment method Merchant/issuer population Period Count/value basis Denominator Source Authentication environment where relevant The brief explicitly requires these dimensions because incompatible fraud statistics can produce misleading comparisons.

Regulatory and privacy flags Fraud controls can involve: * personal information; * device information; * identity verification; * behavioral data; * automated decision-making; * cardholder authentication. Requirements vary by jurisdiction. Do not generalize European strong-customer-authentication requirements into a global rule. Do not publish legal claims about liability shifts, authentication mandates or privacy permissions without jurisdiction-specific review.

Safety and abuse-enablement check The article intentionally explains: what merchants observe where fraud enters which objects can be compromised how merchants classify evidence without providing: * stolen-card validation instructions; * authentication bypass procedures; * velocity-limit evasion; * bot evasion techniques; * account-takeover instructions; * proprietary fraud thresholds. That matches the brief's requirement to keep Payment Fraud Fundamentals defensive and merchant-focused.

Amber-flag claims “CNP transactions are fraudulent.” Incorrect. CNP describes the remote payment environment. “CNP fraud means stolen-card fraud.” Too narrow. Stolen credentials are one mechanism; account takeover and card-testing overlap can also exist. “Authentication failure proves fraud.” Incorrect. Authentication can fail for legitimate or technical reasons. “Issuer decline means the issuer detected fraud.” Unsupported. Declines have multiple causes. “A new device is a fraud indicator that should be blocked.” A new device can be a risk signal, but the decision requires context. “A chargeback confirms CNP fraud.” Incorrect. Chargebacks include non-fraud disputes, while blocked fraud never becomes a chargeback. “3-D Secure prevents CNP fraud.” Too absolute. EMV 3DS is designed to strengthen cardholder authentication and help reduce CNP fraud; it does not eliminate every fraud mechanism. “More authentication always improves merchant economics.” Unsupported. Authentication must also be evaluated for legitimate-customer friction.

Unsupported.

Requires approved merchant-specific evidence.

* Passport Risk; * custom risk rules; * suspicious-transaction alerts/declines; * merchant-supplied risk information; * risk review; * 3-D Secure integration.

CNP risk model * exact current product name; * supported card flows; * account/device data used; * behavioral inputs;

Authentication * current EMV 3DS versions/support; * markets/networks supported; * challenge/frictionless handling; * exemptions or regional treatment where applicable. Velocity/rules * current capabilities; * merchant configurability; * alert/review/decline options. Risk review * current availability; * workflow; * merchant responsibilities; * fulfillment interaction. Performance * approved CNP fraud reduction; * approved false-positive results; * approval effects; * merchant outcomes. Do not expose proprietary thresholds, model features or security architecture that could help attackers circumvent controls.

Cluster sameness audit Field Card-Not-Present Fraud Opening device Category error: CNP environment versus fraud mechanism Fraud actor External unauthorized actor; mechanism varies Targeted asset Remote card payment, credential or associated account Entry point Multiple points across remote-payment journey Attack mechanism Credential misuse/account compromise/testing/automation overlap Merchant loss Unauthorized payment plus fulfillment/operations where relevant Primary signals Multi-layer payment, account, device and authentication context False-positive risk Treating normal remote behavior as inherently suspicious Format Remote-payment attack-surface map Evidence anchor Merchant must establish trust without traditional physical card presentation Editorial position Diagnose mechanism inside CNP rather than treating CNP itself as fraud Original framework CNP Fraud Attack Surface Map Primary metric Confirmed CNP fraud by clearly defined count/value denominator Conclusion Identify what is actually being abused CTA Map evidence across the remote transaction lifecycle Closing device Five-question merchant decision framework This keeps Article 3 distinct from the taxonomy article and from the dedicated Stolen Card, Account Takeover, Card Testing and Bot Payment Attacks pages.