PSD2 - 10 questions requiring an answer - Here is a shot on an answer.

A bit more than 3 months ago, I submitted the blog "PSD2 - 10 questions I would like to see a clear answer on" (https://www.linkedin.com/pulse/psd2-10-questions-i-would-like-see-clear-answer-joris-lochy/), raising 10 questions around PSD2, on which I was searching an answer on. Via different channels, I got requests of many people, that they would love to get also the answers on those questions.

With the excellent support of Ralf Ohlhausen (Executive Advisor at PPRO and Tink) and the input of some other people, I have tried to compile an answer on these 10 questions. Unfortunately, people looking for a clear, undisputable answer, will be disappointed. As with most complex topics in the financial industry, the answer to almost each question is "it depends…​". It depends on whether you look at the strict interpretation of the European directive (normally only 1 answer possible), the local interpretation of the national regulatory authorities (so 28 possible answers) or the specific bank interpretations (hundreds of different answers possible).

Another important consideration in answering the questions is that PSD2 targets 28 different countries, with very different payment situations before PSD2. Especially for initiating a payment, it can be confusing for certain countries what really changes. For countries like Belgium, the Netherlands and Sweden most PSD2 payment requirements are already fulfilled, i.e. they already have SCA for payment initiation, banks already support online payments and already no commissions are asked to retail clients to execute a payment. This is however not the case for certain countries, where simple 1-factor authentications (e.g. username/password) are still commonly used and lots of banks don’t provide services yet to external parties to initiate a payment. For citizens of the first group of countries, it might seem that the payment initiation is not really changing because of PSD2, while for citizens of the 2nd group the impact is much more considerable.

End of November I was attending the Digital Finance Summit in Brussels (organized by Fintech Belgium, B-Hive, Febelfin and EBF), where David Kestens presented a new firm (= Cake) he is creating, which aims to improve the customer’s Daily Banking experience (in first phase only in Belgium) by aggregating all account information from different Belgian banks. Having received a TPP license of the Belgian regulator in July 2019, Cake started integrating the PSD2 services of the 18 Belgian banks, just after the PSD2 deadline of 14/09. To everyone’s surprise, he presented following shocking conclusions: of the 18 banks in scope, 0 exposed a great API, 2 a stable API, 4 a mediocre API, 8 a horrible API and 4 no API at all. Along the identified issues were missing data (e.g. account information only providing the amount or no indication of whether it is a credit or debit…​), wrong data, missing transactions or impossible authentication flows (e.g. QR code showed on phone to be scanned by phone on which QR code is showed). These poor results are the best proof of why an answer "it depends…​" is still applicable, as long as the market has not stabilized. It is clear, that most banks have exposed an MVP API, which needs to be further extended to meet all regulatory requirements. This will take time, which will have a negative impact on planning of TPPs, building on top of PSD2 services for their business offering.

Before going further into the answers on the questions, it is however important to define some terms. This will be a no-brainer for people familiar with PSD2, but for some readers it might be good to repeat the definitions:

• AIS: Account Information Services: services (= APIs) offered by ASPSPs to retrieve account information (balance and/or transaction information)

• AISP: Account Information Service Provider: any organization (e.g. the company Cake above mentioned) that wishes to retrieve online account information of one or more accounts held at one or multiple ASPSPs

• ASPSP: Account Servicing Payment Service Providers: any organization that provides and maintains accounts (typically a bank)

• PIS: Payment Information Services: services (=APIs) offered by ASPSPs to initiate a payment instruction

• PISP: Payment Initiation Service Provider: any organization (like a retailer) that wishes to initiate credit transfers on behalf of the client.

• PSP: Payment Service Provider: a party, which offers merchants online services to accepting electronic payments (e.g. Adyen, Mollie, Ingenico…​)

• PSU: Payment Service User: the end-user (the real customer) consuming the PSD2 services via a TPP

• RTS: Regulatory Technical Standards: set of compliance standards (security, accountability…​) to be met by all parties (regulating both ASPSPs and TPPs)

• SCA: Strong Customer Authentication: part of RTS standards, SCA enforces a 2-factor user authentication, when executing a payment

• TPP: Third-Party Provider: the collective name for AISPs and PISPs

After having introduced those concepts, let’s give it a try to answer the questions:

Question 1: Are saving accounts and foreign-currency (i.e. non-EUR) current accounts in scope of PSD2?

PSD2 enforces banks to expose account information for all payment accounts in Europe, independent of the currency (so also non-EUR accounts).
The definition of a payment account is generally less clear, as it differs by country, but the most used definition is an account which can be accessed remotely (= online) and has the ability to execute payment transactions (without the use of an intermediate account) to a third-party and receive such transactions from a third-party.

As most saving accounts can receive payment transactions but cannot execute payment transactions to a third-party (only allowed to execute payments to accounts at the same bank with a same holder structure), a saving account is not considered as a payment account. This means banks are not legally obliged to expose PSD2 APIs for saving accounts, but of course there is no rule prohibiting either (as long as the GDPR rules are followed).

So, when considering the AIS APIs, we can conclude that banks are legally obliged to expose all current accounts (also non-EUR), but not saving accounts. This doesn’t mean however that certain banks are not exposing AIS services for saving accounts as well.
If a bank does not expose saving account information via APIs, a TPP is allowed to access the information via the bank’s user interface (e.g. via screen scraping), but this gives usually a quite bad user experience (as user often to reauthenticate for each access, when bank has implemented SCA to access its online banking).

Question 2: Are cash accounts of corporate customers in scope of PSD2?

As mentioned in the answer of question 1, any payment account is in scope of PSD2 and this independent of the customer type (retail or corporate), so current accounts of corporate customers are indeed in scope of PSD2.
As PSD2 enforces also that the APIs exposed in context of PSD2 should support all authentication methods offered by an ASPSP directly, this also means the PIS APIs should provide services like 4- and 6-eyes validations. In many cases, the MVP version of the bank APIs does not yet support those complex cases, making payment initiation via PSD2 for corporate customers still out of reach.

Question 3: What is the actual gain for a TPP using the PSD2 payment API?

The majority of merchants with an online presence will not switch to become a TPP, but instead will continue to pass via an e-commerce PSP (like Stripe, Adyen, Mollie, Ingenico…​) to ensure a proper payments integration. The work to become a TPP would far exceed the added-value for a merchant, especially since a PSP provides a lot of additional value added-services to a merchant, such as integration of different payment methods, following all evolutions in these integrations and other services, such management reporting, reconciliation, tools to manage refunds and services for fraud detection.

The PSPs are likely to become TPPs (or at least connect to cross-country TPPs) and consume the PSD2 PIS services of banks in order to reduce costs and provide additional payment methods, but this will not always be directly visible for the merchant or end-customer.

However also for this question it’s important to look at all countries in Europe. There are enormous differences in online payments between European countries: while in France 80% of online transactions is done via credit cards, in Germany the most common online payment method are bank-based payments like direct debit and credit transfer. In the Netherlands there is a strong focus on the usage of iDEAL.
In countries with a strong presence of such local, online transfer payment methods, like Bancontact in Belgium, iDEAL in the Netherlands, Giropay in Germany and EPC in Austria are less likely to be impacted by PSD2 for online payments.
For other countries, the impact will be more considerable. Before PSD2 only half of the EU banks were connected to a bank payment scheme. This meant that customers of those banks were obliged to use a credit card or digital wallet to execute an online payment. Thanks to PSD2, those customers will now get easier access to online payments as well.

Many large eCommerce players are however hesitant to implement payments based on PSD2, due to its poor usability. Amazon is known to have implemented a very strong risk-based authentication and continuous fraud detection system, allowing to identify fraud even before coming to the check-out. This complex system allows Amazon to execute credit-card payments without any user action. Switching to PSD2 PIS, which typically results in a redirection to the bank app, followed by a strong customer authentication, would be a serious step back in the user experience perspective.

Question 4: Usability of PSD2 for apps, which are not very frequently (or even only once) used

Most banks have implemented PSD2 with an extensive consent management solution¨, which requires the end-user to create a consent at the bank to allow the TPP to access account information and/or initiate a payment.
This consent is usually:

• Limited in time (expires after a while, often set to 3 months)

• Limited in scope (only for specific PSD2 services)

• Limited to specific account(s)

• Limited to 1 bank user

• Limited to 1 specific TPP

This means that a TPP can only call a PSD2 service on behalf of the end-user, if a valid consent exists. This means a significant drawback, especially for TPPs, which don’t have a regular contact (a one-shot action or an infrequent access) with the end-user.

Recently the EBA has indicated that this detailed cross-check implemented (on consents) by the banks is not in line with the PSD2 directive. The EBA confirms that if the TPP collects an explicit consent (collected separately from any other agreements) of the end-user to process his bank data, that this suffices, meaning that no redirection to the bank is required. Banks however try to keep this double-check, as it makes it more difficult for TPPs to access the precious bank data, but also protects the bank better against frauduleus TPP calls.

It will be interesting to see how this evolves. For TPPs only a flow with no redirection provides the same user convenience as card payments. TPPs argument that the risk for the bank has already been sufficiently mitigated by an extensive onboarding procedure with the regulator to become a TPP (as PISP and/or AISP). This onboarding already includes an audit of the TPP’s security systems, the need for a liability insurance, an extensive investigation into all operational procedures and governance of the organization…​

Question 5: Data storage and consent expiration

An AISP can store the information retrieved from banks, including the customer credentials. Any information that was retrieved can be stored by the AISP, if it meets all rules defined in the GDPR directive.

As mentionned above most banks have however implemented a consent expiration after typically 3 months. In most current implementations this means that a TPP can only accumulate data for 3 months, when there is user interaction, i.e. if a user does not re-authenticate (i.e. renew his consent for the TPP), there will be a gap in the accumulation.

Like the creation of a consent, we also have a misalignment between the interpretation of the PSD2 directive between banks and TPPs. Banks believe that the consent must be renewed via an explicit user interaction, while AISPs believe it can be done with the credentials stored during the creation of the expired consent. Till now the regulators have not taken a clear stand in this discussion.

Question 6: Which usage of PSD2 data is allowed

TPPs need an explicit consent of the user to access the user’s data. In line with GDPR, this consent should inform the customer, what the data will be used for and to which parties the data will be provided. GDPR defines also that the data can only be stored if there is a clear need for (i.e. it is not allowed to store personal data for potential future usage) and that any change in usage or delivery to other third-parties should be agreed with the customer.

Once a TPP has received this consent, the TPP can retrieve the account data also when there is no trigger (i.e. no user interaction) of the user to the TPP. The TPP can to do this up to 4 times per day and of course more when there is user interaction.

Question 7: PSD2 aggregators - Who is the TPP and how is it viewed by the customer?

As already explained in answer to question 4, a lot of banks have implemented a consent management system, which authorizes a specific TPP to call the bank’s services. Furthermore, most banks require a TPP to first onboard the bank, to get a specific token to create those consents.

Such a TPP onboarding is however also not in line with the philosophy of the PSD2 directive. Normally a TPP is validated and accepted by the regulator, which grants the TPP a PSD2 license. With this license, a TPP can get access to any bank, without further due diligence from their side. The bank should therefore not have a notion of the details of the TPP, nor should a customer be able to manage all his TPP consents in the bank’s website.

In this setup, the TPP is always the party interacting with the end-customer, independent if the TPP has outsourced the PSD2 connectivity to an aggregator or if the bank has outsourced the provision of its APIs to a bank-side aggregator. For the end-user only the TPP and his bank matter, i.e. the rest should be invisible for him and is also not relevant for him from a responsibility and liability point of view.

As with most of the above questions, there is however a difference between the reality and the intention of the PSD2 directive and the regulator. When banks have implemented consent management systems, linked to the details of a specific TPP and allowing the bank customer to manage all his consent in the bank online website, these outsourcings will raise issues, as the TPP known to the end-user (i.e. the TPP with which the customer interacts) and the TPP known to the bank (i.e. the aggregator) will not be the same.

Question 8: Is the creditor account number part of the consent?

Just as for answer to question 6 and 7, also here it is important to consider that normally a consent should not be linked to a TPP and that there should be no onboarding of TPPs by banks.
As a result, the account number of the creditor should be dynamically passed along as part of the payment instruction. The account number of the creditor should therefore not be part of the consent at the bank side and a TPP can use any account as creditor account, as long the customer confirms the payment, via the digital signature system.

Question 9: Signing of a PSD2 payment transaction

The PSD2 directive indicates that a payment initiated via a TPP should follow the same signature rules as a payment initiated from the bank’s own channels. This means any limits or authorization procedures (like 4-eyes, multiple SCAs…​) the bank applies for a standard payment should also be applied for a PISP.

Example: suppose John is booking a trip online via a TPP and paying with PSD2 with the joint current account. The amount of the trip requires however his wife Melinda to co-sign as joint account holder. Via the multi-signature system of the bank, Melinda will be notified on her mobile, that she should co-sign a pending payment, via the banking app. In the future it might be possible, that this co-signing would also be integrated in the TPP app.

Question 10: Real-time nature of a TPP

As indicated in answer to question 6, a TPP can access the account information up to 4 times per day without customer involvement. This means a real-time alerting on the account situation, is currently not an option for TPPs.
Likely this limitation of 4 times per day will be removed in the future (as too restrictive for TPP usability). Furthermore, banks could provide webhooks to TPPs, allowing banks to push real-time any changes to an account position, thus eliminating the need for TPPs to make unnecessary calls to the bank.

Conclusion: the answers to these questions show that there is still a long way to go before the objectives of PSD2 (i.e. increasing competition and increased customer service) are reached. Regulators will need to audit the current PSD2 implementations delivered by the banks, to ensure that proper PSD2 services are provided in line with the PSD2 directive and the clarifications made by the EBA. At the same time, a new version 2.0 of the PSD2 RTS (Regulatory Technical Standards) standards is required to clearly define and agree all cases currently not covered by version 1.0. Only when this evolution becomes a reality, the account data currently stored in the bank systems will be truly unlocked.