What Open Banking UK Is

Open Banking is a set of standards regulating the process of sharing data between banks, bank customers, and third-party Fintech apps. These standards are enforced by banking law in a given country, in the case of the UK by the British law. Open Banking Implementation Entity is responsible for developing Open Banking standards in the UK.

Open Banking in the UK has a long history, but its current form has largely been shaped by the Second Payment Services Directive (PSD2) of the European Union. PSD2 came to life in October 2015, but the most important changes for payments in the context of Open Banking came into force in January 2018. Since that date, all European banks, including UK banks, must comply with European Union regulations concerning the technical standards for strong customer authentication and common and secure open standards of communication. The UK has always been, and remains, at the forefront of this transition.

Get OAuth, Consent, and API Security for UK Open Banking

Cloudentity comes with an instantly applicable authorization server profile specific to the UK Open Banking ecosystem that can make your solution instantly compliant with the UK Open Banking requirements.

Create Account

Learn More

Open Banking UK Flow

First, let’s take a look at the typical flow for Open Banking UK and see what parties does it define and they interact with each other. For a detailed description of every party, please check the Open Banking Glossary.

• In one of the most typical scenario, the OB flow of actions is triggered by the Fintech application user, who is usually a bank customer.
• The user initiates a request in the Fintech application.
• The application connects to the bank, which is another key participant of the OB flow represented by personas of the bank administrator and the bank customer.
• Last but not least, Cloudentity acts as an enabler for most of the interactions and integrations that take place along the flow.

For a detailed description of every abovementioned participant, please check the Open Banking Glossary.

Integration with the Bank

Cloudentity is an OAuth server compatible with multiple Open Finance specifications, such as FAPI (Financial-grade API) or Open Banking UK.

The key mechanism supported by Cloudentity to integrate with the bank is the use of the custom consent page. It offloads Cloudentity from necessity to retrieve and manage users' accounts, which becomes the responsibility of the bank. The bank needs to implement their own custom consent page, in which the user is asked to grant the account access to the Fintech application.

Read More

For more information on the custom consent page in the context of Open Banking, see

• How consents are managed in Open Banking
• Building the Open-Banking-compliant consent page with Cloudentity.

Open Banking covers diverse scenarios and multiple use cases. However, it’s typically always about the integration of one entity to another for a safe and efficient information exchange. Key processes enabling the OB flow are

• Integration with Cloudentity APIs and bank APIs

• Integration of the bank with Cloudentity

• Integration of the financial application with the bank

• Integration of the financial application with Cloudentity.

Open Banking UK Course of Actions

1. In the Fintech application, the app user initiates a request for an information/action from a particular bank. If this is the first time the user requests information from a particular bank, the application prompts him/her to select a bank to be connected. Next, the application displays a consent page asking the user what data to request from the bank (what data the user wants to share to the app from the bank).

   

   Note

   OB specifications require financial applications to ask the user what data they want the application to request from the bank on their behalf, for example, account details, lists of payments or transactions.

2. Intent registration is performed.

   1. The application connects to Cloudentity and receives client credentials that allow the app to log in to Cloudentity.

   2. Using the client credentials, the application logs in to Cloudentity and receives a token.

   3. Using the token, the application sends information to Cloudentity (ACCOUNT ACCESS CONSENT API) that it needs an access to specific account(s) in the bank.

      Note

      Cloudentity exposes API that allows applications register an intent to access a particular scope of data (consents).

   4. In the response, the application receives ConsentId from Cloudentity.

      Result

      The user’s intent to connect to the bank is registered in Cloudentity.

3. The application redirects the user to Cloudentity to start the authentication of the user.

4. With Cloudentity the user logs in to the bank (authentication) using an identity provider.

5. The identity provider of the bank sends the account consent confirmation and registration to Cloudentity.

6. The user gets back to the application to follow up. Authorization and verification is performed.

7. The application requests a token from Cloudentity. Strong client authentication is performed.

8. Authorization and verification is performed.

   1. Cloudentity redirects the user to the bank consent page. The user defines the accounts to be connected and scopes of data to be shared in the application.
   2. The consent page uses Cloudentity internal APIs to verify the account access consent (to accept or reject the consent).
   3. An authorization code of the application is exchanged for an access token (provided from Cloudentity) using mTLS.

9. The application receives an opaque access token and an ID token from Cloudentity.

   Result

   The application has been integrated with the bank. The application can call API of the bank on your behalf. It can retrieve, for example, a list of accounts or a transactions history.

10. Fintech application makes a call to the bank’s /accounts API.

    Result

    The bank returns data on accounts that the user explicitly agreed to share on the consent page. The app can display the returned data to the user as needed.

Consents in Open Banking UK

Open Banking allows for transparent and controlled financial operations while ensuring the maximum data security and privacy. There are a number of processes and mechanisms behind it with the most evident but perhaps also the most powerful one being the use of consents. The use of consents, which are fundamental for privacy assurance, guarantees that the access to data is always consciously granted by the data owner, with the time and the scope limited as needed. To enable the proper flow of contents in the OB ecosystem, its participants are required to create and manage specific consents types as defined in OB standards. Properly-processed consents are means of communication between different OB parties allowing for the information exchange between them and, ultimately, their integration.

