The real game changer of PSD2: PISPs

In the last weeks I had plenty of discussions with FinTech entrepreneurs about the impact of PSD2. So far nothing different than in the months before but I am getting the feeling that more and more entrepreneurs are eagerly waiting for PSD2 APIs in order to make use of the payment initiation feature. These players want to become a Third Party Provider or more specifically a Payment Initiation Service Provider (PISP) under the new PSD2 regulation.

I believe that the rise of new PISPs could be an actual game changer for open banking and financial service industry in general. Services that are reading out bank account transactions and balances, which are called Account Information Service Provider (AISP) under PSD2, have been around for many years: early movers were offering Personal Finance Management (PFM) tools and newer players also doing more specific problem solving than just aggregation. These players had ways of getting the data, and even though the technology like screen scraping was not great, it still worked (but slow).

But PSD2 will help most of them only partially, as for many use-cases not only the current account is relevant but also other bank accounts. These additional bank accounts do not fall under PSD2 and many banks will not provide APIs to offer access to this data. Hence, screen scraping or other technique still have to be used to obtain this data. The benefit of PSD2 for many AISPs? Not so big. Exceptions are of course services around customer identification where one account is completely sufficient.

Payment initiation on the other hand is different: even though payment initiation is also possible with the same technologies as AISP it is way more complex and harder to implement (different TAN methods, account blockage while testing, etc.). Probably also one reason Sofort lobbied for the PSD2 regulation strongly. New PSD2 APIs will make the usage of payment initiation easier and ensure a more stable functionality for the benefit of the end consumer. Additionally, payment initiation only requires access to one single bank account: the current account. Thus, companies that only want to do payment initiation and not intend to read out account information will be able to provide their service while only using PSD2 APIs and do not need to rely on other technologies such as screen scraping for other bank accounts. This will be a huge benefit.

Additionally, to these technical “details” there is one more reason why I believe payment initiation could be a game changer: even though it is not a daily use case, for many of us it is a reason to use the online banking of our bank to execute payments. Speaking for myself I am guessing I am transferring money around 3-4 times per month (mostly paying back lunch expenses to friends / colleagues). But at the moment I have no other choice than use my mobile / online banking app to send the money, even though the experience is not always the best (depending on which bank account I use). With PSD2 APIs I will be able to use PISPs to make this payments execution in a more convenient way. You might argue that 3-4 transfers per month are not relevant, but it might be just another step further away from my bank-provided front end.

The technology for this will be there soon, I am exciting to see who are the first players who will be benefiting of it.