What is open banking?

Open banking is a set of regulations and standards. These enable third-party financial service providers to access financial data and initiate payments. Previously, these tasks could only be performed by banks, which stifled competition and potential innovation. Open banking requires banks to offer their data and services through standardised APIs.

TrueLayer's APIs offer a single point of integration that provides access to hundreds of banks across the UK and Europe.

The CMA Order and Open Banking Standard

The development of open banking followed an investigation by the UK's Competition and Markets Authority, or CMA, in 2016. This investigation led to the CMA Order in 2017. The order made the nine largest banks in the UK open up access to their data to third party service providers, as long as the consumer provided consent for them to access this data.

Part of the CMA Order stated that the CMA9 banks had to create and maintain an 'Open Banking Standard'. The standard requires the CMA9 banks to implement secure and standardised APIs. These APIs developed organically through collaboration between banks, fintech companies, and technical experts, and formed the basis of TrueLayer's Data API.

PSD2 regulations

The Payment Services Directive 2 (PSD2) was implemented in early 2018.

After the UK left the EU, it continued to follow the Open Banking Standards, rather than the PSD2. However, the two follow the same overarching principles.

PSD2 introduced regulation for payments services across the EU. As part of this, it defined the roles and responsibilities of each party within a payment.

Roles in open banking payments

Party	Description
Payment Services User (PSU)	An end user, typically a consumer or business — someone who is buying something. They need to provide explicit consent for any financial services to be performed for them (access to their account details or payments).
Account Servicing Payment Service Provider (ASPSP)	Banks that hold PSUs' accounts, also known as account-holding banks. The PISP initiates payments from this account to another account. These are third-party providers who provide access to services and facilitate interactions with ASPSPs.
Payment Initiation Service Provider (PISP)	PISPs are businesses that are permitted to initiate payments for customers under the PSD2. They have approvals and licenses from any necessary local authorities (such as the FCA in the UK), which enable them to initiate payments directly from a PSU's account. Regulated PISPs can initiate payments for PSUs from ASPSPs themselves. If you're not regulated as a PISP, you must initiate payments through one such as TrueLayer.
Account Information Service Provider (AISP)	AISPs are businesses who can access account information on behalf of end users. Like PISPs, they have approvals and licenses from any necessary local authorities, which enable them to retrieve information about a PSU's account. Regulated AISPs can retrieve account information for PSUs from ASPSPs themselves, as long as they have the PSU's consent. If you're not regulated as an AISP, you must retrieve PSU account information through a regulated AISP such as TrueLayer.
Businesses who require PIS or AIS but are unregulated	Businesses who are not regulated can offer payment initiation services, or access account details, for PSUs. However, they must provide these services through a regulated PISP or AISP such as TrueLayer.

This diagram shows how a payment initiation request flows. In layman's terms, it goes from a customer, to a merchant, to a payments provider, then the bank.

Consent

A key part of PSD2 is consent. For PISPs or AISPs to initiate payments or aggregate financial data, the end user must give informed consent for this to happen. According to the PSD2, information around payment initiation must be written in "easily understandable words and in a clear and comprehensible form."

If you use one of TrueLayer's prebuilt authorisation UIs, such as the HPP, EPP, or the iOS or Android SDKs, these include appropriate wording to comply with the PSD2's guidance for payment initiation. If you build your own UI, you need to include appropriate wording for individual payments or VRPs.

When you develop a UI for collecting financial data through the Data API, you can use TrueLayer's auth dialog to ensure you provide enough information for the PSU to give informed consent. If you're regulated you can develop your own authorisation dialog, but look at our recommended designs and wording before you do so. If you are regulated, collecting consent is ultimately your responsibility and liability.

Steps in payment initiation

This flow applies for both unregulated and regulated PISPs, and focuses on the steps of payment initiation impacted by regulation. Extra information is provided after a step where the flow differs for regulated PISPs.

Your user requests for a payment to be initiated through your service as a PISP, which is provided as a request to the /payments endpoint.
If you're unregulated as a PISP, you need to provide payment service user details in your request. If you're regulated, you don't need to.
Your user uses an interface to authorise the payment from their bank account held with the ASPSP.
If you're unregulated as a PISP, you need to include our exmobact wording that explains that TrueLayer is initiating the payment. If you're regulated, you don't need to.
After the successful or failed payment, the interface informs your user of the result of the payment, and providers an ID for the payment, to remain compliant.

How TrueLayer helps

TrueLayer's APIs are a single source that can integrate with hundreds of banking providers across Europe. The APIs are built to handle all possible behaviours, as different countries and banks implement their APIs differently.

If your company is not regulated to offer payment initiation or account information services, TrueLayer is regulated to offer these services. You can use TrueLayer's APIs and merchant accounts to offer a range of financial services regardless of your regulatory status.