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:

•Customer and device

↓

•Customer account

↓

•Card credential

↓

•Authentication

↓

•Authorization

↓

•Fulfillment

↓

•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.

•What was compromised?

Card credential?

Merchant account?

Identity?

Nothing confirmed yet?

•Where did the suspicious behavior enter?

Session/device?

Login?

Payment credential?

Authentication?

Payment attempt?

Fulfillment?

Post-payment dispute?

•What evidence do we actually have?

Distinguish:

signal

from:

suspicion

from:

confirmed fraud.

•What merchant value is exposed?

Is fulfillment:

immediate

delayed

reversible

or:

irreversible?

•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

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

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.