Analysis of the PSD2 Draft Regulatory Technical Standards. What does it mean for the market?
September 23, 2016 - Answering the ten questions posed by the EBA
Following its entry into force in January 2016, the revised Payment Services Directive (PSD2) has created a regulatory framework that is intended to re-shape the EU payment market. By enabling the sharing of data that banks have historically held within the confines of their systems, PSD2 opens up the market to innovative services. Drivers such as boosting innovations, enhancing competition and improving consumer protection ought to be seen as very positive in any market.
In August 2016, the European Banking Authority (EBA) has published a consultation paper on the draft Regulatory Technical Standards (RTS) specifying the requirements on strong customer authentication and common and secure communication under PSD2. In this document, the EBA has listed ten questions that the payment industry is expected to provide feedback to. It is an encouraging initiative from the EBA to request the industry’s opinion before enforcing such regulation. The following sections provide our position on the draft RTS. Based on this analysis UL is formulating a formal answer to the EBA.
UL’s position and main consideration
One of the objectives of PSD2 is to offer consumers the possibility to access their account information and funds through third parties. This should allow new banking and payment experiences for consumers and is very much aligned with the recent trends in our increasingly connected digital society.
UL recognizes the challenge of balancing the consumer protection and payment experience, especially in the e-commerce world. UL fully supports the concept of strong customer authentication (SCA) as a way to increase consumer protection. The payment experience, however, is noticeably impacted in the e-commerce services and the hassle of paying for something can prevent the consumer from buying it. There is a direct correlation between convenience and conversion rates and without proper balance between consumer protection and user experience, the SCA can become a ‘conversion killer’.
Additionally, authentication mechanisms, methodologies and frameworks have evolved throughout the years in order to allow authentication to become less of a friction point in the user journey. At UL, we have followed this evolution closely in order to support our clients to develop more reliable, yet more user friendly ways of authenticating consumers.
It is really unfortunate to see that some of these new frameworks and concepts are not fully explored by the RTS. Specifically, mechanisms such as Risk-Based Authentication, Federate Access and Federate Identity Management, 3rd party or distributed authenticators, are examples that are already heavily used by the industry today as they can offer superior consumer experience. They have apparently not fully been considered or even allowed based on the scope of the current RTS.
The consequences of the limited view of the RTS might be quite negative in the long term for the market and will certainly slow down or even prevent a wide adoption of the regulation. For instance, if we consider Amazon’s “1-Click” ordering and similar solutions as an example, from the moment this regulation would become effective, consumers would need to provide two-factor authentication in order to complete such purchases, which would ultimately put the entire concept behind these solutions in jeopardy.
The payment industry has already faced a similar issue with the introduction of 3D Secure implementations and the negative impact it’s had on merchants’ conversion rates. We can extrapolate this example to other services like Uber, and even in-app payments in order to illustrate the potential impact on consumers and merchants.
This RTS also fails to outline requirements for a recent, but growing trend in the market, which is in-store remote payments (for instance Apple in-store remote payments). The line between card not present and card present transactions for in-store payments are getting thinner by the day, yet, how such scenarios should be treated, exemptions and other considerations cannot be seen in the RTS.
Digest of the Draft RTS
The key topics outlined in the draft RTS are outlined below along with UL’s opinion regarding the EBA’s proposed solutions. Based on this analysis, UL is developing a formal response to the EBA with suggestions on how to improve it in order to make it more consistent and allow it to support a successful PSD2 adoption.
Generating an authentication code
In the draft RTS, a list of requirements for strong customer authentication and authentication procedures is provided. In situations where user authentication is required, such as initiating payments and accessing account information, this process shall result in the generation of unique authentication codes for every action or request of the consumer. Additionally, the RTS specify security features of this authentication code and mechanisms to prevent access by unauthorized parties, e.g. black lists, time-outs, communication protocols and risk profiles.
The requirement for the authentication code to be accepted only once may interfere with some possible services. UL anticipates that many third party providers (TPPs) would offer both account information and payment initiation services. In practice, this could mean that showing the account balance and recent transactions just after making a payment with a TPP would require the user to authenticate himself separately for each type of service. This may compromise the user experience for comprehensive payment services. For this reason, UL suggests to allow the use of a single authentication code for a simultaneous account information and payment initiation request when originating from a single TPP. Consecutive requests should still require unique authentication codes.
According to PSD2’s requirements on Strong Customer Authentication for payments, Payment Initiation Services Providers (PISPs) have to apply elements which dynamically link the transaction to a specific amount and a specific payee (e.g. the merchant). Additionally, the payer shall be made aware at each stage of the transaction amount and the payee information, reflecting the dynamic nature of the underlying authentication code. Therefore, to assure the data transparency and segregation of the merchant and the Payment Service Provider (PSP) environment, it is specified that “the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment”.
In principle, UL agrees with the EBA’s reasoning to separate displaying the payment amount and payment initiation, although this requirement needs to be clarified further. In particular, the definition of different channels needs further explanation. For instance, if a merchant application provides an embedded checkout function, would it be considered as two separate channels? Does the EBA intend the end user to be able to differentiate channels? In this case, the user experience may be compromised. The EBA should clarify that the end user interface may not show the difference of channels. However, in the background, the channels of the payment information (merchant) and of the payment initiation (PISP) shall be different.
Definition of authentication elements
The RTS define general requirements for the authentication elements required as part of the strong customer authentication. They are categorized as knowledge, possession and inherence. Specifically, the RTS specify that the requirements for the knowledge element shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters. The possession element shall be characterized by security features such as algorithm specification, key length and information entropy. For the inherence element, security features include algorithm specifications, biometric sensor and template protection features.
These requirements are too generic and do not provide a sufficient baseline to the industry. In our opinion, these requirements need to be linked to the best practices and standards that already exist in the market such as e-IDAS, STORK or NIST 800-63 (at least for inspiration as the latter one is managed by the US authorities).
Additionally, the EBA’s general position is that behavioral data cannot be considered as a standalone inherence element, but rather as an additional tool for fraud prevention. UL, however, would strongly recommend the EBA to let issuers manage their own risk and balance the security measures and the user experience by use of a liability shift. Since the liability for the end user authentication is with the account servicing payment services providers (ASPSPs), i.e. the bank, the ASPSPs should be able to decide on means of authentication, including the choice of using the behavioral data as a second factor of authentication. If an ASPSP is willing to take risk while offering a smooth authentication process to consumers, ASPSP should be allowed to make this choice.
Exemptions to Strong Customer Authentication
The RTS list the exemptions from the application of strong customer authentication. Namely, SCA is not required in the following scenarios:
- when the payer accesses exclusively the information of its payment account online, without disclosure of sensitive payment data.
- For contactless electronic payment at a point of sale, the individual limit is set to 50 EUR, with a cumulative limit of 150 EUR.
- Online credit transfers to a previously trusted payee, or when the payer and payee are the same natural person,
- the individual limit for remote electronic payments are set to 10 EUR with a cumulative limit of 100 EUR.
UL in general agrees with the list of exemptions provided by the EBA although some requirements need to be refined. Moreover, additional guidelines are required to provide more solid requirements.
In particular, the EBA only focuses on providing limits in euros and does not address localization of the limits in domestic currencies. Moreover, UL would recommend the EBA to treat the given limits as a maximum amount and to let the member states to decide on the appropriate limits within the defined cap. For example, under the current text, Sweden would have to adopt a limit of SEK 478.72 (EUR 50 equivalent), which would be both difficult to communicate to consumers and be impacted by currency fluctuations. Letting the member state define a limit in its local currency without exceeding EUR 50, for example SEK 400, would directly address both the aforementioned issues.
Additionally, the EBA has not made any provisions for the cases that the individual domestic limits need to go higher due to market demand or exceed the defined limits due to inflation or currency fluctuations.
Finally, to provide a consistent user experience, UL recommends to align all the authentication thresholds regardless of how the payment is initiated (e.g. via ASPSP/user or PISP) and the payment channel (e-commerce or in-store). UL would also expect that the same list of exemptions applies for PISPs.
Overall, UL acknowledges the EBA intention to protect the end user from fraud, especially in the e-commerce field. However, in an effort to protect the user experience during checkout, UL recommends to introduce a clear liability program where ASPSPs can decide the level of risk they are willing to take.
Security measures to protect the confidentiality and integrity of users’ personalized security credentials
The RTS establish a clear need for the protection of personalized secure credentials for payment transactions, during their processing, storage and transmission. However, the requirements for protection of such credentials remain quite vague. We believe that the EBA needs to recommend a market-proven framework as part of this RTS, in a similar way to its recommendation for card-based payment transactions, in the “Book 4 – Security – SEPA Cards Standardization Volume Version 7.5”, which sets PCI DSS as a baseline for protecting card data.
Additionally, the RTS require that “The security measures to protect the confidentiality and integrity of payment service users’ personalized security credentials shall ensure that the payer is exclusively associated with the personalized security credentials…”. This creates a gap that makes it unclear whether or not the usage of 3rd party authenticators, such as FIDO’s UAF and U2F solutions, and solutions like Apple’s TouchID and Samsung’s Iris recognition solution are allowed or not. Such solutions perform user enrolment and authentication independently from the application or service requesting it, meaning that the ASPSP cannot ensure that their personalized security credentials properly link the user’s identity and the TPP. Therefore, if such requirements indeed cause such solutions not to be valid in the scope of SCA, this will cause the creation of services and user experiences which are not aligned with the current market demands and trends, which will definitely hamper the adoption of the overall regulation.
For the purpose of identification, authentication, notification, and information, the EBA specifies that it is up to ASPSP to identify common and secure open standards of communication. The ASPSPs shall offer at least one communication protocol that is documented and freely available for the TPPs. This interface shall use ISO 20022 elements and other standards of communication that are developed by Europe standardization bodies.
UL received very positively the recommendation of ISO 20022 as a standard for communication between parties. Given that the ISO 20022 standards leverage the most common technologies in the online communications domain, it will grant solution providers an easier implementation of this protocol in their solutions.
Nevertheless, it is important to highlight that the difference between ISO 20022 and its established business scopes. ISO 20022 is generally referred to as a “standard to create standards”, that means that it provides a framework for creating communication protocols. Based on ISO 20022, some business scopes were already created for specific purposes, such as card payments, securities and trade services, which contain pre-defined message catalogs.
If the EBA is recommending ISO 20022 in order to allow parties to create their own messaging specifications, this will not promote interoperability. Instead, the exact opposite effect will be obtained, where different parties will enforce their own proprietary protocols, making it difficult for Account Information Service Providers (AISPs) and PISPs to connect to all ASPSPs.
The possible solution in this case is to enforce the usage of one of the established business scopes of ISO 20022, for instance “Payments”, “Cards” etc. and define appropriate data dictionaries to use along with these standards.
We believe that the EBA should take one step forward and propose the actual protocol or scope of ISO 20022 to be used and the companion data dictionary, otherwise, true interoperability will never be a reality.
The EBA proposes that during identification between TPPs, website certificates issued by a qualified trust service provider under an e-IDAS policy should be used and be allowed for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services. UL understands that this requirement is valid and that leveraging such standards and requirements, is one of easiest ways to assure proper identification between TPPs on a regional level.
Limiting the frequency of AISPs requests to ASPSPs
The RTS specify that AISPs can request information from designated payment accounts when the payment service user is not actively requesting such information no more than two times a day. According to the EBA, this requirement intends to achieve an appropriate balance between allowing AISPs to provide updated information to their users while not negatively impacting the availability of the ASPSPs’ communication interface.
UL disagrees with the principle. First of all, as the number of AISPs grows, this will push a sole responsibility to ASPSPs to keep a robust infrastructure in order to support all the calls, without any protection against AISPs requesting data at any time during the day, which could impact the performance of the service and more specifically the requests from users that explicitly need to update the displayed information.
UL would recommend the EBA to address the following two points:
- If the non-user initiated requests are to be permitted (as per the current scope), it should be possible for ASPSPs to differentiate between requests originating from AISPs and requests originating from users, and therefore give the option to prioritize user-originated requests.
- The number of requests per day (2), seems arbitrary, as it may not necessarily reflect actual AISP or user needs. As some services may perhaps require more frequent updates than others, the number of AISP originated requests may need to be higher. The recommendation would therefore be to remove the minimum number of requests and let AISPs find user-friendly ways of triggering user-initiated data requests.
Therefore, this requirement should be reassessed in order to specify in more details specific use cases that can trigger information requests and their initiator, therefore allowing ASPSPs to properly manage these requests and as a consequence offer higher quality services.
Although the RTS contains a valid authentication framework, it doesn’t seem to take into account the latest market trends and offerings in the field of authentication. As a consequence, both the objective of proposing new banking and payment experiences through the TPPs and further enhancing the consumer-centricity of those solutions are in jeopardy.
Additionally, the lack of a clear protocol requirements between parties for secure communication, may also hamper both interoperability and long-term innovation. If we take the lessons learned from the card payment market, the EBA should consider setting clearer standards around security and interoperability and let the market find ways to innovate and manage the customer experience.
UL strongly encourages all the industry stakeholders to provide strong feedback to this consultation, exposing their concerns and strive to promote the creation of technical standards that are aligned with the most recent market trends in security, interoperability and usability.