What the 3DS Requestor Must Disclose Before an App Collects Device Data
Teams building app-based 3D Secure usually discover the disclosure obligations at the worst possible moment, which is during app store submission, with a release date already committed. The requirements are not onerous. They are just easy to miss, because they sit in a specification that engineering reads and a compliance process that engineering does not own.
This is what the protocol expects of a 3DS Requestor app, and where regional privacy rules change the picture.
Why there is anything to disclose
App-based authentication works because the SDK collects a rich set of device data through operating system APIs and delivers it to the issuer for risk assessment. That set includes device manufacturer and model, operating system and version, geolocation data including IP address and locale, device fingerprint, telecom data such as SIM metadata, and interface preferences.
Some of that is sensitive user data by any reasonable definition, and certainly by the definition operating system providers apply. Collecting it in an app triggers obligations, both from the platform and from applicable privacy law.
Worth noting what happens to the data, because it shapes the disclosure. The SDK encrypts it using the Directory Server public key. It passes through the 3DS Server, which cannot read it. The Directory Server decrypts it and passes it to the Access Control Server. All device information is accessed only by the ACS, and the requestor cannot access or modify device-level data during an authentication request.
That is a genuinely privacy-protective design, and it is worth saying so in your own disclosures. The merchant collects this data in the sense that their app invokes the collection. They do not receive it.
What must be disclosed, and when
Two distinct moments, with different requirements.
At app submission. In line with regional regulations and operating system provider policy, the 3DS Requestor must provide prominent disclosure of the use of this data in the application at the time of submission to the operating system provider. That disclosure has to specify which data elements may be collected and used as part of a 3DS authentication.
This is the one that catches people. It is not a privacy policy update. It is a statement made to the platform as part of submission, and it needs to be specific about elements rather than gesturing at device data in general.
At installation. The requestor app must prominently disclose to the user that the app will access and use sensitive user data, giving phone number as an example, and that it will provide access to that data to the 3DS SDK and the ACS for transaction risk assessment.
Both halves of that second disclosure matter. The user is being told that data is accessed, and separately that it is passed onward to named parties for a named purpose. A disclosure that covers collection but not onward provision is incomplete.
The consent rule that surprises engineering teams
When sensitive user data is invoked for a 3DS authentication, the SDK must verify user consent and permission before requesting that data from the requestor app, implemented in accordance with the permission designation in the SDK device information specification.
And then the rule that determines how you build it. The 3DS SDK must never prompt for user consent or permission for any data within a 3DS authentication.
The SDK checks consent. It does not ask for it. Consent has to have been obtained already, by the app, through the platform’s own permission mechanisms, before the transaction starts.
The practical consequence is that your permission strategy is a product decision made at onboarding, not a runtime decision made at checkout. If a permission has not been granted, the SDK proceeds without that element rather than interrupting the payment to ask. Which is correct behaviour, and also means that a poorly designed onboarding flow quietly degrades your authentication data for the lifetime of the installation.
Teams that treat permissions as something to request at first use, in context, with a clear explanation of the benefit, end up with materially better data than teams that bundle everything into an unexplained prompt on first launch. That is an ordinary mobile product problem, but it has an authentication consequence most product managers do not know about.
Populate fully, within what you are permitted
EMVCo strongly recommends populating all fields accessible to the SDK, based on device and runtime permissions, to better inform network and issuer processing systems.
The qualifier is the governing part. The recommendation is to supply what is genuinely available given the device and the permissions granted. It is not an instruction to maximise collection, and it does not override platform policy or applicable law.
The related discipline is about accuracy rather than volume. Incomplete or incorrect information, including placeholder values that do not accurately represent the cardholder or the transaction context, can lead to increased challenges or declined authentication. Filling a field with something to avoid leaving it empty is worse than leaving it empty, because the ACS treats it as an assertion about the transaction.
Where regional privacy rules bite
The specification accommodates the fact that privacy mandates differ by region, and one accommodation is worth understanding because it is often misread.
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 the cardholder ticked at checkout. EMVCo notes this can be helpful in regions with privacy mandates that prohibit providing billing and shipping address details.
So it functions as a privacy-preserving substitute where full address data cannot be sent. But the guidance is explicit that requestors should still provide billing and shipping address information where no privacy mandate prevents it, even when the indicator has been supplied. The indicator supplements the addresses; it does not replace them.
There is also a caution about indiscriminate use. Some requestors always populate this indicator as part of checkout even where it carries no meaning, for instance on digital goods where a shipping address is irrelevant. That is not helpful to the ACS and it is a small example of a general principle: a data element populated reflexively conveys less than one populated because it is true and relevant.
This is a cross-functional problem
The reason these requirements get missed is structural. The specification lives with engineering. App submission lives with mobile release management. Privacy disclosures live with legal or compliance. Authentication performance lives with payments. None of them owns the whole obligation.
A workable arrangement is to treat the disclosure set as a release artefact with a named owner, reviewed whenever the SDK version changes or the device information specification is updated. Since all 3DS components are expected to support the latest device information version to maintain compatibility with operating system platform providers, and major operating system releases arrive at least annually, that review will recur whether or not you plan for it.
A short pre-submission checklist
Before your next app submission, confirm the following.
- The platform submission disclosure names the specific data elements that may be collected for 3DS authentication, rather than describing device data generically.
- The installation-time disclosure covers both access to sensitive user data and onward provision of it to the SDK and ACS, with the purpose stated.
- No consent prompt is triggered from within an authentication flow.
- Permission requests are placed where a user can understand why they are being asked, and the app degrades gracefully where permission is refused.
- Address and cardholder data are populated accurately rather than reflexively, with the Address Match Indicator used where it is meaningful and not as a default substitute.
None of this is legal advice, and requirements vary by jurisdiction and platform. Organisations should confirm what applies to their own markets and app stores with their own privacy and compliance function.
Frequently Asked Questions
Can the SDK ask the cardholder for permission during a transaction?
No, and this is stated as an absolute. The 3DS SDK shall never prompt for user consent or permission for any data within a 3DS authentication. Consent is obtained by the app in advance through the platform’s own permission mechanisms, which makes it an onboarding design decision rather than a runtime one.
What happens if the cardholder refuses a permission?
The element simply is not available, and it must be declared as a device parameter not available rather than omitted or filled with a placeholder. The authentication proceeds with less data. That is why permission design at onboarding has a direct and lasting effect on authentication quality.
Does the merchant receive the device data it helps collect?
No. The app invokes the collection, but the data is encrypted to the Directory Server and accessed only by the ACS. That distinction is worth making explicitly in your own disclosures, because it is more privacy-protective than most users would assume.
Is this legal advice?
No. Requirements vary by jurisdiction and by app store, and the specification requirements described here sit alongside rather than replace applicable privacy law. Organisations should confirm what applies to their own markets and platforms with their own privacy and compliance function.
Planning an app-based 3DS integration? ActiveSDK is the GPayments mobile 3DS SDK. Speak with a 3DS specialist about device data collection and integration planning.
