Open banking data: what is it and what is it good for?

Open banking is an initiative that allows consumers to securely share their financial data with third-party organisations, such as financial technology (fintech) companies and other financial institutions. This data-sharing allows organisations to offer consumers a broader range of financial services, such as personal finance management tools and tailored lending options. 

Open banking involves customers authorising third-party providers easy access to their financial data. Without this free-flowing interlinked data stream, it wouldn’t be possible to offer better products and services tailored to the specific needs of every client.

However, there are still a lot of questions about the types of data shared with third parties and how that trust-based relationship can benefit all parties involved.

In this article, we will discuss open banking data, who can use it, what data is shared in these kinds of interactions and the importance of consent in this whole process. 

Open banking: how do you manage consent?

All the innovations brought about by open banking wouldn’t be possible if consumers didn’t allow third-party providers (TPPs) to access their financial data. To initiate and deliver quality products and services, TPPs need customer consent to secure, filter and process relevant financial information.

Consent management is a delicate matter and one that shouldn’t be taken lightly by any of the parties involved. It requires diligence and a lot of legal and technical know-how, as well as a stable technological architecture.

Contrary to what you might think, managing consent is not as simple as clicking ‘Agree’ or ticking a box. It has to be completed in accordance with rules and regulations like PSD2 and GDPR. The TPP and the bank both need to know that the client has authorised access.

The banking consent model usually works as follows:

• TPP asks the client for consent

• Client agrees and authenticates the agreement

• Both ends see confirmation, and the data from the AISP is transferred to the TPP or from the PISP to the bank

To be clear, this is how things work most of the time. There can, however, be variants to securing open banking consent that can work in different ways.

For example, consider that instead of requesting confirmation or authentication monthly for a recurring payment, the open banking system could simply ask for consent for renewal every 12 months. During this 12-month period covered by the authorisation, there would be no need for monthly client consent to take payments.

A general understanding of how data and information flow during the consent-requesting process is vital to the success and transparency of operations.

This open banking consent flow stems from the setup itself. It starts by clearly indicating that by providing consent, a client will transfer some of their financial data to third-party providers. This allows TPPs to initiate payments or collect certain data.

Of course, every region has different regulations about how authentication should be implemented, but usually, it relies on two-step verification or other universally approved ID methods such as:

• a mobile identification service

• logging into a bank account

• a digital signature

How open banking consent works

In an effort to make this somewhat complex procedure more easily understandable, consent management can be divided into three different phases:

1. Consent Phase:

• the interface relays to the user what information is requested, clearly exposing its purpose and always allowing for explicit opt-out;

• if the user provides consent, they should be informed of the time-bound nature of the permission, assuring they remain in control of their data;

2. Authentication Phase:

• the bank takes over the process and engages the user in authentication methods to ensure data security;

• user identity is verified, reassuring them that the third-party provider (TPP) cannot see their credentials. This stage of the process should be distinct from the TPPs user flow;

• banks should use the same login/credentials process as their online banking to create familiarity and trust;

3. Authorisation Phase:

• The bank relays to the user the information to be shared with the TPP;

• the bank asks the user if they authorise the sharing of account information, always allowing for denial of the request;

• The user response is sent to the bank, with data recorded accordingly;

Consumers must always be aware of who they are providing access to their data, for how long and for what purpose. It’s important to remember that users have the right to revoke their consent at any time.

For open banking, these parameters can be interpreted as follows:

• Who is accessing their data: TPPs identity;

• For how long: number of days

• For what purpose: account details/payments

• Expiration process: when will it expire, and how can the user revoke consent?

Open banking data sharing: how does it work?

Open banking data is usually used as a synonym for the general term “open banking”. This practice allows third-party providers of financial services to access consumer account data and other relevant financial information with their express permission.

From a technical standpoint, the process is completed via designated tools commonly known as APIs or Application Programming Interfaces. The data sharing is monitored and supervised according to existing government regulations, like PSD2 in the European Union or the Open Banking Act in the UK.

However, since these regulations change from region to region, different types of data are being shared as a result of open banking services.

There are typically different layers of security and verification in place during the exchange of data between financial institutions and TPPs. This is done to ensure the transparency and integrity of the process.

The passing of data from one end to the other is completed almost instantaneously thanks to the state-of-the-art technology of APIs, ensuring fluidity, efficiency and security.

Who can access open banking data?

