Those working for compliance of a bank with PSD2 in the EU are searching for the specifications, recommendations, or at least examples for their implementations. Some institutions have published such specifications, all providing different approaches. We can follow any of them, or, based on their experience, we can create our own specifications. Let’s have a look at them.
The Berlin Group is a pan-European payment interoperability standards and harmonization initiative. Version 1.1 was published on 11 May 2018.
Another option is the PSD2 API of STET, contributed by several French banks. Version 1.3 is available since 10 April 2018.
Open Banking Payment Initiation API version 1.1 and Read/Write Data API version 2.0 are other options. They were last modified on 30 November 2017 and 2 March 2018.
We usually analyze the specifications above during discussions as they seem to be open, most likely useful for Hungarian implementations.
Confusing terms
In my Article on the players of PSD2, I described the players and drew the main connections between them. Reading through “Opinion of the European Banking Authority on implementing the RTS on SCA and CSC“, published on 13 June 2018, I found the following statement. “Furthermore, Article 36(1)(b) of the RTS states that ASPSPs shall provide PISPs ‘with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user’. In addition, Article 36(1)(c) of the RTS requires ASPSPs to provide immediate confirmation of whether or not there are funds available at the provider’s request, in a ‘yes or no’ format. The EBA wishes to clarify that Article 36(1)(c) applies to PSPs including CBPIIs and PISPs, rather than solely CBPIIs.”
First, we have to understand what CBPII means. CBPII stands for Card-Based Payment Instrument Issuer. EBA uses this term. This kind of entity is the same as PIISP (Payment Instrument Issuer Service Provider) in the picture of this article, which other parties use.
The data
Article 36(1) specifies what kind of data the ASPSP (Account Servicing Payment Service Provider, practically the bank) should give to payment service providers who use the API of the bank. The bank should offer three kinds of data.
Information about the bank account and transactions to the AISP. Information about the status of a payment transaction to the PISP. And confirmation of available funds to someone. Who is this someone? Considering the opinion cited above, confirmation of available funds should be available to PISP and PIISP. For this reason, I modified my picture to show it.
Who is compliant?
Let’s wait a bit, and let’s have a look at those standards mentioned at the beginning of this article!
At Berlin Group, PIISP is a role, which can initiate confirmation of available funds only. And only PIISP can start this kind of transaction. Therefore it seems that Berlin Group specification today is not compliant with the regulations if we consider the EBA opinion as cited above.
At STET, the Payment coverage check function is a part of the Payment Instrument Issuer Service, which belongs to the PIISP role and only to the PIISP role. So, it seems that, in this form, the specification doesn’t comply with EBA opinion.
At Open API, there is no such role as PIISP. And there is no such a function as a confirmation of available funds. So, if confirmation of available funds is a mandatory function, then this standard is out of scope.
Planning the solution, it’s a crucial question, where to go, what to follow. This question is a bit more complicated if there is no chance to select a certain standard, following it and specifying only the specialities of a country or an organization.
It seems that EBA has a different view on the role of the players of PSD2 than other parties do. Hopefully, they will work shoulder to shoulder to eliminate this difference because our tasks will be quite complicated if such differences arise during the implementation period.
