PSD2: EBA Opinion Allows More Time to Implement Strong Customer Authentication

On 21 June 2019, the European Banking Authority (EBA) published an Opinion on Strong Customer Authentication (SCA) under the revised Payment Services Directive (PSD2). The EBA’s Opinion allows Competent Authorities (CAs) to exceptionally grant additional time beyond 14 September 2019 to specific Payment Service Providers (PSPs) to comply with the SCA requirements. It also provides clarification about the compliance of common authentication methods with PSD2’s SCA requirements.

In this article, I discuss the clarifications of the EBA’s Opinion and also raise some areas where additional clarification is required.

Scope of Extension

The Opinion allows Competent Authorities (CAs) to exceptionally grant additional time beyond 14 September 2019 to specific Payment Service Providers (PSPs) to comply with the SCA requirements. More specifically, the Opinion states that “CAs may decide to work with PSPs and relevant stakeholders, including consumers and merchants, to provide limited additional time to allow issuers to migrate to authentication approaches that are compliant with SCA, such as those described in this Opinion, and acquirers to migrate their merchants to solutions that support SCA.”

As such the Opinion heavily refers to issuers, acquirers, and merchants when discussing the possibility to obtain more time to comply. This terminology is typically used in the context of card payment for e-commerce. This is probably the case because most requests to delay the September deadline came from e-commerce companies.

This raises the question whether Competent Authorities will only grant additional time in the context of card payments for e-commerce, and perhaps not in the context of other applications that require strong authentication, such as online banking and mobile banking. We have requested that the EBA clarify this.

WHITE PAPER

Enabling PSD2-Compliant Fraud Monitoring with OneSpan Risk Analytics

New PSD2 requirements demand that financial services organizations perform transaction monitoring. Learn the specific requirements and how OneSpan Risk Analytics can keep you compliant in this white paper.

Download Now

Timing of Extension

As mentioned above, the Opinion allows CAs to provide “limited additional time” to PSPs to comply with the SCA requirements. However, the Opinion does not impose a deadline. As a consequence, different PSPs might have different timelines to comply with the SCA requirements, and this could impact payments where multiple PSPs are involved. For instance, if a card payment is performed between a card issuer that complies as of 14 September 2019 and an acquirer that has received an extension of say six months, then the acquirer might send a request for payment without SCA to the issuer. But, the issuer will decline the payment, because it requires SCA. As a consequence, payments could be declined although both issuer and acquirer act correctly. This clearly raises the need for CAs to grant extensions in a coordinated way.

Alignment of SCA and Open Banking Timelines

Until now, the introduction of Open Banking APIs and SCA went hand-in-hand and followed the same timeline, with the deadline being 14 September 2019 for both. The EBA’s Opinion allows additional time to implement the SCA requirements but does not allow additional time to implement Open Banking APIs, the other pillar of PSD2. As a consequence, banks could offer Open Banking APIs to Third-Party Providers (TPPs) without SCA.

This has a number of consequences:

• Impact on security: If a bank does not protect bank accounts with SCA, and if it supports authentication via the embedded model, TPPs will obtain weak credentials used to protect bank accounts. For instance, if a bank account is protected with a username and static password, the TPP could obtain these credentials. As a consequence, the TPP could log onto these bank accounts and perhaps perform payments without the account holders being aware.

• Impact on user experience: Users who access their bank accounts via a TPP (or more specifically an Account Information Service Provider or AISP) might be required to perform SCA for Bank-A but not for Bank-B. As a consequence, the user experience within the AISP’s application will be different for different banks, which might be confusing. This also applies for TPPs who act as Payment Initiation Service Provider (PISP).

WEBCAST

Webinar: PSD2 Strong Customer Authentication Deadline Extension - Clarifications on the EBA’s Opinion

Learn from PSD2 SCA expert Frederik Mennes about the scope & timelines of the SCA extension and which authentication solutions comply.

Watch now

 Compliance of Authentication Elements

The Regulatory Technical Standards (RTS) on Strong Customer Authentication and Common and Secure Communication of PSD2 define SCA as an “authentication based on the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent […]”. The Opinion contains clarifications about which authentication elements can be considered as strong and in which category they fall (i.e., knowledge, possession, or inherence).

Below are a number of noteworthy clarifications from the Opinion:

• SMS as possession element: The Opinion clarifies that SMS can be considered to be a valid possession element. More specifically, the SIM-card in the mobile device that receives the SMS is a valid possession element. This implies that one-time passwords (OTPs) delivered via SMS can be used to construct a strong authentication mechanism when combined with a second factor (e.g. a password or PIN). However, the Opinion does not clarify whether SMS can be used for dynamic linking. Indeed, the dynamic linking requirement in Article 5 of the RTS stipulates that the confidentiality and integrity of payment information (e.g., bank account number or amount of money) needs to be protected during the authentication process. Since the content of an SMS is typically not protected, it seems SMS does not meet the dynamic linking requirements. The EBA should provide further clarification about this.

• Mobile apps as possession element: The Opinion reinforces Article 7 of the RTS, which implies that mobile apps are valid possession elements, if they are protected with a device binding mechanism that links the mobile app to the device on which it runs. A mobile app that is not protected with a device binding mechanism cannot be considered a valid possession element.

• OTP lists as possession element: Financial institutions sometimes use printed matrix cards or printed OTP lists (sometimes referred to as “TAN lists”) to authenticate the end-user of an online banking application. The Opinion clarifies that these printed cards or lists do not constitute a valid possession element, because they can easily be copied (e.g., by taking a picture of the card using a mobile device).

There are a number of topics not addressed in the Opinion that would benefit from further clarification. I have submitted questions about these topics via the EBA’s Q&A tool:

• Usage of partial or full IBANs in dynamic linking: The dynamic linking requirement states that the authentication code must be calculated over an identifier of the beneficiary. Suppose an IBAN is used to identify a beneficiary. Is it then required to calculate the authentication code over the full IBAN, or does it suffice to use a portion of it? Similarly, is it sufficient to show only a portion of the IBAN to the payer? In practice banks often only use a portion of the IBAN for multiple reasons, because it is inconvenient to type or show the full IBAN.

• Usage of hash of payment information: Still in the context of dynamic linking, the question is often raised whether it is necessary to calculate the authentication code over the payment information (amount, beneficiary ID) itself, or whether it suffices to calculate the authentication code over a hash of the payment information. If the authentication code is calculated over a hash value and the payer does not see which payment information is used, payers might not understand which transaction they is actually committing to. Social engineering attacks against authentication systems often exploit this.

We hope that the EBA will provide additional clarification about these topics.

More in-depth analysis of the SCA requirements of PSD2 is available on my blog.

This article, originally published on 2 July 2019, first appeared on Frederik Mennes’ personal LinkedIn page and Wordpress blog.