More Data, Better Approval Rates: Making the Most of Mastercard's 3DS Enhanced Data Standards

For any merchant taking card payments through Acquired, the data you send in a 3DS authentication request is one of the most cost-effective levers you have for lifting approval rates, and it tends to be one of the most overlooked. Mastercard is fairly direct about the value of it: richer authentication data can lead to better risk decisioning, more frictionless approvals, higher conversion, and less fraud. With its Enhanced Data Standards, Mastercard has also set a minimum data bar for every authentication request. That minimum is a modest one, but the more interesting story is what happens when you go well beyond it.

The opportunity hiding in your authentication request

Every card-not-present transaction you send for 3DS authentication carries a set of data fields describing the cardholder, their address, and the device they are using. For a long time most of those fields were optional, and plenty of merchants simply left them blank, which meant leaving a fairly easy win on the table.

It helps to think about how issuers actually make their decisions. An issuer approves a transaction based on how confident it is that the person behind it is genuine, and that confidence comes almost entirely from the data in front of it. When an authentication request arrives full of accurate, consistent detail, the issuer is more likely to recognise a legitimate customer and let them through with little or no friction. When the request is thin, there is very little to go on, so the cautious response is to add a step-up challenge or, in some cases, to decline altogether. Supplying more data can give the issuer more reason to approve.

The evidence points the same way. According to Mastercard, “Enhanced data can help improve risk decisioning by Mastercard, Access Control Servers (ACSs), and issuers, which may result in better user experience, increased frictionless rates, higher conversion, and reduced fraud for merchants” (Source: Mastercard, GLB 12982.1). Visa, which brought in its own enhanced data requirements earlier, reports that when merchants populate the priority data elements they can see an authentication success rate lift of around 4 percent and an approval rate lift of around 6 percent (Source: Visa, Better Data Best Practices Guide for Visa Secure). For most businesses that is often a faster return than reworking the checkout flow itself.

There is a fraud benefit alongside the conversion one. Card-not-present fraud is estimated to cost in the region of 15 billion US dollars a year, and richer data does not only approve good customers more quickly, it also gives issuers sharper signals for spotting the fraudulent ones. Over time that tends to mean fewer chargebacks and stronger liability protection on your side of the transaction.

What “more data” actually looks like

None of these fields are new. They have been part of the EMV 3DS specification for years, and they fall into three broad groups. The first covers the cardholder themselves: their name, email address, and phone number, whether home, work, or mobile. The second covers address and delivery, meaning billing address line 1, shipping address line 1 when you are sending physical goods, and the city, postal code, state, and country wherever you hold them. The third is technical and device data, which includes the browser or device IP address, a device ID, device location, and details such as browser screen dimensions, language, and time zone.

In practice the guiding principle is that if you already collect it, you should send it. For most merchants this information is already sitting in their systems and the only problem is that it never gets passed through to the authentication request. Billing postcode and email address are the two fields most often left behind, and they also happen to be among the most useful to an issuer.

The minimum bar, and why it is only a starting point

Alongside the opportunity, Mastercard has set a floor. Under its Identity Check programme, Requirement 209 states that merchants and 3DS operators must ensure every Authentication Request contains at least one fully populated and accurate field from each of three categories, unless local regulation prevents it:

Cardholder identifier	Address / delivery	Technical
Email address	Billing address line 1	IP address (browser or device)
Phone number (home, work, or mobile)	Shipping address line 1	Device ID
Name		Device location (lat/long)
		SDK App ID (Android fallback)

Put plainly, that means one cardholder identifier, one address field, and one technical field in every request. This minimum took effect on 1 April 2026, and Mastercard is phasing in monitoring through its Data Integrity Monitoring Programme, with further detail promised in a separate announcement. Mastercard also sends an enhanced data flag in the authentication messages that indicates whether a given request meets the standard.

It is worth being clear that this is the floor rather than the goal. Requirement 209 is the standard Mastercard expects, but a request carrying only the bare minimum still leaves approval rate unclaimed, because issuers tend to reward completeness rather than the bare pass. The merchants who get the most out of this are the ones who treat the minimum as a baseline and send everything they reasonably hold.

For Acquired merchants the starting position is a good one. Acquired already captures and passes the browser fields, including the browser IP address and the screen height and width, so those particular fields are already being passed. What is left is mostly the cardholder and device detail, and much of that can be stored against your Acquired Customer ID rather than sent on every single request, which keeps the integration work light.

Your action plan

For most teams this is a plumbing exercise rather than a question of capturing new data, which is exactly why the return on it is so good. A practical way to approach it is to work through four questions in order.

1. What data do you already have? Take stock of what your systems actually hold about each transaction, from the cardholder’s name, email and phone, through billing and delivery details, to the device data captured at checkout. Most merchants are sitting on more than they realise, and remember that through Acquired the browser data is already being handled.
2. What are you holding but not sending? Compare that against what is actually going out in your authentication requests. The gap between what you have and what you pass through is usually where the quickest wins sit, and billing postcode and email are the two fields that most often go missing.
3. What more could you reasonably get? Where a field is genuinely absent, think about how you might capture it, but bear in mind that this does not always mean asking the customer for more. A good deal of the most valuable data is collected automatically in a normal checkout flow, and other details may already exist elsewhere in your records. Adding friction to the checkout to chase a single field can cost you more than the field is worth, so it is worth weighing case by case.
4. If you are collecting it, are you validating it? Sending data is only half the job. A phone number or postcode that is incomplete or inaccurate does little for your authentication outcomes and can work against you, because the value of these fields lies in being both complete and accurate rather than simply present. It is worth checking that what you capture is being validated properly at the point of entry. That is a larger topic in its own right, and one we will come back to in a separate article.

Sending complete authentication data used to be one of those quietly sensible practices that nudged approval rates up. Under the Enhanced Data Standards, and with Visa already down the same road, the direction of travel is clear, and there is a real payoff for those who provide more than the minimum. Clear the floor, then keep going, because richer data remains one of the most cost-effective levers most merchants have for approving more genuine customers and turning away more fraud. If you are unsure what your current requests contain, the Acquired Implementations team can help you review which data fields your integration is currently passing.

Actual results may vary depending on your integration, data quality and individual issuer behaviour.

Sources and references

• Mastercard, GLB 12982.1, “Mastercard Global Identity Check Authentication Methods for Multi-Factor Authentication and Enhanced Data Standards Requirements and Updates,” 3 February 2026 (Requirement 209, effective-date table, and customer benefit statement).
• Mastercard Identity Check Program Guide, the authoritative reference for required data elements, cited as the binding standard by the Mastercard Security Rules and Procedures, Merchant Edition, section 6.2.2.1 (Acquirer Authentication Strategy).
• EMVCo 3-D Secure specification for field formats and definitions.
• Card-not-present fraud cost figure: Boston Consulting Group Authentication Market Study, North America, January 2025 (cited in GLB 12982.1).
• Visa authentication and approval-rate uplift figures: Visa, “Global — Better Data Best Practices Guide for Visa Secure” (Visa Secure Services Library, Merchant Resources). Uplift based on merchants populating more than 50 percent of the priority data elements; dataset comprises 95 percent of Visa Secure global transactions, February to March 2022.