Based on our experience (we currently natively support Open Banking UK, Open Finance Brasil, Consumer Data Rights, Financial Data Exchange and more) we know that constructing an Open Finance/Banking/Data system from the ground up can be a challenging endeavor, prone to errors.
Rather than being burdened by security requisites, you can leverage the functionalities of our FAPI-certified Authorization Server and channel your attention towards defining business logic, modeling consent structure and user experience.
In this blog post, we will focus on how to build Open Banking and store consent in external service of your choice. Before deep dive, let’s recap what are the key actors and how data is shared in Open Finance ecosystem.
Open Finance Actors
The actors in Open Finance ecosystems typically include a variety of entities and organizations that play different roles in facilitating open data services and transactions. These actors can vary by region and specific implementation, but here are some common ones:
TPPs (Third Party Providers)
External companies that leverage the open data APIs to develop new financial products and services that rely on access to customer account information and payment initiation capabilities.
Individuals and businesses are the end-users of Open Banking services. They can access their financial data, make payments, and use various financial products and apps offered by TPPs.
Financial Institutions (FIs)
These are Banks, Credit Unions, and other Financial Institutions that hold customer accounts and provide financial services. They are required to open up their APIs to enable access to customer data and payment initiation.
Open Finance Data Sharing Explained
Data sharing in Open Finance is a process that allows individuals to grant authorized TPPs access to their financial information and services. Here’s a step-by-step explanation of how data is shared:
User Consent Initiation: TPPs need to initiate the process of getting the user’s consent. Technically, it means that the TPP uses the authorization server’s OAuth
/authorizeAPI that can be used, for example, to initiate the payment on behalf of the users. Users may initiate the consent process through TPP’s mobile app, website, or any user interface provided by the TPP.
Authentication: To ensure the user’s identity, the user typically logs in to their bank or financial institution’s account using strong customer authentication (SCA) methods.
Consent Page: After successful authentication, the user is presented with a consent page.
This page provides details about what the TPP is requesting, including:
- The specific data or accounts the TPP wants to access (e.g., account balances, transaction history).
- The purpose of access (e.g., checking account balances for financial management).
- The duration for which the consent is granted (e.g., one-time access, ongoing access).
- Any additional terms and conditions set by the TPP or the user’s financial institution.
User Approval: The user carefully reviews the information presented in the consent page. They have the option to accept or reject the request for access. This step is essential for ensuring that the user maintains control over their data and who can access it.
Consent Record: If the user grants consent, a consent record is created. This record includes details about the granted consent, such as the scope of access, the user’s identity, the timestamp, and any other relevant information.
Access Token Generation: If consent is granted, the TPP’s application receives an access token from the authorization server.
Data Access: With the access token, the TPP can now access the specified financial data or perform transactions on behalf of the user. Access is typically limited to what was explicitly granted in the consent form.
Revocation and Management: Users retain the right to revoke their consent at any time. They can do this through their bank’s interface or through the TPP’s application. When consent is revoked, the TPP’s access to the user’s data is immediately terminated.
Audit and Monitoring: Robust monitoring and auditing mechanisms are in place to track and analyze data access. This helps ensure compliance with regulations and security standards.
Implement Open Finance Ecosystem
In the integration pattern we are proposing to the customers interested in building an Open Finance solution, a key architectural advantage lies in the loose coupling between Cloudentity FAPI-certified authorization server and consent storage.
Below, you will discover a sequence diagram illustrating the authorization flow, detailing the interactions between TPPs, the Authorization Server, the Consent Page, and the Consent Storage.
Based on the diagram, you can see how Financial Institutions may utilize Cloudentity as a security provider responsible for allowing the TPPs to get user’s authorization and doing so in a secure way.
Request authorization: This step is done using either lodging intent pattern or TPP passing data directly in the flow using various techniques such as: essential claims / dynamic scopes / RAR.
Authentication: How users authenticate is out of scope of this integration, but you may:
Consent Page: After authentication, the user is redirected to external Consent Page configured in the authorization server.
Consent Storage: Upon consent approval, the consent record is created in an external system the of your choice. The unique consent id is passed back to authorization server to issue access token bound to the consent.
Why Cloudentity as Open Finance Authorization Platform
Cloudentity already provides out-of-the-box compliance with security profiles for Open Finance initiatives around the world. We know it - building your Open Finance ecosystem is not easy and that’s why we think you should focus on what matters the most - your user journeys, business models, consent APIs.
Financial Institutions that wish to take part in an Open Finance ecosystem or build one themselves can utilize our Generic Open Banking workspace profile.
It complies with Financial-Grade API (FAPI) requirements. It can be used to integrate custom consent pages.It can easily enforce RAR, PAR, supports all OAuth and OIDC flows, major extensions, and more.
Try It Now
Get a free tenant, try the demo for the Generic Open Banking workspace, and explore how Cloudentity can help you create your Open Finance ecosystem from scratch.
Building a generic Open Banking solution with an FAPI-certified Authorization Server is a complex but rewarding endeavor. This article provides a comprehensive roadmap, highlighting key considerations and best practices to ensure the success of your Open Banking venture. By following these guidelines, organizations can harness the power of Open Banking to deliver innovative financial services while maintaining the highest levels of security and compliance.