PSD2 - 10 questions I would like to see a clear answer on

Hundreds of blogs and articles have been published about PSD2, all calling it a revolution in the banking and payment landscape. With the deadline of PSD2 roll-out (14th September) just passed, I am surprised however how much practical questions (specifically on how the PSD2 APIs can practically be used by TPPs) I can’t find an answer on, even when I talk to people who are considered as experts in the subject.

Below my list of top 10 questions related to the usage of PSD2 APIs, I am still trying to get an answer on. Being far from a PSD2 expert, some questions might have already clear answers, but despite intensive research and numerous discussions with PSD2 experts, I am still in the dark. Via this list, I try to open a reflection on the practical implementation of PSD2, as these low-level implementation issues might block the strategic intend of the PSD2 directive, which ultimately leads to very little change in the payments landscape.

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

Based on my research, PSD2 enforces banks to expose all liquid Euro bank accounts and their transaction information. This means both current and saving accounts. Nonetheless I have come across several banks, which intend to expose only their Euro current accounts, as - according to them - this meets the minimum requirements of the directive.

This brings the questions about the relevance of the dozens of account aggregators and PFM tools, which promise us the world once PSD2 is in place. The absence of open APIs on term and securities accounts gives already a big gap for a holistic customer view, but when the aggregated view is limited to only Euro current accounts the view becomes not very useful. A use cases like saving goals, based on saving accounts at different banks, becomes almost impossible to properly implement.

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

In many banks separate back-end payment and account systems exist for Retail and SME customers on one side and large corporate customers on the other side. This because large corporate customers have very specific needs with regards to accounts and payments (like cash management, payment netting…​).

In most banks the focus of PSD2 seems to be on the Retail and SME segment. Does this mean PSD2 API services on accounts of corporate customers are out of scope? If so, strange that we still see so many articles of Fintechs promising new use cases for corporates based on PSD2. If not, it is not very clear to me how all complex payment rules (e.g. 4 or 6 eyes principle for signing) existing for corporates will be handled via the PSD2 APIs.

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

The idea of PSD2 is to increase competition in the payments landscape. Suppose I own a well-running webshop and I am using today a payment provider, like Adyen (iDEAL), Square, BrainTree, Stripe, Klarna, Ingenico (Ogone), Payconiq, CyberSource…​ to allow my customers to pay from products on my website, what will change PSD2 for me?

I could register my webshop as a TPP and directly connect to the different PSD2 APIs of the different banks I want to allow payments from. This would avoid me having to pay commissions to my payment provider, but will it really save me money? Instead of having to integrate with an easy, well-documented service of the payment provider, I now have to get certified as a TPP with the national banking authority (in most countries this appears to be a lengthy and complex process, resulting in files of more than hundreds of pages), get onboarded at each bank and build (and later maintain) the connection to each individual bank (each having a slightly different API standard and authentication mechanism). Unless you have the size of an Amazon, this cost will be significantly larger than staying with my existing payment provider.
One alternative could be to pass via a PSD2 aggregator, but then I still need a TPP accreditation and now I have to pay a fee per payment to the PSD2 aggregator. My choice to stay with my current payment provider will be quickly made, especially knowing the complex consent management process (for the customers of my webshop) linked to using PSD2 APIs (see questions below).

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

Before a TPP can call a bank for initiating a payment or retrieving account information, the end-customer needs to give a consent to authorize the TPP to perform this action on the customer’s behalf. This process of setting up a consent is however quite time-intensive, i.e. customer needs to select his bank, after which he is redirected to the online banking of that bank, where he needs to authenticate himself and select the account(s) for which he wants to give consent. After this consent creation he is redirected back to the TPP’s app.

When we talk about use cases supported by PSD2, we often hear about account aggregators and PFM tools. These are tools, which the user will consult on a regular basis, justifying the effort of the customer to setup a consent. Many use cases, positioned in context of PSD2, are however one-shot or very irregular interactions (e.g. a website for requesting a credit and allowing the website to get access to your account information for a financial risk profiling) with the end-customer. For these use cases, it is doubtful if the end-customer will do this effort to create a consent.

Question 5: Data storage and consent expiration

A lot of TPP use cases require to store snapshots of the account data, retrieved via PSD2, for further processing (e.g. for training machine learning processes). This is required as most "account transaction history" PSD2 calls are limited in the period for which they can retrieve historical data (e.g. maximum 6 months).

Is such a storage of account data by the TPP allowed? Which constraints can a bank impose on a TPP to retrieve historical data? Normally PSD2 APIs should provide the same data as available in the online banking solution, but often those expose only specific, advanced searches to lookup older transactions.

If a TPP wants to have a full historical overview, without any gaps, it will be required that the TPP also retrieves data when the customer does not login to the TPP. To which extend is this allowed? To avoid a TPP retrieving info of unaware customers, a consent will normally have an expiration date. While this is useful for customers no longer wanting to use the TPP, it will be annoying for customers who only use a TPP occasionally, as gaps in the snapshot might exist and customer will be asked to extend his consent when he logs in. Furthermore, it is not very clear, if a consent extension will even be possible. For most banks, a fully new consent will need to be created, when the previous one expires.

