Every issuer has a cardholder who buys from the same three merchants every week and gets challenged every time. The risk model is not wrong exactly. It just has no way of knowing what the cardholder knows, which is that this particular merchant is entirely routine.
The trust list is the protocol’s answer to that. It lets the cardholder tell the issuer, during a challenge they are already completing, that this merchant should not require one next time.
It is a specified feature, it has been in the protocol for several versions, and a striking number of issuers have never enabled it.
What the feature does
During a 3DS challenge, when the issuer is in direct communication with the cardholder, the issuer or ACS can offer the cardholder the option to add the merchant they are currently paying to a trust list.
The important design point is that the issuer stays in control of which merchants get offered. This is not a cardholder-driven free-for-all. The issuer decides which merchants are eligible to be proposed, and can weigh the risk associated with the merchant type and market alongside the cardholder’s own transaction history. An issuer might choose to offer the option only for low-risk merchants, or only to cardholders with an established pattern.
On subsequent transactions with the same cardholder and merchant, the trust list status becomes available as an input, and the ACS may apply a trust list exemption and complete the transaction without a challenge.
A terminology note for anyone on an older estate
If your documentation, your ACS configuration screens or your internal vocabulary still says whitelist, that is version 2.2 language. Version 2.3.1 uses the term trust list, replacing whitelist and whitelisting.
This matters more than terminology usually does, because teams searching their own specification documents for the older term will not find the current requirements, and teams reading current EMVCo material while running 2.2 configuration will not immediately recognise that they are looking at the same feature.
Two management models, with different operational consequences
The feature can be run in two ways, and the choice has real implications.
Managed by the ACS. The issuer’s ACS holds the trust list management system and displays the prompt during a challenge. The list belongs to the issuer, the issuer sets the policy, and the data stays within the issuer’s authentication environment.
Managed by the Directory Server. The DS holds the trust list management system under an agreement with the ACS, and manages the list on the ACS’s behalf. The ACS still displays the prompt to the cardholder during the challenge, but the status is maintained and communicated at the DS. In this model the DS can set the relevant challenge indicator on the way through and update the list based on what the ACS reports back.
The second model reduces what the issuer has to build, which is why it appeals to smaller programmes. The trade-off is that the trust list becomes a scheme-level asset rather than an issuer-level one, and the issuer has correspondingly less direct control over its contents and lifecycle.
There is a third option worth naming, which the specification explicitly does not prevent. Issuers can offer cardholders alternative channels for managing their trusted beneficiaries, for example through online banking. For many issuers that is a better cardholder experience than a checkbox on a challenge screen, and it need not be either-or.
The link to the trusted beneficiary exemption
In markets in scope of the revised Payment Services Directive, the trust list feature may be used for the trusted beneficiary exemption.
Two cautions attach to that sentence and both matter.
First, may. The protocol feature and the regulatory exemption are related but not identical. Whether an exemption is permissible, on what basis, and what evidence supports it are questions determined by the applicable rules in the relevant jurisdiction. Organisations should confirm requirements for their own markets rather than assuming that enabling a protocol feature satisfies a regulatory test.
Second, this is a European framing. Issuers outside PSD2 scope can use the trust list purely as a friction-reduction and cardholder-experience feature, with no regulatory dimension at all. The value proposition is different but it is not absent.
The operational detail that catches people out
Here is the requirement that quietly breaks trust list implementations.
The ACS uses merchant information to manage the list, drawing on elements such as the merchant name, the 3DS Requestor name and the 3DS Requestor ID. It is therefore essential that the merchant and the 3DS Server provide consistent merchant information across the trust list enrolment and all subsequent transactions.
Read that again if you are about to enable this feature. If a merchant’s identifying data varies between transactions, because of a gateway migration, a rebrand, inconsistent population by different integrations, or simply a change in how a name is formatted, the matching fails. The cardholder enrolled a merchant and is still being challenged, and from their point of view the feature is broken.
This is not an issue an issuer can fix alone, because the data originates on the acquiring side. What an issuer can do is monitor for it. A trust list that accumulates enrolments but produces few exemptions is the signature of a matching problem rather than a policy problem.
Discovering support before requesting
On the acquiring side, the ACS Information Indicator in card range data can signal both that the ACS supports the trust list and, separately, that it supports the trust list exemption. These are distinct signals for a reason. An ACS may be able to prompt a cardholder to enrol a merchant without being able to apply an exemption on the basis of that enrolment.
The 3DS Server can check these before setting the relevant challenge indicator, which avoids requesting behaviour the ACS cannot deliver.
Where the prompt sits on the challenge screen
The trust list prompt shares challenge-screen real estate with device binding, and the specification provides a way to indicate whether these prompts should appear above or below the action buttons.
That sounds trivial. It is not. A challenge screen that asks the cardholder to complete an authentication and simultaneously offers two optional enrolments is a screen with three decisions on it, at the exact moment the cardholder wants to finish paying. Placement, wording and whether you offer both prompts on the same challenge are genuine design decisions with measurable consequences for both completion and enrolment.
EMVCo maintains interactive UI and UX design guidelines covering these screens, which are worth reviewing before your design team starts from scratch.
Is it worth enabling
The honest answer is that it depends on your portfolio.
The feature pays off where you have repeat cardholder-to-merchant relationships that are currently being challenged, and where your merchant data is consistent enough for matching to work. Subscription services, regular retail, and travel booked through the same platform all fit that pattern.
It pays off less where transactions are one-off, where challenge rates are already low, or where merchant identification in your inbound traffic is messy. In that last case, fixing the data is the prerequisite, not the feature.
What it should not be treated as is a way to reduce authentication rates in aggregate. The trust list narrows challenges to the transactions that warrant them, on the cardholder’s own instruction. That is a better outcome than a blanket reduction in scrutiny, and it is a more defensible one if anyone asks.
Frequently Asked Questions
Is the trust list the same thing as a whitelist?
Yes. It is the same feature under a different name. Version 2.3.1 of the specification uses the term trust list, replacing whitelist and whitelisting as used in version 2.2. If your configuration screens or internal documentation still say whitelist, you are looking at the same capability.
Can cardholders manage their trust list outside a challenge?
Yes. The specification does not prevent issuers from providing alternative channels for cardholders to manage their trusted beneficiaries, online banking being the obvious example. For many issuers that is a better experience than a checkbox on a challenge screen, and the two approaches are not mutually exclusive.
Who decides which merchants a cardholder can add?
The issuer. The issuer controls which merchants are proposed and can weigh the risk associated with the merchant type and market alongside the cardholder’s own transaction history. An issuer might offer the option only for low-risk merchants, or only to cardholders with an established pattern.
Why would enrolments not translate into fewer challenges?
The most common cause is inconsistent merchant identification. The ACS matches using merchant information such as the merchant name, requestor name and requestor ID, and consistency across enrolment and subsequent transactions is essential. Where that data varies between transactions the matching fails, and a trust list that accumulates enrolments but produces few exemptions is the signature of that problem.
Reviewing what your ACS supports? ActiveAccess is the GPayments Access Control Server solution for issuers and processing centres. Speak with a 3DS specialist about trust list and exemption configuration.