TrueLayer specialises in providing reliable connections to banks, so our clients can concentrate on putting open banking data to work for their customers. Data retrieval is one of our core products. For that reason, we are the first link in what can often be an ongoing data chain.

We’ve written this article for anyone interested in the protections that exist for customers who choose to access their financial data through third-party providers. We hope readers will come away with a clearer view of the different roles of businesses involved in open banking.

Note: In this blog ‘customers’ is used to refer to the 'end-users’ of open banking services.

The regulatory perimeter

A few weeks ago, the FCA added a new page to its website about ‘agents of AISPs’. This included a graphic explaining the ‘regulatory perimeter’ as it applies to open banking providers. The reason: there is still some confusion about the roles and responsibilities open banking provides when handling customer transaction data.

There’s an important reason to get this right. In an open banking world:

Protection should follow the customer at each step in the data chain.

That’s because there can be a number of actors involved at any one time in retrieving data, and making use of it for the customer — these are the links in the chain. There are corresponding rules and requirements for these various actors — which come into play where the links intersect.

Open banking

‘Open’ banking suggests that something has been closed off, or inaccessible. That something is customer transaction data. Banks have historically hoarded this data like sleepy dragons, sitting on treasure 🐉.

It suits banks to have a unique perspective on their customers’ spending habits, incomes, life events. It’s a perfect source of market intelligence and a monetisable commodity. This explains why, while the banking industry has embraced advanced technology in many areas — trading, cloud, AI, even blockchain — it has been trailing behind in the technology of data access.

An end to screen-scraping

Until recently, those looking to put transaction data to work for customers had to make do with ‘scraping’ data, which involves credential sharing — something neither banks nor customers felt comfortable about (see our SCA blog post on this).

Open Banking changed things. It introduced requirements for dedicated data-sharing channels, between banks and third parties.

In the UK, most banks chose to build these dedicated channels using Application Programming Interfaces (APIs). This has many benefits:

1. It allows third parties to access the specific data that customers ask them to, rather than retrieving it in catch-all fashion (as per screen scraping);

2. It does away with credential sharing — instead, customers are re-directed to their banks, and never have to share their banking passwords with anyone else;

3. It allows better control of who can access and retrieve data.

In fact, only companies who are regulated by the Financial Conduct Authority (FCA) or an EU equivalent can request access to customer transaction data via APIs. This is the start of a strong data chain. 🔐

Two complementary regulations break the banks’ stranglehold hold on customer transaction data, while also raising standards around security, consent and data protection — enhancing the strength of each link. These are the:

• Revised Payment Services Directive (PSD2)

• General Data Protection Regulation (GDPR)

What is the data chain?

PSD2 requirements

PSD2 provides a strong legal framework for companies wishing to retrieve data from customer bank accounts. First, the data retrievers, so-called ‘account information service providers’ (or AISPs) must pass the FCA’s licensing process. As part of this, AISPs need to prove that they:

• have robust systems and controls to keep data safe and secure;

• use a specific ‘trust framework’ for identification towards the bank (see our eIDAS article)

• hold professional indemnity insurance;

• have oversight and control over any technical service providers;

• have processes to obtain explicit consent from the customer to access their transaction data;

• are accountable to the customer if something goes wrong. In the UK that means having a complaints procedures in place, and that customers can escalate these complaints to the independent Financial Ombudsman.

PSD2 roles

The FCA’s updated webpage, and its written guidance from 2018, seeks to illustrate the different roles under PSD2. There are several actors in the data chain, with differing regulatory status and responsibilities:

• Account information service providers (AISP);

• Technical service providers (TSPs);

• Agents;

• Third parties not providing AIS referred to in law as ‘another person’.

As the FCA states:

“

More than one business may be involved in obtaining, processing and using payment account information to provide an online service to a customer. However, the business that requires authorisation or registration to provide the account information service is the one that provides consolidated account information to the payment service user (including through an agent) in line with the payment service user’s request to that business.

Role of Account Information Service providers (AISP)

An AISP is authorised to deliver a consolidated view of account information to customers. This can mean either displaying full transactions across accounts to the customer or breaking the data into useful insights (e.g. total balances, incomings and outgoings etc). Once authorised by the FCA, an AISP has the legal right under PSD2 to retrieve customer transaction data from a bank to enable this.

A key safeguard in PSD2 is the requirement for the AISP to obtain explicit consent from the customers before accessing their account. This means the AISP must enable the customer to make an informed decision about whether or not to give access to their transaction data.

ℹ️ Being ‘informed’ means the customer understanding:

• the nature of the service being provided;

• how their information will be used;

• who will have access to the information.

In practice, AISPs obtain this PSD2 consent up-front by using ‘consent screens’ that prompts the customer to make an active choice about access to their data:

The FCA is clear in its guidance that customers do not have to give explicit consent to the bank for it to release the data, only to the AISP.

However, to ensure no unauthorised access, AISPs are also required to send (or ‘redirect’) each customer to their bank provider to provide full authentication, before a secure connection can be established between the AISP and the bank. Current requirements mean that the authentication will expire every 90 days, meaning AISP access will expire at a fixed point without customer action. ⏳

Role of Technical Service Providers (TSP)

If you are already authorised as an AISP and just want to focus on delivering a killer product to your customers, you may want to use TrueLayer just as a ‘technical service provider — TSP’ to help you with maintaining several bank connections.

