EMV 3-D Secure, or who stole an SMS with a one-time password

[Tomcat]

Introduction​

Ensuring security when making payments has been and remains one of the most important tasks of any payment system. Engineers and cryptographers are working to create new algorithms and protection systems, and attackers are trying to find vulnerabilities in this protection. A significant increase in payment card security occurred between 2000 and 2010, when the introduction of the EMV standard for physical cards and 3-D Secure for online payments greatly limited the ability of fraudsters to counterfeit cards and exploit stolen details.

As a result, technically, payment cards turned out to be so well protected that the weakest link in making payments turned out to be the person, and the attention of criminals around the world since the 2010s has been increasingly focused on him.

At the same time, real experience has shown that the introduction of additional security levels not only reduces the convenience for the end user, but also reduces the proportion of successfully completed payments, the so-called conversion.
Loss of conversion means that the store will not receive enough profit, and the card holder will not make the desired purchase. Thus, everyone is a loser.

My name is Alexey Kasyakin, I am the technical owner of the 3-D Secure platform at NSPK. Together with Sergei Lysenko (at NSPK he leads the development of EMV 3DS 2.0) and Alexey Krutikov (leader of the platform development team), we want to talk about 3-D Secure technology, its history, main problems and development prospects. And also about why you shouldn’t be afraid if you stop receiving your one-time password.

A Brief History of 3-D Secure 1.0​

The late 1990s saw rapid penetration of the Internet into everyday life. The emerging sales channel via the Internet opened a new page in the history of trade and caused an explosive growth in remote payments using bank cards. At the same time, the share of card fraud on the Internet is growing rapidly, because... To make a payment, it was enough to have only the card number and expiration date.

Payment systems respond to the new threat by introducing a new security parameter, which is printed on the back of the card. It is designed to ensure that it is the cardholder who makes the payment. However, due to the short length of the code (3 characters), it is possible to spy on it when paying for goods at the checkout or get it by stealing a physical card.

Then the urgent need to protect remote payments led to the emergence of the first security standard, 3-D Secure. It allows the bank, at the time of payment, to request additional confirmation from the cardholder, without which the payment will not be processed. Since then, for more than 20 years, 3-D Secure technology has ensured the security of payments made on the Internet.

How 3-D Secure 1.0.2 works​

The protocol describes the interaction of three parties, called domains, as reflected in the name "3D". Deciding on the possibility of performing an operation involving three independent domains became the main idea of the technology.
Let us highlight these domains and their areas of responsibility:

• Issuer Domain - includes the cardholder and the bank that issued the card (Issuer). The area of responsibility of this domain is cardholder authentication, that is, confirmation of the fact of legitimate ownership of the card by the person performing the transaction. The main 3DS component in the Issuer's domain is called ACS (Access Control Server).
• Acquirer Domain – includes an online store and a bank servicing its account and operations (Acquirer). This domain is responsible for building commercial relationships with the buyer, as well as for conducting the financial component of the transaction through the payment system. It is from the Acquirer's domain that the payment transaction is initiated. The main 3DS component in the Acquirer domain is called MPI (Merchant Plugin Interface).
• The interaction domain is the payment system (PS). The payment system ensures interaction between the Acquirer's domain and the Issuer's domain, establishes the rules for this interaction, defines security requirements, and also provides the ability to complete the financial part of the transaction. The main 3DS component in the PS domain is called DS (Directory Server).

Now that we have decided on all the actors, let's delve a little deeper into the technical implementation. The 3-D Secure protocol is built on top of the HTTPS protocol using XML messages to transfer data between domains.
A simplified operating diagram is shown in the figure below.

Making a payment consists of the following steps:

