With less than 6 months to go until PSD2 comes into force, banks are still grappling with the significant technical challenges of safely providing access to customer payment data and accounts. Technical standards are a hotly debated topic, and the term “screen scraping” is finding its way onto risk committees and change boards across the financial services industry. So what is it? Why does it matter? and why is it important to act now?

What do we mean by the ‘screen scraping’ issue?

Under PSD2, from 13 January 2018 Account Servicing Payment Service Providers (ASPSPs), whether banks or other payment services providers, must allow PISPs and AISPs (together TPPs) to respectively initiate payments from and allow access to data in online client accounts (Regs 69 & 70 PSRs 2017).

However, the Regulatory Technical Standards that the EBA is to establish on the interface to be used (SCA-RTS) will not be adopted until 18 months after PSD2 comes into force1.

The question is whether in the interim TPPs should be able to access a client account by impersonating the client through the normal client user interface, often called ‘screen scraping’.

An issue with screen scraping is that access is potentially anonymous – without the use of a fit for purpose API, the ASPSP may not be able to distinguish a TPP and accordingly will afford them the same account access and functionality as a client. In contrast a fit for purpose API is a dedicated interface that can store and apply permissions/restrictions and control communication with the ASPSP’s system in a more dynamic way.

What is the status quo at European level?

The EC and the EBA have (seemingly strongly) opposing positions on whether screen scraping of data/transactions should be allowed under PSD2.

The EC’s latest revision of the RTS stipulates that an ASPSP must offer either a dedicated interface for TPPs, or allow them to make use of the normal client interface. With dedicated APIs as yet underdeveloped and none sanctioned by the SCA-RTS for a further 18 months, from 13 January 2018 most ASPSPs will therefore have to let TTPs use normal client access channels. While the EC proposal is that TPPs are required to identify themselves to the ASPSP (and ASPSPs must develop a method to enable this), their access will be without the controls that a dedicated API could provide.

Whilst the EBA has published an Opinion disagreeing with most of the EC’s amendments to its draft RTS, particularly in relation to screen scraping being permitted, the EC will have the final say on this and will probably hold their position.

What is the FCA/Treasury position?

The FCA follow on from the EC’s approach and stipulate that unless an ASPSP provides a dedicated interface, they should allow ‘screen-scraping’2.

  • If an ASPSP adopts a dedicated API channel prior to SCA-RTS applying, it need not allow usage of the client channel. However, the dedicated channel must not frustrate access.
  • If an ASPSP does not adopt a dedicated API, it must allow TPPs use of the client channel.
  • Under PSRs 2017 an ASPSP can only deny a TPP access for “reasonably justified and duly evidenced reasons relating to unauthorised or fraudulent access”. FCA consider an ASPSP must have an objective and evidenced led reason; it cannot take a one size fits all approach and must restore access once the issue is resolved.
  • The ASPSP should contact the client before denying the TPP access and if it cannot do so beforehand, must do so immediately afterwards.
  • A denial of access must be reported to the FCA using the new form (SUP 15 Annex 10). A business as usual denial of access that would also be denied to a client need not be notified.
  • ASPSPs should not take active steps to discourage client usage of TPPS.
  • Only TPPs that are registered / authorised by the FCA have a right to access. An ASPSP is not obliged to give access to an intermediary under the FCA’s transitional regime (see new PERG 15.7). The FCA however discourages ASPSPs from adopting a blanket policy to blocking these firms3. Nonetheless access is not obligatory and it seems reasonable that prior to FCA vetting (PI cover, security standards etc.) an ASPSP could require equivalent assurance.
  • The FCA recognises that ensuring good customer outcomes sits alongside enabling innovation and expects cooperation between ASPSPs and TPPs.

As we read it, the FCA guidance suggests that pre applicability of SCA-RTS, a TPP need not identify itself to the ASPSP (para 17.69 of the ‘Our Approach’ document). However the EC’s draft SCA-RTS referred to above does seem to require this (Article 33(3)(a)).

Practical steps?

Enabling TPPs represents a paradigm shift for UK ASPSPs, who need to consider key areas such as client communications, IT security, fraud management and operational risk.

With no allowance for contracts between an ASPSP and a TPP and (it seems) limited allowance for due diligence, banks will need to build new, real time, proactive controls. Crucially they will need to:

  • Consider early adoption of a dedicated TPP API.
  • Build a method for TPPs to identify themselves when accessing a customer’s account.
  • Establish a pre-SCA-RTS policy for dealing with TPPs.
  • Consider carefully its message to and contractual terms with clients.
  • Adapt its fraud and unauthorized transaction monitoring to the new landscape.
  • Have a ‘denial of access’ assessment, notification and client contact procedure in place.
  • The picture is changing rapidly and whilst the outcome will not be known until the RTS are finalised in late November, the latest FCA guidance on screen scraping makes it an increasingly likely that this scenario for banks to deal with. The time for to “wait and see” is over, banks must act now to secure their customer’s payment data and accounts before the 13th January deadline.