A brave new world for third party providers is advancing in the payment services sector, while UK and EU regulatory initiatives strive to stay abreast and facilitate ongoing innovation. Brett Carr examines HM Treasury’s February consultation paper on the implementation of PSD2, along with Europe and the UK’s Open Banking initiatives.

Taking a step back: what is PSD2?

The original payment services directive (PSD) was adopted in 2007 and was hailed as the key to a single market for payments in Europe. Since then, new types of payment service have grown in use and popularity and with that comes the requirement for new regulation, greater transparency and updated security standards. On top of this, EU member states are accused of having implemented PSD in different ways, leading to regulatory arbitrage and legal uncertainty, particularly in the use of the directive's exemptions. PSD2 will incorporate and repeal PSD. PSD2 seeks to update the current framework on payment services and aims to level the playing field by, among other things, updating definitions to provide certainty, widen the scope of the original directive (to regulate the new payment services we discuss below), address security concerns and improve consumer protection.

What is Open Banking?

To most 'Open Banking' is the term used to describe the tag-team combination of:

  1. The Competition and Market Authority's (CMA) 'Open Banking Remedy' which resulted from the CMA's conclusion from its retail banking market investigation, that older and larger banks do not have to compete hard enough for customers’ business.
  2. The second Directive on payment services in the internal market ((EU) 2015/2366) (PSD2), which together, according to the Financial Conduct Authority (FCA), will "enable new and innovative ways of using the information available in customers’ accounts and making payments from these accounts."[1]

Our obsession with mobile devices and FinTech has seen a rise in popularity for the offerings of third party payment service providers (TPPs) (these relate to payment services from providers that do not manage the account of the payment service user). These TPPs most commonly come in the form of apps which can aggregate our scattered financial data in one place providing us with insightful analysis, and allow us to initiate payments and transfers from apps not run by our banks.

Innovators consider that a combination of artificial intelligence and Open Banking will revolutionise the market for financial services, leading to many of us adopting a personal financial assistant in our pockets who (among a number of other functions) will be able to monitor markets and let us know when we should move our money to a higher paying savings account with another provider and then, with a tap of our phones, initiate the transfer for us. But, these apps are only as good as the access they have to our financial data and to-date there has been no requirement to provide such free flowing access in the way that is proposed with Open Banking.

The UK's vision for greater innovation and competition is closely aligned with that of Europe and the CMA is demanding that banks act to accelerate technological change in the UK retail banking sector. Their view is that Open Banking will enable personal customers and small businesses to share their data securely with other banks and with third parties, enabling them to manage their accounts with multiple providers through a single digital app, to take more control of their funds (for example to avoid overdraft charges and manage cashflow) and to compare products on the basis of their own requirements.

To do this, the CMA requires nine banks[2] across Great Britain and Northern Ireland to deliver an Open Banking Application Programming Interface (API) Standard, which will have to be PSD2 compliant and delivered by January 2018 when PSD2 must be transposed into national law. This API Standard is expected to provide the framework for how TPP software authenticates, accesses data, and initiates payments with an account servicing payment service provider (typically a bank) (the ASPSP). For those of us who do not operate in the tech world on a daily basis, APIs are tried and trusted technology that is used by many well-known online brands, for example it's how Uber overlaps with Google Maps to provide information about the location of a taxi.

To date TPP services have not been regulated payment services in most EU member states. To formalise a regulatory approach to TPPs, PSD2 introduces two new payment services that will be regulated:

  1. Payment initiation services (PIS), provided by Payment Initiation Service Providers (PISP).
  2. Account information services (AIS), provided by, you guessed it, Account Information Service Providers (AISPs).

A payment initiation service is defined in PSD2 as a "service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider."

An account information service is defined in PSD2 as an "online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider."

We will refer to PISPs and AISPs interchangeably with TPPs.

As an overview, PSD2 requires the following in relation to TPPs:

  • Professional indemnity insurance (PII): As part of their authorisation requirements under the directive, providers of PIS and AIS will be required to hold PII or a comparable guarantee against liability, covering the territories in which they offer services
  • Consent: article 64 provides that a transaction is considered authorised if a payer has given consent to the transaction in the form agreed with the payment service provider, which may be via either the payee or the PISP
  • Access to payment accounts: As drafted at articles 66 and 67, PSD2 requires that banks and other ASPSPs must cooperate with TPPs and provide the TPP access to payment accounts when the payer gives their explicit consent
  • Limits of access to payment accounts: article 68 stipulates that ASPSPs may deny AISP or PISP access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account or initiation of a payment transaction. ASPSPs are required to inform the payer of the reasons for the denial of access and immediately report the action to the competent authority
  • Unauthorised/incorrect transactions: articles 71 states that where a PISP is involved in an unauthorised or incorrect transaction, the payment service user shall obtain rectification from the ASPSP
  • Liabilities of providers and users: article 73 states that where an unauthorised transaction is initiated through a PISP, the ASPSP shall still be responsible for refunding the payer. Where the PISP is liable for the unauthorised payment transaction, it will immediately compensate the ASPSP, with article 72 setting out that the burden of proof falls on the PISP to prove that it was not at fault
  • Article 98 of PSD2 requires that the European Banking Authority (EBA) develops regulatory technical standards (EBA RTS) for, amongst other things, the requirements for common and secure open standards of communication between ASPSPs, PISPs, AISPs, payers, payees and other payment service providers.