• The cardholder places an order in the online store with online payment, enters the card details on the payment page and clicks the “Pay” button
• Data from the payment page is transferred to MPI
• MPI sends a VEReq (1) message to the DS with the card number and online store data
• DS checks the VEReq message, determines the card issuing bank and sends the VEReq (2) message to the ACS
• ACS checks the VEReq message and determines whether the buyer can be authenticated using 3-D Secure, and then generates the VERes message (3). If authentication is possible, the URL of the ACS page to which the user should be redirected is passed to VERes. VERes message is sent to DS
• DS checks the VERes message and returns it back to MPI(4)
• MPI generates a PAReq (5) message with operation information and technical data from the ACS. The message is sent through the browser to the ACS URL received in VERes
• ACS, in response to the browser's PAReq (6) request, returns the cardholder authentication form. The holder sees a one-time password input field
• The holder enters the code received via sms/push and presses the “Confirm” button, the code is sent to ACS
• ACS verifies the code and generates a PARes message with the authentication result and data for performing the financial component of the transaction. The PARes(7) message is sent via the browser to the MPI address
• MPI receives PARes (8) from the browser, verifies the message, including the signature, and, if successful, initiates the financial part of the operation (authorization)
• MPI receives the result of the authorization and redirects the browser back to the online store, the holder sees the result of the payment

As we can see, the 3DS authentication process involves the exchange of technical information between several parties involved, while the process looks quite simple to the user.

Stages of development of 3-D Secure in Russia​

3DS technology has become a completely new phenomenon in the country's payment space, so its entry into the Russian market was not easy. As a result, the introduction of 3DS initially greatly undermined the transaction flow, that same conversion. Let's remember what methods banks used to verify a client:

• Static password. The simplest method was one of the earliest implemented. When making the first payment from the online store, the client was redirected to ACS, where he had to come up with a password by filling out a registration form. The created password was tied to the card. For subsequent payments, an authentication page appeared where you had to enter this password. The advantages of this method were its relative simplicity and the ability to quickly change the password if necessary. For some time, this authentication method was considered safe and convenient. But soon the security of static passwords began to deteriorate: they were stolen from clients by finding security holes in browsers; in the call centers of banks there could be “their” people who found out the passwords; There have even been cases where the password was found written down on a piece of paper in a stolen wallet, as happened with PIN codes. A few years after its launch, static passwords are no longer considered secure and payment systems strongly discourage their use for 3DS authentication.
• Scratch card. This is a map on which the information is under an erasable layer. We have all at least once played an instant lottery or received similar cards in stores, from which a layer was then erased with a coin to get to the secret. Similar cards were issued for 3-D Secure, each containing a number of one-time passwords. Clients received these cards at bank branches. When making the next payment on the ACS page, you were required to enter one of the passwords from the scratch card. This approach provided a higher level of security, but other problems arose: the one-time codes on the card ran out or the card was lost, and you had to go to the bank branch for a new one. Clients forgot about this and encountered a problem already when making a payment. Then began attempts to enter already used codes and calls to bank call centers with requests to authorize payments with the old code, which was technically impossible. As a result, both conversion and customer satisfaction fell.
• Codes on the receipt. This approach is similar to the previous option, but here one-time codes were printed on the receipt when making a transaction at an ATM, where it was more convenient to receive them than in branches. But checks could also be stolen. Moreover, another method appeared in ATMs: having a duplicate card, the so-called white plastic, an attacker could withdraw money, receive codes and pay on the Internet.
• CAP reader (Chip Authentication Program). This device, similar to modern mobile terminals, was given to the client upon receipt of the card. A card was inserted into it, an access code was entered, and a one-time password was generated on the screen. This approach provided high cryptographic protection, but was not widely used due to the high price of the CAP reader and inconvenience of use.
• Display Card – Bank card with a random password generator. You can read a little more here. Such cards were both convenient and safe, because... the password generator was always at hand and had strong cryptographic protection. But there were also serious disadvantages that did not allow such cards to spread en masse. First of all, this is the price, which is not designed for the mass client. In addition, the card contained an autonomous power source, which could be discharged before the card expired, and in general such cards were more vulnerable to mechanical stress.

Since 2008-2009, mobile operators in the Russian Federation began to gradually reduce tariffs for sending SMS. Thanks to this, it became possible to use Dynamic OTP (One Time Password), which turned out to be very convenient to send as an SMS message to the client’s phone number linked to the card. After the client was redirected to ACS (PAReq message), he was sent a password via SMS, after entering which the cardholder’s identity was considered confirmed. Since SMS messages can be received by any phone, they had the greatest potential at that time as a cheap and reliable confirmation mechanism. Recently, there has been a trend of switching to Push messages as a cheaper method for banks. In addition, they cannot be intercepted on the mobile operator’s side. In the case of SMS, it is the mobile operator that becomes an additional link in the chain of “trust”, and in the case of roaming there are several of them.

