An introduction to the basics.
The EU Payments Services Directive (PSD2) was introduced in 2018, building and previous legislation from 2007. PSD2 covers several different areas, including what was a fundamental new concept – open banking.
The idea behind open banking is incredibly simple.
Before PSD2, an individual or an organisation (let's call them a "user") could effectively only access their account through their account provider (such as their bank). So if – for example – they wanted to see a list of recent transactions, the user had to log into their online banking application. Or if they wanted to initiate a payment out of their account, they also had to do so directly through their account provider's application.
What open banking did was to enforce the idea that the account - and the funds held within it - belong to the user and not the account provider. So a user must be able to access and initiate a payment out of that account in any way that they wish. To enable this, all account providers must provide technical access to regulated third parties, enabling them to perform these activities on behalf of a user, without that user having to go directly to their account provider.
Let's pause to define a few important terms. There's a lot of jargon in PSD2, but here are the important things to know…
Some definitions
A payment service user, or PSU, is a person making use of a payment service account. In other words, an account holder.
A payment account is an account held in the name of one or more payment service users which is used for the execution of payment transactions, such as a bank account or an "e-money" wallet.
An account provider, sometimes also referred to as an Account Servicing Payment Service Provider or ASPSP, is an organisation providing a payment account to a user. So this can be a bank, an e-money issuer, or other similar entity.
A third-party provider, or TPP, is an organisation that is authorised to creates apps and services for users to connect to, and initiate payments out of, an account provided by an account provider. There are several categories of TPP (AISP, PISP, CBPII) but that's not important for a general understanding.
So how, according to the regulations, can an account provider allow a third-party provider to access accounts on behalf of a user? Surely this is very well defined? Well… yes and no!
PSD2 states that account providers must provide a dedicated interface, which is an API that is suitable, secure, accessible, and dedicated to this purpose. But the regulations shed very little light on how this should be done, nor do they establish any sort of technical standards or infrastructure. As a result, many different standards and systems have sprung up.
For example, in the UK an organisation called the Open Banking Implementation Entity (OBIE) has defined an API specification and set of standards. A UK account provider can choose to join the OBIE register and/or use those standards for its APIs, but there is no requirement to do so. Another popular standard used in much of the EU is the Berlin Group NextGenPSD2 specification, but this is also optional.
Is that all?
This is where it gets interesting…
Simply having an API – regardless of specification – is not enough. The requirements of dedicated interface are a lot wider. By way of a few examples, an account provider must also;
Check that a third-party provider is correctly approved with their local regulator and has a valid set of SSL certificates when they apply to connect to the account provider and, and also when they make API calls into the dedicated interface
Provide suitable levels of support to third-party providers at all times, without creating any friction or time delays for either registration or use of its dedicated interface
Measure, record and report on uptime and usage statistics at a granular level, right down to each individual endpoint, by day, indicating uptime, speed or responses, error rates and more. This information not only needs to be provided to the regulator on a quarterly basis in a pre-defined format, but it also needs to be published in realtime on an account provider's website
As well as the dedicated interface itself, an account provider needs to deliver a range of resilience services, such as a contingency mechanism that kicks in should a fallback be required
Does this apply to my business?
We're asked this question a lot. Is my product in scope? Well, it depends. If your product allows a user to store funds, make payments (including card payments), and access that account online, then almost certainly. But it's not always that simple.
Many organisations work with some type of sponsor, such as an e-money issuer. In that instance, where does the responsibility lie, and who has to do what?
Take a look at Do I need a Dedicated Interface which addresses these questions and includes a handy checking tool that will guide you to the right answer.
Is it all bad?
Absolutely not!
In this article we've focused on what an account provider must do in order to avoid falling foul of the regulator. But let's not forget that open banking is fundamentally a very good thing.
It places more control in the hands of the user, helping them to better manage their money. If you are an account provider, it makes your product far more compelling, since it can be accessed in a whole new set of ways, helping you to remain top of wallet, front of mind. And that's just a glimpse into the benefits.
Check out this article to find out more.
Fancy reading the regulations?
Be our guest.
The Regulatory Technical Standards of PSD2:
For specific requirements applicable to the interface, see section 2, articles 30-36 (page 15) .
The FCA make the same information available via their website: https://www.handbook.fca.org.uk/techstandards/PS/2021/2021_01/chapter-v/section-2/034.html Article 32 relates to dedicated interfaces.
Do you have any questions?
We've got you covered. Take a look at our FAQs or get in touch with the team at info@tell.money
Comments