Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?

As stated in the consultation paper, the draft RTS, along with provisions already setup in PSD2, set out a harmonized framework that is aimed at ensuring an appropriate level of security for consumers and Payment Service Providers, through the adoption of effective and risk-based requirements, securing and maintaining fair competition among all PSPs and allowing for the development of user-friendly, accessible and innovative means of payment. Envestnet Yodlee (Yodlee") agrees with the need for strong customer authentication in payment transactions as well as risk-appropriate customer authentication for Account Information transactions. Risk-appropriate customer authentication incorporates many of the elements put forth in the Articles of Chapter 1, most notably the need for a user authentication procedure that provides for proper disclosure and consent while balancing the user rights to a competitive financial services environment. The procedure should generate an authentication code with appropriate considerations (i.e. persistence, reuse, etc.) for the customer’s engagement with the AISP and be protected by technical safeguards. (Article 1) Yodlee is engaging with industry on developing such authentication schemes and will be pleased to discuss our work to date."

Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions 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, as foreseen in Article 2.2 of the draft RTS.

In the context of an Account Information transaction or user experiences, Yodlee agrees that the confidentiality, authenticity and integrity of the information provided by the customer and retrieved about them on their behalf must be ensured. Such controls should be risk-based and comply with applicable security privacy regulations and standards based on a threat assessment of harm to the customer.

Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?

Article 3, knowledge, considers “something the user knows” while Article 4 considers “something the user has”. There is also the consideration of “something the user is” which is commonly called biometrics. For the purpose of the RTS, this could be part of Article 4 as current trends in biometric authentication for financial services treat this similarly (i.e. a fingerprint is stored on the mobile device. The challenge is that Article 5 considers that devices and software are provided to the user. In today’s payments and AIS experiences, users have their own devices (browsers, mobile, tablets) with varying levels of compliance. Therefore, the software used should be containerized to enforce the RTS on such devices.

Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?

Yodlee recommends that if risk-appropriate customer authentication is not included in the RTS for AISPs, then AISP transactions should be exempt for strong authentication as defined in the RTS.

Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?

No, other than to reiterate that if risk-appropriate customer authentication is not included in the RTS for AISPs, then AISP transactions should be exempt for strong authentication as defined in the RTS.

Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?

As previously stated in our response to Question 5, if risk-appropriate customer authentication for AISP transactions is not incorporated in the RTS, then AISPs should be excluded from SCA.  However, that would reasonably require a separate RTS for AISPs to address the protection of confidentiality and integrity of personalized security credentials used for in account information services environment.

Accordingly, Yodlee responds as follows regarding the protection of the confidentiality and integrity of AISP users credentials:

• Yodlee considers Article 9 as defining control objectives for security and integrity.  These apply to credentials for AISP as well as PSPs .  As control objectives are risk-based and different from prescriptive controls, this supports our recommended differentiated approach to PSP and AISP credential management.
• Applying Article 10 to the AISP ecosystem means that there must be contractual obligations for security by all parties.  This is already partly in place in our model (customer-AISP, AISP-aggregator) so missing is the agreement between aggregator-bank.  However, bilateral agreements of this sort are contrary to the goal of establishing the broader ecosystem that we want to see develop to foster protection, innovation and competition.  Therefore Yodlee suggests the following additional paragraph to Article 10:

The service agreement between consumers and account information services providers and between account information services providers in the case of 3rd party aggregators shall include contractual provisions ensuring that account information service providers have appropriate security measures to meet the control objectives referred to in Article 9 to protect data related to the personalized security credentials used by the account information services provider.

• Yodlee agrees that Article 11 is risk-based.
• Article 12 is more complicated in the AISP model.  Yodlee agrees that association between the consumer and their credentials must be ensured, but not with tying it to a device.  Here too we suggest another paragraph that mirrors the current one, but removes that particular control. 
• Yodlee would suggest agreement in Article 13 that security devices are not applicable in an AISP context.  The other control objectives seem fine.
• Yodlee believes that Articles 14, 15 and 16 are workable so long as aggregators receive relief from the frequent recertification for the AISP.

Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?

Yodlee agrees with the EBA that common and secure standards of communication are necessary to ensure standards for identification, authentication, notification and information exchange. However, while account information service providers are referenced in the Articles, there are significant differences in the user experience and information exchanged than with a payment transaction that requires the RTS consider AISP-specific provisions. As recommended in responses to previous questions, Yodlee believes this should be directly addressed in this RTS or in a separate RTS specific to the AISP experience.

Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.

No, Yodlee does not agree that setting an artificial limit on the frequency of data collection is warranted or beneficial. To the contrary, Yodlee’s experience is that such limitations are detrimental to the consumer and the AISP, and can negate the value of providers’ solution. Timely and up-to-date data is required to allow consumers to make good financial decisions, for underwriters to make appropriate lending decisions and for advisors to provide proper advice in compliance with regulations and standards for such advice. An artificial limit will negatively affect all these requirements, reduce adoption of these necessary tools and stifle innovation.
Yodlee agrees that there are operational risk and commercial practicalities with maintaining the ASPSP interfaces. The best way to addresses, these are, in our experience, with standards and guidelines for governance and service operations linked to the user experience and compliance requirements of AISP models.

Please select which category best describes you and/or your organisation

[Other "]"

If you selected "Other", please provide details

With more than 1,000 customers and over 16 years in the industry, Yodlee is the leading account aggregation platform provider globally. Yodlee provides account aggregation capabilities with a hosted solution and open APIs on a business-to-business basis to customers around the world, including within the European Union, that include banks and FinTech and companies. These customers offer data from Yodlee’s platform to hundreds of thousands of retail consumers in Europe through the customers’ own personal finance management solutions, which provide a single platform for consumers to track, manage, and improve their finances across a host of different banks and financial institutions. Customers can also use Yodlee’s platform to establish the authenticity of account holders in real time and for risk management purposes. Yodlee’s customers include top global banks in more than 20 countries. Leading financial innovators like Kabbage and PayPal are also Yodlee’s customers.

With more than 15 years’ experience integrating into the largest banks in the world, security is in the Yodlee DNA. Yodlee has extensive experience meeting the highest standards in data security, privacy, and regulatory compliance. Yodlee is audited by U.S. regulatory agencies and maintains comprehensive security procedures, policies, controls, and reviews across every aspect of its technology and its business, globally. Protecting the personal information of individuals who use Yodlee customers’ products and services is the top priority at Yodlee. Yodlee does not typically receive any information from data providers that is considered personally identifiable information under the relevant regulations. As a precaution, Yodlee further scrubs all user data received to ensure elimination of any potential personally identifiable information that might appear in a transaction string or elsewhere, so that no data utilized by Yodlee contains any user identifiable or attributable information. In addition to Yodlee’s own internal audits, transaction level scrubbing is also checked by leading third party security and privacy experts like TRUSTe.

These security standards have been established over nearly two decades of partnership with our financial institution clients and regulatory authorities worldwide.

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

Consumer-permissioned financial data aggregation and analytics

Name of organisation

Yodlee, Inc.