On 14 September 2019 the Payments Services Directive 2 (PSD2) regulation came into full force and concluded a transitional period which started in January 2018.
The regulation makes substantial changes to the payments industry as well as payment operations.
Account Servicing Payment Service Providers (ASPSPs) such as banks, are obligated by the Directive to provide Third Party Providers (TPPs) access to their clients' payment account information when authorised to do so by a client.
Access by TPPs is achieved through Application Programming Interfaces (APIs) allowing TPPs to build cash management applications and payment initiation tools on top of a bank's data and infrastructure. TPPs then may aggregate data from multiple banks, enabling clients to view and control their accounts from a single place.
The regulation also includes tough new security protocols and rules for the transmission of client data over the internet, known as Strong Customer Authentication (SCA).
The European Commission's objectives for PSD2 include:
- Expanding the scope of payments to include international currencies and payments in/out of the EEA territories.
- Changes in pricing due to the mandating of the shared cost principle (SHA) charging option for all intra-EEA payments.
- Changes in complaint handling and regulatory reporting.
- Setting minimum standards for Strong Customer Authentication.
- Creating new classes of financial institutions, TPPs, and enabling their entry to the market.
- Requiring banks to allow TPPs to access their client data and payment infrastructure with the appropriate client consent.
New financial institution
A TPP is a financial institution that is certified and authorised by a National Competent Authority (NCA). Banks are obligated by the PSD2 directive to implement and make available APIs, which will allow TPPs to access account information when authorised by the client. Only the client owner of the account can authorise access for the TPP.
There are two main types of service business model that we expect to be most relevant for our clients within corporate banking.
Payment Initiation Service Providers (PISPs)
PISPs who when authorised by a client, can initiate a payment from a client's bank account and act on behalf of the client in the transfer of funds.
Account Information Service Providers (AISPs)
AISPs who when authorised by a client, can gain access to the client's payment account information, balance and historical transaction data, through the bank's APIs.
Stronger security for users
A key element of the regulation, and the latest to be enforced, is the requirement for Strong Customer Authentication. This ensures there are adequate security protocols in place to authenticate clients when using third party provider services, to authorise account access, and to manage payments. All payments must be authorised by using at least two of the following authentication factors:
- Knowledge (something only the user knows) – for example, a password.
- Possession (something only the user possesses) – for example, a one-time token.
- Inherence (something the user is) – for example, a biometric fingerprint.
A non-bank PISP or AISP will act as an intermediary between clients and their multiple banks. Within corporate banking, treasury management solutions may feature predominantly, but there are many types of organisations that will operate in this space. There is also nothing to stop banks themselves becoming PISPs or AISPs to offer additional products and services.
If you are a TPP
MUFG has implemented the Berlin Group API standard and a detailed document of this specification can be downloaded from the Berlin Group website.
We have created the COMSUITE API Service as part of the requirements in the regulation. This includes a dedicated website (COMSUITE API Portal) for TPPs to register for our API services and a test facility for code development with our APIs.
Within the COMSUITE API Portal a TPP can subscribe to the APIs after successfully submitting an application, which must include the relevant National Competent Authority (NCA) registration number and eIDAS or OBWAC certificate.
For our German clients who use the WEB CMS service, please access the WEB CMS developer's portal.
For our Italian clients who use the CABEL service, please access the CABEL developer's portal.
For our Polish clients who use the BusinessPro service, please access the Business Pro developer's portal.
Read the Quarterly KPI Statistics on the availability and performance of each of our API services.
Should you have any queries about PSD2, registering as a TPP, or requiring technical support for our COMSUITE API Service, please email us firstname.lastname@example.org.