.png)
The implementation of the 3DS 2.0 protocol is undoubtedly good news fore-commerce platforms. Its functionalities meet the requirements of the EU's Second Payment Services Directive (PSD2), which is designed to increase banking security in Europe as well as simplify the adoption of new technology. Improvements in security and user experience are expected to be the definitive driver for online transactions to take off.
3DS 2.0: What is it?
3DS or 3D-Secure is a security authentication protocol for card-not-present (CNP) payments. It is a set of operational standards that adds a layer of security to online or digital payment transactions. The protocol is applied in the issuer domain, the acquirer domain, and the payment network domain. Hence its name, 3D, which refers to the three domains involved.
It was launched in 1999 with the aim of protecting users from possible fraud in their online purchases. However, after two decades in use, the protocol proved insufficient to guarantee convenient and secure transactions.
Among other things, authentication with 3D Secure 1.0 authentication was executed in a pop-up window. This logically generated mistrust in users, who perceive popups as bothersome marketing or potentially malicious software, leading them to give up and abandon the shopping cart. Moreover, it had compatibility issues with mobile devices and the loading speed of the authorisation page was awfully slow.
To address these limitations and meet the requirements of PSD2, an updated version knownas 3DS 2.0 was developed. Specifically, the changes are aimed at facilitating strong client authentication processes and secure communication.
What is the goal of 3DS 2.0?
In short,the main objective of 3DS 2.0 is to optimise authorisation and payment processes. This is in line with the Regulatory Technical Standards (RTS) of the PSD2, effective from September 2019. The requirements of these regulations include strong customer authentication and secure communication.
These measures aim to increase the levels of account data protection and improve the security of payment services. In this respect, the RTS envisage measures to improve the compatibility of authentication on mobile devices and the integration of digital wallets.
In particular, the use of dynamic methods is suggested for strong client authentication (SCA). For example, replacing static passwords with biometric data or token-based authentication. Dynamic methods represent a continuous approach to security and authentication, which is harder to sidestep than simple one-time-only passcodes or question-based authentication.
How does strong client authentication work with 3DS 2.0?
Let’s say,for example, that you want to make an online purchase or payment. After submitting your payment details, the merchant will forward this information to the issuer. The sender must analyse the transaction and determine its level of risk in order to authenticate it.
It is likely that the institution will ask the cardholder to follow additional security guidelines. A 3DS 2.0 protocol will generally require the user to authenticate his or her identity by providing:
· A one-time password or code sent by email or SMS
· Biometric information, such as a face scan or fingerprint
The issuer and the seller can also share rich data, which supports the approval or denial process of the transaction. This information enables risk-based authentication decisions to be made.
This involves using transactional data to establish risk analysis criteria. It may include factors such as:
· Transaction value
· Transaction history and purchase behaviour
· Information about the device
· Type of customer (new or returning)
Ultimately, this will allow the issuer and merchant to refine their fraud detection systems. The assessment of the variables allows the identification of risk levels by correlating authentication approvals and rejections with chargeback rates.
On the other hand, it improves the user experience and hopefully contributes to reducing shopping basket abandonment.
Strong customer authentication rules and exemptions
The PSD2 Regulatory Technical Standards (RTS) provide for some exclusions for the implementation of strong client authentication. Thus, these exclude the obligation to use 3DS 2.0 protocols:
- Transactions between traders or customers not domiciled in the European Economic Area or handled by issuers in other countries. It's the so-called "ONE LEG TRANSACTION".
- Transactions initiated by the merchant (MIT) based on a prior authorisation with the customer (e.g.,collection of subscriptions). However, to classify a payment this way, it must meet these requirements:
o The subject matter of the transaction corresponds to the payment of goods or services contracted by the customer.
o The merchant must have a purchase order from the customer.
o Authorisation for automatic debiting of the payment without any specific action by the customer.
- Purchases of goods or services made by mail or telephone call.
- Corporate transactions with security protocols through direct channels. This includes card payments as long as the cardholder is not a consumer. The competent authority must certify that the security levels of the payment processes used are equivalent to those of PSD2.
A Secure Client Authentication (SCA) exemption may also be requested in the following cases:
- Low value transactions
- Frictionless flow (transaction risk analysis or TRA)
- Trusted beneficiaries
Low value transactions
For the application of this exemption, it is indispensable that the operations comply with certain conditions:
- The amount of the transaction is less than 30 euros.
- The cumulative value of recurring electronic payment transactions does not exceed EUR 100, counted since the last application of the SCA.
- Applicable up to a maximum of four consecutive remote electronic payment transactions. Beyond this limit, the issuer must perform strong customer authentication again.
Frictionless flow
Issuers and dealers can apply for frictionless flow for low-risk transactions (TRA). This involves exemption from SCA based on a Transaction Risk Analysis. Attention needs to be paid to the requirements that must be met for a transaction to qualify under this category.
Low-risk operations should have the following cumulative characteristics:
- The payment service provider must demonstrate that its platform has a low level of fraud. Fraud rates are determined in relation to the type of transaction on a rolling quarterly basis. In no case may the fraud rate exceed the benchmark.
- The value of the transaction does not exceed the exemption threshold specified inthe Regulatory Technical Standards on SCA. This amount is a maximum of EUR 500.
- Absence of conditions that would suggest an increased risk of fraud. This includes unusual behaviour of the payer, an abnormal location, or access from devices that have not been used before.
It should be noted that the SCA exemption for low-risk transactions is not automatic. It must be requested and may be refused by the issuer even if the requirements are met. It should also be borne in mind that in case of fraudulent transactions, the issuer may be exempted from liability if the trader has submitted the request.
Similarly, where the merchant makes the request, the issuer can exempt itself from liability if the transaction is fraudulent. It is therefore advisable to check the payment provider's rules before requesting a TRA exemption. Remember that fraudulent transactions affect not only the profitability of your business but also your fraud rate.
Trusted beneficiaries
The most striking feature of this exemption is that it is the only one that can be requested by the customer. Its purpose is to facilitate the management of recurring payments or payments to trusted suppliers. Customers can request that the SCA be waived for transactions carried out at the merchants where they usually make their purchases.
This results in greater ease as additional verification steps are avoided. However,the payment provider may apply the SCA if it considers that there is a risk of fraud. In addition, transactions must comply with the general requirements of the Technical Regulatory Standards. And ultimately, the issuer can set particular conditions for the creation of these lists.
In no case may the issuer create a list based on the payer's recurring purchases nor may it modify it or remove any payee. For their part, merchants can inform about the benefits of this exemption, but they cannot apply for it on behalf of their customers.
The SCA shall be applied whenever the registration of a trusted beneficiary is created or modified.
What are the implementation deadlines and where are we in the process?
Like any regulation involving technological change, the implementation of 3DS 2.0 is a gradual process. 2023 seems to be the final date to turn the page and leave the 3DS 1.0 protocols behind.
Since the publication of the PSD2 RTS on 14 September 2019, the following developments have taken place:
2020
- A sof 14 March 2020, the Regulatory Technical Standards are mandatory in the EU, and 3DS 2.0 is the recommended protocol for payment issuers to comply with the regulation.
- In April, Visa Corporation started to implement the change of responsibility for transactions. The decision affected all transactions in the Asian Pacific, European, Middle Eastern, and African regions. In August, the payment service provider added the United States to this list of countries.
- In December, Mastercard announced a rate increase for 3DS 1.0. The aim of this move was to boost the migration to 3DS 2.0.
2021
- Mastercard continues its rate increase strategy for 3DS 1.0 authentication. In July, it extended its application to the APAC region. In return, it offered free authentication with 3DS 2.0.
- In October, this PSP stopped supporting authentication with 3DS1. As a result, issuers who had not yet switched to 3DS 2.0 were forced to generate their own ACS solutions.
- For its part, Visa continued to process transactions with 3DS 1.0, but discontinued support for the 'Attempt Server' for that solution.
2022
- October 2022 will be a key month for the final adoption of 3DS 2.0. From 14 October, American Express will authenticate transactions only with 3D Secure 2.0 worldwide. It will only maintain support for SafeKey 1.0 in India.
- This is also the date when Diners and Discover plan to stop supporting ProtectBuy 1.0.2.
- On October 15, Visa will stop processing applications with 3DS 1.0. Similarly, Mastercard will stop supporting 3DS 1.0 with the exception of transactions in countries such as India.
2023
- In 2023, countries that continue to support and implement 3DS 1.0 must migrate to 3DS 2.0. By October of that year, Mastercard is expected to discontinue support for 3DS 1.0 in India and Bangladesh altogether.
- American Express will no longer support SafeKey 1.0.
Who benefits from 3DS 2.0?
The 3DS 2.0 protocol is a virtuous solution, offering advantages to all those involved in e-commerce operations. First, users will be better protected against fraud attempts when shopping online. The shopping experience will be much more convenient and simpler, even when using mobile devices such as smartphones or tablets.
Since 3DS2.0 integrates natively with mobile applications, they will not have to leave the merchant's site for authentication. In addition, they can also top up their e-wallets, thanks to this authentication.
Retailers are very optimistic about the effects these changes will have on their shopping basket abandonment rates. Chargebacks and, consequently, the costs associated with them are also expected to decrease considerably.
Finally, issuers will be able to make better decisions about transaction risk. This is because they will have access to a broad set of cardholder and transaction data.
.png)