Note

The compatibility with Open Banking standards requires a specific flow and processing of consents. Cloudentity helps to achieve it by providing OB-enabling features, for example, by allowing the Fintech application to register consents.

Consents Delivery

As specified in Open Banking UK standards, consents are created and provided by OB actors to request the users' access to specific scopes of data.

• Financial application (developer) is responsible for creating and delivering the first consent that the user receives after triggering the Open Banking flow. This consent, as required by OB standards, is to ask the user what data needs to be retrieved from the bank and, thus, shared with the application. With these confirmed with the consent, Cloudentity takes care of all required redirects to proceed with the authentication and authorization of the user.

  

• Financial institution (developer), is responsible for creating and delivering the other consent that the user (bank customer) receives. This consent, as defined in OB standards, is to specify what accounts and scopes of data the user wants to share with the Fintech application.

  

Consent Management by the User

The user can manage their consents themselves in the self-service application. Such as application is usually available from the bank website as a customer portal. The use can visit the portal, log in to the account, and check what applications they share access to their accounts with and can revoke some consents.

Consent Management by the Admin

The bank administrator can manage users' consents granted to the Fintech applications in the admin application. Such as application is usually built and provided to the admins by the bank (developers) as an admin portal. In the portal, the administrator can preview all the users' consents and their statuses. If needed, users' consents can be also revoked by the bank administrator in the portal.

Consent Management with Cloudentity

Cloudentity provides a set of features that not only allows the maximum privacy and security of financial operations but also enables Open Banking. Cloudentity provides rich APIs both for creating and managing consents in accordance with Open Banking standards.

Note

Cloudentity uses the same APIs that are defined in Open Banking standards, for example, in OB UK API specifications.

Consent pages built for OB authentication and authorization purposes use internal APIs of Cloudentity to accept or reject the consents.

Read More on the Custom Consent Page

For more information on how the custom consent page works and how to build to your own consent page using Cloudentity, see Building the Open-Banking-compliant consent page.

The APIs for creating and managing consents are provided by Cloudentity out-of-the-box along with complete applications serving the same purposes. Installing Cloudentity, you get a set of easily-integrated APIs to create and manage the user consent.

Fintech App Compliance

The Fintech application, or Account Information Services (AIS) as per the Open Banking UK standard, is a piece of software designed to support financial services and processes. There are a number of fintech app types, for example, financial aggregators - for collecting and organizing your financial information - or payment apps, which enable you to carry out various transactions.

For a Fintech app to be a legit part of the Open Banking ecosystem, the Fintech application needs to comply with the Open Banking standards defined in OB specifications. Again, there are plenty of those with the Open Banking Read-Write API specification as perhaps the most vital in the context of developing Fintech apps.

If you check the spec, you can get a feeling that creating your application according to Open Banking standards might be not that easy. Indeed, it can be tedious and challenging for an individual developer to design and build the application that conforms to all the relevant rules and guidelines defined in the OB specs. Fortunately, there are tools and solutions that makes it easy for you.

Cloudentity makes the Fintech app development process simple and clear by

• Enabling the intuitive configuration environment for your app

• Providing mock Financial apps that you can play with, inspect, and imitate while creating yours

• Provisioning the easily-integrable sandbox with diverse Open-Banking scenarios involving Fintech apps

• And more (see Fintech app with Cloudentity and Fintech-dev essentials).

Fintech App with Cloudentity

Cloudentity offers a number of features that can help you develop and configure an Open-Banking-compliant Fintech application.

Cloudentity offers a dedicated Open Banking UK workspace with multiple features enabling a quick and intuitive configuration of Fintech applications. You can immediately see if your workspace complies with the Open Banking UK standards.

Settings in this workspace are preconfigured to support Open Banking UK standards, for example the use of mTLS as an authentication method is enabled by default. The Open Banking workspace simplifies the way to register and configure your application in Cloudentity so that it authenticates properly and send requests as needed.

Cloudentity tells you if your Workspace complies with Open Banking UK regulations.

Fintech-dev Essentials

Fintech App needs to make a client credentials call to register a new intent. The app gets authorized to Cloudentity API using a FAPI-compliant method.

Note

• Cloudentity sample Fintech apps in the Open Banking Quickstart use the client credentials flow with mTLS.

• For the mTLS authorization, you need keys to be generated. Depending on your country, there are different organizations handling that.

As an alternative to configuring the application for TPP in Cloudentity (OAuth client), you can use Dynamic Client Registration.

After the intent registration, the Fintech app needs to commence the authorization code grant flow and include claim openbanking_intent_id. The authorization code grant flow requires the PKCE extension and mTLS for the token exchange.

Example

See SAMPLE TTP in the quickstart to see how the authorization flow looks like.

Try it out

Had enough of the reading? Register your tenant and spin up your Open Banking workspace in a matter of minutes.

Alternatively, you can try the sample apps locally. Visit the Open Banking Quickstart repository and check out Cloudentity’s capabilities for handling Open Banking scenarios for different countries, including the UK.