Question 6: Which usage of PSD2 data is allowed

A customer needs to give consent to a TPP to access his account data, however it is unclear what the TPP can use the data for. According to the GDPR directive, a TPP cannot provide the data to other parties, without the explicit consent of the customer, but to which extend can they use the data themselves. Are following use cases allowed:

• Can a company use the PSD2 data gathered for 1 product/service for another product/service offered by same company? E.g. can an account aggregator use the PSD2 information for a financial scoring when they sell also credits?

• Is a TPP allowed to make a batch call every night for all its customers (also those who don’t actively use the TPP platform) to gain customer insights and potentially sell, aggregated, anonymized data to third parties?

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

Due to the multitude in API specifications, PSD2 aggregators will most likely become the standard for TPPs to connect to banks, as maintaining a direct API connection to each bank will be too costly to setup and maintain.

PSD2 aggregators like e.g. Ibanity, Token, Figo…​ provide 1 standard API towards the TPP and translate the request to the specific APIs for each bank. However, before a TPP can make a call to a bank, the TPP should normally first be onboarded at the bank. This includes a basic due diligence check of the TPP. As a result, the TPP will receive a token from the bank, which can be used to create PSD2 consents at the bank for the TPP users, which are also customer at the bank.

However, when passing via a PSD2 aggregator, how will this onboarding be done?

There are 3 options:

• The communication between the PSD2 aggregator and the bank is always under the ID of the "PSD2 Aggregator" (which is an onboarded TPP at the bank). This means however that customers can’t properly manage their consents anymore within their bank’s online banking, as they only see consents linked to PSD2 aggregators and not linked to the TPP they are actually interacting with (normally the "PSD2 Aggregator" is a hidden process in the background for the end-customer).

• The communication between the PSD2 aggregator and the bank is under the ID of the TPP (having direct contact with end customer) and banks have an agreement with PSD2 aggregators that the due diligence done by the PSD2 aggregators suffices for the bank, allowing the "PSD2 Aggregator" to onboard as many TPPs as they want at the different banks. This is the most convenient situation for all parties, but exposes banks at a big risk as ultimately, they are still liable for usage of their PSD2 services.

• The communication between the PSD2 aggregator and the bank is under the ID of the end-user facing TPP, but each TPP still needs to onboarded at each bank it wants to use via the aggregator. This option reduces however the advantage of a PSD2 Aggregator as TPPs still need to do a whole effort to onboard at all banks.

For me, none of the 3 options seems to meet all promises made by PSD2 (i.e. easy, cheap access of TPPs to account data and payments, with end-customer in full control of which party can see/do what).

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

Multiple banks request the creditor account number when onboarding a TPP (as part of the TPP due diligence), while others require the definition of the creditor account number as part of the consent creation. Both approaches make sense from a security perspective, as there is less possibility to manipulate the creditor account number when making a PSD2 payment call (if creditor account number is part of the HTTP body of the payment request, it is very susceptible to man-in-the-middle attacks).
On the other side, this restriction also limits strongly the use cases a TPP can implement on top of PSD2. A typical use case, where a TPP assists an end-customer to pay his invoices and bills (e.g. via OCR), requires of course each time a different creditor account and would not be possible when this restriction applies.

Question 9: Signing of a PSD2 payment transaction

According the PSD2 SCA requirements, a PSD2 payment from TPP needs to be signed as soon as it surpasses a certain amount or risk level defined by the bank. At that moment the customer would need the specific authentication mechanism of the respective bank to authorize the payment. As it seems now the limits for signing a payment are relatively low, most payments would still need signing at bank side, which reduces the advantages of a PFM tool or account aggregator (i.e. hiding the specifics of each bank) considerably.

Furthermore how the process flow will look like, when more complex signing is required (e.g. when multiple signatures of different people are required), is not very clear.

Question 10: Real-time nature of a TPP

Customers are acquainted with real-time systems, alerting users real-time about certain events. Many PSD2-based account aggregators and PFM tools have such mechanisms in mind (e.g. alerting customer when current account surpasses certain limits), but to avoid too large delays (between the event and the alert), ideally an event-trigger mechanism (a publish/subscribe model where a TPP subscribes to receive every update on a specific account) should be in place, but this is not foreseen in PSD2.

If TPPs still want to approach this real-time nature, they will have to continuously poll the bank APIs to identify updates. This brute-force mechanism will likely be the chosen technique, as PSD2 APIs need to be exposed for free by the banks (even when TPPs consume very high volumes). This will ultimately lead to very high traffic of API calls, without much added value, bringing extra costs for banks. A review of the model would be required to avoid such an "abuse" of the bank’s PSD2 APIs. E.g. forcing TPPs to pay a small amount per PSD2 API call or limiting the total number of PSD2 API calls per TPP per day/week/month. It is unclear however if a bank can enforce such limits within the PSD2 directive.