Under PSD2, TSPs are no different from any other outsourced provider — think of banks outsourcing some of their work to AWS or to app development companies. That means that TSPs do not need to be regulated under PSD2 to be involved in open banking. It also means they will be largely invisible in the customer journey (just as you don’t need to be aware that AWS is involved in your online banking experience).

That doesn’t mean there aren’t safeguards around the role of TSPs. Under PSD2, the AISP is responsible for compliance with PSD2 where account access is outsourced to a TSP. The AISP must ensure that the way it outsources does not impact its ability to comply with regulations. If any problem is caused by the TSP, it is the responsibility of the AISP to make the customer whole again. The TSP and the AISP must also follow additional European Banking Authority Guidelines on Outsourcing. Finally, TSPs need to identify themselves to banks using their AISP clients’ certificates.

Crucially, where TSPs are involved, it also remains the full responsibility of the AISP to obtain and manage consent:

The data chain begins when data is retrieved from a customer’s account either by an account information service provider (AISP), or a technical service provider (TSP), on behalf of the AISP. Now we'll discuss the next links in the data chain: Agents — who provide account information services on behalf of AISPs; and then we examine so-called ‘Third Parties not providing AIS’.

Note: In this ‘customers’ is used to refer to the ‘end-users’ of open banking services.

What are Agents? 🤔

Under PSD2, AISPs may provide their services through agents. Agents are not regulated in their own right, but provide the AISP’s services to end-customers on behalf of the AISP. In the same way that an AISP is responsible for everything done by its TSP, the AISP is also responsible for everything done by its agents and must have systems and controls in place to monitor its agents’ activities. This is reflected in the PSD2 requirement for the AISP to increase the amount of professional indemnity insurance it holds in proportion to the number of agents it has. AISPs must also register their agents with the FCA. TrueLayer’s agents are displayed on the FCA’s register.

Because an agent is not providing account information services in its own right, it is not the agent who should obtain explicit consent to access account data, but the AISP, also known as the ‘Principal’. It is also the AISP (not the agent) that retrieves the data from the customer’s bank, identifying itself with its own eIDAS certificate. All of this needs to happen before the AISP’s account information service is provided to the customer through the agent:

TrueLayer provides a consent screen for its agents to use so that we can collect the end-customers’ consent when we provide AIS through our agents:

A further safeguard for the customer is that under PSD2 rules, an agent of an AISP “cannot provide or purport to provide account information services in its own right.” According to FCA guidance, an AIS agent must be clear to its customers that it is providing the services of an AISP, even where it is doing so through its own platform. TrueLayer works with its agents to ensure this is made clear to customers where account information is being displayed:

The third party not providing AIS

The final ‘PSD2 role’ illustrated on the FCA’s new page is that of a third party not providing AIS, also known in law as “another person.” The legal framework for an AISP to share data with businesses who are not themselves regulated under PSD2 comes from the UK Treasury regulations, which implement PSD2, specifically the definition of ‘account information services’. Under the definition, an AIS can provide services:

“

“Only to the payment service user or the payment service user and another person in accordance with the payment service user’s instructions.”

An example of this role in action would be a bank partnering with an AISP to use the account data to power a lending decision, or a credit reference agency using the data to help calculate a credit score. The critical thing is that the companies partnering with the AISP are not themselves providing consolidated account information back to the customer, so do not need to be regulated as AISPs under PSD2. They are benefiting from being able to access and use PSD2 open banking data via AISPs.

In this model, it is the AISP’s responsibility to obtain consent for two things. First, to access the data under PSD2, and second, to share the data with ‘another person’ who is not doing AIS (i.e. ‘in accordance with the payment service user’s instructions).

Once the data has passed to “another person,” it is no longer the responsibility of the AISP under PSD2. To better understand the protections that continue to follow the customer in this data chain, it is time to introduce GDPR.

GDPR and the data chain

Like any business that handles personal data (transaction data being a good example of this), AISPs must also comply with GDPR and other data protection laws. That means data protection requirements on processing and/or controlling data apply. Whether an actor in the data chain is a processor and/or a controller will depend on exactly what they are doing with the data. This is one example of how legal responsibilities may be assigned in a particular open banking data chain:

Ultimately, under both PSD2 and the GDPR, each actor in the data chain is responsible for keeping the customer data it holds safe and secure. That means that protections continue after data is passed to a business that is not PSD2 regulated.

While PSD2 gives customers the right to complain to a regulated AISP, and to escalate that complaint to the Financial Ombudsman, GDPR gives individuals the right to claim compensation from an organisation if they have suffered damage as a result of it breaking data protection obligations. While there is no compensation awarding body for GDPR breaches (unlike the Financial Ombudsman), in the UK, consumers can complain to the Information Commissioner’s Office (ICO), and the ICO can take action against the organisation. Individuals can also make a claim in court, which can decide whether or not the organisation would have to pay compensation, assuming the individual has suffered loss as a result of the breach.

Ongoing chains ⛓

The reality and opportunity of open banking is that customers become empowered to extract their own data from banks and do with that data what they wish.

PSD2 businesses have a responsibility to enable this while keeping customers safe. That means:

• Acting as responsible, secure data retrievers

• Ensuring the data hand-off to businesses inside and outside the PSD2 perimeter is made strictly in accordance with the customer’s wishes and the law

• Only trading with reputable businesses who take their responsibilities under the GDPR seriously

At TrueLayer, we are committed to delivering a secure, transparent, and safe service for our clients and their customers. Contact us to hear how you can be the next strong link in the data chain.