The Outlier Lab

3-D Secure and Card Verification

Issuer-side cardholder authentication (EMV 3DS) and card checks (CVV, AVS, zero-dollar verification) used at checkout and at card-funded account funding, trading off fraud, liability shift and conversion.

What it is

EMV 3-D Secure is a messaging protocol between the merchant (3DS Server), the card network (Directory Server) and the issuer (Access Control Server). The merchant sends rich transaction and device data. The issuer risk-assesses it and returns one of three outcomes:

  • Frictionless: authenticated without customer interaction
  • Challenge: an OTP, an app push or biometric, or other methods
  • Rejection or attempt

Authenticated transactions generally move fraud-chargeback liability from the merchant to the issuer under network rules.

Versions (as of late 2026):

VersionStatusNotes
3DS 1.0RetiredStatic passwords, redirect-heavy; high abandonment
EMV 3DS 2.1Sunset; card schemes ended transaction-processing support on 24 September 2024n/a
EMV 3DS 2.2Widely deployed baselineExemptions signaling, decoupled authentication, 3RI (merchant-initiated authentication)
EMV 3DS 2.3.1 (2.3.1.1 current)Released September 2022; 2.3.1.1 published May 2023 and replaced 2.3.1.0Adds data elements for Secure Payment Confirmation (passkey-style, developed with FIDO and W3C) and improved out-of-band authentication
EMV 3DS 2.4Draft for comment in 2026Not yet a production requirement

Card verification checks:

  • CVV2/CVC2: proves the presenter has the card data printed on the card, beyond the number alone. It doesn't prove the presenter is the cardholder, since stolen card data usually includes it.
  • AVS: compares the billing address with the issuer's record. Useful mostly in the US, UK and Canada, and only as a weak signal.
  • Account verification / zero-amount authorization: confirms the card is open and valid when it's added. It is also the endpoint card testers target.
  • Network tokens and cryptograms: for wallet and token transactions. These carry device-binding context from provisioning (Digital Wallet Provisioning Fraud).