Today, many banks use a hybrid system of PUSH and SMS messages. This approach is justified because The bank application may not be installed, may not work correctly, or may not have access to the Internet. In this case, SMS is used. However, the authentication method using OTP no longer meets modern requirements for convenience when making payments, and fraudsters are finding new ways and opportunities to obtain OTP from clients. Most of the other verification methods described above have been replaced over time as unsafe, too expensive or inconvenient for the client.

What required improvements in 3DS 1.0​

For more than twenty years, the first version of the 3DS protocol has been solving its task of ensuring the security of remote payments. However, any technology becomes obsolete, and over time there were some features of the 3DS 1.0 that required the following improvements:

• Increased conversion. Whatever authentication method is used, any additional confirmation of payment by the client creates an additional barrier to completing the payment, which affects both the client and the store. The reasons why the payment is not completed can be very different:
  • Customers' distrust of pop-up windows and entering codes into them, fear of being deceived.
  • Lack of understanding of what exactly needs to be done to confirm payment.
  • Input errors, entering a different value, for example, PIN; entering the wrong code from a scratch card, etc.
  • Poor Internet connection, problems with redirection to ACS or back from ACS to the store.
  • Lack of access to the phone linked to the card.
  • Uncertain reception, problems with sending SMS on the bank’s side, or with delivering SMS to the client’s phone.
  • And so on.
• Adaptation to mobile devices. When certifying Issuers using 3-D Secure 1.0 technology, payment systems imposed certain requirements on the size and content of the authentication page. These requirements greatly limit the web developer in the layout of these pages. As a result, it may happen that when we try to pay in a beautiful, modern online store, we are redirected to a small page somewhere in the corner of the screen. In some cases, the code entry form may not even be visible. When using a mobile device (the share of payments from which is growing every year), the user faces a similar problem: the HTML form presented by the Issuer looks foreign in the GUI of the mobile application, its scale and position may be inconvenient for the user.
• Increased protection against social engineering fraud. No 3DS 1.0 authentication method provides truly reliable payment protection against fraud methods known collectively as “social engineering.” Fraudsters can obtain a one-time code directly from the client, misleading him. For example, a fraudster introduces himself as a bank security officer and reports a suspicious transaction on a client’s card. To cancel it, you need to call the code that will come via SMS or PUSH. At this time, using the compromised card details, the fraudster performs a money transfer operation, for which a confirmation code is requested. Similarly, when calling, scammers may introduce themselves as police officers, FSB officers, bailiffs, lottery representatives, etc. At the same time, their goal remains the same: to provoke the client into compromising the card details and/or one-time code.
• Improving user experience. Over the past 20 years, banks have taught customers that entering OTP is normal. But in reality, less than 0.05% of all transactions are fraudulent. That is, for almost all operations with OTP input, it is not actually required, because it is carried out by the legitimate card owner.

To solve these problems, the next version of the protocol was developed - EMV 3DS 2.0. We will talk about its origins, capabilities and advantages, as well as its launch in the Mir PS in the next article.

In the last article, we talked about how the first reliable authentication protocol for payments by plastic cards 3-D Secure 1.0.2 appeared, what problems it solves and what disadvantages it has. Now we would like to talk about the future of 3-D Secure technology, and why you shouldn’t worry if you stop receiving SMS with a one-time password.

The Birth of EMV 3-D Secure​

By the mid-2010s, the moral and technical obsolescence of 3DS 1.0.2 prompted the EMVCo consortium (an organization that develops standards in the field of payment technologies) to develop a new version of the protocol, which was called EMV 3-D Secure 2.0.
It is similar to its predecessor, but introduces a number of significant improvements. The first draft version of the EMV 3DS specification was numbered 2.0.1. The first working version is number 2.1.0. We list its main capabilities and features:

