Mastercard’s 3DS Mandate July 2026 Deadline and What Merchants Need to Know

On 1 April 2026, Mastercard updated the data its Identity Check programme expects on every 3D Secure request, and it gave merchants until 1 July 2026 to comply. That deadline is now under two weeks away. 

From that date, every 3DS authentication request your checkout sends should carry a cardholder name, a billing address line 1, at least one contact method, and a device identifier. If they are missed, then there is a risk of authentication downgrades, lost liability-shift protection, and the emergence of a relatively quiet cost that shows up later in the approval numbers.

This is not a software upgrade that is installed once. The Mastercard 3DS cardholder data mandate changes what your payment stack has to collect and pass at the moment of checkout. This guide breaks down what changed, the exact required fields, why presence is not the same as verified, how it compares to the Visa rules, and the steps to get compliant before July 2026.

What is the Mastercard 3DS data mandate?

The Mastercard 3DS data mandate is a rule requiring every 3D Secure authentication request to carry a defined set of cardholder and device data fields, effective 1 July 2026. It sits inside Mastercard Identity Check, the brand name for Mastercard’s EMV 3DS implementation. Mastercard published the updated requirements on 1 April 2026 and gave the ecosystem a three-month runway to adopt them.

The driver is data quality. EMV 3DS already lets issuers approve card-not-present transactions without challenging the cardholder, but only when the request carries enough signal for the issuer’s risk engine to make that call. Thin requests force more challenges and more declines. By reclassifying core fields from optional to required, Mastercard Identity Check compliance now depends on the completeness of the data you send, not just the fact that you ran 3DS at all.

Does it apply globally? Yes. This is a Mastercard scheme rule, not a regional regulation, so it reaches any merchant running Mastercard Identity Check on card-not-present transactions, regardless of country. E-commerce 3DS compliance in 2026 means meeting these field requirements everywhere you accept Mastercard online.

What is 3D Secure 2.0, and how does the frictionless flow work?

3D Secure 2.0, also called EMV 3DS, is the authentication protocol that lets a card issuer verify a cardholder during an online purchase by sharing data across three parties: the merchant, the card network, and the issuing bank. The current specification merchants are migrating to is EMV 3DS 2.2. The question of what 3DS 2.0 is and how the 3D Secure 2.0 protocol differs from the old version, the simplest answer to it is data. The legacy 3DS 1.0 redirected shoppers to a static password page. The 3D Secure 2.0 mandate across the networks replaced that with a richer exchange of more than 100 data points passed silently to the issuer.

Frictionless flow

A frictionless 3DS flow is one where the issuer authenticates the cardholder using the submitted data alone, with no password, no one-time passcode, and no app prompt. The issuer’s risk engine reads the EMV 3DS 2.2 cardholder fields, scores the transaction as low risk, and returns an authentication result in seconds. EMVCo estimates the majority of EMV 3DS requests now resolve frictionlessly. For the shopper, the purchase just goes through.

Challenge flow

The challenge flow triggers when the risk engine cannot clear the transaction from data alone. The cardholder gets a step-up prompt, usually a one-time passcode by SMS or a biometric approval in their banking app. Challenges convert worse than frictionless approvals, because every extra step is a chance for the shopper to drop off. The whole point of sending complete data is to keep more transactions in the frictionless lane and out of the challenge lane.

What fields are mandatory from 1 July 2026?

Four data points become mandatory under the Mastercard 3DS required fields for July 2026, with a second tier of fields required whenever you hold them. The table below lists the 3DS mandatory fields Mastercard now expects:

The practical rule that Mastercard and Visa both push is simple. If you collect it, send it. A billing postal code sitting in your database but missing from the authentication request is a field the issuer’s risk engine never sees, and a signal you paid nothing to collect but threw away at the worst moment.

Present versus verified: why the data has to be right

The trap lies here. Passing a field and passing a correct, verified field are not the same thing, and the mandate rewards the second. A billing address line 1 that is stale, mistyped, or autofilled with a delivery address still counts as present, but it weakens the issuer’s risk assessment instead of strengthening it. If you have asked whether your 3DS fields are verified, the honest test is whether the values you send match authoritative records, not whether the fields are simply populated.

This is where 3DS data quality drives the auth rate impact. When the data is complete and accurate, the issuer’s risk engine has a clean signal and clears more transactions frictionlessly. When the data is present but wrong, the request can still authenticate, but the engine trusts it less, leans toward a challenge, or declines. Incorrect 3DS data does not throw a loud error. It quietly erodes your approval rate one transaction at a time, which is exactly why a 3DS data quality check for merchants belongs in your pre-July work, not your post-incident review.

The upside of getting it right is measurable. Visa’s own analysis of its equivalent data mandate reported an authentication success rate lift of around 4 percent, an approval rate lift of around 6 percent, and a sharp increase in frictionless authentication once merchants sent the complete field set. Those figures are Visa’s published numbers for the Visa Secure mandate and are a directional guide to what verified cardholder data in 3DS can do, not a Mastercard guarantee.

Is this the same as the Visa 3DS data mandate?

Largely, yes. Mastercard deliberately aligned its 3DS data requirements with the fields Visa made mandatory under the Visa Secure data field mandate, enforced from 12 August 2024. The difference between the Visa 3DS mandate and the Mastercard 3DS mandate is mostly timing and brand name, not the underlying data.

For most merchants, this is good news. Because the two networks converged on the same EMV 3DS 2.2 cardholder fields, you can build your data collection once and satisfy both. If you have already adapted to Visa in 2024, your Mastercard gap may be small, but it is worth confirming field by field rather than assuming parity.

Your Mastercard 3DS compliance checklist before July 2026

If you are working out how to comply with the Mastercard 3DS July 2026 deadline, work through these steps with your payment service provider or gateway.

Audit what you send today

Pull a sample of recent 3DS authentication requests and check which of the four mandatory fields are actually present and populated. Many merchants collect billing addresses and email at checkout, but never map them into the AReq message. Find those gaps first.

Close the data collection gaps

Where a mandatory field is missing, update your checkout to capture it, and confirm your gateway forwards it into the authentication request. Capture device identifier data, browser IP or device ID, through your provider’s 3DS SDK or browser collection script.

Verify, do not just collect

Run billing address, name, and contact details against authoritative sources so the values you send are accurate, not just filled in. Identity verification for 3DS compliance closes the gap between present and verified, and that is the difference that protects your approval rate.

Monitor after go-live

Track your frictionless rate, authentication success rate, and challenge rate before and after July 2026. A drop in frictionless share is the first sign a field is missing or malformed.

How Shufti helps with 3DS data compliance?

If your checkout spans multiple countries, the hard part of this mandate is not collecting a billing address. It is making sure the name, address, and contact details you pass are accurate across markets where formats, scripts, and authoritative sources all differ. A field that looks fine in one region can be the wrong shape in another, and the issuer’s risk engine treats wrong as worse than absent.

Shufti verifies cardholder data against authoritative records before it reaches the authentication request, so the values feeding your 3DS flow are confirmed, not just captured. Its address verification and identity verification layers were trained natively across 240+ countries, which is where merchants running global checkout usually feel the gap. Cleaner inputs mean a cleaner signal for the issuer, and more transactions that clear frictionlessly.

See how Shufti can verify the cardholder data feeding your 3DS flow before the July deadline and book a 20-minute demo.