The overall idea behind PSD2 open banking is not new, Yodlee and others have for a while aggregate accounts, and they have done this through a process known as screen scraping. Now though the world is changing and radically.
The first and most important point to make is what has been published by the EU is Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA) and Common Secure Communications, and although not technical per se they are mandated. Thus this is not like PSD2, a directive where some countries may delay implementation according to a white paper from Konsentus:
The timings for PSD2 open banking are mandated across the whole of the EU.
In August 2016 the EBA published a consultation on the RTS, subsequently there have been several iterations and on March 14, 2018, the European Parliament and European Council approved the final version (Commission Delegated Regulation (EU) 2018/389). So what are the key dates, in reality there are two:
- March 14, 2019 All financial institutions (FI) offering a transactional account must have APIs available for approved Third Party Providers (TPPs) to start testing.
- September 14, 2019 Systems must be available for TPPs to go live.
The Detail of the Mechanism
The RTS comes into force on September 14, 2019 and during the time prior to this all financial institutions that offer transactional accounts must develop and implement technical solutions required to deliver PSD2 open banking. FIs will generally look to deliver the PSD2 open baning access via an API, although they can continue to allow in effect TPPs to access Payment Service User data via the online banking interface (a contingency mechanism often referred to screen scraping). However, they must comply with PSD2 in that they will need to put in place measures so the FI knows who is accessing the data i.e. which TPP; and also still obtain the Payment Service Users explicit consent.
The RTS states (Article 33.6) that for a financial institution to be exempted from having to provide a contingency mechanism (such as allowing the web-based online interface for screen scraping), the dedicated interface (API) must be available for testing by TPPs (AISPs, PISPs and PIISPs) no later than six months before the RTS live date of September 14, 2019. Thus March 14, 2019 is the date when financial institutions (FIs) must bd ready for TPPs to start testing with them.
Many FIs consider screen scraping to pose a significant security risk as their Payment Service Users’ security credentials need to be shared with potentially unapproved third parties. These third parties could be breached and thus Payment Service User secure data accessed.
What is a Transactional Account
PSD2 uses the term ‘Transactional Account’. For the UK the FCA defines a transactional account in the FCA handbook as a ‘Payment Account’; and a Payment account” is defined in the FCA regulation 2 as: “an account held in the name of one or more payment service users which is used for the execution of payment transactions”.
So in simple terms pretty much any account that can be used for payments whether called a FI, Credit Institution or regulated as an EMI or PI falls into the regulation as long as it can be accessed online i.e. through the web or a mobile app. This means that accounts such as prepaid cards right through to ‘traditional’ current accounts are covered.
Who are Third Party Providers (TPPs)
- AISPs: Account Information Services provide an overview of available accounts and balances to their Payment Service Users; and
- PISPs: Payment Initiation Services can initiate payments on behalf of Payment Service Users, using the FI’s own infrastructure to effect the payment.
- PIISPs: Payment Issuer Instrument Service Providers check the availability of a given payment amount by the Payment Service User’s account.
The RTS and Security Credentials and Open Standards of Communication
Security Credentials: The RTS clearly outlines the standards required to protect financial institutions Payment Service Users’ security credentials. It covers how credentials are created, stored, deactivated, revoked and shared with the Payment Service User.
Common and Secure Open Standards of Communication: The final section of the RTS defines the communication interface i.e. the API to be used by the FIs. Key is that the interface must be open to any approved TPP to access. The API must though have:
- A robustness equal to the FI’s own web-based Filing interface
- Be secure
Getting consent right for everyone
Article 94 of PSD2 allows FIs and TPPs to process personal data necessary for the provision of their respective payment services only with the “explicit consent” of the Payment Service User.
Under Article 6 of the EU General Data Protection Regulation which comes into force in May 2018, “consent” is one of the lawful bases for processing personal data. “Explicit consent” has a very different meaning under GDPR though.
Under GDPR an explicit consent statement needs to specifically refer to the element of the processing that requires explicit consent. The UK Information Commissioner’s Office (ICO) states, “the statement should specify the nature of data that’s being collected, the details of the automated decision and its effects, or the details of the data to be transferred and the risks of the transfer”.
Other than that, the requirements for explicit consent are the same as the GDPR’s definition of consent, which is:
“any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.”
For the UK, the FCA’s guidance on the implementation of PSD2 clarifies that the interpretation of “explicit consent” under GDPR, should not be read across into Article 94 of PSD2, and that a FI cannot use the requirement to obtain “explicit consent” under Article 94 as a means to avoid its obligation to disclose payment account data to a TPP. So it is clear, whilst “explicit consent” must be obtained it cannot be used as an obstruction to sharing data.
The FI though needs to remember that it also remains the controller of its Payment Service User’s account data under GDPR. This means that it will be responsible for protecting their Payment Service User’s data from unauthorised access or loss and thus needs to ensure at all times that it only shares data with approved TPPs. GDPR guidance on data portability, for instance, explains that controllers will be expected to implement safeguards to ensure that third parties from whom they receive data porting requests are genuinely acting on the data subject’s behalf.
Are you ready for PSD2 open banking
FIs need to understand if they will be ready for PSD2 open banking by March 14 2019. Not being ready could lead them to being open to regulatory fines. Some of the key questions around Payment Service Users and their consent are:
- How will you handle Strong Customer Authenticationand what model will be used e.g. re-direct, decoupled or embedded?
- How are we protecting our Payment Service Users’ security credentials?
- How will you check all Third Party Providers are approved?
- How will we communicate to Payment Service Users’ and manage Payment Service User revocations?
- How will you ensure a 99.99% up time to TPPs ensuring access to data at anytime if they need to be checked each time they access the API?
Liability PSD2 open banking
There is still some uncertainty over who foots the bill when things go wrong. It has long been the case that the FIs have to refund Payment Service Users in the event of unauthorised and incorrectly executed transactions. But what happens if Payment Service Users push funds to the wrong account?
The FCA comments in its Approach Document that in relation to payments initiated via a TPP, the burden of proof lies with the TPP to demonstrate it was not responsible for the error.
The TPP will be required to prove, amongst other things, that the payment order was received by the Payment Service User’s FI and that while within the TPP’s “sphere of influence” it was authenticated and dealt with correctly. The FCA clarifies that it will consider any part of a transaction over which the “TPP has control” to be within the TPP’s sphere of influence. Clear? A key part of this process for the FI will be to have an irrefutable tracking system in place so they can prove what data was sent to whom, when and based on what checking of the TPP.
The European Payments Council commented that under PSD2, the risk and the burden of financial recovery appeared to lie with the FI, and cautioned against the FIs being made liable for TPP’s mistakes or other risks (such as cyber-vulnerabilities) arising from the TPP’s activities. It clearly stated that this would only be acceptable where an agreement between the TPP and the FI was in place. It argued that such an agreement should relate to the terms of the payment initiations and account information services offered by the TPP in question.
The government has yet to introduce a mechanism for resolving stakeholder concerns around liability. It noted the FI’s unease in relation to the practical difficulties of obtaining compensation from a TPP, but says the FIs should rely on their traditional rights of action against a TPP who breaches its regulatory obligation to refund them for an unauthorised transaction, this could lead to many messy court cases.
The CMA’s Open Banking proposed a method of resolving disputes between the FIs and TPPs in January 2018 in that it designed a Dispute Management System for the FIs and TPPs in the case of managing complaints, disputes or enquiries. Under the scheme, participants sign-up to a Code which sets out common best practice standards and principles for the FI and TPPs. This includes best practice for where a complaint, dispute or enquiry is taken to mediation, adjudication or arbitration. Could this be the future, however as it is only a voluntary code for which not all TPPs may participate, how will it work in practice?
——————————————————————————————————————————————
Author: Brendan Jones
CCO / Co-Founder of Konsentus Ltd. Konsentus provides a SaaS based consent and preference management solution for EU FIs enabling them to deliver PSD2 open banking. He has over 30 years’ experience in the UK & international payments industry, having held executive positions in banking, payment & technology companies including Giesecke & Devrient, Bank of America MBNA & the Datacard Corporation.
The post PSD2 open banking: The ticking timebomb for financial institutions appeared first on Payments Cards & Mobile.
