figo’s two cents on the Commission’s RTS on communication under PSD2

Go! – Parliament and Council should approve provided RTS

It’s almost done! On Monday this week, the European Commission submitted the Regulatory Technical Standards (RTS) for approval by the European Parliament and Council. figo generally welcomes the latest version with regard to the outcome on XS2A communication under PSD2, even if the devil is in the details once again. Any lingering issues – which we will further outline below – should not become deal breakers and the Parliament and Council should give their approval. We think that these last hurdles can be properly solved by the EBA and national authorities, if they plan their practical involvement wisely now.

From our point of view, the Commission has found an acceptable way to meet the RTS’ higher goals, which figo promoted in our open letter earlier this year.

That is to

  • minimise the climate of distrust between the banking and FinTech industry and enable a joint open banking market,
  • provide clear incentives for banks to build market and user-friendly Open Banking APIs in due course as well as to
  • leave enough room for standardisation and automation of regulatory compliance.

Moreover, the market urgently needs a final RTS version to work with. Especially, as the RTS transition period of 18 months will already be a challenge for the market. In Member States without any final PSD2 transposition law the situation as from January 2018 will be even worse.

No! – There is no such thing as a general “Screen Scraping Ban” 

No general “screen scraping ban” was introduced by the Commission this week. Any generalised statement in that matter failed to mention the according conditions under which a ban is given. For example, a ban on anonymous scraping of online banking front-ends for access to payment accounts (i.e. without authorising as a supervised Third Party Provider towards the bank) was regulated by PSD2 on first level a long time ago. What was actually new and welcomed by banks was the fact that under the new RTS, banks are not required to ongoingly maintain and provide two access routes for Third Party Providers (TPPs).

If banks fulfill a set of specified requirements, they are not obliged to provide TPPs with a direct access gateway (i.e. authorised scraping) in addition to a dedicated API. Banks have to offer API documentation as well as a proper testing facility six months before the application date of the RTS. A forced use of the API – or to be more specific – an exemption for the bank to provide an additional fallback/direct access way for communication is only given after a successful API-compliance check by national authorities. API compliance checks can only be conducted on the basis of an API that “has been widely used for at least three months.” Last but not least, TPPs have to make use of these approved APIs at earliest when the RTS apply (probably about September 2019) or after banks have fulfilled all the outlined requirements at a later stage.

Another important Commission statement in that context is that “The RTS […] not cover the access to accounts other than payment accounts, which falls under the competence of the Member States.” Consequently, Member States could in theory impose bans on screen scraping for any services beyond PSD2, e.g. for which access to brokerage or saving accounts data is needed. But independently from any national legal obstacles for TPPs to obtain this data, banks have the chance to monetise this premium API data towards TPPs. If banks do, we cannot exclude the possibility that they will block TPPs from unauthorised screen scraping of content, which is not covered by PSD2. This would be possible with a lower risk of coming into conflict with competition regulations, as it used to be in the pre-PSD2 times for payment accounts access.

Yes! New RTS content, we like

figo explicitly welcomes the new Art. 32 Nr. 3, as it provides an end to ongoing discussions on potential hurdles for TPPs when using dedicated interfaces. It clearly states a first and non-exclusive set of obstacles for TPPs that banks are not allowed to create under the RTS, such as

  • preventing the use by TPPs of the credentials issued by banks to their customers,
  • imposing redirection to banks’ authentication or other functions,
  • requiring additional authorisations and registrations of the TPPs in addition to those provided for under PSD2, or
  • requiring additional checks of the consent given by payment account holders to TPPs.

The last being extremely important with regard to potential conflicts from a bank’s perspective, when preparing compliance with the General Data Protection Regulation (GDPR).

Let’s do it! How to overcome any last hurdles

Issue #1: Exemption of providing a fallback/direct access (Art. 33 No. 6) and ongoing monitoring of RTS-compliance of APIs by national authorities (Art. 32 No. 2) 

  • National authorities shall exempt banks that have opted for a dedicated interface from the obligation to set up a fallback/direct access where the dedicated interface meets further specified conditions.
  • The EBA is to be consulted to ensure a consistent application of these conditions.
  • Banks that have put in place a dedicated interface shall define transparent key performance indicators and service level targets.
  • Interfaces, indicators and targets shall be monitored by the national authorities and stress-tested.

Today’s EU and national authorities are hardly able to handle the ongoing monitoring and stress-testing of PSD2 APIs. They currently lack resources and technical skills to do so. Therefore, figo enthusiastically welcomes the solution to obtain a helping hand from market participants in that regard, i.e. – according to the Commission’s fact sheet on the RTS publication – “the set-up of a market group, composed of representatives from banks, payment initiation [PIS] and account information service [AIS] providers and payment service users [which] will review the quality of dedicated communication interfaces.

However, it is important to stress that such a stakeholder group can only be helpful insofar as it is composed of well-experienced and actively contributing market participants. And with regard to selecting TPPs, experience should be measured in active AIS, PIS and banking API years instead of company age. A wisely-composed stakeholder group which defines and regularly reassesses EU-wide minimum standards for key performance indicators and service level targets could provide a solid foundation for a level playing field of API-compliance checks. A competent and motivated market group can and should also serve as technical consultant to the EBA’s and national authorities’ staff in order to take initial steps towards centralised real-time monitoring tools at the authority level in the long-term.

Last but not least, a jointly working market group could provide support in clustering the envisaged API-compliance approvals by authorities on a fair and transparent product or technical service provider level instead of a single API/per bank level. This could minimise upcoming efforts to a large extent.

Issue #2 Revoke exemption of providing a fallback/direct access (Art. 33 No. 7) 

  • National authorities shall revoke the exemption where certain conditions are not met by banks for more than two consecutive calendar weeks.
  • In this case banks are to establish, within the shortest possible time and at the latest within two months, the contingency mechanism of a fallback/direct access.

This provisions leave us with some question marks; e.g. why is it not regulated how a bank can regain an exemption after losing it and in a shorter period than two months, instead of only obliging banks to build a fallback solution within this given time frame? TPPs surely prefer a promptly-fixed API instead of waiting two months for a fallback solution for which they would have to build up a separate access technology. There is hope though that authorities will manage this process in a more workable manner in practise and guided by the EBA within a EU level playing field. Again, centralised real-time monitoring at the authority level would help to minimise all kinds of manual steps in such a time-critical process.

So… all things considered, figo says “Please go for it, Parliament and Council! Approve the present RTS!



figo makes financial data from thousands of European financial sources easy and secure to use for your digital services – learn more about our products.

Find out more about figo and the team behind it here.

Let’s talk!