Every EMV 3D Secure (EMV 3DS) authentication request can tell the issuer whether the merchant wants the cardholder challenged. The field is the 3DS Requestor Challenge Indicator (threeDSRequestorChallengeInd). It is a preference, not an instruction: the issuer’s Access Control Server (ACS) makes the final decision. Used well, it gives the issuer context it cannot see. Hard-coded to one value, it either adds friction or does nothing.
The values and when each fits
EMVCo defines the values below. If the field is omitted, the ACS treats it as 01, no preference.
|
Value |
Meaning |
When a merchant typically sends it |
|
01 |
No preference |
The default when the merchant has no particular reason to steer the outcome |
|
02 |
No challenge requested |
Low-risk transactions where the merchant would rather avoid friction |
|
03 |
Challenge requested: 3DS Requestor preference |
The merchant has its own reason for concern, such as signs of account takeover or a high-risk basket |
|
04 |
Challenge requested: mandate |
A rule requires strong authentication, for example setting up a recurring payment in a market with SCA rules |
|
05 |
No challenge requested: transaction risk analysis already performed |
Where the acquiring side has applied a transaction risk analysis exemption (how SCA exemptions travel through the 3DS messages) |
|
06 |
No challenge requested: data share only |
The merchant wants to share data with the issuer without authentication |
|
07 |
No challenge requested: strong authentication already performed |
Strong authentication has already taken place under an arrangement that permits it (delegated authentication) |
|
08 |
No challenge requested: use whitelist exemption if no challenge required |
The cardholder has added the merchant to the issuer’s trusted list |
|
09 |
Challenge requested: whitelist prompt requested if challenge required |
The merchant wants the issuer to offer trusted-listing during any challenge |
Values 01 to 04 exist in EMV 3DS 2.1.0. Values 05 to 09 arrived with version 2.2.0. Values 10 to 79 are reserved for EMVCo, and 80 to 99 for Directory Server use, so a card scheme may define its own.
The issuer still decides
An ACS can challenge after a no-challenge request if its own risk assessment demands it, and it can authenticate frictionlessly after a challenge request if it is confident. Requesting no challenge does not by itself change liability either: protection follows the authentication outcome and the card scheme’s rules. In the EEA and UK, when an exemption requested from the acquiring side is applied, fraud liability generally moves to that side, so values 05 and 08 carry consequences beyond friction.
Common mistakes
- Sending 04 on every transaction. It tells issuers that strong authentication is mandatory when it is not, and adds friction for no protection the merchant would not otherwise get.
- Sending 02 on every transaction. Issuers learn nothing from a value that never changes, and the merchant still sees challenges.
- Sending 05 without an agreed transaction risk analysis arrangement with the acquirer.
- Sending 2.2.0 values to card ranges that only support 2.1.0. The 3DS Server should check the version each range supports, which it learns from card range data (card range data).
- Requesting no challenge while sending thin data. An issuer with little information is more likely to challenge regardless (requestor data quality).
Measuring whether it works
Split authentication outcomes by the indicator value sent. If 02 and 01 produce the same challenge rate for a given issuer, the preference is having no effect there. If 03 rarely produces a challenge, issuers may already be confident in those customers. Track fraud on frictionless outcomes after 02 requests, because that is where a merchant’s preference has taken risk off the table. How merchants should measure 3D Secure performance sets out the wider framework.
Frequently asked questions
Does the issuer have to honour a request for no challenge?
No. The indicator is a preference. The issuer’s ACS can still challenge if its risk assessment or applicable rules require it.
What happens if the merchant leaves the field out?
The ACS treats a missing indicator as 01, no preference.
Does requesting a challenge give better liability protection?
Liability follows the authentication outcome and scheme rules, not the request. A completed challenge produces a full authentication; so does a frictionless authentication. The request only influences which of those happens.
Which value should be sent when setting up a recurring payment?
In markets with strong customer authentication rules, set-up of a recurring arrangement normally needs strong authentication, so 04 is the usual choice. Confirm local rules and your acquirer’s guidance, and see merchant-initiated authentication for what happens afterwards.
Can card schemes add their own values?
Yes. EMVCo reserves 80 to 99 for Directory Server use, so a scheme can define values for its own programmes. Check each scheme’s documentation before sending them.
Getting the indicator right
GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs and merchants. To review how your checkout sets the challenge indicator, speak with a GPayments 3DS specialist.