• Frictionless authentication. The protocol allows, using risk-based analysis (RBA), to perform so-called Frictionless authentication, that is, to confirm that the card belongs to the payer without his direct confirmation. This is one of the most important innovations, which entails the main advantages of the new protocol: convenience for the client and increased conversion rates for merchants.
• Support for multiple authentication channels:
  • browser-based (browser-based or BRW) – a familiar payment channel from an online store through a browser on a desktop, mobile device, etc.;
  • from the application (application-based or APP) – 3DS authentication is performed directly from the mobile application (there is no browser), while a special SDK library integrated into the application is responsible for the implementation of EMV 3DS functions. This allows you to improve the user experience, because... authentication takes place in the native environment of the payment application (no more clumsy HTML pages!). At the same time, additional data about the device is collected, which is important for “recognizing” the client’s risky machine and increases the security of the operation;
  • initiated by merchant (3DS requestor initiated or 3RI) – initiated by the store independently, without a request from the holder. This channel can be used for subscriptions, recurring payments, etc.;
• Support for two "categories" of authentication:
  • payment (Payment or PA) – the holder is authenticated in order to pay for a product or service, or make a money transfer;
  • non-payment (Non-Payment or NPA) – the holder is authenticated when performing a transaction that does not involve further movement of funds. For example, linking a card to a service, checking when tokenizing a card, etc.;
• Security of information flows. Unlike the first version of 3DS 1.0.2, in which application data is transferred through the browser, all relevant data in EMV 3DS is transferred through a secure environment directly between components of the 3DS payment infrastructure. The user device is used only to fulfill technical requests when interacting with the Issuer's ACS;
• Support for a flexible risk analysis system , which, in addition to performing Frictionless, can also respond to threats, including those using social engineering. If the system detects a money transfer that is atypical for a given client, for example, from an unfamiliar device or from another country, then such an operation may be blocked or may require enhanced authentication methods. Confirmation may require not only entering a one-time password, but also answering additional security questions or entering biometric data. Of course, this does not protect against social media. engineering by 100% (if the holder wants to give his money to scammers, he will give it to him), but reduces the likelihood of successful fraud compared to the first version of the 3DS.

As you can see, the existing problems of 3DS 1.0.2 are largely solved by EMV 3DS 2.0. In addition, the protocol is actively developing, payment systems and banks are implementing its next version - 2.2.0 (and 2.3.0 is next), which introduces a number of additional features. But more on that at the end of our article.

How EMV 3-D Secure 2.0 works​

The 3-D Secure 2.0 protocol is built on top of the HTTPS protocol using messages in JSON format (JSON is preferable to XML, which was used in 3-D Secure 1.0). The composition of the domain model has not changed (the description can be found in the section “Scheme of operation of 3-D Secure 1.0.2” in the previous article). The main changes affected the work scheme, a simplified model of which is presented in the figure below.

EMV 3DS adds a new information flow between the 3DS Server (as MPI is now called) and the DS. In it, 3DS Server periodically receives with a DS request PReq (1) information about the card ranges of Issuers subscribed to the protocol and their parameters. In the PRes response message, the DS component for each card range returns the supported protocol version, additional options, and the 3DS Method URL. 3DS Method URL is the URL of the ACS component that must be called by the 3DS Server in the browser before authenticating the user. With this call, ACS can identify the device, collect its parameters, and associate it with that data when it receives an authentication request.

Client authentication when performing an operation through a browser (Browser-based) consists of the following main steps:

• Placing an order in an online store with payment online. The buyer enters the card details on the payment page of the online store and clicks “Pay”;
• The online store transmits payment information to 3DS Server;
• 3DS Server, if there is a 3DS Method URL, initiates its call in the client browser, after which it generates an AReq (2) message, which contains:
  • card number;
  • order details;
  • information about the online store;
  • collected information about the client device.
• The AReq message is sent to the DS;
• The DS checks the AReq, determines the Card Issuer, and sends the AReq (3) to the ACS;
• ACS, based on data from AReq and collected device data (3DS Method), decides on the need and method of additional verification of the buyer;
• ACS returns a response to DS - message ARes (4). In it, ACS communicates its authentication solution. If additional confirmation is required, the address of the ACS page is also transmitted;
• DS checks the ARes message and sends it to 3DS Server (5);
• 3DS Server checks the message and analyzes the decision made by ACS:
  • If the ACS has confirmed successful authentication (for example, using risk analysis), then the 3DS stage ends. 3DS Server initiates payment authorization and redirects the buyer’s browser back to the online store, where the payment result is displayed;
  • if the ACS requires additional confirmation, then the 3DS Server generates a CReq (6) message, which is sent through the browser to the ACS URL received in ARes.
