Open Finance Customer Consent Flows
This article sheds light on the process of managing consents as defined in Open Finance specifications. It is to help you understand responsibilities of specific OB players in the context of the consent creation and administration. Finally, you'll find here information on methods for managing consents in accordance with OB standards.
Consent Management Overview
Consent management is a key component of Open Finance ecosystems, including Open Finance initiatives and more broad Open Finance initiatives like Consumer Data Right (CDR) or Financial Data Exchange (FDX). It refers to the process of obtaining and managing consent from consumers for the collection, use, and sharing of their financial data.
In Open Finance ecosystems, financial institutions and other organizations are required to implement APIs that allow consumers to manage their consent preferences for their data. This includes APIs for requesting consent, granting consent, and revoking consent.
Consents in Open Finance
Open Finance 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 ecosystem, its participants are required to create and manage specific consents types as defined in OF standards. Properly-processed consents are means of communication between different Open Finance parties allowing for the information exchange between them and, ultimately, their integration.
Note
The compatibility with Open Finance standards requires a specific flow and processing of consents. SecureAuth helps to achieve it by providing Open Finance-enabling features, for example, by allowing the Fintech application to register consents.
Consents Delivery
As specified in Open Finance standards, consents are created and provided by Open Finance 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 Finance flow. This consent, as required by Open Finance 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 Open Finance 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.
Check how SecureAuth Supports the User's Consent Management
To see how the consent management looks like from the user's perspective, see Check the Customer Portal for the sample self-service application that SecureAuth offers in its sandbox.
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.
Check how SecureAuth Supports the Admin's Consent Management
To see how the consent management looks like from the admin's perspective, see Check the Bank Admin Portal for the sample admin application that SecureAuth offers in its sandbox.
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 Finance. SecureAuth provides rich APIs both for creating and managing consents in accordance with Open Finance standards.
Note
SecureAuth uses the same APIs that are defined in Open Finance standards, for example, in OB UK API specifications.
Consent pages built for Open Finance 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 Building the Open-Banking-compliant consent page.
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.
Check how SecureAuth supports the consent management
To find out what applications SecureAuth offers in its sandbox for the consent management, see Check the Customer Portal and Check the Bank Admin Portal.
Check in the Sandbox
You can see how consents are processes in the Open Finance Quickstart that SecureAuth provides on GitHub. Specifically, there are two applications to help you understand the flow and the lifecycle of consents in the Open Banking environment: the admin portal and the customer portal. Exploring the two sample application in the sandbox, you can learn how SecureAuth enables the integration for consent-management purposes.
Another mock application available in the sandbox is the SecureAuth portal itself. It is configured so that its features are in line with Open Finance standards. For example, in the openbanking workspace, the Consent screen function is preconfigured to use the Open Banking consent type.
Get the Quickstart
Navigate to cloudentity/openbanking-quickstart in your browser.
Clone the repository by executing
git clone git@github.com:cloudentity/openbanking-quickstart.git
in the terminal.Start the Open Finance Quickstart by executing
make run-dev
in the terminal.
Check the Customer Portal
Note
Customer portal is an application for the self-service consent management
In your browser, navigate to
https://localhost:8085
to access the customer portal.Log in to the mock portal with the credentials specified in README of the quickstart.
Explore the portal to check what actions you can take as a user and how the application enables managing consents from the user's perspective.
SecureAuth Enables User's Actions on Consents
As a user, you can
Check what application(s) you provided with access to you data and what scope(s) of your data they are allowed to access.
Revoke the permissions you've already granted.
Note
To manage access using the customer portal in the sandbox, you need to have some account(s) and/or application(s) connected therein.
Check the Bank Admin Portal
Note
Bank admin portal is an application for the administrative consent management.
In your browser, navigate to
https://localhost:8086
to access the bank admin portal.Log in to the mock portal with the credentials specified in README of the quickstart.
Explore the portal to check what actions you can take as an admin and how the application enables managing consents from the administrator's point of view.
SecureAuth Enables Admin's Actions on Consents
As a bank admin, you can
Check application(s) that specific users provided with access to their data.
Check types of permissions that specific users provided to particular applications and verify scopes of data they shared with the apps.
Revoke the permissions on behalf of the users.
Note
To manage access using the bank admin portal in the sandbox, you need to have some user account(s) and/or application(s) connected therein.