PSD2: EBA defines a clear path to authentic and secure communications

PSD2: EBA defines a clear path

On February 23 the EBA published the final draft of the Regulatory Technical Standards on strong customer authentication and secure communication under PSD2 (the revised Payment Services Directive).

1000
Rali Genova

Assistant Manager, ECB Office

KPMG in Germany

Email
Keys on the door
PSD2 timeline chart

During the consultation period 224 responses to EBA’s questions were submitted by a wide and representative group of stakeholders. Once EBA reviewed the responses, 3 key issue areas were identified:

  1. Scope and technological neutrality of the requirements
  2. Exemptions, including scope, thresholds and the addition of an exemption for low risk transactions based on TRA (transaction risk analysis)
  3. Access to payment accounts by third party providers and requirements concerning the information communicated.

EBA has reviewed all submitted responses and made changes to the original draft version in various articles in the above-mentioned categories. Some of the most notable changes include:

  1. Certain details of the knowledge element of Secure Customer Authentication (SCA) were removed – “… shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters ensuring resistance against the risk of the elements being …”. Similarly, the details of the possession element “algorithm specification, key length and information entropy ensuring resistance against the risk of the elements being (used) …” were removed. These requirements may relate to specific elements (passwords or token generators) and therefore could limit innovative solutions such as image recognition.
  2. References to compliancy with ISO 27001 on processing and routing of personalized security credentials and authentication codes were removed from Article 21 due to concerns that adopting some industry standards against others may disadvantage specific parts of the industry.
  3. Exemption from the principles of SCA for ‘unattended terminals’ (i.e. for transportation or parking fares) was added.
  4. A TRA-based exemption from the principles of SCA was added in Article 16 of the RTS. The exemption applies to specific remote electronic transactions that have been classified as low risk by a transaction monitoring mechanism (TMM) and fulfil the conditions described in paragraph 2 (transaction amount does not exceed a specified reference rate for remote card-based payments and credit transfers; certain conditions are met, as detailed in paragraph 2c; the calculation of the fraud rate and the resulting figures are subject to audit by internal or external independent auditors). Exemption for corporate payments was not granted, however and so they will still need to comply with SCA principles.
  5. The limit for remote payment transactions was increased from EUR10 to EUR30. And an exemption for a series of credit transfers was made more generic by referring to it as a series of payments.
  6. ASPSPs must now offer at least one interface for AISPs and PISPs for access to payment account information and “screen scraping” (or the so-called “direct access”) will no longer be allowed once the transition period has elapsed and the RTS applies (November 2018 the earliest). In addition, ASPSPs should provide the same level of availability and performance for that interface as they do for their own interfaces used by their customers. Same level of contingency measures are expected in case of unplanned unavailability. AISPs can issue automatic information access to a payment account a maximum of four times per day, unless agreed bilaterally between the parties, however active requests (initiated by the payment service user, still remain unlimited.

Implications

Business models and profitability drivers is the number one supervisory priority for the ECB for 2017. Furthermore IT disruptions and non-bank competition have been identified as significant drivers for risk for banks. PSD2 is an opportunity for banks to address those drivers and the risks associated with them by looking at how the new regulation can help them change their business models and new product development and prepare them better for non-bank competition. In the next section we discuss some of the details around what the RTS means for banks.

The Draft RTS received comments from a wide range of stakeholders – future AISPs, PISPs, unregulated service or IT providers, e-money and payment institutions, merchants, acquirers and card schemes. This shows how wide the reach of PSD2 is. So what are the implications of the RTS on SCA and secure communications for those stakeholders?

Characteristics of the three elements of SCA

Various respondents to the draft RTS expressed concern with adding unnecessary layer of complexity to online payments which may lead to more abandoned transactions and decrease in online payments overall. By removing the characteristics of the three elements of SCA, EBA ensures technology and business-model neutrality and allows Payment Services Providers (PSPs) to continuously evolve and adapt to current fraud scenarios. This also allows for flexibility and better user experience in designing online payments without introducing unnecessary complexity and additional steps. However ASPSPs and AISPs are still required to implement SCA and have until (earliest) November 2018 to do so. There are, however, certain transactions which are exempt from SCA under the final RTS: access to balance and recent transactions without disclosure of sensitive payment data; recurring payments to the same payees which have been previously created by the payer through SCA; payments to self from a natural or legal person within accounts in the same PSP. The exemption does not apply the first time an account is accessed or when the payer initiates a series of payment transactions for the first time. Article 10 provides further details on these and other exemptions.

Interface enabling secure communication between ASPSPs and PISPs/AISPs

ASPSPs should provide at least one interface enabling secure communication with AISPs, PISPs and PSPs issuing card-based payment instruments. Those interfaces should be well documented and publicly available and should provide a way for AISPs/PISPs and PSPs to test their technical solutions against them. What this means is banks (ASPSPs) must implement interfaces for account information, payment initiation and balance check (for card issuers) which are publicly accessible (with proper identification), provide communication via secure encryption and secure customer authentication when their customers would like to grant access to their accounts. While these type of public interfaces are widely used in other industries (e.g. your car might already be integrated with Android Auto, Google’s audio entertainment and messaging API), they are still new to the financial sector and banks should not underestimate the time and effort required to put them in place. There are a few possible considerations to be made – should the bank implement their own interface on top of their existing core banking systems, or should they look for a SaaS solution (software as a service)? Or maybe even start a complete digital transformation and replace the existing core banking system with an API-based solution which can easily be connected to the ever-growing ecosystem of third-party service providers?. The timelines and requirements for both considerations differ, so a timely decision is needed. None of those solutions are easy, and all pose their risks and challenges. Regardless of the route banks choose to take, authentication measures used for SCA should be usable through these public interfaces as well as through existing customer interaction channels. Performance should be on par to receive a potentially high number of requests and last but not least, the interfaces should be designed, selected and built in the light of the banks’ strategic ambitions.

Background

PSD2 entered into force on January 12 2016 and will apply from 13 January 2018. The regulation includes 11 mandates for EBA, three of which relate to the development of RTS and guidelines on security for electronic payments. The three RTS, similar to the one published now in its final draft, have different application dates. For more information on the final RTS on SCA and secure communication, please refer to EBA’s website.

Connect with us

Stay up to date with what matters to you

Gain access to personalized content based on your interests by signing up today