Not everyone can easily access open banking data. To be able to collect such information, with consent from the user, one has to be an accredited data recipient.

To be accredited, organisations must meet specific requirements before they can even be considered to access customers' personal account information.

Corresponding authorities are responsible for approving accredited data recipients in the respective countries and regions. For example, the ACCC (Australian Competition and Consumer Commission) is in charge of open banking data accreditation in Australia.

The responsible entities in each region can provide, modify or revoke accreditation for data gathering. They are also accountable for ensuring the private sharing of relevant data without violating the law.

Of course, regulations are required to clarify what kinds of data can be collected by third-party providers and the security measures they must implement to guarantee the quality of their services. 

What data is being collected by open banking?

The data that open banking third-party providers are gathering can vary according to the local/regional regulations and the services provided.

Regulators typically impose strict limitations on what type of information can be collected. This aims to limit the scope of data collection, ensuring that TPPs access solely what is strictly required to provide the designated financial service.

With this in mind, the most common data points include the following:

• Account holder data (name, surname, etc.)

• Personal code or company code

• Residential or location address

• Merchant category codes or activity codes

• Financial liability (active) information

• Account information regarding deposits and/or securities

• Transaction codes

Sometimes there might be space for the gathering of other information in possession of the financial institution (employment status, place of employment, etc.), but this will always depend on the active regulations.

Open banking: how is your data protected?

As with all open transactions, the security of data is always a top concern. To keep open banking data safe, developers and regulators must work together.

Open banking is already shifting the financial paradigm worldwide, and it shouldn’t be considered a niche concept designed to benefit only some. Instead, we should interpret open banking as a valuable tool to change the way we all look at finance.

In the UK, for example, open banking delivers significant benefits to small businesses, and one in ten digitally enabled consumers is now using open banking. It is only natural, with this in mind, to have concerns about how security mechanisms are being developed and implemented. The industry has striven to prevent malicious actors and cyber-criminals from taking advantage of the open nature of this project. 

There remain, however, three major concerns for both customers and developers:

• Malicious software

• Data breaches

• Hacking

Although financial institutions, third-party providers and regulators are aware and work to keep up with modern-day threats, some challenges must be addressed.

The most obvious one is the standardisation and regulation of open banking data and data exchange, with a more severe impact on developers than on users. Developers have to follow the rules and guidelines closely. Independent regulators audit open banking APIs if they want to keep their licences and continue providing financial products and services. Much of this work was done by implementing PSD2 and GDPR legislation in the EU, now considered the gold standard for all financial transaction-related security.

Enabling open banking consumer data in the right way can also help overcome many challenges. This way, the client is in charge of when and how they wish to provide their information. The TPPs must disclose what they are gathering and for what purpose, ensuring full transparency and privacy for open banking data.

GoCardless and open banking

The first open banking-powered feature in GoCardless is Instant Bank Pay. Instant Bank Pay complements the existing Direct Debit functionality of GoCardless with a simple, convenient way to collect one-off payments. 

Alternative options for one-off payments were previously limited:

• Cards have expensive transaction fees

• Bank transfers offer a poor customer experience

• Direct Debit is not optimised for one-off payments

Instant Bank Pay payments are instantly confirmed, meaning better visibility for you and your customers, less time spent chasing one-off payments, and a smoother customer experience.

Case study: combine instant and recurring payments

For many UK SMEs, Direct Debit holds several advantages as a payment collection method:

• affordable transaction fees, 

• a high level of automation which eliminates late payments 

• strong consumer protections providing customers peace of mind

However, one sticking point has often been the three-day payment cycle which has been problematic for certain businesses that need to see funds clear that day or the next day.

Gravity, a trampoline park business, used to offer customers the option of card payments or Direct Debits. However, card payments meant expensive transaction fees, and Direct Debits took too long to clear the first payment, which meant that customers could use the service then cancel their mandate before a payment went out.

GoCardless was able to offer a combination of Instant Bank Pay and Direct Debit, allowing Gravity to take an initial payment instantly and then reliably collect future payments through Direct Debit.

As a result of using Instant Bank Pay, Gravity was able to:

• prevent subscription cancellations and subsequent revenue loss

• save 50% on transactions fees

• reduce customer sign-up time by 55%

• get 90% of new customers to use the Direct Debit and Instant Bank Pay combination

• make sign-up easier and quicker for customers

Watch the short video on how Gravity used Direct Debit & Instant Bank Pay: