In relation to card tokenisation that can be used for the purposes of various payment solutions, does the token that is created from the card details qualify as a “possession element” according to the strong customer authentication (SCA) requirements?
According to article 7 “Requirements of the elements categorized as possession” of the RTS on SCA & CSC “1. Payment service providers” shall adopt measures to mitigate the risk that the elements of strong customer authentication categorized as possession are used by unauthorized parties” and “2. the use by the payer of those elements shall be subject to measures designed to prevent replication of the elements”.
Tokenisation is the process of substituting sensitive data such as the card details with a value that is non-sensitive and has no exploitable meaning. This value, the token, can be used in order to process the payment without actual card details being exposed while these are held safe in a secure token vault or a device secure component based on implementation-specific methods and according to security best practices.
Tokenisation on payment processing is a security measure that has not been developed in order to provide authentication means to the payer but to mitigate risks derived from keeping actual card details from environments where data can be vulnerable and, if breached, used for illegal purposes.
Tokenisation on payment processing can be used in various use cases that may cover Card-Present (CP) and/or Card-non-Present (CnP) transactions and typically fall into the following broad categories:
A. Digital wallets that can facilitate CP transactions through close proximity at the POS and/or CnP transactions such as e-commerce or in-app transactions:
Typically, in these cases the token issuance process involves interaction of the cardholder with a token service provider and a card issuer via the digital wallet and the token resides on the payer’s device (e.g. secure element, host card emulator) in order to facilitate close proximity at POS payments.
CnP transactions such as e-commerce or in-app transactions may utilise either the token that resides on the consumer’s device or a token that resides on a shared storage that merchants can interact with by implementation-specific methods.
Consumer access to the payment token may be controlled either by the consumer device itself or a digital wallet app that will require consumer credentials.
B. Card-on-File (CoF) transactions that are used to facilitate CnP transactions such as one-click orders and in-app transactions:
Typically in these cases the cardholder maintains a relationship with a merchant (mobile or web) and the merchant is the one that triggers the token issuance process following the consent of the cardholder. The token is bound to both the cardholder and the merchant and is restricted in its usage to the specific token acceptance environment (e-commerce platform or merchant application) and may also add further restrictions based on the specific device or certain transaction types.
The token may reside on the merchant’s environment or on a shared storage that merchants can interact with by implementation-specific methods.
Consumer access to the payment token will require consumer credentials associated with the merchant’s platform.
Tokenisation on payments processing is also used widely in order to facilitate Merchant Initiated Transactions (MIT) following a mandate that has been given from the payer to the payee through an SCA process. As already clarified in a previous Q&A 2018_4031 transactions initiated on the basis of such a mandate can be qualified as payee initiated transactions, provided that those transactions do not need to be preceded by a specific action of the payer to trigger their initiation by the payee.
Article 4(30) of Directive 2015/2366/EU (PSD2) defines possession as ‘something only the user possesses’.
Article 7(1) of Commission Delegated Regulation (EU) 2018/389 prescribes that ‘payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.’ Paragraph 2 of the same Article continues by specifying that ‘the use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.’
Article 24(1) of the Delegated Regulation further prescribes that ‘payment service providers shall ensure that only the payment service user (PSU) is associated, in a secure manner, with the personalised security credentials, the authentication devices and the software’.
In addition, the EBA clarified in the EBA Opinion on the elements of strong customer authentication under PSD2 (EBA-Op-2019-06) that ‘possession does not solely refer to physical possession but may refer to something that is not physical’ (paragraph 24) and that ‘approaches relying on mobile apps, web browsers or the exchange of (public and private) keys may also be evidence of possession provided that they include a device-binding process that ensures a unique connection between the PSU’s app, browser or key and the device’ (paragraph 26). This means that 'approaches relying on the exchange of (public or private) keys may also be evidence of possession'.
Finally, recital 6 of the Delegated Regulation clarifies that the security features of the elements categorised as ‘possession’ can be algorithm specifications, key length and information entropy.
In relation to the above, and for approaches currently observed in the market, tokenised card payment solutions may constitute a possession element because, depending on the practical implementation of the solution, they may:
(i) provide evidence that the payment service user is in possession of the digitised version of the payment card (the process of tokenisation may bind the cardholder and the token to a trusted device); and
(ii) mitigate the risk the token is used by unauthorised parties and prevent replication of the element, including by substituting the card details with a token with no exploitable meaning, applying domain restrictions, binding the token to a trusted device, and verifying the identity of the cardholder by provisioning the payment card details securely.
This requires, in accordance with Article 97(1)(c) of PSD2, the application of SCA at the time of the issuance of the token, which includes provisioning of the payment card details and the association of the token with the device under Article 24 of the Delegated Regulation.
Therefore, the tokenisation of card details may meet the requirements of Article 7(1) of the Delegated Regulation, if the payment service provider of the payer (the issuer) is involved in the process of issuance of the token directly or indirectly (e.g. through an outsourcing agreement with a third party, i.e. a token requestor such as a wallet provider in the case of digital wallets or a merchant in the case of cards on file). This may allow the issuer to meet the requirements of Article 7(1) to adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possessions are used by unauthorized parties, in particular through the verification of the identity of the cardholder and the binding of the token to a trusted device.