Ralf, you are a member of the API Evaluation Group; what is it about, and what did the group commit to?
The API Evaluation Group (API EG) was created by the European Commission (EC) with the support of the Euro Retail Payments Board (ERPB) of the European Central Bank (ECB). The group met for the first time on 29 January 2018. The EC tasked us with creating a market view about how APIs should look like for use in PSD2, i.e. open banking.
To give some background, API stands for ‘application programming interface’. APIs are the technical interface between banks and fintechs. They’re the foundation of Open Banking and once restrictions on ‘screen scraping’ come into force, they will be fundamental to the operation of many fintechs and payment specialists.
To ensure a level playing field and a workable technical basis for the European finance sector, whatever standards emerge for open-banking APIs, they must work for all parties: consumers, fintechs, banks and regulators.
The job of the API Evaluation Group is to formulate a set of recommendations describing how ‘good APIs’ look like in the eyes of the market participants and are therefore likely to be ‘widely used’ by Third Party Providers (TPPs), which is one of the prerequisites for banks getting exempted from providing a fallback mechanism to their customer (online banking) interface.
The API EG’s goals are to:
Define objective API evaluation criteria and guidance
Evaluate specific API initiatives against those criteria and guidance
Evaluate representative examples of practical implementations
Provide guidance on KPIs such as API security and performance requirements
Define the basic principles of a common testing framework
In what timeframe can we expect to see these decisions carried out?
The group agreed to report its progress by June 2018. Between January and June, we’ve been meeting once or twice a month, either in person or by phone.
What are the objective criteria to evaluate an API for the purpose of PSD2?
Well, that’s what we’re currently working out. So, you’d better ask us in June. What I can tell you is that we’re working hard to ensure that the requested functionalities will be both robust and representative of a broad consensus across the industry.
If an API meets the requirements set by the API Evaluation Group, is there still a need for a fallback option?
The decision of granting banks an exemption from providing a fallback lies with the National Competent Authorities (NCAs). They shall consult the European Banking Authority (EBA) beforehand and we strongly believe that the API EG’s advice will be valuable for them, too. I hope that these decisions will not be taken lightly and that there will be coherence across the countries.
Market players are certainly expecting a high level of interoperability and uniformity, as you’d expect in the single market. But for anything as large and complex as the EU financial industry — with thousands of banks and fintechs as well as 28 separate jurisdictions, a level of fallback and redundancy is vital if all operators are to have complete confidence in the system that will underpin open banking in Europe. And it’s vital that they do so, because if they don’t the EU will be at a disadvantage in comparison to other markets in the world.
Are we heading towards one standard API in Europe, just as in UK (Open Banking) and India (UPI)?
I don’t think so. At the moment, the API EG is looking at the 5 most prominent API initiatives. Some of them may join forces, but there are several others already and more are likely to appear. Plus most of these API initiatives are offering different options, so they can be implemented in different ways, which no doubt the banks will do. Of course, there would be advantages in having a single standard for Europe, but there is value too in allowing different technologies and PSD2 was deliberately designed to be technology agnostic, which I believe is the only way to ensure future proof. So, API implementations will differ from market to market and maybe even from bank to bank. APIs have been given a lot of advance laurels, now it’s the time for banks to prove that they will really lead to bigger and better TPP products, compared to what was possible up to now via the bank’s customer interface.
What are the most contentious topics in this phase of the PSD2 implementation?
The API EG is composed of representatives from across the industry. It includes members from the banks, the fintechs, the industry bodies, and relevant European institutions. Hence, it’s not easy to find agreements, but so far, I think we have worked well together towards a common goal: the creation of API standards that will make open banking a reality in the EU, giving our financial industry a much-welcome boost and European consumers access to world-beating services.
The hottest topics discussed to date were the pros and cons of credential sharing, what account data is required to allow for a reliable and real-time payment initiation and how this can be obtained, as well as how Account Information Services can be given a level playing field compared to a bank’s own capabilities in this area. Some banks may just want to achieve minimum compliance, some others may want to offer more to be exempted from providing a fallback, and yet others – hopefully many – will want to attract as many TPPs as possible so that their customers get the widest choice of available value-added services in the market. Therefore, API initiatives should cater for that and provide a wide range of options. I think everyone can agree on that. The controversy is about which of these options should be implemented by a bank in order to be compliant and which additional ones to qualify for an exemption.
A good example of this is the ‘Authentication (SCA) guidance’ document, which the API EG just released. It clarifies that API standard initiatives should support all authentication methods and processes and should not prescribe redirection-only methods, which introduce unnecessary friction to the user’s payment flow and could also not support payments in retail stores or using new devices like wearables or voice assistants.
API standard initiatives, which are not able or willing to provide a broad range of functionalities should make room for others who can. I am not saying this is easy, because most are driven by the banks, whilst their users, i.e. customers, are the TPPs. But if they take a minimalistic approach, and some do, they have to realize that any bank implementing it would be a) at risk of not being compliant, b) unlikely to get a fallback exemption and c) certainly much less competitive than others, who use a broader API standard.
Consumer trust is key in this ecosystem; what is your vision on user centric consent management and where should consumer consent be managed such that consumers have control over who has access to their data?
One of the things the API group is working on, is establishing the processes and responsibilities necessary for gaining consent. These discussions are still ongoing, so I can’t give you the official position yet. But I can tell you what I think. To be PSD2 and GDPR compliant, TPPs must obtain the explicit consent from users for accessing their data. Banks can rely on their legal obligations for processing this data. It would be a horrible user experience if consent had to be given twice.
One of the reasons TPPs are now required to get PSD2-licensed is to allow NCAs to supervise and ensure that user consent is provided and that the data accessed is handled securely. Consumers can always choose not to give any consent, but this is about those wanting to use TPPs and their value-added services and therefore want to allow the use of their data for that. Obviously, they can withdraw their consent or simply stop using such services at any time.
About Ralf Ohlhausen:
Ralf Ohlhausen, MSc in mathematics and Master of Telecommunications Business, has over 25 years’ experience in ecommerce, financial services, mobile telecommunications and IT. Before joining PPRO Group, he was President Europe at SafetyPay. Other management positions on his international career path took him to Digicel, O2, British Telecom and Mannesmann-Kienzle. At PPRO, Ralf is responsible for increasing PPRO’s global reach, focusing in particular on the addition of new payment choices to the company’s portfolio.
About PPRO Group:
Cross-border e-payment specialist, PPRO Group, (PPRO) removes the complexity of international ecommerce payments by acquiring, collecting and processing an extensive range of alternative payments methods for Payment Service Providers (PSPs) under one contract, through one platform and one single integration. PPRO supports international payment methods across more than 100 countries, allowing PSPs to expand their merchants’ ecommerce reach, arrange hassle-free collection and achieve higher conversion rates.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now