A further update on the API Evaluation Group

In January this year, the European Commission (EC) created the API Evaluation Group (API EG) with the support of the Euro Retail Payments Board (ERPB) of the European Central Bank (ECB). For the time up to June 2018, this industry body was tasked to advise the API initiatives, which have been established within or across several EU countries, about what their standards for application programming interfaces (APIs) for use in open banking should provide, in order to “look good” in the eyes of the represented market stakeholders.

I had summarised the API EG activities on the first two meetings here, and this follow-up now describes the group’s work as published up to now, which covers the months of February to April:

February: compiling requirements and started the dialogue with the key API initiatives

Following a conf call on 22-Feb, the group held meetings on 27 & 28-Feb, as well as a workshop with the five API Initiatives (APIIs), which were invited and agreed to participate (the Berlin Group, Open Banking UK, STET, Polish Bank Association and Slovak Banking Association).

Prior to the workshop, the group agreed a list of requirements, eight of which were then disclosed to the APIIs at the workshop to give an idea of the discussions and conclusions of the API EG up to that point:

• The API standard should enable both AIS and PIS in one single combined (technical) communication session. Smooth integration in a technical communication session for all the roles in scope of PSD2 (AIS & PIS).
• The API standard should support PIS and AIS for online payment accounts (individual/consumer and corporate payment accounts).
• The API standard should enable the following role-based access:
  1. a “pure PIS” user journey, implying the payment execution SCA only;
  2. a mixed AIS/PIS journey in one session, implying one SCA to view data (including for example balances and account related data), and one payment execution SCA;
  3. a “pure AIS” journey, implying one SCA to view data (no payment execution);
  4. Card based payment instrument issuer (CBPII) confirmation of available funds.
• The API standard should not require any additional checks of the consent given by PSUs in addition to the consent given to the TPP.
• The API standard should allow for the ASPSP and TPP to fulfil all their legal obligations (GDPR & PSD2).
• The API standard should enable a secure data exchange between the ASPSP and the TPP, mitigating the risk for any misdirection of communication to other parties.
• The API standard (including any definition of data structures) should conform to (widely used) standard(s) issued by international or European standardisation organisations. API EG expects that implementation of the standard does not create obstacles.
• The API standard should be built in such a way to allow the measurement of the API performance.

The API EG also established 5 technical subgroups, one each per APII, out of the 27 technical experts the members were able to delegate to the more technical evaluations where necessary.

The group also established a first list of so-called “hot topics”, which need focus and, if possible, should be resolved:

• Redirection vs other authentication methods
• AIS data (what data is in scope?)
• Access to payment account information by AISPS (4 times a day; 90-day period SCA)
• Consent in scope of PSD2 in the context of the GDPR
• Who applies SCA? (what are the consequences)
• Security

The EBA attended every meeting since 27-Feb and explained that it was quite unusual for a supervisory body to become a participant of such a group and that even though the EBA is not an active observer it does not mean that they will remain silent. The API EG as such can hope but cannot expect that its guidance will be taken into account by the NCAs and it should be clarified that the presence of observers on the API EG does not imply that the observers agree with the views expressed and documents published by the API EG. However, the EBA agreed to convey the views of the group to the NCAs and provide feedback to the group, where appropriate and possible.

During the workshop, the APIIs gave an update about their work so far, and the API EG clarified its role. The conclusions were that:

• Different initiatives are at different levels of maturity and depth of implementation.
• Majority focuses on standardisation activities (not implementation).
• On key issues there is a keen interest to work together.
• There is already some cooperation between different initiatives. Any convergence type of activity is indeed to be applauded.
• The API EG is aware that there are other initiatives. However, being mindful that bandwidth is limited, the review will focus on the five initiatives that were identified in the report of the ERPB WG on PIS.
• If there would be other significant initiatives, the API EG might however need to assess whether these should be included.

March: tackled the hot topics

