PSD2 and third party providers: Where next for account information and payment initiation services?
Published on 4th Feb 2015
Trilogue negotiations are beginning after a compromise text for the revised Payment Services Directive (“PSD2”) was agreed in December 2014. We examine one of the fundamental changes: the extension to third party providers of account information and payment initiation services.
Innovative solutions have been emerging in the evolving payments market which enable merchants to receive payments direct from their customers’ bank accounts, not through any card scheme. Often cited examples include iDEAL, Sofort and Trustly. Alongside these new offerings, technology solutions which enable an ‘availability of funds’ check on the payer’s account have also appeared.
Similarly, there has been a growth of technology-focused companies offering customers (mostly SMEs) consolidated account information from across a number of accounts held with different providers – or simply the electronic extraction of information to help produce management accounts and the like. Examples in the UK include Bankstream and MoneyDashboard, the Edinburgh-based service provider which recently raised a further £2.5 million.
Support from Europe for these developments
The European Commission has seen these developments and is determined to support them, both to support the European digital and electronic payments agendas and, more importantly, to encourage competition. It regards banks as ‘gatekeepers’ to accounts held with them and the information in those accounts and believes that this role gives them a de facto monopoly.
Accordingly, the European Commission has determined to bring third party providers of account information and payment initiation services (“TPPs”, “AIS” and “PIS”, respectively), into the scope of PSD2. Its rationale is that by doing so, it will give these TPPs rights to access the relevant accounts on the basis of an agreed framework (including as to liability) and customers of TPPs protection through regulation and the application of security standards.
The framework would effectively regulate the interaction between, and the rights and liabilities of, the three parties involved – the payment service user (“PSU”), the account servicing payment service provider (“AS PSP”) and the TPP. This would both create a harmonised approach across Europe (currently, there is inconsistency in how TPPs are regarded) and also avoid the need for TPPs to seek individual bilateral agreements with each AS PSP, so facilitating the growth of these new offerings.
Fascinating, complex and emotive
These developments are fascinating, complex and emotive. Fascinating, because this is a new field of regulation worldwide (Europe is once again leading), which encourages competition by breaking down the payment chain. Complex, because of the tripartite arrangements involved. And emotive, because of the risks involved for, and changes to systems, processes and documentation required by, AS PSPs in a change that perceived to be of limited benefit to them. Like when the PSD was introduced (with the battle over execution times, eventually settled in favour of D+1), the banking industry has come in for severe criticism for its relentless opposition to the TPP provisions, stiffening the European Commission’s resolve to legislate.
Key issues
So, as trilogue commences, what are the key issues which will need to be determined? It is clear that PSD2 will provide for TPPs to be authorised; recognise that AIS are different from PIS; require AS PSPs to allow their PSUs to use TPPs and to not discriminate (for example, TPP initiated payments as compared with PSU initiated payments); and for the PSU to seek recourse for unauthorised transactions first from the AS PSP and, where the TPP is at fault, for the AS PSP in turn to have a right of recourse to the TPP.
The key issues as we see them include:
- Scope: The compromise text limits the right to make use of a TPP to where the relevant payment account is “accessible online“, an undefined term which could exclude mobile. There seems to be no restriction upon the use of TPPs from a different Member State, so allowing cross-border access.
- Access rights: The AS PSP is permitted to refuse a request for access where duly motivated. This both lacks clarity and seems to apply on a one-off basis, i.e. to the initial set-up, not on an on-going basis. Similarly, it does not deal with individual access requests, nor whether access can be differentiated between AIS and PIS TPPs (account information service provider access being regarded as involving less risk). One concern raised is that of high frequency requests, promoted by TPPs as delivering a ‘real-time’ service.
- Use of the PSU’s personalised security credentials: There seems to be a degree of consensus that the PSU should not share his credentials to allow a TPP to access his account. However, as PSD2 is advocating “strong customer authentication“, the position is not yet settled. If it is allowed, how can or should the AS PSP be able to distinguish between the PSU and the TPP using the PSU’s credentials?
- PSU’s consent: Clearly a PSU should consent to TPP access. However, should this just be on a one-off, upfront basis and, if so, for how long would this consent last, or on each access request?
- Authentication and security: PSD2 is advocating “strong customer authentication” to include “elements dynamically linking the transaction to a specific amount and a specific payee” for all electronic remote payment transactions. Will this also apply to all TPPs, including AIS TPPs?
- Communication standards: PSD2 contemplates common and secure requirements for communication between the three parties – PSU, AS PSP and TPP. Shouldn’t the development of these be in an open and co-operative manner, involving a multi-stakeholder body with appropriate representation?
This non-exhaustive list of issues to be resolved demonstrates the complexity of the payments industry and the need for a legislative solution which is agnostic as to technical solutions, future-proofed and, above all, pragmatic. Otherwise it will stifle, not encourage, these developments, to the detriment of all stakeholders.