What Open Finance Is

Regulators impose fundamental rules on the participants of Open Finance ecosystems. Each participant must comply with a set of standards that define interoperability and security within the ecosystem. Each participant must stick to the rules related to user consent, as well as align with local customer experience guidelines (e.g. UK’s CX Guidelines) to make the sharing of data seamless and secure.

Get OAuth, Consent, and API Security for Open Finance

Cloudentity comes with instantly applicable, jurisdiction-specific, preconfigured Open Banking profiles that can make your solution instantly compliant in the area of the security profile.

Create Account

Learn More

Although the rules and ecosystem definitions are similar and refer open standards, each ecosystem is in fact unique and either defines local standards or applies a local profile of open standards. The result is that the final rules that each participant needs to comply with are jurisdiction-specific and go well beyond open standards. It renders the use of generic IAM software that does not cover local Open Banking standards ineffective while building the Open Finance solution.

Customer’s consent grant flow that is fundamental for data sharing is a good example. Customer consent grant must precede any customer’s data exchange between a financial institution that holds data and a fintech app that is about to receive it. The user journey supporting it is almost same in each jurisdiction. The consent screen seems to be pretty regular that customers have seen many times while sharing non-financial data. At first glance, it also seems that such a flow is offered by most of access management software out of the box.

It is important to note that in the generic Open Finance consent grant flow:

• Initiation of the flow is precisely defined and requires the use of advanced authorization capabilities, supporting a mix of open standards’ profiles and jurisdiction defined standards,

• User experience of the flow, the consent screen look and options related to a scope, as well as consent duration are strictly defined by the ecosystem’s user experience guidelines,

• Consent is fine-grained and apart of the scope definition, it requires selection of accounts that imposes integration of consent and access management platform with the data holder’s system,

• Consent grant must be made available to the customer, thus it must be available for retrieval and management through ecosystem-specific consent APIs supporting the jurisdiction specific consent model.

Financial institutions building a solution that lets them join the ecosystem shall ensure that consent and authorization platform they select is built for Open Finance ecosystems and lets them focus solely on the exposure of data via data APIs.

Huge Growth Scale

Open Finance ecosystems grow at a huge scale. Individual components not only must be able to integrate with one another, but they also need to scale. For example, when UK Open Finance marked 4th year milestone, the cumulative growth of the ecosystem was equal to 4.5 million regular users and noted, for example, more than 500% of increase in the area of online Open Finance payments.

Modern Architecture

When financial institutions prepare their systems to fulfill all the requirements coming from the above four Open Finance pillars, very often such institution needs to make a technological advancement. Financial institutions must be prepared not only to adjust their software to be a part of a microservice mesh, but they must ensure the security and scalability of their solution. Additionally, each component of the distributed architecture must work flawlessly in terms of the interoperability to achieve proper and seamless communication between the system components.

What Open Finance Requires To Enable Financial Data Sharing

Looking at the big picture, financial institutions need to adjust their system in four main areas to become Open Finance compliant.

In short, financial institutions need to expose Data APIs over which data will be shared. Equally importantly, to enable sharing over Data APIs they need to meet Access Control requirements, expose ecosystem-specific Consent APIs, and support the customer consent flows that are part of and support various Customer Journeys required by the ecosystem.

In more detail:

• Data APIs are a set of ecosystem specific APIs exposed by financial institution over which data is shared. Access to Data APIs is reserved to fintechs that are ecosystem participants, registered at financial institution that have been granted customer consent to access the data. API consumption requires authentication with the access token associated with the consent grant.

• Access Control is required to control to access to customer’s data shared over Data APIs. The access control must fulfill regional requirements, meet regional standards, as well as support advanced profiles of open standards required by the ecosystem like advanced OAuth profiles, Financial grade API, mTLS for OAuth, or Strong Customer Authentication. Compliance of Open Finance solution must be certified for support of these profiles.

• Consent APIs and consent screen, consent data model, consent acquisition flow that support regional standards must be exposed by a data holder in every ecosystem. Customers must be able to grant informed, granular, usually time-bound consents that pertain to accounts that user has selected. Consent grants must be available to customer via fintech app and financial institutions APIs for display and management. Parties must be notified about consent grant changes in the way defined by the ecosystem.

• Customer Journeys are defined in each ecosystem. The biggest part of these journeys are precisely defined customer consent flows. Rollout of nearly every Open Finance ecosystem starts with the requirement for support of solely basic read-only journey (i.e. web scenario of sharing accounts information) but in time, support for more sophisticated journeys is required from financial institutions. Advanced journeys require support for various strategies of customer consent grant acquisition. The scenarios span from browser-initiatied transaction authorization with the use of a bank’s mobile app or embedding consent screen into fintechs app boosted with SCA. Each jurisdiction defines specific requirements related to consent screens and information that needs to be displayed. Some jurisdictions also require a capture of certain information during the consent flow, such as taxpayer’s identitification numer (Cadastro de Pessoa Fisica CPF in Open Finance Brazil).