Since the evaluation of the APIIs was still ongoing, a large part of the meeting on 27-Mar focused on the hot topics and getting a common understanding of the different views around the table:

• Redirection vs other authentication methods
  1. ASPSPs and TPPs each prepared an input document
  2. EuroCommerce and BEUC explained their concerns
  3. The ECB invited ASPSPs and TPPs to discuss further and find a way forward
  4. The EMA representative added that a range of authentication approaches is needed
  5. One co-chair summarised that the API initiatives shall define standards that support a wide range of authentication processes – a spectrum of options. This will support the ASPSP to be able to implement one, or more, authentication processes in a standardised uniform way and facilitate market choice.
  6. Gijs Boudewijn and I took away the action to create a single document
• AIS data
  2. The ASPSPs believe the focus should be on information in scope of PSD2.
  3. The AISPs on the other hand argue that information on non-payments account should be included as well in view of the fact that currently 80% of the accounts aggregated are not payment accounts.
  4. Indeed, AISPs argue that the access through an API only makes sense if they can access all types of accounts.
  5. The ECB representative suggested that since the PSD2 scope is limited to payment services and payment accounts, and considering the tight time line, it would be beneficial to focus on issues related to the PSD2 and the RTS.
  6. The EBA representative also noted that the competence of the NCA in this context is limited to the evaluation of PSD2 matters.
• Access to payment account information by AISPS (four times a day; 90-day period SCA)
  1. Burkovic who was assigned to this topic informed that in his view the fact that the AISP can only check four times a day is disadvantageous as in the ASPSP’s interface the information is updated in real time.
• Consent in scope of PSD2 in the context of the GDPR
  1. Resolution was already in sight, as the ASPSPs were advised that they can process data based on their legal obligation, i.e. will not need PSU consent
  2. TPPs agreed that their situation is different and that they will need to obtain the PSU consent
• Who applies SCA?
  1. The lack of clarity stems from the fact that in some clauses of the PSD2 reference is made to ‘PSPs’ and hence it is not specified whether it relates to ASPSPs and/or TPPs.
  2. The view of the ASPSPs is that PSPs issuing the credentials are in charge of the SCA and applying exemptions to SCA.
  3. The AISP view is that the law allows them to handle SCA themselves, based on credentials they issue to PSUs.
• The “what” question
  2. The co-chairs suggested to rely on the November 2017 report of Euro Retail Payments Board (ERPB) Working Group on payment initiation services (PIS) in relation to the information (i.e. the “What”) the ASPSP should provide to the PISP under PSD2.
  3. The ASPSP representatives commented that they did not agree with all the recommendations that are included in the report of the ERPB WG. Moreover, they noted that the ERPB itself did not endorse the report but rather ‘took note’ of it.
  4. The ECB representative remarked that the ERPB PIS WG report had been agreed without any comments. [Note: the ERPB of 18-Jun-2018 re-endorsed the work and outcome of this PIS WG]
• Security
  1. It was agreed that this topic needs to get framed first.

April: hard work on requirements and hot topics

During a conf call on 12-Apr the group reviewed the process on the API standard requirements list with the aim to complete it at the next meeting, which then happened on 23-Apr.

First however, the group reviewed progress on the hot topics and managed to agree their recommendation on “redirection”, which was then published here.

Unfortunately, there was less progress on the other hot topics, and whilst they were all discussed again at length and in detail, it was not possible to resolve any other one at that stage.

The list of “API Standard Requirements” was almost complete and it was agreed that in order to make the engagement with the API standard initiatives more effective, the requirements should be rephrased into ‘SMART’ (yes/no) questions in line with a harmonised view of what a good API should look like. This way the initiatives will not need to assess whether they are compliant, they will only need to provide a factual response (i.e. yes/no and clarify why yes/no). In case API initiatives would not support certain features then the list of questions will provide an early warning system to identify potential issues.

Next

A lot has happened since, but I have to await the public release of the following meeting minutes, before I can summarize and comment on them in my next blog about the API EG work.