The 3DS Liability Shift: What You Are Getting, and When to Hand It Back

Before we can talk about the shift, we need to talk about the liability. Every card payment carries a quiet question with money attached: if this transaction turns out to be fraud, who pays for it? For most of the history of card-not-present payments the answer was simple. The merchant did. The 3DS liability shift changed that answer, and it remains the single biggest commercial reason to authenticate a payment. But it is widely misunderstood: what it covers, what triggers it, how to tell whether you have it, and, least discussed of all, when the smart move is not to take it. This article works through all four.

A short history of merchant liability

When the card schemes built their dispute frameworks, they split chargebacks into two families. Non-fraud chargebacks are commercial disputes: goods not received, not as described, a credit that never arrived, a subscription the customer says they cancelled. Fraud chargebacks are the “this wasn’t me” disputes, where the cardholder claims they never authorised the payment at all.

For card-present payments, fraud liability has long depended on the technology at the till, which is why the rollout of chip and PIN came with its own liability shift onto whichever party had the weaker setup. But in card-not-present, where no card is seen and no PIN is entered, the schemes settled the question early and bluntly: the merchant chose to accept a payment without the card being present, so the merchant carries the fraud risk. For decades, every remote fraud chargeback landed on the merchant’s desk by default, along with the chargeback fee and the operational cost of dealing with it.

That was the world 3D Secure was built to change. When Visa launched Verified by Visa in the early 2000s, followed by Mastercard’s SecureCode, the deal offered to merchants was explicit: put the cardholder through authentication, and if the issuer verifies them, fraud liability for that transaction moves from you to the issuer. The liability shift was the carrot that drove 3DS adoption for two decades before any regulator made authentication mandatory.

Then SCA made it the default

In the UK and EEA, PSD2’s Strong Customer Authentication requirements turned authentication from an option into the norm for remote card payments, fully enforced in the EEA from January 2021 and in the UK from March 2022. The commercial logic of the shift carried straight over. When a customer is successfully authenticated through 3DS, the issuer has vouched for their identity. If that same cardholder later claims the payment was unauthorised, the dispute is the issuer’s problem, not yours. Fraud chargebacks under reason codes like Visa 10.4 and Mastercard 4837 are, for authenticated transactions, no longer chargeable back to you.

This is not the end of chargebacks, though, and it is not the end of disputes dressed up as fraud. The shift covers fraud chargebacks only. An authenticated customer can still charge back a payment because the service was not delivered, or dispute an instalment they say they already paid. If your chargeback problem is first-party misuse or service disputes rather than third-party fraud, authentication will not make it go away. We covered this distinction in more depth in our piece on challenge preferences, and for collections portfolios especially, knowing which family your chargebacks fall into should come before any authentication strategy.

The myth: “no challenge, no shift”

Here is the most persistent misconception in this corner of payments: that the customer has to be actively challenged, with a one-time passcode or a banking app approval, for the liability shift to apply.

They do not. The shift attaches to successful authentication, not to the challenge. When the issuer authenticates a customer frictionlessly, deciding from the data in your authentication request that this is genuinely their cardholder without asking them anything, the transaction carries exactly the same fraud liability protection as a completed challenge. The customer never sees a thing, and you are just as covered.

This matters because merchants who believe the myth request challenges they do not need, and pay for them in abandoned checkouts. The challenge step is a known drop-off point, and forcing one on a known, low-risk customer buys you protection you would have received anyway. The right question is never “how do I get the customer challenged?” It is “how do I get the customer authenticated?”, and the best answer is usually to send authentication data rich enough that the issuer can say yes silently. You also get a say in which flow the issuer picks, through the challenge preference field: no preference, no challenge requested, challenge preferred, or challenge mandated for recurring mandate setup. We covered how to set that field per transaction, rather than hard coding it, in a previous article.

ECI: how to know whether you have the shift

You do not have to guess whether a given transaction carries the shift. The authentication response tells you, through the Electronic Commerce Indicator, or ECI. It is a small field with large consequences, and the schemes encode it differently:

Authentication outcome	Visa ECI	Mastercard ECI	Fraud liability
Fully authenticated (frictionless or challenge)	05	02	Issuer
Attempted: you tried, but the issuer or its authentication server could not complete, and the scheme stood in	06	01	Issuer, subject to scheme exclusions
Not authenticated: failed, unavailable, or never attempted	07	00	Merchant

Attempts exist so you are not punished when the issuer’s side cannot complete authentication: the scheme stands in and the shift generally still applies. But the schemes have been narrowing the exclusions around attempts, so a book heavy in ECI 06 or 01 traffic is relying on the weakest form of the protection.

The practical habit to build is monitoring your ECI mix. A book of transactions sitting at 05 and 02 is a book where fraud chargebacks are largely someone else’s problem. A creeping share of 07 or 00 is unprotected exposure, and it is visible in your data long before it is visible in your chargeback figures.

When the smart move is to hand the shift back

Everything so far says the shift is valuable, and it is. So it sounds odd to suggest ever giving it up on purpose. But for your lowest-risk customers, that is often exactly the right trade.

Think about who your safest payer is. For a lender, it is the borrower two years into an agreement, paying the same amount on the same date from the same device. For a collections firm, it is the customer months into a plan they have never missed. The fraud risk on these payments is close to zero, which means the liability shift on them is insurance against something that essentially does not happen. Meanwhile even the frictionless flow has a cost: an extra round trip, a dependency on the issuer’s authentication infrastructure, and a small but real chance the issuer steps the customer up anyway.

This is what SCA exemptions are for. The regulation allows certain transactions to skip authentication entirely: low-value payments, and transactions covered by transaction risk analysis, where an acquirer with sufficiently low fraud rates can wave qualifying payments through up to defined value thresholds. Ask for an exemption and there is no 3DS flow, no challenge, no authentication latency at all. The price is that fraud liability stays with you, because the shift only ever attaches to authentication. For the borrower on their fortieth consecutive repayment, that is a price of roughly nothing, paid for a conversion benefit you collect on every single transaction.

The mechanics of exemptions, which ones exist, who can apply them, and how to build a strategy around low value and TRA, deserve a full article of their own, and that is where this series goes next. The takeaway for now is the mindset: the liability shift is a tool, not a trophy. Take it wherever the risk is real. Hand it back where risk is not, and collect the conversion instead.

If you want to see your own ECI mix, or talk through where exemptions could fit in your flows, the Acquired team can walk you through both.

Sources and references

EMVCo, EMV 3-D Secure specification, Visa and Mastercard scheme rules, for ECI values and fraud liability (authenticated 05/02, attempted 06/01, non-authenticated 07/00) and the fraud dispute reason codes covered by the shift (Visa 10.4, Mastercard 4837).

Mastercard Identity Check Program Guide, current edition (26 May 2026, Mastercard Connect): message category 80, ECI 04, and SLI 214 (merchant liable) for Identity Check Insights, plus its planned migration to Enhanced Data Share Only and Data Share Only (bulletin GLB 13695).

Commission Delegated Regulation (EU) 2018/389 and the FCA’s onshored SCA-RTS, for the SCA requirement and its exemptions; enforced in the EEA from 1 January 2021 and the UK from 14 March 2022.