UL does not fully agree and suggests the following:
1. Article 1.1 of the draft RTS should be adapted to allow a single authentication code to be used for a simultaneous request for multiple services from a single TPP, e.g. account access and electronic transaction initiation.
2. Article 1.3d states: “protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS”. In case a better and more secure technology is released in the future, all the parties would be forced to use this technology as it is explicitely written in the RTS. In this case, the suggestion would be to recommend parties to use state of the art and market proven security protocols, instead of indicating one specific technology.
3. Article 5.1 of the draft RTS should consider allowing behavioral data as a standalone inherence element.
1. 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, the current requirements 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 e.g. a simultaneous account information and payment initiation request when originating from a single TPP. Consecutive requests should still require unique authentication codes.
2. 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, strongly recommends 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 ASPSPs, the ASPSPs should be able to decide on means of authentication, including the choice of using behavioral data as a second factor of authentication. If an ASPSP is willing to take risk while offering a smooth authentication process to consumers, the ASPSP should be allowed to make this choice. We also refer you to Question 4 where we discuss the need of clearly defined liability program
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 meaning of ‘independent or segregated’ in the context of the channel, mobile application or device (Article 2.2b) needs further clarification, as it is currently not clear what should be separated.
The definition of the independent and segregated channels is not clearly defined. For example, in the case that a merchant application provides an embedded checkout function, would the application and the checkout function be considered as two independent 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.
Articles 3, 4 and 5 are too generic and do not provide a sufficient baseline to the industry. UL suggests that these requirements be linked to the best practices and standards that already exist in the market such as e-IDAS, STORK or NIST 800-63.
Below we provide three examples showing that the current requirements are lacking specificity.
The wording of Article 3.1, 4.1 and 5.1 suggests that all of the mentioned security features should be used at all times. UL is of the opinion that this is too strict, specifically in the case of the requirement to always have a biometric sensor for the inherence factor. We foresee that sufficiently secure features, other than a biometric sensor, can be implemented as an inherence factor. We also refer to our answer to Question 1, where we suggest to allow the use of behavioral data for the inherence element.
On top of this, the requirement of using non-repeatable characters for the knowledge element (Article 3) needs clarification. In the case that EBA means that any character cannot appear more than once in the user’s password, this will reduce the total entropy of the password and limit the number of possible password options available for the end user. This will increase the chance that the end user will use the same password for multiple services. With regard to the password requirements, we suggest to link these to best practices and standards that already exist in the market.
Finally, the requirement to have an expiration time for the knowledge factor is ineffective without a specifically defined maximum, as providers would be able to set this to a practically infinite time.
UL agrees with the list of exemptions provided by the EBA although some requirements need to be refined:
1. The localization of limits into other currencies should be addressed and member states should have the option to define lower limits;
2. Provisions for future changes of limits should be included;
3. UL is of the opinion that the limit of EUR 10 for remote electronic payment transactions is not effective and will compromise the user experience. UL suggests to align all the limits regardless of the channel of payment;
4. Article 8.2c should be clarified with regard to the way the payer and the payee can be identified as the same natural or legal person;
5. As a separate important topic, UL suggests to include a clear liability program to RTS.
1. The current RTS only provides limits in euros and does not address localization of the limits in domestic currencies. Moreover, UL recommends the EBA to treat the given limits as a maximum amount and to let the member states 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.
2. 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.
3. The EUR 10 limit is too low for e-commerce transactions and will compromise a smooth checkout of the customer. This also will handicap mobile payment solutions especially when the mobile payment service is used for public transportation services. While the payment amount for the public transportation services may easily exceed the 10-euro limit, the user may not have internet access or it may not be realistic to perform the strong customer authentication during the ticket purchase. As a part of Question 5, UL recommends to align all the limits regardless of payment initiation method and payment channel. This will provide a consistent user experience.
4. Article 8.2c needs to be elaborated further to clarify how the payer and the payee are identified as the same natural or legal person. This is in particular important for the case where a country has central identity services used by the ASPSPs to identify customers. In this case, the exemption can be extended to inter-ASPSPs.
5. UL acknowledges EBA’s 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. The liability program may also address the use of behavior data as a second factor of strong customer authentication (as discussed in Question 1)
UL recommends to align the limits defined in Chapter 2 regardless of payment initiation method and payment channel.
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, following an initial SCA at registration.
Partially. Some of the articles must be reviewed or improved in order to provide more solid requirements:
1. Article 9.1.c will bring significant impact to mobile payment solutions based on Host Card Emulation (HCE) which make use of secure software mechanisms to store secret cryptographic material. Typically, the host memory or the Trusted Execution Environment of a mobile device that stores this information is not considered tamper proof, making existing products in the market non-compliant with the new requirement.
2. Article 10 is expected to recommend a market proven framework for the protection of personalized secure credentials;
3. Article 12 should be clarified to show whether the usage of 3rd party authenticators is allowed or not. UL recommends to reconsider this requirement to align with the latest authentication trends;
4. Article 13.c.2, states that “The delivered personalised security credentials, authentication devices or software require activation before usage”. This will require substantial changes to existing mobile provisioning processes, where consumer authentication and credential activation happen prior to the secure payment credentials being sent to the device. (e.g. mobile banking in-app provisioning).
5. Overall, UL recommends to incorporate world accepted standards such as GDPR, ISO or NIST as a baseline for the protection of personalized secure credentials.
1. 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.
2. The RTS require in Article 12 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 possibly 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.
3. UL strongly believes that the General Data Protection Regulation (Regulation (EU) 2016/679), ISO or NIST should be incorporated or used as a baseline in the scope of this chapter. These standards provide a more robust set of requirements, which can complement the requirements exposed in this chapter. Ultimately, a suggestion would be to use one of the above mentioned standards as baseline, and only provide complementary requirements where (and if) necessary. This will allow cross markets solution developers and service providers to adhere to only one set of regulations.
EBA’s reasoning behind having requirements for common and secure and secure open communication protocols are reasonable, although the provisions proposed in chapter 4 could be more complete. UL specifically recommends the following:
1. Establish proper timing requirements;
2. Propose the actual business scope of ISO 20022 to be used and to define the companion data dictionary protocols (Article 19.3).
(Although it is part of this chapter, the specific discussion about Article 22.5b will be left to question 10).
1. Without proper timing requirements between request and response messages for instance, parties may define their own requirements, which can highly compromise interoperability.
2. 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 payment solution providers an easier implementation of this protocol in their solutions.
Nevertheless, it is important to highlight that ISO 20022 itself is just a standard for developing standards for different business scopes. In fact, there is a number of different established business scopes based on ISO 20022. 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 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.
UL agrees with the requirement to use ISO 20022, as long as it follows the premises that were discussed in question 7 about ISO20022.
Given the online nature of ISO20022 and the underlying technologies this standard is based upon; UL believes that enforcing its adoption will not handicap the capability of any party to either implement it or to innovate in the service offer or user experience. However, if a vanilla version of ISO20022 is implemented and every player decides to define its own version, local and/or regional interoperability may never be achieved. We believe that EBA should take one step forward and propose the actual protocol or business scope of ISO20022 to be used and the companion data dictionary, otherwise, true interoperability will never be a reality.
Leveraging e-IDAS policy is one of the most efficient ways to assure proper identification between TPPs on a regional level.
[General considerations and conclusions will be presented after the answer to question 10]
[Answer to question 10]
UL disagrees with the principle of requiring the ASPSP to allow a certain fixed number of requests by AISPs. In turn, UL suggest to consider implementation of priority rules for the user and AISP initiated requests. In the case the prioritization is not possible the AISP initiated requests should not be allowed.
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 recommends the EBA to address the following two points:
1. 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-initiated requests.
2. 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 initiated requests may need to be higher. Moreover, it is likely that the majority of AISPs will request information updates at the same time (for example 12.00 and 23.00). In this case, the current constraint will limit the pick of requests to twice a day but will not solve a problem in general. The recommendation would therefore be to remove the minimum number of requests. In turn, to protect the user experience, ASPSPs shall be able to differentiate the requests that are initiated by the user and to prioritize these requests. Ideally, this requests shall be routed via different API that would allow to process the user-initiated requests even in the case when the channel for the AISP-initiated requests is overloaded.
Overall, 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.
[-End of answer to question 10-]
One of the objectives of PSD2 is to offer consumers the possibility to access their account information and funds through third parties. This allows 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 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. However, with too strict requirements regarding SCA, the payment experience in e-commerce services can be noticeably impacted and this hassle can prevent the consumer from buying the product. 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 has 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. 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.
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.
By doing this, EBA will be able to provide technical standards that are aligned with the most recent market trends in security, interoperability and usability, which will facilitate and thrust the adoption of PSD2 by all the parties involved in this ecosystem.