Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
This is vital to make sure ASPSP complies with Article 67 3 (b) regarding non-discriminatory access to payment accounts for AIS-providers.
While we fully understand the need for an ASPSP to have control over how TPPs are accessing them, a substantial risk with ASPSPs being able to force the communication towards a “dedicated interface” is that it de facto gives incumbent ASPSPs an unfair interpretative prerogative to decide what data elements constitutes as payment account information under the XS2A-rule and what is viewed as sensitive payment data (since neither are defined within the PSD2 or the RTS), allowing them to block their customers from sharing certain data elements about their payment accounts or transactions with TPPs. This would cement an uneven playing field to the detriment of consumer utility, competition and innovation.
It is of vital importance that the EBA takes this seriously and makes sure to define the RTS in such a way that this unfair interpretative prerogative doesn’t occur in order to ensure that the ASPSP complies with Articles 66 4 (c) and 67 3 (b) regarding non-discriminatory access to payment accounts for TPPs. It is key that the spirit of PSD2 that consumers must be enabled to share data about themselves is ensured by the RTS. Otherwise incumbent ASPSPs will by virtue of their de facto “legacy ownership” of their customers’ data keep an, in our opinion unfair, competitive edge vis-à-vis other ASPSPs.
Our fundamental view is that the customer owns the right to her data and should be able to share it with whoever she wants. The fact that an account holder already today could provide a third party with the rights to view all of her financial information (even beyond payment accounts) by issuing a power of attorney establishes that the account holder is already legally free to share her data with a third party without the ASPSP being able to arbitrarily block certain data elements from being shared. These fundamentals should be preserved as we move this process to the digital space with the implementation of XS2A in PSD2, especially considering the fact that the TPPs will have to be licensed (which is not the case with third parties using a power of attorney).
The EBA should consider that the facts that a TPP a) will have to be licensed, b) will have to identify themselves towards the ASPSP in all communication sessions via a Qualified certificate, c) will be mandated to keep the communication session as short as possible and d) will be mandated to limit the request of information to only designated payment accounts and associated payment transactions at the users explicit consent, should provide enough principle based provisions for sufficiently secure communication without mandating the use of only one of the available interfaces. In practice a dedicated interface would probably almost always be used since it would be easier for the TPPs to access, but this would make sure that it is properly maintained and would not discriminate access to data for PSUs connecting through TPPs.
However, if the final RTS specifies that TPPs must only use the provided dedicated interface, one possible solution to this problem would be to give an independent governing entity the mandate to specify and continuously oversee which data elements should be made available for TPPs (and possibly also handle uptime and access complaints). Of course these requirements would only apply for data elements that are available through at least one of the ASPSPs own customer-facing interfaces; hence they would never force an ASPSP to provide a data element that it doesn’t provide in its own customer interface.
Recital 93 PSD2 makes clear that the RTS “should be compatible with the different technological solutions available.” It would be out of scope for the RTS to define or promote a specific communication or messaging standard.
More concretely, ISO 20022 would raise the following issues:
• ISO 20022 is not at all compatible with TPP direct access via the customer-facing online interfaces of the ASPSP.
• PIS/AIS do not make up a payment standard but are software solutions used by payment service users. Imposing a bank-to-bank messaging standard is as such conceptually flawed as ASPSPs do not use ISO 20022 when communicating with payment service users via software such as the web browser.
• Imposing the need for ISO 20022 would mean large investment requirements for ASPSPs, without any clear rationale.
• If Avanza would offer a dedicate interface for TPPs, we would most likely do so on the basis of an adapted version of our mobile app API, which already exists. This would ensure operating performance on par with the mobile app API. An ISO 20022 compliant interface would become a separate infrastructure project and we would need to effectively have to maintain two different types of APIs.
• What is the reason for us to having to “standardise” any innovation/new feature (e.g. a new authentication procedure) that we develop? Why should this be shared with and subject to comments and “approval” by a broad standard-setting community? This is a direct discouragement of innovation.
• To our knowledge there currently exists no ISO 20022 standard for AIS/PIS. It cannot be the meaning of the RTS to impose a wholly unproven standard which is not compatible with AIS/PIS as they work today.
One possible solution for the EBA to consider would be to only implement the limit of twice per day for direct access to the customer facing online interfaces and set a higher limit for dedicated interfaces. This would also provide an incentive for the TPPs to make use of the dedicated interface rather than the customer facing interface.
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?
While we believe that ASPSPs should always be free to enforce SCA even on transactions that meet the criteria for exemption, the provisions in the RTS should be defined in such a way that ASPSPs will not be able to discriminate TPPs from accessing the same read-only non-sensitive data elements related to payment accounts and payment transactions that the PSU would be able to access without SCA in the ASPSPs own customer interface. For example, if an ASPSP doesn’t require the PSU to perform SCA to view the account balance (after the first time) in the ASPSPs own mobile application or website it should not be able to force it upon TPPs. This should be true even after 30 days (it should be the same time limit as the ASPSP applies in its own customer interfaces).This is vital to make sure ASPSP complies with Article 67 3 (b) regarding non-discriminatory access to payment accounts for AIS-providers.
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?
The rationale behind the draft RTS (69 a) seem to suggest that in case an ASPSP provides a dedicated interface for TPPs to access, the TPP must not access payment accounts by means of direct access via the customer-facing online interfaces of the ASPSP.While we fully understand the need for an ASPSP to have control over how TPPs are accessing them, a substantial risk with ASPSPs being able to force the communication towards a “dedicated interface” is that it de facto gives incumbent ASPSPs an unfair interpretative prerogative to decide what data elements constitutes as payment account information under the XS2A-rule and what is viewed as sensitive payment data (since neither are defined within the PSD2 or the RTS), allowing them to block their customers from sharing certain data elements about their payment accounts or transactions with TPPs. This would cement an uneven playing field to the detriment of consumer utility, competition and innovation.
It is of vital importance that the EBA takes this seriously and makes sure to define the RTS in such a way that this unfair interpretative prerogative doesn’t occur in order to ensure that the ASPSP complies with Articles 66 4 (c) and 67 3 (b) regarding non-discriminatory access to payment accounts for TPPs. It is key that the spirit of PSD2 that consumers must be enabled to share data about themselves is ensured by the RTS. Otherwise incumbent ASPSPs will by virtue of their de facto “legacy ownership” of their customers’ data keep an, in our opinion unfair, competitive edge vis-à-vis other ASPSPs.
Our fundamental view is that the customer owns the right to her data and should be able to share it with whoever she wants. The fact that an account holder already today could provide a third party with the rights to view all of her financial information (even beyond payment accounts) by issuing a power of attorney establishes that the account holder is already legally free to share her data with a third party without the ASPSP being able to arbitrarily block certain data elements from being shared. These fundamentals should be preserved as we move this process to the digital space with the implementation of XS2A in PSD2, especially considering the fact that the TPPs will have to be licensed (which is not the case with third parties using a power of attorney).
The EBA should consider that the facts that a TPP a) will have to be licensed, b) will have to identify themselves towards the ASPSP in all communication sessions via a Qualified certificate, c) will be mandated to keep the communication session as short as possible and d) will be mandated to limit the request of information to only designated payment accounts and associated payment transactions at the users explicit consent, should provide enough principle based provisions for sufficiently secure communication without mandating the use of only one of the available interfaces. In practice a dedicated interface would probably almost always be used since it would be easier for the TPPs to access, but this would make sure that it is properly maintained and would not discriminate access to data for PSUs connecting through TPPs.
However, if the final RTS specifies that TPPs must only use the provided dedicated interface, one possible solution to this problem would be to give an independent governing entity the mandate to specify and continuously oversee which data elements should be made available for TPPs (and possibly also handle uptime and access complaints). Of course these requirements would only apply for data elements that are available through at least one of the ASPSPs own customer-facing interfaces; hence they would never force an ASPSP to provide a data element that it doesn’t provide in its own customer interface.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
We see significant problems with the suggestion that ISO 20022 elements, components or approved message definitions should be required for technological communication solutions for the provision of AIS and PIS.Recital 93 PSD2 makes clear that the RTS “should be compatible with the different technological solutions available.” It would be out of scope for the RTS to define or promote a specific communication or messaging standard.
More concretely, ISO 20022 would raise the following issues:
• ISO 20022 is not at all compatible with TPP direct access via the customer-facing online interfaces of the ASPSP.
• PIS/AIS do not make up a payment standard but are software solutions used by payment service users. Imposing a bank-to-bank messaging standard is as such conceptually flawed as ASPSPs do not use ISO 20022 when communicating with payment service users via software such as the web browser.
• Imposing the need for ISO 20022 would mean large investment requirements for ASPSPs, without any clear rationale.
• If Avanza would offer a dedicate interface for TPPs, we would most likely do so on the basis of an adapted version of our mobile app API, which already exists. This would ensure operating performance on par with the mobile app API. An ISO 20022 compliant interface would become a separate infrastructure project and we would need to effectively have to maintain two different types of APIs.
• What is the reason for us to having to “standardise” any innovation/new feature (e.g. a new authentication procedure) that we develop? Why should this be shared with and subject to comments and “approval” by a broad standard-setting community? This is a direct discouragement of innovation.
• To our knowledge there currently exists no ISO 20022 standard for AIS/PIS. It cannot be the meaning of the RTS to impose a wholly unproven standard which is not compatible with AIS/PIS as they work today.
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.
While we agree with the reasoning behind the proposal to limit the amount of requests for a TPP towards an ASPSP, the limit of twice per day could of course quickly become outdated. If the ASPSP is providing a dedicated interface for TPPs, allowing more frequent requests from AIS-providers should be less of an issue as it potentially could be designed in such a way that a data request overload would either be prevented or would not directly affect the ASPSPs own customer-facing interfaces.One possible solution for the EBA to consider would be to only implement the limit of twice per day for direct access to the customer facing online interfaces and set a higher limit for dedicated interfaces. This would also provide an incentive for the TPPs to make use of the dedicated interface rather than the customer facing interface.