Another update on the work of the API EG

Since our last blog post on the subject, the EC’s API Evaluation Group (API EG) has met twice, in May and June. Here’s PPRO’s summary of what was discussed and decided at those two meetings. See the end of this blog for a short glossary of the terms used in this article.

14 May — the Eighth meeting of the API EG

On 14 May, the API EG met for the eighth time, co-chaired by James Whittle of Payments UK and Oscar Berglund, the CEO of Trustly. This is what the committee discussed.

Account Information Services (AIS) data
ASPSPs want to discuss only payment-relevant data falling within the scope of the PSD2. AISPs, on the other hand, would like access to a broader range of data. For now, the API EG has decided to concentrate on payment-related data, but also continue the subgroup’s work on the hot topic of non-payments data.

PSD2, GDPR and consent
During a presentation by a representative of the European Commission, the group learned that:

• The TPP does not need to pass on details of the consumer’s consent to the ASPSP. The ASPSP does not have a duty to check that the TPP’s customer has consented.
• Whether or not a consumer has a valid contract signifying consent to data sharing with a TPP is subject to the civil law of each member state.
• Explicit consent in GDPR in relation to the processing of sensitive data (which is different to sensitive payment data under PSD2) is an additional condition and not a legal ground. Therefore the TPP’s T&Cs will require an “explicit” (dedicated) paragraph to obtain such consent, but there is no need for a checkbox or explicit text on the user screen.
• If a TPP wishes to process data for purposes other than payment, they need explicit consent or another GDPR-compliant legal basis to do so.

Who applies strong customer authentication?
The committee discussed whether only ASPSPs can handle strong customer authentication (SCA) or whether TPPs can also provide the SCA.

Group members representing banks and other ASPSPs were of the opinion that TPPs should not and could not apply SCA, because they would not be authorising transactions. TPPs disagreed and the European Commission representative suggested to seek further clarification from the EBA (the EBA representatives were not present at that time).

Security
In a discussion on security, TPP representatives pointed out that there is still no clarity or agreement on the meaning of the term “session”. There are, for instance, both communication sessions and transaction sessions but the legislation and technical guidance does not distinguish between them.

This prompted a discussion about communications sessions, with group members asking the EBA for clarification on whether parties in a communication session would need to use the eIDAS certificate also for mutual authentication. The EBA said they would not but after further discussion agreed that the topic still required more thought.

Review of the API functionalities
Committee co-chair James Whittle proposed that the API EG should focus on two things:

• Clarification documents: documents clarifying the official and agreed position on hot topics. These should be published as soon as possible.
• List of recommended API functionalities: this should be made available as soon as possible to those parties, ASPSPs and banks, working on APIs and API-related project

8 June — the Ninth meeting of the API EG

On 8 June, the API EG met for the ninth time, chaired by James Whittle of Payments UK with apologies from Oscar Berglund, who was unable to attend. The group discussed the following topics:

Access to payment account information by AISPs (only) 4 times a day
The group members agreed that the outstanding question is how it will work in practice. It was agreed to pass the matter to those running API initiatives and ask them what functionality they envisage for this.

The “What” question
What information should ASPSPs provide to PISPs under the terms of PSD2? Committee members John Whittle (Payments UK) and Aoife Houlihan (Klarna) noted that this matter has not yet been settled. It was covered in the November 2017 report of the ERPB Working Group on Payment Initiation Services (ERPB WG PIS) but has not yet been discussed in detail by the API EG.

The group agreed that the most important and immediate point to be actioned, is to clarify how the exchange of information should take place. The chair, J. Whittle, suggested to highlight the importance of this matter to the API Initiatives. The EBA said its clarifying documents will be available the next time the API EG will meet.

User information and fraud mitigation
This is a new topic, which the group discussed in response to a powerpoint prepared by several TPPs and shared with the API EG. TPPs would need continued access to data such as name, address, date of birth and (where applicable) national ID number. This information, they say, is crucial to their anti-fraud efforts.

ASPSPs do not want to allow access to this information. Their position is that TPPs should get these details from the merchants, with whom they have a contract. It was decided that further work and more clarity is required on this issue.

The API EG workplan
The group agreed that for each ‘hot topic’ identified since it began sitting, a general summary of the discussion to date — including any agreed positions — should be prepared. There are also a number of items in the group’s terms of references that are still be addressed. For this reason, the API EG has asked the European Payments Council (EPC) to extend the term of the API EG’s life for an extra three months. Both the EPC and EBA representative said that this would have to be the only extension of the group’s lifespan. The group’s work needs to be finished, so that the ASPSPs and the TPPs can use it to prepare their systems for PSD2 compliance.

