.svg)
The European Banking Authority (EBA) has continued to clarify parts of the strong customer authentication (SCA) regulatory technical standards (RTS), delving into issues including mobile-initiated credit transfers and redirects.
The banking watchdog published six new answers regarding the SCA security requirements just prior to the Easter holiday period.
Over the years, EBA Q&As related to the second Payment Services Directive (PSD2) have provided a reliable source of content, reporting on some of the finer points of the regulation — but the good times could be soon over.
The EBA has now answered 210 questions relating to the directive, with just 25 left to clear its backlog.
Dynamic Linking
One of the answers, based on a question first submitted in July 2020 by a Belgium-based trade association, asks about SCA requirements with dynamic linking for mobile-initiated credit transfers (MSCTs).
This probes the EBA on whether MSCT using QR codes can be considered as a proximity payment, meaning that SCA can be applied without dynamic linking.
Dynamic linking involves aligning authentication tokens to the specific payment amount and the specific payee of the transaction, resulting in the SCA becoming invalid if anything is changed regarding the transaction.
Here, the EBA says that the authentication of the payment service user (PSU) is dependent on the use of the internet and additional fraud risks, such as a fraudster intercepting the communication between the PSU and the payment service provider (PSP), and therefore, falls within dynamic linking requirements.
“In the case described by the submitter, the EBA understands that the payer would initiate a credit transfer at a point of sale (POS) with contactless functionality with the authentication of the payer taking place on a mobile application and requiring a mobile network,” the institution clarifies.
A question submitted by the Germany-headquartered Smart Payment Association in May 2020 also looks for answers regarding dynamic linking.
The trade association asked whether if a user's mobile phone interacts locally via near-field-communication (NFC) with a merchant payment terminal to initiate a Sepa Credit Transfer (SCT) transaction, it is considered an electronic remote payment transaction if the user’s mobile phone does not communicate remotely over a mobile network — for example, where the payment terminal connects online to a payment system.
Article 5 of the SCA RTS states that the provisions for dynamic linking apply to electronic remote payment transactions.
“Mobile wallets or smart cards could be used in-store at a POS terminal to initiate instant payments without, similarly to today’s card-based payments, requiring a redirection for SCA,” the submitter says.
Here, the EBA has said that the example given would not require dynamic linking, considering that the transaction is taking place within the premises of a merchant.
Non-discrimination principle
A question submitted by the European Third-Party Providers Association (ETPPA) asked the EBA whether an account servicing payment service provider (ASPSP) can consider that it is not applying the Article 10 exemption when it permits its PSUs to access balances and transactions information through another direct interface, such as Electronic Banking Internet Communication Standard (EBICS), with no systematic or daily SCA.
Article 10 allows PSPs not to apply SCA where the PSU is accessing certain limited payment account information — namely the balance of the payment account and/or the last 90 days' payment transactions.
In its response, the EBA points out that SCA is required when the PSU accesses its payment account online, directly or through an AISP, irrespective of the type of access interface.
ASPSPs can decide based on their risk assessment whether or not to apply the exemption in Article 10 across all or some of their online direct customer channels, such as the web interface or mobile app.
However, in line with the non-discrimination principle that is outlined in Article 67 of PSD2, if the ASPSP applies the exemption in Article 10 to its PSUs in a particular direct online customer channel, it should also apply the exemption for access requests received via an AISP through the same channel, unless the ASPSP has objective reasons not to do so.
A second question submitted by the ETPPA asks whether the non-discrimination principle can be applied to batch/bulk payments.
For example, the ETPPA says that some ASPSPs currently propose to their customers to transact batch payments through the provider’s website or mobile application.
Yet, according to the trade association, some payment initiation service (PIS) application programming interfaces (APIs) do not allow the third-party providers (TPPs) to initiate batch payment in the same conditions as the ones provided by the ASPSP using the website or mobile application.
For example, some PIS APIs do not authorise batch payment, as the clients' International Bank Account Number (IBAN) needs to be first registered using the ASPSP website or mobile application. The TPP cannot realise this payment operation within the API, and is then obliged either to ask the PSU to add the IBAN using the ASPSP website or mobile application, or to web scrape the ASPSP website/mobile application.
The EBA clarified that a payment initiation service provider (PISP) “has the right to initiate the same transactions that the ASPSP offers to its own PSUs, such as instant payments, batch payments, international payments, recurring transactions, payments set by national schemes and future-dated payments,” under the RTS on SCA.
Therefore, ASPSPs should offer to PSUs the possibility to initiate batch payment transactions through a PISP if they have the same possibility via the ASPSP’s direct customer interface.
Redirection or misdirection?
A question anonymously submitted in October last year asked for clarification on ASPSPs compliance with SCA and whether they have the right to block access to payment accounts for a TPP that embeds the ASPSP-provided redirection website in order to provide the PSU with a TPP-provided user interface.
According to Article 68 of the PSD2, an ASPSP can only deny TPPs access for objectively and duly evidenced reasons relating to unauthorised or fraudulent access, including fraudulent initiation of payment transactions.
“It has, however, happened that ASPSPs have contacted TPPs to say that they will restrict access to the PSD2 API because the TPP embeds the redirection domain provided by the ASPSP for PSUs to enter their credentials when using the services of a TPP,” the submitter suggests.
The reason, the submitter continues, is that the PSU in this instance does not enter its credentials into the ASPSP-hosted redirection domain but into an interface provided by the TPP.
In response, the EBA has partially sided with the banks saying that such an approach may lead to a situation where the ASPSP identifies, based on its transaction monitoring mechanisms, that it is not the PSU who is trying to access the account and subsequently denies access to the payment account.
In such a case, the denial of access to the account would be in line with Article 68.
In another question submitted by a credit institution in June 2021, the EBA was asked about redirections and PSU customer journeys.
“May a PPISP connect to the dedicated interface of the ASPSP, only to subsequently embed ('screen scrape') the redirection approach into their own environment, without redirecting the PSU to the ASPSP’s mobile banking app, for authentication?”
The credit institution continued: “Are TPPs allowed to re-engineer the customer journey designed by the ASPSP to the effect that authentication of the PSU will take place in the TPP domain?”
Here, the EBA has said that PISPs and AISPs should follow the technical specifications set out by the ASPSP when accessing the ASPSP’s interface.
Where the ASPSP has opted for redirection or a decoupled approach and does not allow in its documentation the possibility for the PISP/AISP to transmit the user’s credentials to the ASPSP, they should redirect the user to the ASPSP’s domain to authenticate.
In addition, they should not introduce an approach for sending the user’s personalised security credentials to the ASPSP that is different to the approach envisaged by the ASPSP in the technical specifications of the interface, as this approach would not be in line with the regulatory requirements.
