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:
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:
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?
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.
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.
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.
Examining the ECB’s expectations around data, technology, and cyber security.