Asking the Bank to Verify the Shopper (3D Secure / 3DS)
- 3DS = Authentication that shifts fraud liability from you to issuer on CNP transactions
- Worth testing if: Fraud losses are rising or you're approaching your processor's written limit. Measure authorization and abandonment too
- Liability shift: Visa ECI 05/06 = full shift; Mastercard SLI 2 (fully authenticated) / SLI 1 (attempted) = full shift; ECI 07 or no auth = you're liable
- Frictionless rate: Send supported customer and device data, then measure issuer decisions on your own traffic
- Roll out in phases: high-risk segments first, measure for 2 weeks, expand or kill
3D Secure (3DS) is the step where the customer's bank checks that the real cardholder is the one buying. Sometimes the shopper sees it: a code by text, a tap in the banking app. Often the bank recognizes the customer from the data you sent and approves without showing anything at all. When the bank authenticates the payment, it takes on the fraud risk for it instead of you. That handover is called the liability shift, and it's the main reason merchants turn 3DS on.
If you're thinking about declining a transaction for fraud, use 3DS instead.
When your fraud rules flag a transaction as risky, you have two options:
- Decline it - You lose the sale. If it was a good customer, they're gone.
- Trigger 3DS - The issuer authenticates them. If they pass, you get liability shift AND the sale. If they fail or abandon, you've lost nothing you wouldn't have lost anyway.
3DS is not just a fraud prevention tool. It's a recovery mechanism for transactions your rules would otherwise kill.
Liability shift only covers fraud chargebacks (Visa 10.4, Mastercard 4837).
Customers can still dispute for:
- Merchandise not received - Package lost or never shipped
- Not as described - Product doesn't match what you sold
- Services not rendered - You didn't deliver what was promised
- Credit not processed - You owe them a refund and didn't give it
- Processing errors - Duplicate charges, wrong amounts
A fully authenticated transaction that results in an unhappy customer is still a chargeback waiting to happen. 3DS protects you from "I didn't do it" fraud. It doesn't protect you from bad fulfillment, misleading product descriptions, or poor customer service.
No new rollout needed - if your current controls are meeting your fraud-loss budget and applicable requirements. Check your processor's limits and network program conditions. Keep monitoring.
Test first - if fraud losses are rising or you see repeat disputers on high-value orders. Test 3DS on your riskiest segment first and measure the impact for 2 weeks.
Act now - if fraud chargebacks are driving a processor warning or you're approaching an applicable limit. Confirm whether 3DS and liability shift address the disputes you're receiving.
Simple starting rule: Test 3DS on new-customer orders above an amount you choose from your own fraud losses. The $200 population below is illustrative. Set an auth-rate stop limit from lost margin before launch, and judge fraud only after the outcome window closes (before any live test). Required authentication still applies.
3DS shifts liability to the issuer for authenticated CNP transactions. But it also adds friction that kills conversion for some merchants.
Before you flip the switch everywhere, run an experiment.
Illustrative population: Orders over $200 from customers with fewer than 2 prior purchases. Replace those cutoffs with your own high-loss segment before testing.
Control: Same segment, no 3DS challenge
Metrics: Auth rate, cart abandonment, fraud rate, CB ratio (reason code 10.4)
Guardrail: Choose the largest auth-rate drop vs. control that your lost-margin budget can absorb. State it in percentage points and name who pauses the test.
Run length: Plan the sample from your baseline and the change worth detecting. Keep fraud results inconclusive until the outcome window closes.
Kill criteria: Pause at that same auth-rate limit or the dollar-loss cap, whichever comes first. Use the agreed rollback; don't turn off authentication your processor or applicable rules require.
Before it starts: Name who owns the risk and the most it can cost. Two weeks shows the auth rate, not the 10.4 chargebacks, so read the CB ratio after the outcome window closes (the full checklist)
If you turn 3DS on for a segment, you're testing whether fraud liability shift is worth any added checkout friction. Measure completed payments against comparable traffic. An auth-rate drop isn't a fixed cost you can assume.
That's worth it if:
- Your fraud losses are above the budget you've set
- You're approaching your processor's limit or an applicable network program line
- Your margins can absorb the conversion hit
It's probably NOT worth it if:
- Your current controls are meeting your fraud-loss budget and applicable requirements
- Your margins are thin (see interchange optimization)
- Your customer base is older/less tech-savvy (higher challenge abandonment)
Write down your assumptions before you start. Revisit them in 30 days.
3DS Topics
How 3DS Works
| Version | Status | Key Features |
|---|---|---|
| 3DS 1.0 | Deprecated | Static passwords, high friction |
| 3DS 2.0 | Current | Risk-based, frictionless options |
| 3DS 2.1 | Current | Enhanced data, mobile support |
| 3DS 2.2 | Current | SCA compliance, exemptions |
Brand Names
| Network | 3DS Brand Name |
|---|---|
| Visa | Visa Secure |
| Mastercard | Mastercard Identity Check |
| American Express | American Express SafeKey |
| Discover | ProtectBuy |
Liability Shift Rules
This is the whole point. When 3DS authentication succeeds, fraud liability shifts from you to the issuer.
Visa (ECI Values)
| ECI | Meaning | Liability Shift |
|---|---|---|
| 05 | Fully authenticated | Yes, to issuer |
| 06 | Attempted, issuer not enrolled/unavailable | Yes, to issuer (merchant attempted, issuer didn't participate) |
| 07 | Not authenticated / Failed | No, merchant liable |
Mastercard (SLI Values)
| SLI | Meaning | Liability |
|---|---|---|
| 2 | Fully authenticated | Issuer |
| 1 | Authentication attempted (merchant supports UCAF) | Issuer |
| Other | Not authenticated | Merchant |
When Liability Does NOT Shift
Even with authentication:
- Mail order/telephone order (MOTO)
- Recurring transactions (after initial)
- Merchant-initiated transactions (MIT) - see recurring billing compliance
- Certain MCC exclusions
Frictionless vs. Challenge Flow
Frictionless Authentication
The issuer's risk engine decides the cardholder is low-risk and authenticates without interaction.
Benefits:
- Better conversion (no extra steps)
- Faster checkout
- Still provides liability shift
Challenge Flow
Cardholder must complete verification (OTP, biometric, etc.).
When triggered:
- High-risk transaction signals
- Issuer policy
- Cardholder behavior anomalies
- Amount thresholds
Impact on Frictionless Rate
More supported data can help the issuer assess risk, but doesn't promise a frictionless percentage.
| Data Quality | What to check |
|---|---|
| Minimal data | Which supported fields are missing? |
| Good data | Do fields match the order and customer? |
| Excellent data | Does your issuer mix actually produce more frictionless completions? |
Send the supported data your integration permits and your privacy obligations allow: shipping address, email, phone, device info, customer history and IP address.
Rollout Strategy
Don't turn it on everywhere at once.
Phase 1: High-Risk Only (Week 1-2)
Start with segments where fraud is concentrated:
- High-risk BINs (prepaid, certain countries) - see going global
- New customers with no history
- Orders over your average fraud amount
Measure: CB rate change, auth rate change, cart abandonment.
Phase 2: Expand or Kill (Week 3-4)
If Phase 1 shows improvement:
- Expand to medium-risk segments
- Keep monitoring auth rate closely
If Phase 1 shows no fraud improvement and auth dropped:
- Kill it
- Try a different segment or approach
Phase 3: Steady State
Once you find segments where 3DS works:
- Lock in those rules
- Monitor monthly for drift
- Re-test quarterly as issuer behavior changes
- Small samples: 500 transactions isn't enough to measure fraud rate changes. You need thousands.
- Seasonality: Fraud patterns shift. A rule that works in December may fail in March.
- Issuer behavior changes: Frictionless rates depend on issuer risk engines, which update constantly.
- Selection bias: If you only enable 3DS on high-risk orders, of course it will look effective. Compare to a control.
Chargeback Handling for 3DS
When you get a fraud chargeback on an authenticated transaction, include the authentication data in your representment response.
Mastercard (4837):
AUTH MMDDYY/NNNNNN SL 1
Visa (10.4): Include ECI value, CAVV, and 3DS transaction ID.
When 3DS Doesn't Protect
Even with authentication, chargebacks can occur for:
- Non-fraud reason codes (13.x)
- Services not rendered (see 13.3)
- Goods not received (see 13.1)
- Processing errors
- Authentication data errors
Metrics to Watch
Track these during your experiment:
| Metric | What It Tells You |
|---|---|
| Frictionless rate | How often issuers are letting transactions through without challenge |
| Challenge completion rate | How many customers complete the challenge vs. abandon |
| Auth rate by ECI | Are you getting liability shift or just friction? |
| Cart abandonment | Measure at checkout step, not just overall |
| CB ratio on 10.4/4837 | The fraud chargebacks you're trying to prevent |
The Bet Framing
Sometimes the "right" decision loses a specific fight, but you keep it because expected value is positive over many fights.
3DS will occasionally let through a fraudster who passes the challenge. It will also occasionally cause a good customer to abandon. That's fine. The question is whether, across thousands of transactions, you're better off with it than without it.
If you're not measuring, you're not betting. You're just guessing.
Do next
- Velocity Rules - Catch what 3DS misses
- What proof each network accepts - Win with authentication data
- Risk Scoring - Combine with scoring for precision
Look up
- Visa 10.4 - CNP Fraud - Reason code details
- Mastercard 4837 - Fraud - Mastercard specifics
Deeper
- 3DS Exemptions - When to skip authentication
- PSD2 & SCA - European authentication requirements for US merchants
If 3DS is killing conversion:
- Device Fingerprinting - Passive signals
- Rules vs ML - Other approaches