PSD2: Screen Scraping vs APIs?

PSD2 – also known as the Revised Payment Services Directive – is expected to, among other things, create a regulatory framework that obliges banks to let customers share their financial data with third-party providers (TPPs) in a secure way. Having access to that information gives these TPPs the ability to compete with banks in the creation and improvement of certain financial services that otherwise would be out of reach – for example, account aggregators and Personal Financial Management apps are fuelled by users' account balance and transaction data held by banks.More infoFX Management APIInternational Payments

However, uncertainty lingers over both the type and the amount of information that banks will be obliged to share and the communication interface they will need to implement (i.e. the channel used for sharing such information) – these details are being defined by the European Banking Authority (EBA) in the so-called Regulatory Technical Standards (RTS) on strong customer authentication and secure communication. In the rest of this article we’ll dive into the current state of the debate on the communication interface that should be implemented.Disclaimer: Bear in mind that this discussion on APIs vs. screen scraping is distinct from the debate on the specific features that banks’ APIs (e.g. messaging/interface standards) should have. In the event that APIs become the common channel, TPPs would still face enormous costs if they had to integrate with 4,000 different banks in Europe. For more information on this subject, I would recommend you read this and this by John Broxis.

Aren’t TPPs accessing banks' data at the moment – i.e. prior to PSD2?Yes they are, mainly through screen scraping. In a nutshell, when a bank's customer uses a TPP application – e.g. accounts aggregators – they are asked to provide their bank account credentials. With such information, the TPP accesses the client's account through the respective banking platform and scrapes the data. Therefore, the data available to the TPP is identical to the information displayed on the screen of the customer when entering the banking platform.As you can imagine, this type of access is not regulated, is free of charge and does not obtain the bank’s consent. If you add the security and privacy concerns outlined below into the equation, it is easy to see why banks don’t really love this set-up.The other current but much less familiar way of sharing data between TPPs and banks is through API integrations. Here the bank has total control over how and how much data is shared with the TPP and this usually involves a contractual relationship – so banks can monetise it.What are the other reasons why many banks don’t like the current framework?In his April 2016 letter to shareholders, JPMorgan Chase CEO Jamie Dimon made a series of comments on screen scraping that to some extent represent the bank’s main concerns (it is worth remembering that Chase is not a European bank):“When we all readily click “I agree” online or on our mobile devices, allowing third-party access to our bank accounts and financial information, it is fairly clear that most of us have no idea what we are agreeing to or how that information might be used by a third party. We have analyzed many of the contracts of these third parties and have come to the following conclusions:

• Far more information is taken than the third party needs in order to do its job.
• Many third parties sell or trade information in a way customers may not understand, and the third parties, quite often, are doing it for their own economic benefit – not for the customer’s benefit.
• Often this is being done on a daily basis for years after the customer signed up for the services, which they may no longer be using.

We simply are asking third parties to limit themselves to what they need in order to serve the customer and to let the customer know exactly what information is being used and why and how. In the future, instead of giving a third party unlimited access to information in any bank account, we hope to build systems that allow us to “push” information – and only that information agreed to by the customer – to that third party. Pushing specific information has another benefit: customers do not need to provide their bank passcode. When customers give out their bank passcode, they may not realize that if a rogue employee at an aggregator uses this passcode to steal money from the customer’s account, the customer, not the bank, is responsible for any loss. You can rest assured that when the bank is responsible for the loss, the customer will be fully reimbursed. That is not quite clear with many third parties. This lack of clarity and transparency isn’t fair or right.”Why don’t some TPPs support the ban on screen scraping?The EBA – again, the institution that is expected to clarify this matter – has suggested, in the current RTS draft, that the access to the client account should no longer be via the customer’s interface (i.e. screen scraping) but via a “dedicated interface” specially designed for this very purpose (i.e. APIs).The European Parliament ECON PSD2 negotiating team raised its concern about this approach – shared by some TPPs – in its letter to the European Banking Authority. Here is an excerpt:

Translation: Obliging TPPs to no longer connect via the client’s interface (aka screen scraping) and imposing mandatory interfaces (aka APIs) will allow ASPSPs (aka banks) to easily identify who is accessing the account. Since they will be the ones managing the APIs, and since the TPPs that would want to use them would be banks’ competitors, there might be a conflict of interest that could potentially lead to access being denied by banks even for arbitrary reasons, which would go against the spirit of the PSD2.As reported by Payments Compliance, ‘according to Georg Schardt, a managing director at Munich-based online payment provider SOFORT, that model — which is widely expected to be built around the development of an application programming interface (API) by banks — could prevent third-party providers from being able to access customer accounts directly… [Schardt] is not against the development of APIs generally, but said third parties must retain the ability to switch between banks or between access models as they see fit.Besides, Dirk Haubrich, the EBA’s head of consumer protection, financial innovation and payments, responded that the draft technical standards already address a potential scenario where a bank’s API is not functioning properly. “PSD2 itself already says if the interface that is provided by the bank is not available, you can revert back to the old way of how you’ve accessed it,” he said.[EBA’s] Haubrich said he was “keen to hear some more views”, reiterating that industry responses to the authority’s consultation paper will be thoroughly examined. He also pointed out that the technical standards “deliberately did not go down to the level of defining an API” to avoid being overly prescriptive, and potentially stifling to innovators.’What is the reply information we have from the EBA?In the European Parliament ECON Scrutiny Session 29 Nov on PSD2, Andrea Enria, chairperson of the EBA, replied to the concerns raised by the ECON PSD2 negotiating team. Here is an excerpt from his statement:

So, as the last sentence of the last paragraph evidences, the EBA is still open to debating this topic and in the process of canvassing the views of the different stakeholders. Will APIs become the main channel in the end? Will they be the only channel? Could this really give banks free rein to hamper competition? I don’t have the answers to these questions, but hopefully I’ve offered a useful overview of some of the different stances on the subject.I will be covering this topic again in January's Burnmark report on PSD2 and Open Banking. And please, feel free to leave a comment. I would love to hear your opinion on the matter!