What it stops (and what it doesn't)

  • Stops:
    • Use of stolen card data where the attacker can't pass the issuer's authentication
    • Fraud chargebacks on authenticated transactions, by shifting liability
    • Some funding fraud where card-funded instant balances are used for account funding (wallet top-ups, brokerage funding where card funding is allowed, P2P card-funded sends)
  • Doesn't stop:
    • First-party disputes. Liability shift generally covers fraud reason codes only, so "not as described" and "not received" disputes stay with the merchant.
    • Issuer-side weaknesses. Phishable OTP challenges, and weak issuer risk models that frictionlessly approve risky transactions. The merchant then has liability protection but still has a fraudster as a customer.
    • Card testing. Validation happens through authorizations, often on merchants that don't use 3DS. Your defense there is Rate Limiting and Throttling and Bot Management and CAPTCHA.
    • Downstream misuse. Triangulation (real goods to real buyers paid with stolen cards) and misuse of stored cards after ATO, unless 3DS is re-run.

Design considerations

  • Merchants should be selective. Running 3DS on every transaction gives up conversion in exchange for liability shift. Running it on none leaves you with all the fraud. Use your own risk score (Real-Time Transaction Risk Scoring) to decide: request exemptions or skip 3DS on low-risk transactions (where regulation allows), and request authentication, or a challenge, on high-risk ones.
  • Send rich data. Issuers decide frictionless versus challenge from the data you send: device, account age, shipping-to-billing match, purchase history. Better data means more frictionless approvals and fewer fraudulent ones.
  • Use 3DS at account funding as well as checkout. Card-funded wallet loads, P2P card-funded sends and brokerage card deposits are attractive for stolen cards because the value becomes movable. Authenticate the first card-funded deposit, cap card-funded exposure (Velocity and Exposure Limits), and hold card-funded balances from irreversible withdrawal (Funds Availability Holds).
  • Run 3DS on card add. Authenticate when a card is first stored, using non-payment authentication or a 3RI flow, so later merchant-initiated transactions have an authenticated origin.
  • Liability shift doesn't prevent loss. Your chargeback losses fall, but the fraudster still received goods or value from you (or is in your marketplace, or used your rewards program). Track attempted fraud as well as fraud charged back.
  • Card-linked offers and rewards. For Card-Linked Offer Abuse, the threat is cards linked to reward accounts (sometimes stolen or virtual cards). Card-link verification, such as a micro-authorization or 3DS at link time, plus Payment Instrument Signals (BIN type, prepaid or virtual, issuer country) reduce abuse.
  • Know the European context. Under PSD2/UK SCA, 3DS is the main way to meet SCA for card-not-present transactions, with exemptions (low value, transaction risk analysis, trusted beneficiaries, merchant-initiated). Outside Europe, 3DS is optional and risk-driven.

Industry lens.

  • Retail / ecommerce: classic checkout use. Balance conversion against chargeback ratio and network monitoring thresholds.
  • Marketplaces: buyer card authentication, plus triangulation risk on the seller side.
  • Neobanks / payments: card-funded account top-ups and push-to-card. Authenticate and cap.
  • Brokerage: where debit-card funding is offered, treat it as high-risk instant funding.
  • Cashback / rewards: card-linking and gift-card purchases funded by stolen cards.

Implementation path

StageWhat it looks likePrerequisites
CrawlCVV and AVS on all card-not-present transactions; 3DS via gateway on high-risk transactions and first card-funded deposits; rate limits on card-addGateway with EMV 3DS 2.2+; card-add endpoint protection
WalkRisk-based 3DS orchestration (exemption requests vs challenge requests driven by your own score); rich data elements; 3DS on card add; card-funded exposure caps and holdsMerchant-side scoring; 3DS server or provider; data-element hygiene
Run2.3.1 features (SPC, improved OOB) where issuers support them; authentication outcome and issuer response as model features; per-issuer and per-BIN performance tuning; dispute evidence pipelines that use authentication dataProvider supporting 2.3.1; analytics on authentication outcomes; Card Network Dispute Rules expertise

Customer friction and trade-offs

  • Challenge flows cause abandonment, especially on mobile web and with poor issuer implementations. Frictionless rates vary widely by issuer and region.
  • Over-requesting challenges in markets without SCA requirements loses sales with little gain.
  • Under-using 3DS leaves the merchant exposed to fraud chargebacks and network monitoring programs.
  • Passkey-based and SPC-style authentication promise lower friction. Adoption depends on issuers and networks.

Measuring effectiveness

  • Fraud rate and fraud chargeback rate by 3DS outcome (frictionless, challenged, not attempted, failed).
  • Challenge rate and challenge completion rate by issuer, BIN and device type.
  • Authorization approval rate with and without 3DS. Conversion lost to 3DS.
  • Liability-shifted dollars versus fraud dollars actually absorbed.
  • Card-funded funding losses: returns and chargebacks on card-funded balances that were withdrawn.
  • Repeat disputers: dispute rate among authenticated transactions for customers with prior disputes (Dispute and Return History). This separates first-party abuse from true fraud.
  • Card-add decline ratio (a card-testing signal).

Common failure modes

  • 3DS everywhere, or 3DS nowhere, instead of risk-based orchestration.
  • Mistaking liability shift for prevention, and ignoring fraud that never reached a chargeback but still cost goods or rewards.
  • Unprotected card-add endpoints, which become card-testing targets.
  • Outdated protocol versions, or missing data elements, which lower frictionless rates.
  • No 3DS on card-funded account funding, where value immediately becomes movable.
  • First-party blind spot: assuming authenticated transactions can't be disputed, when first-party "not recognized" or service disputes still occur.

Regulatory and policy notes

  • EMVCo specifications. 2.1 is sunset (schemes ended support 24 September 2024). 2.2 is the deployed baseline. 2.3.1 (current 2.3.1.1) adds SPC and OOB enhancements. A 2.4 draft is out for comment.

  • Card network rules govern liability shift, dispute reason codes and fraud and dispute monitoring programs. These change often; see Card Network Dispute Rules. The ECI value returned with the authentication tells you where liability sits:

    OutcomeVisa ECIMastercard ECIFraud liability
    Fully authenticated (frictionless or challenged)0502Shifts to issuer
    Attempted / scheme stand-in0601Generally shifts, subject to scheme exclusions
    Not authenticated, failed, or SCA exemption applied0700 (failed), 06 (exempt)Stays with merchant
    Mastercard Identity Check data-onlyn/a04Stays with merchant

    The shift covers fraud reason codes (Visa 10.4, Mastercard 4837), not non-fraud disputes. A transaction that skips authentication through a low-value or TRA exemption carries no shift, so every exemption request is a decision to keep the fraud liability yourself.

  • PSD2 / UK SCA. 3DS is the primary SCA mechanism for card-not-present. Exemptions are set in the RTS (Delegated Regulation (EU) 2018/389):

    • Low value (Art. 16): remote payments up to €30, until cumulative exempted spend since the last SCA passes €100 or five consecutive exempted payments.
    • Contactless at POS (Art. 11): up to €50 per payment, capped at €150 cumulative or five consecutive payments.
    • Transaction risk analysis (Arts. 18–19): remote card payments up to €100 if the PSP's overall card fraud rate is at most 0.13%; up to €250 at 0.06%; up to €500 at 0.01%. The EBA has confirmed the rate is measured on the PSP's overall card fraud rather than per band. Real-time risk analysis must also find no abnormal behavior, malware, known fraud scenario or high-risk payee location.
    • Status (October 2026): the PSD3/Payment Services Regulation package reached political agreement in November 2025 and final compromise texts were published in April 2026, but it had not been published in the Official Journal as of October 2026. Commentators expect adoption around December 2026 and general application roughly 21 months after entry into force (late 2028), so the PSD2 RTS thresholds above remain the live rules. The PSR keeps the core SCA model and the TRA exemption, with detailed conditions left to new EBA technical standards.

  • Reg Z and Reg E. In the US, consumer liability for unauthorized card use is limited (Reg Z for credit cards; Reg E for debit). 3DS doesn't change the consumer's rights, only how losses are split between merchant and issuer.

Mechanisms addressed

Sources and further reading