Customers and the Data Chain: Retrieving data

null
Jack Wilson, Head of Public Policy
26 Mar 2020
interlocking data chains

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 blog series 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. Part I is about the ‘data retrievers’ — account information services providers, and the technical service providers they work with. Stay tuned for part II.

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?

Infographic
The data chain describes the flow of customer data once it is retrieved from the bank

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)

Infographic
AISP consent

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:

Product Demo
Revolut's consent screen

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.

Infographic
Data retrieved by a technical service provider (TSP)

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:

Infographic
Consent given to an AISP when a TSP is involved

More to come

In this blog, we’ve covered the two actors that can be involved in retrieving data from a customer’s bank account. We’ve demonstrated that strong protections exist to keep data safe, secure and managed in accordance with the customer’s instructions.

Stay tuned for Part II of this blog, where we’ll be covering the next links in the data chain after data has been retrieved. We’ll look first at agents and then at ‘third party providers not providing AIS’, and we’ll conclude with an examination of GDPR.

TrueLayer delivers a secure, transparent and safe service for its clients and their customers. Contact us to hear how you can be the next strong link in the data chain.

Latest
TrueLayer has won Payments Innovation of the Year at the 2024 FSTech Awards
15 Mar 2024

TrueLayer wins Payments Innovation of the Year at 2024 FStech Awards

money moving in and out of a portal
20 Feb 2024

The essential guide to ecommerce payment gateways

PSR VRP consultation
14 Feb 2024

Our response to the PSR's consultation on expanding VRP

Categories to explore