• ACS displays a user interface page for buyer authentication;
• The buyer enters the received code and clicks “Confirm”. A request is sent to ACS with the one-time code entered;
• The ACS checks the one-time code and sends an RReq (7) message with the authentication results to the DS;
• DS checks the message and transmits it to 3DS Server (8);
• 3DS Server checks the message, records the authentication result and generates an RRes message (9) in response. It is needed to inform the DS and ACS that the RReq with authentication results was successfully received;
• The DS checks the RRes message and transmits it to the ACS (10);
• ACS checks the RRes message and generates a CRes message (11), which is sent through the browser to the 3DS Server address. A CRes message is required to return the user's browser from the ACS page back to the online store;
• 3DS Server receives CRes, verifies it and, if successful, initiates the financial part of the operation;
• 3DS Server redirects the browser to the online store with information about the result of the operation.

In the case of an Application-based channel, the interaction scheme has only minor differences, so we will not consider it separately.

Authentication using a one-time code when describing the scheme of the protocol is given only as an example. The specification provides for many different options for authentication of the cardholder by the Issuer, including biometrics, calling external authentication services, etc.

History of the launch of 3-D Secure in the Mir PS​

In the Mir payment system, the issue of launching 3-D Secure technology arose along with the launch of the payment system itself in 2015. It was impossible to put a card into full circulation nationwide without protecting payments on the Internet, so in parallel with the setup and launch of the payment system, work was carried out to implement the 3-D Secure service and prepare related rules and regulations for banks. At the start, an agreement was concluded with another payment system that owns the licensing rights to 3DS 1.0.2 technology. This solution, on the one hand, guaranteed the correct operation of the entire payment infrastructure, including the websites of trade and service enterprises (TSEs), banks and payment service providers. On the other hand, it ensured the maximum speed of solving the problem. The 3DS service for cards of the national payment system is called MirAccept.

The service received further development with the release of a new version of the protocol – EMV 3DS 2.0. An analysis of the capabilities of the new protocol showed that it will be in demand in the payment space of the Russian Federation, because offers a solution to many existing problems with 3DS 1.0.2. In 2016, a project was launched to create a 3DS service for the Mir PS on the basis of its operator, the National Payment Card System (NSCP). For NSPK this was a new, non-trivial task. It is worth noting that while 3DS components for banks and stores are widespread on the market and are offered as boxed solutions, then developing a component in the payment system domain - Directory Server - is a piecemeal task; there are no ready-made offers of such products on the market. In addition, the task was complicated by the fact that it was necessary to implement a reliable, high-load service based on the completely new EMV 3DS 2.0 specification, which at that time existed only in a draft version.

The launch of MirAccept's own platform took almost two years. During this time, technical specifications were prepared, development was completed, testing, acceptance and implementation were carried out. A platform was launched with support for two protocols simultaneously: MirAccept 1.0, based on 3-D Secure 1.0.2, and MirAccept 2.0, based on the modern EMV 3-D Secure 2.0 standard. Simultaneously with the launch of the platform, a number of other tasks were solved, such as creating a certification environment to verify banks’ compliance with rules and service standards, developing test scenarios, writing guidelines and regulations for certification and connection, developing business processes for connection, etc. Thanks to the well-coordinated work of the team, in September 2017, MirAccept’s own platform was successfully launched, and the first industrial payment transactions with holder authentication through MirAccept’s own service were carried out with pilot banks.

At the time of the launch of the new MirAccept 2.0 protocol (in 2017), the EMV 3-D Secure 2.0 protocol on which it is based was practically unknown in the banking environment. PS "Mir" became an innovator in this sense, launching this protocol as the first of all the largest payment systems (and, perhaps, the first in general). NSPK has actually become a driver for promoting new technology in the payment space of the Russian Federation. In 2017, training seminars and lectures began, not only for banking specialists, who were soon to implement the corresponding software systems in their banks, but also for developers and suppliers of software solutions. Courses of varying degrees of immersion and detail have been developed for different target audiences. They included a wide range of topics - from a top-level overview of the technology, to consideration of the details of the implementation of the specification requirements, cryptographic operations and software methods of the SDK integrated into the payment application. At the moment, the payment market is already quite familiar with the technology, and the need for training has decreased. Nevertheless, from time to time we still conduct seminars (and in the current conditions, webinars) devoted to the principles of operation of the technology, certification processes, as well as connecting to the service of Banks and payment providers.

Soon after the launch of the MirAccept Platform, it became clear that Banks needed help in conducting risk assessments of transactions, because There is not always time and resources to implement your own risk analysis systems. On the other hand, without this functionality, the transition to a new protocol simply meant replacing old 3DS 1.0.2 messages with new EMV 3DS 2.0 messages without changing the user experience. It is frictionless authentication without additional confirmation from the card holder, while maintaining the level of security, that is the main advantage of the new protocol. And in order for it to work, a risk analysis system was needed.

Based on these considerations, a pre-design study was carried out at the end of 2017, and in 2018 a project was launched to create our own RBA machine, which was called the Decision Making Service (DSS).

By August 2019 (in less than two years), the project was completed and the service went into pilot operation. For its work, we developed our own risk model, which takes into account dozens of attributes of the payment being made, ranging from the characteristics of the user device to the statistics of confirmed fraudulent transactions in a given trade and service enterprise. Because The payment system is located at the intersection of all interbank payment traffic, the SPR has the ability to analyze a significant amount of data and, for each payment, evaluate how well the operation corresponds to typical user behavior. The result of the service is transmitted to banks in the form of a risk score so that they can make a final decision whether it is necessary to request additional confirmation of the operation from the holder or whether it can be carried out in frictionless mode. The first truly authenticated operations using a frictionless scenario began at the end of 2019.

If we talk about the prospects for risk analysis in general, then it is already possible to evaluate with high quality 40-60% of transactions in the so-called “green zone”, that is, without requiring additional confirmation of payment from the holder for them. Some banks use DSS for this, others use their own risk analysis solutions.

Today, a dedicated team is engaged in the development of the 3-D Secure Platform at NSPK. Just recently, the core of our Platform (Directory Server component) was successfully certified by an independent EMV testing laboratory, and we received confirmation that our component complies with the requirements of the latest valid version of the EMV 3DS 2.2.0 specification. This opens up the possibility for us to provide participating banks with new capabilities based on the 2.2.0 specification. Next we want to talk about these possibilities.

New features in EMV 3DS 2.2.0​

Released at the end of December 2018, version 2.2.0 of the specification contains important innovations and improvements:

• Payment authentication in 3RI channel . In version 2.1.0 for 3RI, only non-payment authentication (NPA) was possible, which is appropriate, for example, when linking a card to a personal account, electronic wallet, etc., which is not required for operations initiated by merchants without the participation of the holder. In 2.2.0, the implementation of payment authentication (PA) within 3RI also became possible. Moreover, the authentication scenario is possible both Frictionless and Challenge. In the latter case, a new approach to authentication is used - Decoupled Authentication.
• Decoupled Authentication or delayed authentication is an approach in which cardholder verification can be delayed in time. The authentication method to be used is at the discretion of the issuer. For example, this could be a call from the bank to the client at a time convenient for him, a request for confirmation by e-mail or through a mobile application. The key is that confirmation is not required at the time of the transaction itself, but can be completed over a long period of time, up to seven days.
  To perform deferred authentication, 3DS Server sends a special flag in the AReq request indicating the possibility of deferred authentication. ACS, based on the authentication method configured for a specific card, can agree to carry out delayed authentication or not. If he agrees, then authentication is carried out using the selected method. Based on the results of the client verification, ACS sends a standard message with the authentication result (RReq) to the payment system (in DS), after which it is redirected to the Acquirer bank in 3DS Server. The advantage of this method is that the client’s confirmation is in no way tied to the process of purchasing a service, which can be successfully used, for example, for the following types of 3RI payments:
  • subscription to the service (recurrent payments - monthly payments for the services of communication and Internet providers, rent, online cinema services, etc.);
  • renewal of insurance and other services (extension of an insurance policy, purchase of new services by prior agreement with clients, etc.).
