08 / 06 / 2023
In this whitepaper, we focus on Strong Customer Authentication brought by PSD2. We explain how SCA and 3D-Secure work for each type of stakeholder in the online payment value chain, in the context of continuous changes in regulation and protocols. It is meant for all the players in the value chain and particularly e-retailers and issuers. We also bring perspectives on how they can better tackle the challenges related to SCA implementation, and we highlight approaches to lower friction in the customer journey on e-commerce transactions.
To strengthen the fight against payment fraud and protect consumers, the Europe Banking Authority (EBA) has imposed that online buyers should go through a strict authentication process, known as SCA (Strong Customer Authentication). SCA applies to all online card transactions and has a major impact on merchants and issuers.
Under the Second Payment Services Directive (PSD2), merchants are no longer responsible for asking for authentication according to the risk of the transaction. This now falls under the responsibility of the card’s issuing bank. In addition, the EBA also decided to follows the NIST (National Institute for Standards and Technology) recommendation that a single-use code received by SMS was not secured enough to be considered as a strong authorisation.
This led to a shift from a simple authentication via SMS to authentication via a mobile application in most cases. Strong authentication is now mostly achieved via the consumer's smartphone through biometrics like fingerprint or facial recognition, for example..
At the same time, and for online card payments, the existing authentication mechanism (3D-Secure) evolved into a more complete solution (called EMVCo 3DSv2), which is much more complex to implement (with exemptions depending on use cases, multiple authentication methods, etc.). Moreover, this new 3D-Secure is not easy to set up by e-merchants, eager to optimise their transformation rates, so critical in online sales.
This paper aims at explaining the joint evolution of PSD2 SCA and 3D-Secure and the impacts. It focuses on online payments by bank cards, in the context of a simultaneous evolution in regulatory and protocol changes. It is meant for all the players in the value chain and particularly e-retailers and issuers. It describes and explains how SCA and 3D-Secure work, the changes, the context and the impact, for each type of stakeholder.
Finally, it brings perspectives on how to better tackle the challenges that come along with SCA implementation at this stage of 2022.
The Second Payment Services Directive (PSD2) was drafted by the European Commission with two objectives in mind:
Consumer protection will be achieved through the implementation of Strong Customer Authentication (SCA). It aims at protecting users of banking services and their transactions, that can be online payments.
Of all the actors in the payment chain, e-merchants are certainly the most impacted by PSD2. Indeed, the transformation rate can drop during the payment phase if the consumer is confronted with strong authentication. This is particularly the case if the SCA is done on a separate channel and requires an interaction from the consumer.
The objective here is to provide payment value chain stakeholders - and in particular e-retailers and issuers – with guidance to better understand SCA and its challenges in order to successfully implement it.
PSD2 changes the EU’s regulatory framework by focusing on three aspects to make electronic payments and online banking safer and easier for consumers:
When an online payment is made with a card, the acquirer bank or the PSP can request a cardholder authentication.
Card payments are determined according to a set of set of specifications (3DS) defined by the payment schemes (Mastercard, Visa, CB, …) and EMVCo. EMVCo regularly publishes new technical specifications defining how the different actors should communicate during an online payment. (See 6).
Historically, the 3DSv1 standard was used. During an online purchase, cardholders verified their identity by receiving a code by SMS ( One-Time-Password or OTP) on their mobile phone. This guaranteed payment to the merchant.
In this context, the e-merchant could disengage from this mechanism and avoid the authentication perceived as a friction and a possible cause of cart abandonment by the cardholder during the payment phase. If the e-merchant disengaged from 3DS and there was a fraud, it was his financial responsibility and the responsibility of his acquiring bank.
This SMS OTP was useful in the fight against online card payment fraud. However, it is now considered unsecure when used on its own as, it is relatively easy to intercept a SMS, read or modify it. In addition, many payments did not benefit from strong authentication.
SCA enables payments and particularly banking operations to be done in a more secure way.
SCA is meant to apply in the framework of the following use cases:
In practice, SCA applies to any electronic payment, including credit transfers, as long as the payment is not subject to an exemption (see 4.4).
The SCA is not restricted to the connection to a payment account. The creation or modification of a third party beneficiary for a credit transfer for example, or a change of vital information (secret code, address, telephone number, etc.), and any sensitive operation, is subject to strong authentication.
PSD2
SCA was deployed largely under PSD2. Published in the Official Journal on December 23rd 2015, PSD2 aims to strengthen consumer protection, promote innovation and improve the security of payment services within the European Union and the European Economic Area.
Standards
Regulatory technical standards (RTS) are, in this case, a package of technical standards designing a framework for use of SCAs and securing of payment data to achieve the objectives set by PSD2.
Validated in November 2017 by the European Commission and in March 2018 by the European Parliament, the standards entered into force on 14 September 2019. Delays were granted (18 months), as not all players in the payment ecosystem were ready at that date. Additionally, ramp-up was introduced in the e-commerce sector, starting with soft-decline applied for transactions with high amounts and with a progressive lowering of the threshold.
The RTS standards set out the SCA obligations and the exemption cases.
SCA technical solutions
SCA, also called multi-factor authentication, improves the security of online payments by making the cardholder authenticate with a combination of at least two elements that concern him:
These authentication factors must be implemented in such a way that if one factor is compromised it does not affect the other(s). It is, therefore, necessary to implement a special security around these factors to ensure their authenticity and integrity throughout the authentication process.
EBA published on 21 June 2019 its opinion on these elements of SCA under PSD2
EBA opinion of valid authentication factor
We can see different authentication methods on the market, depending on the bank’s digital strategy, or its need to deploy a variety of methods to address and equip all its clients.
For instance, lots of banks have chosen a tactical approach and reinforced the existing OTP with a PIN or a password. This has the advantage of complying with regulations on time. However, the impact on the user experience is important and reduces the authentication success rate in general.
The strategic approach consists of fitting the SCA in the bank’s digital strategy. As an example, in France, we can see the SCA solution being directly integrated in the bank’s mobile application. In Germany, we see separate applications dedicated to managing authentication. The advantage of such solutions based on smartphone possession is that you can enhance user experience with push notifications and make the most of the usage of biometrics on the device.
New trends are encouraged to reach the right balance between security and user experience:
All of this with the same goal: getting rid of passwords and improving customer experience.
All the players in the online payment chain are affected by the implementation of SCA. The most common model for defining the functioning of the payment chain is a rectangular shape, called the "4-Corner Model", and includes the 6 actors listed below.
The cardholder
The cardholder is the consumer who owns a payment means provided by the issuer and used in the context of the purchase of products or services provided by a merchant. He is the one who pays the merchant.
The merchant
The merchant in this case is the e-retailer providing an online selling website and delegating the acceptance of the payment mean to a PSP. He is the one who cashes the payment.
The issuer
The issuer is the provider of the payment means for its customers: the cardholders. It is the issuer’s responsibility to authenticate the cardholder, to verify the availability of funds and to settle the payment with the merchant’s acquirer.
The acquirer
The acquirer is the provider of the monetary contract of its customer: the merchant. The acquirer is generally a bank. It will request the provision of funds and acquire the funds on behalf of the merchant.
The Payment service provider (PSP)
The PSP is a subcontractor of the merchant. It provides a secured technical solution for the online acceptance of payment cards on behalf of the e-merchant. This role is purely technical and can be fulfilled by several types of actors, sometimes the acquirers Themselves.
The schemes
The card schemes networks allow acquirers and issuers to communicate with each other. To make this communication as efficient as possible, they define the rules for the use of their payment instruments and approve the conformity with the market technical solutions. They manage themselves the interbank clearing financial flows. Sometimes, issuing and acquiring banks use a third-party clearing house (STET in France).
What is the impact for e-merchants?
In theory, the role of the e-merchant is the same as before. For e-merchants who systematically activate 3DS (via their PSP), nothing changes with regard to the payment guarantee.
However, for e-merchants who choose to disengage from 3DS to optimise their conversion rate, the change is major: the issuing bank can impose a 3DS challenge for online card payments.
The e-merchant loses some control over the conversion rate (the ratio between the number of transactions and the total number of unique visitors, over a given period) at the time of payment. Indeed, even when requesting a 3DS without strong authentication, it is the issuer who eventually takes the decision whether or not to trigger the 3DSV2 strong authentication step at the final transaction phase.
In addition, the application of the exemptions provided in PSD2 must be reviewed with the merchant acquirer to ensure that they are implemented in specific cases where the 3DS step could be avoided.
PSD2 impacts different aspects in the payment securing chain. It modifies the responsibility in the event of fraud or outstanding debt and introduces the notion of exemptions in the application of strong authentication rules.
The main changes are:
Mandatory strong authentication
PSD2 introduces mandatory strong authentication for all electronic payments, with exemptions for certain types of transactions.
Authentication exemptions
The RTS define the cases that can be exempted from strong authentication (independently of the authentication mechanism and of the authentication method) to maximise the fluidity of the user experience while ensuring the security of the transaction. A transaction during which the cardholder does not have to authenticate is then referred to as a frictionless transaction.
Responsibility shift
The issuer bears the legal responsibility in case of fraud. The only exception is when the merchant has requested a strong authentication exemption via the authentication or authorisation request and when this is accepted without any new authentication request from the issuer. For all acquirer exemptions, the responsibility in case of fraud is borne by the acquirer.
Risk management
As issuers now bear the responsibility, they become responsible for managing the risk of fraud. However, depending on the contracts between acquirers and merchants, the merchants may have different degrees of involvement in risk management. For example, the merchant may offer his own risk analysis to his acquirer, who may accept that the merchant take responsibility for the fraud in the event of an exemption based on that analysis.
To meet the regulatory requirements, the technical standards had to be adapted. The 3D-Secure standard rules online card payments. 3DS was upgraded to version 2 and is standardised by EMVCo (see 5).
3DSv2 allows to manage new authentication methods and the full implementation of SCA exemptions. It also allows authentication in a wide variety of new types of devices (mobile, tablet, etc.) and should help to reduce fraud while decreasing friction.
It is a protocol that enables to implement SCA on e-commerce transactions in a universal and standardised way.
Amendment to PSD2 were introduced in a final report published by the EBA on 5 April 2022. Following a public consultation that attracted more than 1200 responses and an extensive analysis of the feedback received, the EBA introduced changes to the RTS, while retaining the mandatory exemption. As proposed in the consultation paper, the time limit for the renewal of the SCA was extended from 90 to 180 days.
Since the implementation of PSD2, the payments market has continued to evolve. New market players as well as new payment solutions, services and technologies have emerged and the needs of payment service users (PSUs) have changed in view of the continuing digitalisation of our society. These changes have created new risks and challenges that must be addressed. With this in mind, the European Commission launched a PSD2 review consultation on 10 May 2022. The review, which closed on 5 July, aimed to assess the effectiveness, efficiency, costs and benefits, coherence and EU added value of the directive. It will determine if the PSD2 objectives were achieved or if changes are needed and if so, the type and scope of changes.2
Frictionless flow can be enabled for these exemptions:
Contactless transactions below €50, but SCA to be applied after either 5 transactions or €150 cumulative spend without SCA (PSP can choose)
Trusted beneficiaries: merchants whitelist managed by the cardholder. Addition of the merchant to the whitelist as possible trusted beneficiary can be requested either by the merchant during authentication or by the issuer. In any case, the issuer bears responsability in case of fraud
Payments to trusted beneficiaries (through a "whitelist"), that has been previously confirmed by the player when SCA was applied
Recurrent transactions with the same amount to the same payee, providing that SCA is applied when the initial paylent is made and if there are any amendments to the payents
Payments to self when both accounts are held by the same bank
Remore electronic payment transactions (e.g., eCom) under €30, but SCA to be applied after either 5 transactions or €100 cumulative spend without SCA
Low risk remote payments are exempted if transaction risk analysis shows that fraud levels for the PSP fall below an exmption threshold value set by the EBA
Trusted beneficiaries (“Whitelisting”)
The cardholder can create a list of trusted beneficiaries, for which SCA won’t be applied. However, strong authentication will be applied once, when the cardholder first whitelists the beneficiary and adds it to his list of trusted beneficiaries..
Secured corporate payments
The SCA does not apply to companies that should already have secure means and information systems in place to make payments. Business/corporate cards also benefit from an issuer exemption defined by the RTS.
Low Value Payment (LVP)
PSD2 allows for an SCA exemption to allow frictionless payments when the transaction does not exceed €30. Transactions carried out without authentication must not exceed €100 or 5 successive repeat transactions. The challenge is that neither the online payment providers nor the acquirers can keep tract of the overall number of consecutive low-value transactions made by a given individual, or even the amount of the last SCA. This can only be verified by the issuer at payment authentication.
The issue for merchants, online payment providers or acquirers is that if the issuer discovers during the authorisation phase that the counter or total amount limit was exceeded, it must reject the payment authorisation with the so-called “soft decline”. During a soft decline, the transaction must be presented again with SCA.
Low risk transactions (TRA / Transaction Risk Analysis)
The acquirer can, in accordance with the TRA, request an exemption by the issuer (through the payment authorisation or via the 3DS process in the case of an issuer exemption) on behalf of the e-merchant if the merchant's fraud rate is below a certain threshold, i.e. if the rate is below the 'fraud reference rate'.
The issuer may accept the exemption unless it considers that other aspects of this transaction present a risk. The thresholds for online card payments are as follows:
| Threshold value to exempt transactions of less than: | Reference rate in terms of fraud (%): |
| 500€ | 0,01 |
| 250€ | 0,06 |
| 100€ | 0,13 |
TRA exemption should be accepted unless there is suspicion of fraud in the following cases:
Recurring transactions
The amount of a fixed subscription is identified by the issuer who will not apply an SCA challenge to recurring transactions of the same amount and for the same beneficiary. However, there will be a challenge when a cardholder creates, modifies or initiates a series of recurring transactions for the first time.
EMVCo (Europay Mastercard Visa) is a global technical body that facilitates worldwide interoperability and acceptance of secure payment transactions by managing the EMV specifications and related testing programmes. Those specifications are programmes that enable card-based payment products to work together seamlessly and securely worldwide.
To reflect current and future market requirements, the payments industry recognised the need to create a new 3-D Secure specification that would support app-based authentication and integration with digital wallets, as well as traditional browser-based e-commerce transactions. This led to the development and publication of the EMV 3-D Secure – Protocol and Core Functions Specification.
EMVCo has specified various versions of the EMV 3-D Secure protocol, gradually introducing new features aimed at improving the user experience.
Whereas the 1st version of 3DS aimed at meeting compliance, the user experience and flexibility were unfortunately not there. This is the reason why VISA and Mastercard planned the decommissioning of 3DS1 from 14 October 2022 onwards: to guarantee better flexibility and optimised user experience with the second version of the 3DS protocol: 3DS 2.
Indeed, 3DS 2 has introduced significant improvements in terms of user experience, As the feedback from our customer implementation shows, it directly improves the success rate.
Recently, with the version 3DS 2.3.1 we see introduction of new devices and authentication approach (Secure Payment Confirmation, FIDO, device binding, …).
Simplified diagram of the 3DS process
Phase 1
The cardholder goes on the e-commerce website, validates his basket, enters his payment information, validates the payment.
Phase 2
The payment information is sent to the 3DS Server which will identify the Directory Server of the scheme associated with the card to send an authentication request. The Directory Server works as a scheme directory.
Phase 3
The Directory Server identifies the card issuer and forwards the authentication request to its ACS (Access Control Server). The issuer ACS works as a rules engine and is also based on the 3DS protocol. It decides whether there should be an SCA (challenge) or not (frictionless).
Phase 4
The Access Control Server strongly authenticates the issuer cardholder via his defined authentication method, and then sends the validation back to the Directory Server.
Phase 5
The validation is transmitted to the 3DS Server, which notifies the payment service provider (PSP).
Phase 6
The PSP requests the payment authorisation by the acquirer.
The flow below details a typical customer journey during an SCA challenge. It follows 5 key steps.
Purchase
The customer proceeds to the purchase on an e-commerce website from his computer or any other connected device. This is phase 1 on the 3DS process diagram.
Challenge
When validating the card information, a message from the card issuer is displayed to indicate that the authentication will be done via the customer’s smartphone*. This is phase 4 in the 3DS process diagram. The ACS rules engine decided that the cardholder should authenticate to validate the transaction.
* This depends on the authentication mean defined and proposed by the issuer to the cardholder. In this case, the authentication means is based on a smartphone.
Notification
The customer receives a notification from his bank (the issuer) on his smartphone that an authentication is required to complete the payment.
Confirmation of the context
The user clicks on the notification and is directly redirected to an interface on his banking application, which displays the details of the transaction to authenticate: at least the amount of the transaction and the name of the e-merchant.
Authentication
The user checks the transaction and validates it with,for example, ingerprint recognition (or password) combined with the smartphone’s possession factor. When authenticating, it is important that the transaction details are always visible. This ensures the customer he is validating the right transaction, especially when SCA is done “OOB” (Out of Band), I.e. on another device.
Successful authentication confirmation
The authentication is successful and the ACS browser page displays a confirmation screen to the cardholder.
Payment confirmation
The cardholder is redirected from the ACS screen to the merchant screen (automatically or manually depending on the bank configuration). The payment is indicated as complete and the purchase / order as confirmed. The cardholder can make a payment from different channels. SCA is then requested depending on the configuration the issuer has defined, and can take many forms depending on the payment journey.
For most merchants, the way SCA works is transparent and integrated into the services offered by their PSP or their acquirer.
A few major merchants are interested in managing SCA themselves, in which cases they will act as their own PSP for the 3DS part.
The main task from the merchant perspective is to get close to his PSP(s) and/or acquirer to check his level of compliance with the PSD2 regulation and the exemption options that they can offer.
Example of a TRA / Transaction Risk Analysis
Merchants identify applicable exemptions according to their activities and constraints.
They analyse the risk linked to the transaction (usually this is outsourced to the PSP).
They then provide the useful information to the issuer.
PSPs provide the services that allow merchants to accept the consumers’ payments means (cards, credit transfers, online credit, e-wallets). They orchestrate communication between acquiring banks and issuing banks, on behalf of the merchant. They must integrate a certified 3DS server to their IT infrastructure, connect it to the Directory Servers and to the acquirers through the Payment Gateway.
In the framework of card payments, PSPs offer to orchestrate communications between the acquiring banks(on the merchant side) and the issuing banks (on the customer side). They must integrate in their IT infrastructure a 3DS Server solution certified by EMVCo and the different payment schemes they accept (CB, Mastercard, Visa, others) and connect it to the different acquirers.
When a transaction is initiated, the PSP first calls the 3DS Server to initiate a user authentication or an exemption. This is phase 2 in the 3DS process diagram.
During a transaction, the acquirer comes into play at two steps: for the payment authorisation request (phase 6 in the 3DS process diagram) and for the request of acquirer exemptions.
However, the risk analysis can be enriched by, and even delegated to, the PSP or the merchant. The acquirer will have to set up specific contractual agreements with its service providers or merchants to protect itself in case of fraud.
When a cardholder validates his purchase, the PSP initiates an authentication process via its 3DS Server solution. This will identify the card scheme used and contact the appropriate Directory Server associated with it. The Directory Server will then identify the card's issuing bank and contact the issuer's Access Control Server (ACS). This is phase 3 of the 3DS process diagram.
The ACS is configured by the issuer with many parameters. It will perform a risk-based analysis based on the ACS rules engine to decide whether or not the cardholder strong authentication should be exempted.
User experience is the tip of the SCA iceberg. Basically, the user experience is improved if the authentication for the cardholder is frictionless. It is also facilitated if the authentication is done with biometrics, compared to the OTP authentication via SMS, where the user has to input a password received on his phone into a web interface.
The change of authentication mode may lead to misunderstanding for some cardholders. It is, therefore, important that the e-merchants and the issuing banks communicate on those changes with their customers. In addition, the diversity of the SCA paths can also be confusing for the cardholder and presents a risk that can be exploited by fraudsters. This can even be accentuated if the cardholder has multiple accounts in different banks with different authentication methods and different authentication paths.
In fact, there are SCA paths for online payment, but also for operations and transactions performed as part of homebanking services on the banking websites or applications. For example, an SCA challenge can be requested If the cardholder uses a third-party application that initiates a payment.
In addition, different methods and paths will be offered to users who do not own and use a smartphone, who do not use a banking app or who do not have data network coverage on their smartphone.
In all cases, the path must be as fluid as possible so that the cardholder continues to prefer online payment by card versus other payment means (PayPal, etc.).
The major change for the cardholders comes with the necessity of enrolling to a new means of authentication. More modern and more secure means, that do not imply entering an OTP or password, are based on the recognition of a biometric print and / or a known device. That implies that the cardholder does this enrolment prior to any authentication. Not only this step is new for many cardholders, but also it can be seen as painful as it adds a step that was not necessary before, even though it makes every single authentication more fluid and the whole authentication journey smoother eventually.
Unlike usages related to the historical 3D-Secure, the PSD2 SCA no longer allows the e-merchant to disengage from 3D-Secure. However, he will be able to request an exemption to be included in the list of trusted beneficiaries. This request is made to the issuer, who remains the final decision maker.
This responsibility falls to the issuer only, who will therefore be liable for the fraud if SCA is not applied, unless an exemption request was granted. This is why there was an increase in the number of SCAs at the start of the implementation of PSD2. Since the merchant can no longer bypass the 3D-Secure step, cardholders will be more exposed to this step. This friction in the customer journey causes a decrease in the transformation rate at the time of payment.
This transformation rate problem should, theoretically, no longer be a problem as the rates of transactions processed by issuers as “frictionless”increase. It was also expected that cardholders integrate this new authentication mode and understand that SCA protects them effectively against online fraud.
Unfortunately, as we can observe, the frictionless part of authentications is not as high as it was expected initially, for reasons that are developed later in this document (see 7.5). While SCA increases security and protects cardholders, its successful implementation can only be achieved when the main barriers are removed. That is: cardholders acceptance of SCA, appropriate change management from the issuer, right implementation of exemptions, etc. This is why SCA implementation from the merchants and acquirers’ perspective is still not satisfactory.
Merchant leaders will be those that manage to optimise 3DS implementation to take full advantage of exemptionsespecially the TRA-and who control their fraud rate.
E-merchants’ PSPs must implement the 3DS v2. and 3DS v3.x servers.
In particular, version 3DS 2.2 is required to collect all the required shopping cart information (by the merchants) and allow their clients (the merchants) to benefit from the exemptions and notably from the TRA exemption.
This exemption will normally be accepted unless there is a suspicion of fraud. The PSPs must be able to monitor fraud for the merchants they work with.
Depending on the cases, the merchants (mainly the larger ones) performs the risk analysis themselves and transmits all required data in 3DS. Otherwise, and this is generally the case, they delegate the risk analysis to their PSPs. The payment schemes can also provide guidance as they monitor the fraud themselves (CB, Visa, Mastercard).
Acquirers are not in the 3DS process. However, they do have a role to play:
Thereby, fraud management is of particular importance to acquirers. Indeed, their online payments fraud rate will influence the threshold for triggering the SCA challenge and therefore the threshold for an acquirer exemption request.
The fraud rate could become a competitive advantage for acquirers. This could impact contractual discussions between acquirers and e-merchants.
Issuers are the most impacted actors in the frame of the SCA implementation.
Responsibility
Issuers are responsible as soon as strong authentication is activated. In other words, they are responsible if the 3DS process is activated and if they refuse the frictionless request in the frame of an exemption.
SMS OTP
The SMS OTP can still be used as a strong authentication mean under certain conditions.
Nevertheless, as the OTP is not encrypted in the SMS, it can be intercepted and therefore presents a risk. Also, the SMS OTP is not considered as a knowledge factor. It can complicate the customer journey and also generates additional costs.
Reinforced SMS OTP with a password is a compliant SCA authentication mean, that allows issuers to continue working with SMS OTP while pairing it with the homebanking password for example.
However, it generates costs related to SMS sending, and is not a user-friendly authentication mean, as the cardholders need to input two values while authentication, one after the other
Customer journey and change management
More generally, issuers need to ensure the transition from SMS authentication to authentication via their banking applications installed on their cardholders’ smartphones. This includes the implementation of the appropriate methods and mechanisms to make it work, and also the support of their own clients (the cardholders) in the process of understanding, accepting and buying in to those new authentication means.
A major change is that authentication via banking applications implies an enrolment from the cardholders, prior to any strong authentication: enrolment of the password (knowledge factor), enrolment of biometrics prints (inherence factor), enrolment of the device (possession factor), depending on the method. This should take place prior to any payment, for the cardholder to be able to use the method when performing a transaction.
From the issuers perspective, it means:
IT investments related to the management of new authentication methods
Obviously, all those changes come at a price for the issuers, which must meet strategic choices about how to manage new authentication means. They can either reinforce existing methods (implementing reinforced OTP SMS for instance, and develop the necessary tools to manage it, like a password enrolment portal), or they can implement new methods. When doing so, issuers need to decide whether they manage the solution themselves or delegate it to a third party. For example, implementing an authentication SDK in their mobile application, or use a full and ready-to-use external authentication solution.
Exceptions
Issuers need to rethink the customer journey during a strong authentication process to make sure they cover all use cases, regardless of the channel, all this by offering the most fluid and consistent path.
They also need to take into account all the "marginal" uses cases, if they want to make sure all their clients are able to authenticate strongly, whatever the situation they are in: customers who do not own a mobile, customers who do not have installed the banking application, customers who would not have a network coverage for the smartphone during an authentication request, etc.
Security
Issuers are responsible of the security (integrity and authenticity) of the authentication factors of their cardholders. This can have major impacts in terms of security choices, with significant consequences in terms of costs. Issuers will also tend to decline a transaction if the smartphone OS (Operating System) is not up to date, as this information goes in their scoring process before deciding whether or not a authentication should be challenged or declined. This example shows again the importance of appropriate communication and change management from the issuers towards their customers, the cardholders.
As an example – If the smartphone is used as a possession factor, issuers must ensure the security of the authentication process on a device they don’t master the security of. A smartphone whose operating system (iOS for Apple and Android for Google) was not updated by the phone user or which is no longer maintained by the manufacturer can present security flaws. These flaws can be exploited by hackers in order to implant malware and therefore access sensitive information and take control of the smartphone.
Issuers must ensure they put in place:
A secure environment for authentication execution
It is the environment in which the authentication process takes place (See 6). This environment integrates and protects the authentication process, and allows the issuer to free himself from the Operating System of the cardholder smartphone.
Dynamic link
During an online payment with a card, PSD2 RTS requires that the SCA process proposed by the issuer makes a dynamic link between the transaction, its amount, and the name of the merchant (or even the merchant’s payment provider), and that this information be protected throughout the entire authentication process. This ensures that the cardholder is validating the appropriate transaction. Otherwise, a user could successfully authenticate during a payment, but with a "fake" validation screen that would not be the right one, because it would have been modified by a malware in the background, or via a window popping upfront at the time of validation.
Simply fill in a few details and our experts will get in touch.