Afternoon session with API initiatives

The API initiatives representatives were thanked for taking the time torespond to the questionnaire and for joining this meeting. J. Whittle informed that the API EG had identified challenging topics in some areas and that the aim would be to work together through the next stages which includes the publication of refined version of the recommended API functionalities by the end of June, albeit without any scoring or comparison table.

Before starting the review of the questionnaire, the API initiatives were asked to share their views on testing:

• Although the Berlin Group is a pure standards initiative they see the need to work commonly on this topic for example within a community or with a couple of ASPSPs. A cross border implementation project was setup which covers test concepts, test catalogues on functional, performance and security testing, certification policies etc. for the Berlin Group NextGenPSD2 Standard. This project is also working on requirements on solution provided.
• Stet has specified a requirements document in relation to testing issues and is providing a testing sandbox. They are also about to start with the definition of test cases.
• The Slovak banking API initiative referred to an ASPSP that has a portal where information is published which anyone can test for free without the need of certificates.
• Open Banking UK (OBUK) is using an independent software company that is providing sandbox facilities in the UK. Certification is considered to be an important topic.

While going through the list of questions one by one in extensive detail it was noted that

• some of the recommended functionalities are required by law; and
• some address a market need
• different interpretation of the questions resulted in different answers

Following further clarification some of the no answers hence changed into a yes (and vice versa).

J. Whittle concluded that the afternoon session with the API initiatives had been very helpful. As a next step, the API EG will need to produce a list of recommended API functionalities and for this the API EG might potentially require further input from the API initiatives.

At its next meeting on 25 June 2018 the API EG will need to further refine this list and reconcile it with the anticipated clarification documents from the EBA. As mentioned before, the API EG aims to publish a list of recommended API functionalities by the end of June 2018. The API EG also agreed to extend the work of the group for another 3 months in order to be able to tackle other deliverables such as testing that are included in its terms of reference.

Glossary

AISP: Account Information Service Provider — a company which gives customers information about their accounts. An example might be an aggregator which gives customers access to all their bank accounts and investments through a single online dashboard.

API: Application Programming Interface — a programme or suite of functions which enables a software developed to build programs fit for a specific purpose. A common use of APIs is to help developers create programs that are compatible with a particular piece of software. In the context of Open Banking and PSD2, banks create APIs which allow TPPs to interface with bank systems and access — with consumer permission — bank-account data.

API EG: the EC’s API Evaluation Group — a committee composed of representatives from fintechs, banks, industry groups and regulators. Its job is to define how good APIs should look like in order to recommend ASPSPs getting exemptions from providing a fall-back to their user interface.

ASPSP: Account Service Payment Service Provider — an institution which provides customers with a payment account. In most cases this will be a bank, but it could also be a building society, savings society or e-money institution. Under PSD2, ASPSPs will have to give third-part providers (TPPs — for instance fintechs) access to customer account data.

CBPII: Card-based Payment Instrument Issuer – a PSP issuing cards and executing card-based payments for accounts they do not service themselves, i.e. those of another ASPSP.

EBA: European Banking Authority — the EU bank regulator.

EC: the European Commission.

eIDAS certificate: Electronic Identification, Authentication and trust Services — a standard for electronic identification in the EU.

EPC: European Payments Council — an industry body founded to promote the development of a single payments market throughout the EU.

GDPR: General Data Protection Regulation — the EU’s new privacy law, introduced in May 2018.

PISP: Payment Initiation Service Provider — can ask for permission to connect to a bank account (or other ASPSP account) and to initiative a payment from that account to a third party on behalf of the account holder.

PSP: Payment Service Provider — a PSD2 licensed entity, e.g. ASPSP, PISP, AISP or CBPII

RTS: Regulatory Technical Standards — the technical standards which define what definitions and terms evoked in PSD2 mean for banks and TPPs in practical and technical terms.

SCA: Strong Customer Authentication — the improved standards of authentication mandated by PSD2. SCA must be based on at least two of the following elements:

• Knowledge — something only the user knows
• Possession — something only the user has
• Inherence — something about the user that is unique to him or her

TPP: Third Party Provider — PISPs, AISPs or CBPIIs.