The 3D Secure Liability Shift: What It Covers, What It Doesn't, and How to Protect Yourself

The liability shift is the most commercially significant feature of 3D Secure. It is also the most misunderstood. Enabling 3DS does not provide blanket chargeback protection. The shift applies only when specific conditions are met, and those conditions fail more often than most teams realise. The result: merchants absorb fraud losses on transactions they assumed were covered.

What the liability shift means

Under standard card-not-present rules, the merchant is liable for fraud chargebacks, specifically the category of dispute where a genuine cardholder asserts that they did not authorise the transaction. When a transaction is successfully authenticated via 3DS, this liability transfers to the card issuer. If a fraud chargeback is subsequently filed, the issuer, not the merchant, absorbs the loss.

The mechanism exists because 3DS authentication constitutes a verified claim by the issuer that the cardholder was authenticated at the time of purchase. Having made that determination, the issuer accepts responsibility for it.

When the liability shift applies

For the liability shift to be in effect, the following conditions must be met:

• The transaction must have been processed through 3DS authentication, not merely attempted.
• The authentication must have produced an ECI code and CAVV/AAV value that indicate successful authentication. The ECI codes that signal liability shift are ECI 05 for Visa (fully authenticated) and ECI 02 for Mastercard.
• Both the ECI and CAVV/AAV must be included in the authorisation request submitted to the issuer. These values are returned by the 3DS process and must be passed through to the acquiring bank's authorisation API. Dropping them (a common integration error) means you cannot demonstrate authentication occurred.
• The dispute must be fraud-coded: specifically, the cardholder is asserting they did not make or authorise the transaction.

When the liability shift does NOT apply

Non-fraud chargebacks

The liability shift covers fraud chargebacks only. It does not cover service disputes, non-delivery, item significantly not as described, or processing errors. If a cardholder receives a product that does not match the description and files a chargeback, 3DS provides no protection. These disputes remain with the merchant regardless of authentication outcome.

SCA exemptions

When a transaction is processed using an SCA exemption, the authentication step is bypassed. Whether a liability shift applies depends critically on who requested the exemption.

If the merchant requests the exemption (low-value, TRA, trusted beneficiary, or secure corporate), there is no liability shift. The merchant bears the fraud risk on that transaction. This is the core tradeoff in SCA exemption strategy.

If the issuer applies the exemption on their own initiative, for example by granting a frictionless flow without the merchant requesting it, liability remains with the issuer. The merchant does not lose protection in this scenario.

One additional operational risk that is often overlooked: if a TRA-exempted transaction results in fraud, it does not just create a chargeback liability, it also counts against the fraud rate of the party that applied the exemption. Each party is responsible for maintaining fraud rates within the legal thresholds set under PSD2. Exceeding those thresholds can result in losing the right to apply TRA exemptions altogether. This means the true cost of a fraud event on an exempted transaction is not just the chargeback value; it is also the potential loss of a valuable conversion tool.

It is also worth noting that even when a merchant correctly applies a TRA exemption, the issuer is not required to accept it. The issuer can still trigger an SCA step-up if they deem it appropriate.

If you want to learn more about SCA exemptions under PSD2, read https://www.pci-proxy.com/blog-posts/sca-exemptions-under-psd2-a-practical-guide-for-payment-teams

Data-only 3DS

Visa and Mastercard both support a variant called Data-Only 3DS (or Mastercard Identity Check Insights), where transaction data is shared with the issuer to improve their risk decisioning, but a full authentication is not completed. Data-only does not result in a liability shift. It can improve authorisation rates but provides no fraud chargeback protection.

Recurring and merchant-initiated transactions (MIT)

Subsequent charges in a recurring series, such as subscription renewals and instalment payments, are classified as merchant-initiated transactions and are out of scope for SCA. The default position is clear: since MITs are not authenticated at the time of each transaction, fraud liability for those charges remains with the merchant. The liability shift from the initial authenticated CIT does not automatically extend to subsequent MITs.

This is an important distinction. A merchant who authenticates a customer at sign-up and then assumes ongoing fraud protection for all future recurring charges is exposed. Each subsequent MIT carries merchant liability unless your acquirer and card scheme have a specific arrangement that provides otherwise, so always verify this directly.

There is also a material scheme change to be aware of for Visa merchants running standing instruction MITs: as of July 2025, Visa has mandated that standing instruction MITs must use Card on File (COF) tokens rather than Device Tokens. MITs initiated with Device Tokens provisioned after 30 July 2025 will be declined. This is a live operational requirement, not a future consideration.

Technical failures in the integration

If the 3DS authentication completes successfully but the ECI and CAVV values are not correctly passed to the authorisation request, you cannot prove authentication occurred. The liability reverts to you. This is an operational quality issue, not a theoretical risk. It occurs with surprising regularity in systems where the 3DS and authorisation layers are maintained by different teams or systems.

ECI codes and what they mean

‍

‍If you want to learn more about 3DS data fields and what they mean, read https://www.pci-proxy.com/blog-posts/understanding-the-essential-3ds-data-fields-for-authorization-success

Protecting your liability shift in disputes

When a fraud chargeback arrives on an authenticated transaction, representing it correctly requires submitting the authentication evidence to the scheme's dispute resolution system. The evidence that must be retained and included:

• ECI value: Confirms the authentication outcome code.
• CAVV / AAV: The cryptographic authentication verification value returned by the ACS. This is the primary proof that authentication occurred.
• 3DS Server transaction ID: The unique identifier for the authentication session.
• ACS transaction ID: The issuer-side identifier for the authentication event.

These values should be stored against the transaction record at the point of payment. If your system does not currently capture and store all four, this is a gap that needs to be addressed. Not because it is rare to need them, but because the cost of a single high-value dispute where you cannot represent correctly will typically exceed the engineering time required to fix the data capture.

Operational note: Run a periodic audit of your 3DS data capture against your chargeback evidence submissions. If you are losing disputes on authenticated transactions due to missing authentication values, the issue is almost always upstream in the payment integration, not in the dispute process itself.