EBA欧洲银行-Fourth-set-of-issues-raised-by-EBA-WG-on-APIs_7页_339kb

EBA Responses to Issues XIV to XX from the API Working Group under PSD2

Core Content Overview

The European Banking Authority (EBA) has provided responses to several issues raised by participants in the API Working Group under the Second Payment Services Directive (PSD2). These responses aim to clarify the legal obligations and practical considerations for Account Servicing Payment Service Providers (ASPSPs) and Third Party Providers (TPPs) in the context of Application Programming Interfaces (APIs).

Key Issues and EBA Responses

Issue XIV: Confirmation of Payment Execution

• Topic: Whether ASPSPs must provide updates on the status of a payment transaction to PISPs after initiation.
• Main Concerns:
  • PISPs need to confirm payment status to provide clarity to merchants and PSU.
  • Early rejection alerts help in offering alternative solutions and avoiding revenue loss.
• EBA Response:
  • The EBA has addressed this through Q&A 4601 (07 June 2019).
  • Article 36(1)(b) of the RTS requires ASPSPs to provide information on payment initiation, but not further updates.
  • Some API standards allow optional updates, but they are not legally mandated.

Issue XV: Biometrics and Authentication on Mobile Apps

• Topic: Whether ASPSPs should allow biometric authentication for TPPs.
• Main Concerns:
  • TPPs need to ensure seamless authentication using the same methods as the ASPSP's own channels.
  • Biometric authentication is essential for a good customer experience.
• EBA Response:
  • ASPSPs must ensure their dedicated interfaces do not prevent PISPs and AISPs from using the same authentication methods available to PSUs.
  • If biometrics are used in direct customer channels, they should also be supported in TPP interfaces.
  • ASPSPs must secure the transmission of authentication status to TPPs, using methods like signed proofs.

Issue XVI: Access to Non-Payment Account Information

• Topic: Whether AISPs can access non-payment account data via customer interfaces.
• Main Concerns:
  • Screen-scraping may inadvertently access payment account data.
  • There is a need for clearer guidance to prevent this.
• EBA Response:
  • PSD2 and RTS apply only to payment accounts, not non-payment accounts.
  • The definition of a payment account is based on functionality, not just denomination.
  • From 14 September 2019, screen-scraping for payment accounts without identification is no longer allowed.
  • AISPs are responsible for ensuring they do not access unnecessary data.
  • GDPR obligations apply to both ASPSPs and TPPs.

Issue XVII: Stress Testing of ASPSP Interfaces

• Topic: Whether stress testing in a production-like environment is permissible.
• Main Concerns:
  • Stress testing in production could affect service levels for other interfaces.
  • It is difficult to simulate high request volumes without real users.
• EBA Response:
  • Stress testing can be conducted in an environment with the same infrastructure and features as the production dedicated interface.
  • Real customers are not required for such testing.
  • This approach is compliant with EBA Guidelines (EBA/GL/2018/07), as long as service level targets are met.

Issue XVIII: Qualified eIDAS Certificates for ASPSPs

• Topic: Whether ASPSPs need to include all roles in their eIDAS certificate.
• Main Concerns:
  • Credit institutions acting as TPPs may need to be authorized for multiple roles.
• EBA Response:
  • ASPSPs can provide all payment services under PSD2 as part of their general authorization under Directive 2013/36/EU.
  • They do not need to be individually authorized for each service.
  • The roles of "payment initiation", "account information", and "issuing of card-based payment instruments" can be included in a single eIDAS certificate.
  • The EBA has also clarified this in O&A 4413.

Issue XIX: 4 Times Per Day Access by AISPs

• Topic: Whether the 4 times per day access limit applies to ASPSPs' dedicated interfaces.
• Main Concerns:
  • The limit restricts the ability of AISPs to provide timely alerts.
  • It may push users to use ASPSPs directly instead of AISPs.
• EBA Response:
  • The 4 times per day limit applies to AISPs accessing payment account data without customer involvement.
  • It does not apply to ASPSPs' dedicated interfaces.
  • Higher frequency access can be agreed upon with the PSU's consent.
  • Push notifications are a viable alternative to mitigate the impact of the limit.

Issue XX: Sharing of Payment Account Number with PISPs

• Topic: Whether ASPSPs must share the payment account number with PISPs.
• Main Concerns:
  • Fraud risks increase if refunds are sent to unauthorized accounts.
  • PISPs may need the account number to process refunds.
• EBA Response:
  • ASPSPs are only required to provide information necessary for the PIS.
  • The account number is not mandatory unless the PSU explicitly authorizes it.
  • The EBA clarified in Q&A 4188 and the Final Report (feedback table, page 71, comment 80) that ASPSPs can ask the PSU to select the account during authentication before redirecting back to the PISP.
  • Refunds should be agreed upon by the merchant and PSU, and the payment account is determined by their agreement.

Summary of Key Points

• Legal Obligations: The EBA clarifies that certain requirements (like payment execution updates, biometric authentication, and access limits) are not legally mandated beyond what is specified in the RTS and PSD2.
• Flexibility and Practicality: The EBA supports the use of optional features like push notifications and app-to-app redirection to enhance user experience and reduce friction.
• Data Protection: Both ASPSPs and TPPs must comply with GDPR when handling personal data.
• Account Classification: Payment accounts are defined by their functionality, not just their name or denomination.
• Stress Testing: Can be conducted in a production-like environment without real users, provided service level targets are met.

These responses aim to balance regulatory compliance with the practical needs of the financial industry in the context of open banking and API integration.