Detail of HM Treasury's consultation (HMT Consultation) in relation to TPPs

The HMT Consultation reiterates that PSD2 recognises that TPPs are not currently regulated and as such there is a limited amount of consumer protection in place. PSD2 requires that firms offering TPP services be registered or authorised, depending on the service being offered, and therefore meet certain security, risk management, transparency and other standards.

Moreover, the requirement that banks and other ASPSPs who provide and maintain payment accounts for a payment user must provide access to online payment accounts to TPPs, will strengthen innovation and competition in the payments and account information market.

Competent authority

In line with current authorisation arrangement for payment institutions, the government believes that the FCA should undertake the role of registering and authorising AISPs and PISPs, and ensuring that ASPSPs, AISPs and PISPs are meeting their obligations under the legislation. As part of this, ASPSPs must notify the FCA where access is denied to AISPs or PISPs.

HMT considers that PSD2, and the proposed draft implementing regulations, are clear that where a payer is using an AIS or PIS, explicit consent must be obtained by the AISP or PISP for the service or payment transaction in question. The authorisation of a payment transaction does not have to be given by the user directly to the ASPSP but can be given only to the PISP.

Authentication 

Authentication shall be conducted in line with the implementing regulations and with the EBA RTS and HMT believe that best practice is expected to involve customers authenticating themselves directly with their ASPSP, i.e. providing their payment account login details only to their ASPSP, rather than to the AISP or PISP, with confirmation of access then provided by the ASPSP back to the AISP or PISP.

HMT expects that AISPs will be able to access account information held by ASPSPs on both a one-off and ongoing basis. Ongoing basis means that users will be required to authenticate their identity once and then, with appropriate consent, the AISP will continue to be able to access their information even after the user’s immediate session has ceased. ASPSPs are expected to allow for regular communication sessions with the AISP, but not necessarily to provide an uninterrupted data stream. This has become a contentious area that'll we'll revisit a little later.

Communication 

HMT will leave the matter of secure communication to the EBA RTS.

HMT envisages that users will have the right to use AISPs and PISPs in relation to all online payment accounts. Online is taken to mean any account which is accessible by the user on the internet through any device, including a computer, a mobile phone, or an application on a mobile phone. HMT considers that online payment accounts are likely to be:

  • Personal current accounts
  • Business current accounts
  • Credit card accounts
  • Flexible savings accounts
  • E-money accounts

This definition goes broader than the CMA remedy, which applies only to personal and business current accounts. However, as the CMA note, there is likely to be value in including all payment accounts within the development of the Open Banking API Standard.

Account information service access

ASPSPs are expected to provide to an AISP access to the same information regarding a payment account as is available to the user when accessing their account online directly with the ASPSP.

It seems the EBA in its draft RTS has deliberately avoided listing what needs to be available, rather requiring ASPSPs to provide the same information as is available to users on an online banking platform, in an attempt to address concerns TPPs have raised in relation to the potential lack of availability or lack of resources invested by ASPSPs to maintain and/or provide technical support for accessing the dedicated interface.

Payment initiation service access

ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP.

AIS and PIS business models in scope 

HMT says that the government reads the definition of PIS and AIS in the directive (article 4(15) and 4(16)) broadly. The government interprets the definition of AIS as meaning that an AISP uses some or all of the information from one or more payment accounts held by the user with one or more ASPSPs, to provide an information service. The government expects these services to include, though not be limited to:

  • Dashboard services that show aggregated information across a number of payment accounts
  • Price comparison and product identification services
  • Income and expenditure analysis, including affordability and credit rating or credit worthiness assessments, and
  • Expenditure analysis that alerts users to consequences of particular actions, such as breaching their overdraft limit

Rights and obligations

As we've considered above, ASPSPs are expected to provide unhindered access to AISPs and PISPs providing a service to a user with a payment account held with the ASPSP, subject to the implementing regulations and EBA RTS on authentication and communication.

HMT further considers that AIS and PIS access should be available to a user whenever they can access their payment account online directly with the ASPSP. As such, HMT highlights that if the user can access their payment account online 24 hours a day, 7 days a week (excluding scheduled maintenance or system failures) then the ASPSP should be providing access to AISPs and PISPs on the same terms.

HMT does however consider that it is necessary to balance the rights for users to use AIS and PIS (and therefore those providers to have access to users’ accounts) with the cost to ASPSPs of providing secure access. ASPSPs only have to provide one mechanism for access, as such, the government believes that the best way of achieving this is through the Open Banking API Standard, provided it meets the requirements of the implementing regulations and EBA RTS.

Liability 

HMT states that where an unauthorised transaction occurs, including when it has been initiated through a PIS, ASPSPs will be responsible for refunding a user immediately. The exception is where there are reasonable grounds for suspecting fraud which the ASPSP believes needs further investigation. As under the PSD, PSPs will be expected to quickly resolve any investigation so that payers that have not engaged in any fraudulent activity can be refunded immediately.

