Issuers can only assess the risk data they actually receive. That sentence is uncontroversial and almost never acted on, because the data quality problem in 3DS is not a strategic one. It is a hundred small encoding and population decisions made by different people at different times, most of which nobody has ever reviewed.
3DS requestor data quality is the acquiring-side half of the frictionless problem. Issuer risk model tuning is the other half, and it belongs to the issuer. This half belongs to you.
The failure mode that costs the most
Start here, because it is the one that does active harm rather than passive harm.
Incomplete or incorrect information, including dummy values that do not accurately represent the cardholder or the transaction context, can lead to increased challenges or, at worst, declined authentication.
Read that carefully. A placeholder is not a neutral act. When you populate a field with a default string to avoid leaving it empty, you are making an assertion about the transaction, and the ACS treats it as one. An issuer whose risk model sees the same fabricated address across thousands of transactions from one requestor learns something about that requestor, and what it learns is not helpful to you.
Empty is better than wrong. Accurate is better than both.
Time is where most implementations go astray
The 3DS Server must provide all date and time data converted from local time into Coordinated Universal Time, so that the Directory Server and ACS can interpret them correctly during checks and risk analysis. This applies to the purchase date and time and to all the date-related elements in the merchant risk indicator.
The consequence of getting it wrong is not subtle. When validating the authentication request, the Directory Server or ACS may respond with an error where the purchase date and time has not been converted to UTC.
This is worth auditing specifically, because time zone handling is the classic place where a system works perfectly for months and then breaks at a daylight saving transition, or behaves differently for one region’s traffic than another’s.
Encoding rules that produce silent rejections
Several fields have defined formats, and getting them wrong produces validation failures rather than degraded results.
Country and state. Billing and shipping address country values follow the three-digit ISO 3166-1 standard. State values follow ISO 3166-2, encoded in one to three alphanumeric characters, where the standard includes both country and subdivision but only the subdivision portion is used in the field.
Cardholder name. In versions 2.1.0 and 2.2.0 special characters are not supported, and the name must use the defined ASCII character set. Accented characters have to be converted to their unaccented equivalents. Version 2.3.1 permits special characters in the cardholder name field. If you operate across markets with non-ASCII names and run a mixed-version estate, this needs handling per version rather than globally.
Browser language. The maximum length is thirty-five characters when all optional information is present, but the 3DS Server should supply the main language tag, which has a maximum of eight characters. Passing the full tag where the main tag is expected is a common truncation error.
IP addresses. Encoded as strings, following the relevant standards for the address version in use. Which address matters too: supply the app IP address for app-based authentications and the browser IP address for browser-based ones. The browser value is the public IP address of the browser connecting to the requestor. The app value is the external IP address the requestor app uses when it connects to the requestor environment. EMVCo describes this as key information used by the ACS for risk analysis, and stresses providing accurate and meaningful values.
URLs. A fully qualified URL is defined as an absolute URL string with an https scheme, encoded in UTF-8 using a defined set of code points, and does not contain credentials. Components may validate the format, so non-conformance produces errors.
Email. The delivery email address follows the same format, length and value rules as the other email elements in the specification.
Screen colour depth. In versions 2.1.0 and 2.2.0 only certain values are accepted, and devices increasingly return values outside that list. The recommendation is for the 3DS Server to supply the closest lower listed value to avoid an error in response. Version 2.3.1 resolved this by permitting any value in a broad range.
Address data and the privacy trade-off
The address match indicator lets the requestor tell the ACS whether the cardholder’s billing and shipping addresses are the same, typically reflecting a checkbox at checkout. EMVCo notes it can be helpful in regions with privacy mandates that prohibit providing billing and shipping address details.
Two things people get wrong.
The indicator supplements addresses rather than replacing them. Requestors should still provide billing and shipping address information where no privacy mandate prevents it, even when the indicator has been supplied.
And it should mean something. EMVCo observes that some requestors always populate the indicator as part of checkout even where it is not meaningful, for example on digital goods where a shipping address is irrelevant. A field populated reflexively conveys less than one populated because it is true.
Two elements worth adding if you are not sending them
Browser user and device identifiers. In app transactions the SDK supplies user and device identifiers. Equivalent browser-channel elements were introduced in version 2.3.1, and the requestor may be able to supply them, for example where cookies are in use. The ACS uses them for risk analysis and to better identify the device and the cardholder. Most browser-channel implementations do not populate these, and they are among the more directly useful additions available.
Prior transaction reference. Where a transaction relates to an earlier one, the requestor can reference the previous transaction’s ACS transaction identifier. Renewing a recurring transaction and a purchase complementing an earlier one are both named use cases. The ACS should then be able to retrieve the previous authentications and take their context into account.
How to audit this
You do not need a project. You need a sample.
Take a few hundred recent authentication requests across your traffic and check three things per field: is it populated, is it accurate, and does it conform to the format the specification requires. Weight your attention by how much of your volume flows through each integration path, because a data defect in the path carrying sixty per cent of your transactions is a different problem from the same defect in a legacy route.
Then look at which fields are systematically empty. Those are the ones where somebody made a decision, usually years ago, that nobody has revisited.
Frequently Asked Questions
Should we populate a field with a placeholder rather than leave it empty?
No. Incomplete or incorrect information, including dummy values that do not represent the cardholder or transaction, can increase challenges or cause declined authentication. Leaving a field empty tells the issuer you do not have it. Filling it with a default tells the issuer something untrue.
Which IP address should we send?
The app IP address for app-based authentications and the browser IP address for browser-based ones. They are different things: the browser value is the public IP of the browser connecting to the requestor, and the app value is the external IP the requestor app uses to reach the requestor environment. EMVCo describes both as key information for risk analysis.
Can we send accented characters in the cardholder name?
Not on versions 2.1.0 and 2.2.0, where special characters are not supported and must be converted to their ASCII equivalents. Version 2.3.1 permits them. If you run a mixed-version estate across markets with non-ASCII names, handle this per version.
What should we do when a device returns a screen colour depth the specification does not list?
On versions 2.1.0 and 2.2.0, supply the closest lower listed value to avoid an error in response to the authentication request. Version 2.3.1 addressed this by allowing any value across a broad range.
Reviewing what your 3DS Server is actually sending? ActiveServer is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist about request data quality.