Out-Law / Your Daily Need-To-Know

Out-Law Analysis 5 min. read

Expectations on PSD2 interactions between banks and fintechs clarified by UK Treasury


ANALYSIS: How long financial technology (fintech) companies have been operating in the UK's payment services market will determine whether they have a choice over whether to temporarily opt out of new regulations that will apply from early next year, according to new plans published by the Treasury.

The plans concern the implementation of the EU's revised Payment Services Directive (PSD2) in the UK, through new Payment Services Regulations which have been laid before parliament.

The policy announcement, which follows an earlier consultation exercise, offers a degree of flexibility to some existing fintechs operating in the payment services market and clarifies what is expected of banks and other payment service providers (PSPs) in terms of enabling those fintechs to access customers' payment accounts or data.

The multi-faceted approach outlined by the Treasury reflects the fact that regulatory standards vital to governing third party rights of access to payment accounts and data under PSD2 have not yet been finalised, as well as the fact that there will be a transitional period of 18 months before the finalised standards actually apply.

Third party access rights and PSD2

Recent years have seen the emergence of innovative, new payment services onto the market in the EU to compete with more traditional payment services offered by banks. Now, customers can, for example, initiate payments from accounts held by their banks through a third party fintech company (payment initiation service providers or PISPS), or use services provided by fintechs to aggregate all their data from multiple payment accounts in one place (account information service providers or AISPs).

In a bid to support the competition and innovation offered by the fintechs and provide a framework for better consumer protection and security, EU law makers updated existing payment services laws with PSD2. For PISPs and AISPs, obtaining new rights to access payment accounts and data means that they will be subject to regulation for the first time.

The revised Directive must be implemented in national laws across the trading bloc by 13 January 2018. However, much of the detail on how banks and other 'account servicing payment service providers' (ASPSPs) must interact with PISPs and AISPs, and on fintechs' obligations when doing so, will be set out in regulatory technical standards (RTS). The final RTS will set out rules on when 'strong customer' authentication applies, when it does not, details around the confidentiality and integrity of personalised security credentials and the means by which communications between the parties involved can be secured.    

Those standards will not apply from the date the new PSD2 rules take effect. Instead, an 18 month transitional period will take place before the RTS must be adhered to. The transitional period will begin from the date the RTS are published in the Official Journal of the EU (OJEU).

The RTS has proven controversial. The European Banking Authority (EBA), tasked with developing the standards, saw its proposals rejected by the European Commission, which has the final say over their implementation. The EBA has subsequently urged the Commission to rethink counter proposals it had tabled. Much of the disagreement has related to the functionality of new 'interfaces' (generally, in the form of dedicated API access) that ASPSPs will be required to develop to support communications with PISPs and AISPs, as well as fall-back options for when those interfaces fail or underperform.

The debate over facilitating third party access rights under PSD2, in the UK at least, is being influenced by ongoing industry work on the development of new open banking standards, which have been mandated by the Competition and Markets Authority (CMA).

Though there are differences in scope between the two regimes, consideration is being given to how open application program interfaces (APIs) being developed under the open banking initiative could be used to support access to payment accounts and data by PISPs and AISPs under PSD2.

The overall picture is therefore a complicated one and it is in this context that the Treasury's new plans have been published.

The Treasury's plans on third party access during the transitional period

In its new paper, the Treasury differentiated between its expectations on third party access once the PSD2 rules take effect in the UK but before the RTS on strong customer authentication and common and secure communication apply, and after the RTS apply.

The obligations, or choices, available to PISPs and AISPs during the transitional period depend on how long those businesses have been operating in the UK.

PISPs and AISPs operational on or after 12 January 2016

For PISPs or AISPs that started to operate on or after 12 January 2016, the date set out in PSD2 itself, the situation is straightforward – UK PISPs will need to be authorised, and UK AISPs registered, with the Financial Conduct Authority (FCA) before PSD2 takes effect in the UK on 13 January 2018 in order to continue operating. The Treasury said applications for authorisation or registration will be able to be submitted to the FCA from 13 October 2017.

Authorisation or registration means becoming subject to PSD2 regulation. These PISPs and AISPs will therefore face a number of new obligations, including on data security and on obtaining professional indemnity insurance or putting in place a comparable guarantee to underwrite their liabilities under the new regime.

During the transitional period, these businesses will be able to continue screen scraping the data they need to provide their services if ASPSPs fail to provide "another access route" for them to use that in the words of Treasury fintechs can use "without having to comply with requirements" on security and authentication under PSD2 that "are yet to come in force" and will be set out in the RTS.

ASPSPs will only be able to stop the firms screen scraping during this period if there are "reasonably justified and duly evidenced reasons related to unauthorised or fraudulent access or payments".

PISPs and AISPs operational before 12 January 2016

The situation is more flexible for PISPs or AISPs that have been operating in the UK prior to 12 January 2016.

Under the Treasury's plans, they can continue to operate on a non-regulated basis – i.e continue screen scraping – until the new RTS take effect. However, PISPs or AISPs that choose that option "will not benefit from the right of access provided for in PSD2", the Treasury said.

The Treasury strongly encouraged PISPs and AISPs which have been operating prior to 12 January 2016 "to apply to be registered or authorised as soon as possible".

While the Treasury is not explicit about what measures ASPSPs will be able to legitimately take to prevent screen scraping by unregulated PISPs and AISPs during the transitional period, it did state that it expects "a degree of cooperation between firms" and that it "would discourage ASPSPs from adopting a blanket policy of blocking these firms".

Once the RTS take effect, unregulated PISPs and AISPs will have to become authorised or registered to continue operating.

Synergies between PSD2 and open banking

In its paper, the Treasury advocated the use of open and secure APIs in facilitating third party access under PSD2. It said the standards being developed under the open banking initiative can support such access under the PSD2 regime.

It said it encourages ASPSPs, AISPs and PISPs to "work towards using the open banking API standards as the basis on which secure API access to other payment accounts is provided in future". AISPs and PISPs should look to "work with ASPSPs to transition to the use of secure APIs as soon as possible during 2018", it said.

It is clear, then, that the government expects banks and fintechs to work together to enable transparent PSD2 services.

We are processing your request. \n Thank you for your patience. An error occurred. This could be due to inactivity on the page - please try again.