• Whitelisting. Another innovation of specification 2.2.0 is the ability for the client to add a merchant (online store or other company to which payment is made) to the whitelist on the Issuer’s side. On the authentication page, the holder has the opportunity to confirm the addition of this merchant to the white list. A prerequisite for being added to the white list is successful authentication using the Challenge scenario. In this case, ACS can additionally inform 3DS Server that this store has been successfully added to the white list.
  
  As a result, the Issuer can carry out subsequent operations from this merchant using this card without additional contact with the card holder, that is, according to a frictionless scenario, because the client gave informed consent to this. In addition, the Acquirer bank, for subsequent payments, can also request a frictionless transaction based on the fact that the merchant is on the white list. The card holder gains control over which stores he allows payment without additional fees. confirmation, which ultimately improves the customer experience. At the same time, the store receives an increase in conversion, because an unnecessary barrier for the client in the form of mandatory transaction confirmation is removed.
  Essentially, whitelisting is a simple and cheap way to realize the benefits of EMV 3DS 2.0 without creating a complex RBA machine.

Prospects for the implementation of 2.2.0 on the market​

As you can see, all innovations in 2.2.0 are aimed primarily at improving customer experience and increasing conversion. Today's customers are very demanding about the convenience of the payment process, so online stores are in an endless race to create various flexible payment scenarios. The ability to add to whitelists (Whitelisting), for example, will help customers who constantly pay for purchases on the same sites to do this more conveniently, without being distracted by additional windows and entering confirmation codes. And new mechanisms for delayed authentication (Decoupled Authentication) will allow online stores and acquiring banks to significantly increase the conversion of recurring payments. At the moment, such payments are considered unsafe, because... During the payment process, the client's identity is not verified (payments are processed without 3DS). New technology from EMVCo allows you to verify a client in a way convenient for him, for example, through the same banking application using a Push notification, without forcing him to simultaneously go to the website and make a payment.

In addition, EMV 3DS 2.0 allows the use of special service fields (so-called Extension fields) for the secure transfer of additional information between Participants in the authentication process. Among the latest changes, for example, it has become possible to transfer additional data about the passenger from the store (air carrier or tour operator) to the Issuer bank (the so-called Airlines Data or “Long Record”). EMVCo issued a separate bulletin about this change, explaining the rules for using service fields for these purposes ( Travel Industry Message Extension ). This and similar opportunities provide a chance to implement complex tasks within the framework of today's rapidly developing e-commerce market and place the prospects for the development of EMV 3DS 2.0 technology a step higher than its predecessor.

Conclusion​

Further penetration of EMV 3DS 2.0 into the payments infrastructure will lead to increased use of RBA and a reduction in the proportion of transactions requiring customer confirmation. Work to improve the quality of transmitted data and enrich it with optional payment details will further strengthen this trend.

Today, the lack of transaction confirmation with a one-time code still causes concern for the average user. But, perhaps, over the horizon in a few years the situation will change, and questions will be raised, on the contrary, by the bank’s request for additional confirmation when making a standard payment. The most technologically advanced and modern market players today no longer require additional confirmation for transactions that correspond to the typical purchasing profile of the cardholder.

The introduction of new features, such as delayed authentication and whitelists, will further complicate the 3DS infrastructure, but at the same time offer the end user of a bank card flexibility and the ability to change payment settings to suit themselves, which will further increase the convenience of card payments.

The transition of payment applications to work with an integrated SDK will make the verification process smoother and more convenient. At the same time, thanks to the transfer of the device’s fingerprint, the level of “recognition” by the Issuer of its client will also significantly increase. The share of transactions requiring confirmation will rapidly fall as such applications become more widespread and cardholders actively use them to pay for goods and services.

Payment authentication for merchant-initiated payments will also increase the conversion of payments for subscriptions to regular services, which have become especially popular in recent years along with the transition to a service-based consumption model.

Thus, in the next few years, we expect to solve most of the problems associated with the legacy of the 20-year-old technology, 3-D Secure 1.0.2, and change for the better the user experience when making payments with bank cards on the Internet.

The patient reader who has reached the end of our article now knows who stole the SMS with a one-time password, and why you should not be afraid of transactions on the Internet without additional confirmation. Safe payments everyone!