UK Open Banking
Learn how the Open Banking UK standard aims at improving the process of sharing data and financial services between different financial institutions.
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.
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, SecureAuth 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
SecureAuth 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 SecureAuth to integrate with the bank is the use of the custom consent page. It offloads SecureAuth 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
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 SecureAuth APIs and bank APIs
Integration of the bank with SecureAuth
Integration of the financial application with the bank
Integration of the financial application with SecureAuth.
Open Banking UK Course of Actions
 |
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.
Intent registration is performed.
The application connects to SecureAuth and receives client credentials that allow the app to log in to SecureAuth.
Using the client credentials, the application logs in to SecureAuth and receives a token.
Using the token, the application sends information to SecureAuth (ACCOUNT ACCESS CONSENT API) that it needs an access to specific account(s) in the bank.
Note
SecureAuth exposes API that allows applications register an intent to access a particular scope of data (consents).
In the response, the application receives
ConsentIdfrom SecureAuth.Result: The user's intent to connect to the bank is registered in SecureAuth.
The application redirects the user to SecureAuth to start the authentication of the user.
With SecureAuth the user logs in to the bank (authentication) using an identity provider.
The identity provider of the bank sends the account consent confirmation and registration to SecureAuth.
The user gets back to the application to follow up. Authorization and verification is performed.
The application requests a token from SecureAuth. Strong client authentication is performed.
Authorization and verification is performed.
SecureAuth 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.
The consent page uses SecureAuth internal APIs to verify the account access consent (to accept or reject the consent).
An authorization code of the application is exchanged for an access token (provided from SecureAuth) using mTLS.
The application receives an opaque access token and an ID token from SecureAuth.
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.
Fintech application makes a call to the bank's
/accountsAPI.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. SecureAuth 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, SecureAuth 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 SecureAuth
SecureAuth provides a set of features that not only allows the maximum privacy and security of financial operations but also enables Open Banking. SecureAuth provides rich APIs both for creating and managing consents in accordance with Open Banking standards.
Note
SecureAuth 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 SecureAuth 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 SecureAuth, see Integrate Consent Screen.
The APIs for creating and managing consents are provided by SecureAuth out-of-the-box along with complete applications serving the same purposes. Installing SecureAuth, 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.
SecureAuth 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 SecureAuth and Fintech-dev Essentials).
Fintech App with SecureAuth
SecureAuth offers a number of features that can help you develop and configure an Open-Banking-compliant Fintech application.
SecureAuth 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 SecureAuth so that it authenticates properly and send requests as needed.
SecureAuth 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 SecureAuth API using a FAPI-compliant method.
Note
SecureAuth 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 SecureAuth (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 thequickstart 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 SecureAuth's capabilities for handling Open Banking scenarios for different countries, including the UK.