Where the PISP is liable for the unauthorised payment transaction, it will immediately compensate the ASPSP. The refund for the payer will be unaffected and the burden of proof falls on the PISP to prove that it was not at fault. It is up to industry to develop appropriate mechanisms so that ASPSPs can work effectively with PISPs, including on mechanisms for resolving any disputes. Industry may find it helpful to include the development of such mechanisms alongside the work on the Open Banking API Standard.

What might this mean for innovation in finance?

As the old adage goes, 'knowledge is power' and the secure access to a wealth of personal financial data, as promised by Open Banking, is already resulting in an explosion of innovation which should dramatically improve the ability for people to source better deals, to save money, to make money, or streamline processes to save time. Among others, key focuses of innovators are on data aggregation and analysis, account monitoring, making product or service recommendations, automation and payment requests. Innovators are looking at providing consumers and SME’s with smarter and more intuitive interfaces to understand their 'big-picture' financial situation by bringing together our financial data from multiple banks and ASPSPs. Open Banking could give ‘robo-advice’ the platform it needs to take-off, or other automated data-lead advice services. The world of 'big-data' means that algorithms could be developed to recognise patterns and suggest ways for users to avoid adverse financial situations or introduce the most relevant products to a user when they actually need them.

However, article 98 of PSD2, means that it is up to the EBA to decide in its RTS the exact when and how that governs TPPs access to a user's account information and the devil is clearly going to be in the detail. Authentication and access has become a contentious area, in particular the frequency with which AISPs will be able to access the users account information held by the ASPSP.

As currently drafted the EBA RTS proposes to limit access in the following way:

"AIS providers shall request information from designated payment accounts and associated payment transactions each time the payment service user is requesting such information or, where the payment service user is not actively requesting such information by connecting to the AIS, no more than two times a day [emphasis added]. The EBA is proposing this requirement to address the concern raised by some ASPSPs that AIS providers may make continuous and possibly automated account information requests, which could impact negatively the availability of the ASPSP’s online platform."

The twice-daily limit has come-in for strong industry criticism. A number have referred to it as an 'artificial limit' that is neither 'warranted nor beneficial'. It is considered by critics that such a limit would 'stifle innovation' and negate the value of a provider's solution with another suggesting that 'prescriptive limits become outdated as technology evolves, while principles are updated over time and foster innovation and competition in the market'.[3] Respondents to the RTS consider that 'timely and up-to-date data is required to allow users to make good financial decisions, for underwriters to make appropriate lending decisions and for advisors to provide advice in compliance with regulations'[4]. PayPal has suggested that "the frequency with which AIS providers can request information should match the frequency with which the Payment Service Provider updates the account information - in practice this can happen anytime from once a day to every few minutes."[5]

So it remains to be seen how 'open' the banks and other ASPSPs will really have to be.

Where are we with implementation?

The government aims to finalise and lay the final implementing legislation in Parliament in early 2017 to provide industry with as much time as possible to adjust to any changes required. The government’s implementing legislation will come into force on 13 January 2018, including the requirements around access set out in article 66 and 67. The EBA is expected to publish the final draft RTS within 12 months of entry into force of the Directive, i.e. any day now[6].

However, in an introductory statement[7] by Andrea Enria (Chairperson of the EBA) to the Committee on Economic and Monetary Affairs (ECON), Enria said that the EBA expects to submit the final RTS "a month or so later than the 13 January 2017 deadline".

Enria highlighted the 'considerable uncertainty' in maintaining the EBA's momentum towards implementation, as the EBA have so far identified approximately 260 distinct concerns and/or requests for clarifications. And they intend to "assess the strength of the argument of every single one of these concerns, with a view to decide whether or not [they] made the right trade-offs in the [consultation paper]."

The EBA intend to then publish what will be a very extensive ‘feedback table’, in which they will provide feedback to the responses they have received. In that table, they will be summarising each of the 260 concerns and requests raised, and make transparent their assessment of whether or not the comments have led them to amend the RTS.

Enria extracted 3 main concerns from the 260:

  1. Monetary Thresholds: relating to the maximum amount of €10 for remote payments.
  2. The Interface and so-called "direct access": whether TPPs will be able to access payment accounts via the customer-facing interface (ie by 'screen-scraping') or whether access should be by a dedicated interface. Enria said they would be seeking input from the European Parliament on this point.
  3. Exemptions to Strong Customer Authentication.

Provisions related to security in articles 65, 66, 67 and 97 will not come into force until 18 months after the EBA RTS are in force. As such, these provisions are not expected to be in force before (at least) autumn 2018.

During this initial period HMT says that ASPSPs will be expected to provide access to AISPs and PISPs from January 2018 and, as industry will have had sight of the draft RTS, the government would expect this to be done in line with the draft RTS wherever possible.

HMT consider that during this period both ASPSPs and AISPs/PISPs will be undergoing a learning process and will be expected to work closely across industry, and where appropriate with the FCA, to overcome challenges that emerge and ensure that users have the ability to use AIS or PIS.