EBA Makes New PSD2 Clarifications

October 19, 2022
Back
The European Banking Authority (EBA) has published its latest payment services-related Q&As, looking at issues such as strong customer authentication (SCA) and passporting.

The European Banking Authority (EBA) has published its latest payment services-related Q&As, looking at issues such as strong customer authentication (SCA) and passporting.

It is a truth universally acknowledged (well almost) that when the EU’s banking watchdog publishes a Q&A, payment service providers (PSP) regulatory teams can be known to break out in a cold sweat, wondering whether a blurred line between complying with the revised Payment Services Directive (PSD2) or not is about to become a lot clearer.

In its latest round of Q&As, which are actually often submitted by PSPs and relevant trade associations, the Paris-based regulator set about making more clarifications on security rules regarding the SCA.

One question from the Financial Supervisory Authority of Norway (FSA) addresses the issue of recurring and future-dated payments, suggesting that the regulatory technical standards (RTS) for SCA do not work for third-party providers (TPPs) when it comes to these methods of payment.

TPPs are enabled by the regulation to offer future-dated and recurring transactions in the same way as account servicing payment service providers (ASPSPs).

However, in this instance, the ASPSP, often a bank, can make this challenging for a TPP if they so wish.

For example, the FSA suggests that arguments are brought forward that the provisions in paragraph 29 of the RTS are being satisfied inasmuch as "... the bank enables the TPPs to offer its customers the same payment methods that an ASPSP offers directly to its PSUs [Payment Service Users], and that the bank is not required to offer TPPs the use of other technical solutions, in this case the mobile/web-bank application, which implements the delayed starting of a payment".

On the other hand, it argues that if there is no functionality that would allow a TPP to send transactions with future dates to the ASPSP the way the PSU is able to do in the ASPSP's direct interface.

“There seems to be no substance in the statement,” the FSA complained in its question.

In this instance, the EBA ruled in favour of the TPPs in the scenario described.

“It cannot be considered that the ASPSP allows PISPs to initiate recurring transactions and future-dated payments and therefore this would not be in line with the PSD2 and the Delegated Regulation if the ASPSP offers its PSUs the possibility to initiate recurring transactions and future-dated payments in its direct customer interface.”

In a question submitted in March this year by a credit institution, the EBA was asked whether it was allowed to use a third-party provider’s PSD2 interface that identifies itself with an eIDAS (EU-recognised digital identity) certificate for purposes other than those specified in the SCA RTS.

Apparently, the TPP informed the institution that it makes requests to the PSD2 application programme interface (API) for purposes other than payment initiation or access to account information, namely, monitoring API availability.

What's more, these API requests are part of the monitoring service offered on the market, which is used, among others, by some national competent authorities.

Here, the EBA appeared to shoot down the TPP’s work, stating that TPPs should ensure that they comply with their respective obligations under PSD2, including the requirement to not access any data for purposes other than for the provision of the payment initiation service or, respectively, the account information service (AIS) as explicitly requested by the end user.

Deutsche Bank asked the EBA for clarification and/or harmonised guidance on the scope of the Bank Offered Consent, as defined in the Berlin Group standard, pointing out that currently this is being interpreted differently by different national competent authorities.

The so-called Bank Offered Consent model is initiated by the TPP via an API and enables the end user to select the account(s) and the access level on the ASPSP's domain or system during the redirected or decoupled authentication procedure with the bank.

The access levels that are possible are account lists only, as well as account lists with balances and with balances and transactions.

An option for the implementation of the redirect screen is to pre-populate all accounts and full access levels and give the PSU the ability to deselect accounts or access levels.

According to the German bank, one TPP highlighted concerns over whether it is allowed to let the end user to determine not only the accounts but also the access level per account.

Yet, there is some divide as other TPPs feel strongly about keeping this feature.

Additionally, ASPSPs that do not offer the selection of the access level per account by the PSU were asked by TPPs to offer this.

Here, the EBA suggested that the Bank Component Model is not actually compliant with the PSD2. However, it offered a get out clause, suggesting that if they do not receive the information from the TPP, they can implement the Berlin standard.

This does foresee some issues, however, as the bank may be able to say that it has not received anything, or even can make it so the third party provider cannot send it to them.

Passporting

Two questions have also been answered by the EBA regarding its central register containing information about payment and electronic money institutions authorised or registered within the EU and the European Economic Area countries (EEA).

One, submitted by the Banco De Portugal, asks the EBA whether under the PSD2, in the exchange of notifications between national competent authorities (NCAs), Annex VI of the Commission Delegated Regulation (EU) 2017/2055, the template for the exchange of information in relation to start of branch/agent/distributor passport activities by payment institutions and e-money institutions, should be sent concerning each new agent/distributor or only for the first agent/distributor acting on behalf of a payment/e-money institution.

Here, the NCA of the home member state should transmit to the NCA of the host member state the notification template as set out in the regulation, and not only for the first agent(s)/distributor(s) included in the initial passport notification, the EBA said.

Meanwhile, an anonymous question submitted in July 2021 asks if a payment institution that is on the EBA register under PSD2 represents an EU passport and means that the TPP is authorised to operate for the services indicated in all EU countries.

“Following checks carried out on the EBA register, it emerged that, for some TPPs, the services provided and the countries in which they are provided are listed analytically; for others, on the other hand, only the EU passport is reported, with an indication of the services authorised,” the question points out.

Here, the EBA answered that the information displayed on the EBA Register indicates the member states where the payment institution is allowed to carry out activities and the payment services that can be provided.

And, in accordance with PSD2, NCAs are responsible for the accuracy of the information contained on the EBA Register and for keeping that information up to date, while the EBA is responsible for the accurate presentation of that information.

Instant credit transfers

A question first posed on November 11 last year probed the EBA about whether CustomerID measures, such as encryption, tokenisation, and transport layer security, need to always be applied in any payer-presented QR code, regardless of who generates it (such as a non-PSP).

As defined by European Payments Council guidance, CustomerID is an identification of the payer, issued by their ASPSP for access to customer facing user interfaces, as required in the PSD2 API.

In accordance with the clarifications provided in a previous Q&A, the question, posed by a Belgium trade association, says that CustomerID facilitates the identification of the PSU for the purpose of authentication but is not in itself a valid SCA, and therefore cannot be considered as a Personalised Security Credentials (PSC).

However, CustomerID is not available to third parties other than the PSU and the PSP, and its disclosure can be used to carry out fraud.

Therefore, taking also into account the provisions of the EBA Guidelines on instant credit transfers and security risk management, the CustomerID cannot be included in a cleartext in a payer-presented QR code for the initiation of credit transfers at the Point of Interaction without any security measures ensuring its confidentiality during the QR code life-cycle.

The EBA agreed with this, and stated that the previous Q&A covers the security measures that should be applied when the CustomerID is included in a QR code and does not distinguish between different parties that may generate the QR code.

“Accordingly, the security measures for the Customer ID should be applied in any payer-presented QR code, regardless of who generates the QR code,” the EBA said.

Our premium content is available to users of our services.

To view articles, please Log-in to your account, or sign up today for full access:

Opt in to hear about webinars, events, industry and product news

To find out more about Vixio, contact us today
No items found.