PSD2: can my cat now call himself a bank?

PSD2 is set to change the payments world. It’s just not clear how.

PSD2 is an EU directive that, unsurprisingly, succeeds PSD. PSD is the 2007 Payment Services Directive that set out a framework for payment services in the EU.

(A warning for the abbreviation averse: this is going to be an abbreviation-filled ride.)

Much like how a family can outgrow a house, the EU payment market has outgrown PSD. Since 2007, new babies, or rather Payment Service Providers (PSPs: I did warn you), have entered the market. Time, therefore, for a new house: PSD2.

PSD2 aims to create the legal framework for the further integration of the electronic payments market in the EU. It also aims to make payments within the EU easy and secure. And to open up the payment market to new players.

So it begins by categorising the different types of PSP. Two are of interest here: the ‘credit institution’ (i.e. banks) and the ‘payment institution’ (companies authorised to provide payment services).

It then looks to the future by defining types of service provider. We have Account Information Service Providers (AISPs), Account Servicing Payment Service Providers (ASPSPs) and Payment Initiation Service Providers (PISPs).

The PISP initiates payments, the AISP provides account information and the ASPSP provides an account for the customer.

In case we didn’t have enough abbreviations, let’s throw another one into the mix: Third Party Providers (TPP). This one isn’t used in PSD2 itself, but refers to the new kids on the block that offer payment services but not accounts.

PSD2 defines three categories of payment service provider, each with their own role in the payments ecosystem.

Now comes the fun part. The EU has provided the sweet shop: it’s up to the payments world to start playing pick and mix. The different PSPs can, in the words of motivational gurus everywhere, be whatever they want to be.

Theoretically, that is.

Obviously the EU doesn’t want my cat to call himself a PISP. He’s good at cat things but lacks financial acumen. So just as you can’t become a brain surgeon without medical training, you can’t call yourself any of the above without the authorisation of the financial authority in your home state.

But assuming authorisation, in this shiny new payment world a bank can be an ASPSP, PISP and AISP all in one. Or a TPP can be a PISP or an AISP or both. And so on.

However, if a TPP wants to be a PISP, it needs access to the customer’s account to initiate payments, the account that the ASPSP provides.

And this is the bit that has had the banks reeling. Three short sentences change the world as banks knew it (Section 4, Article 36 if you like reading EU directives, and to give them their due, it’s very readable).

Credit institutions are going to have to give payment institutions access to their customers’ accounts.

Although PSD2 doesn’t specify how the banks must do this, the general consensus is that they will release APIs.

Now, if consumers are going to be giving TPPs access to their bank accounts, this has its risks. Hence the need for PSPs to be authorised. In addition, PSD2 increases security. Obviously with another abbreviation: Strong Customer Authentication (SCA), or two-factor or three-factor authentication.

TPP’s will need to be authorized and provide two-factor or three-factor authentication to increase security.

Consumer protection also increases: PSD2 covers ‘one-leg transactions’ (payments where only one of the PSPs is located within the EU), reduces the maximum amount for an unauthorised payment from €150 to €50 and entitles consumers to an unconditional refund for a period of up to eight weeks after payment.

So what does all of this mean for PSPs and merchants?

Well, ASPSPs (i.e. banks) must provide access to accounts (XS2A in case you thought we were running out of abbreviations). All PSPs need to implement SCA before the directive becomes national law on 13 January 2018 (although this has already been postponed in the Netherlands). And as already mentioned, PSPs must be authorised.

As to which roles the existing and new players will assume on the market, this remains to be seen. There are opportunities for new products and services, as well as for collaboration between banks and TPPs. But with no common API standard as yet, this may take some time.

Merchants will need to be aware of the enhanced consumer protection that PSD2 offers: the unconditional refund and charges for unauthorised payments. They will also no longer be allowed to surcharge for many card payments. And although it's the job of PSPs and banks to implement SCA, merchants may need to agree to any changes they make to effect this.

Time will tell whether the directive will make payments cheaper for merchants and consumers.

And where will Ginger be in all of this? Hopefully surfing the wave. But to tell the truth, we’re not sure. What we do know is that our flexible API puts us in a good position to add new products and services to our payments platform, regardless whether we develop them or third parties do. One thing is sure: regardless how complicated the world becomes with PSD2 (and all the new abbreviations), Ginger won’t lose sight of its mission: to take the complexity out of payment integration once and for all.

So if you’ve got any ideas or need help getting your head round PSD2 — or if you just want to say PISP, AISP and ASPSP a lot — give us a call.

List of abbreviations

AISP: Account Information Service Provider. Provides information about payment accounts.

ASPSP: Account Servicing Payment Service Provider. ‘A payment service provider providing and maintaining a payment account for a payer’ (PSD2, Title 1, Article 4, paragraph 17)

PISP: Payment Initiation Service Provider. The name says it all: payment initiation services.

PSD: Payment Services Directive 2007

PSD2: Payment Services Directive 2

PSP: Payment Service Provider (See Title 1, Article 1 of PSD2 for the different categories of PSP)

SCA: Strong Customer Authentication. PSD2 defines this as: ‘an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.’

TPP: Third Party Providers

XS2A: Access to Account

For those new to Ginger Payments, we’re running a modular payment platform to make payment integration easier and more flexible. Come check us out.

Thanks to Joachim de Boer.