Solution guides

Cloudentity, the Open Banking Enabler

Maybe it is the market that drives your institution to become a member of an Open Banking ecosystem, or maybe it is required by law. Irrespective of what the driver is, with the right tools you can achieve compliance faster and with less effort than you think. Learn what is required to become compliant with Open Banking regulations and how Cloudentity accelerates building a compliant data sharing solution irrespective of the jurisdiction.

The Open Banking Compliance Challenge

Regulators impose fundamental rules on the participants of Open Banking 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.

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 Banking solution.

What is Open Banking?

Open Banking is a concept of enabling financial institutions' customers to securely share their financial data with fintech applications. Open Banking becomes a global phenomen and is getting introduced in more and more jurisdictions (countries) around the world. Each jurisdiction defines a legal basis that makes the creation of a local Open Banking ecosystem possible. The objective of the ecosystem is to guarantee seamless data exchange between Data Holders (financial institutions) and Data Recipients (fintechs). To ensure interoperability, security, and open exchange of data upon customer consent, each ecosystem is defined by a set of standards.

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 Banking 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 Banking 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 Banking 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.

Enabling Financial Data Sharing

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

Open Banking Pillars

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 Banking 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 Banking 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 Banking Brazil).

Instantly Comply with Open Banking

Satisfying Open Banking ecosystems’ requirements is not trivial. The compliance timelines defined by the regulators are usually very aggressive. The biggest part of the burden of becoming compliant is not on the data APIs themselves but on handling access control to these APIs, compliant customer consent, and customer journeys support.

We get it, and we know from the experience that with the right tools financial institutions can become compliant quicker than by with use of external open-banking platform. Why?

Financial institutions have huge competences in developing APIs. Exposure of data APIs can happen much quicker when handled in-house than the integration with Open Banking system delivered by external vendor that comes with the Data APIs.

Open Banking Pillars and responsibilities

With Cloudentity, the time and effort required to become compliant nearly equals time and effort required to expose the Data APIs. That’s the only thing that is on the financial institution side. Cloudentity provides measures to comply with ecosystems’ security model, control access to Data APIs as per regional standards, provides consent APIs, and satisfy required customer journeys. How?

Cloudentity comes with instantly applicable, jurisdiction-specific, preconfigured Open Banking profiles that will make your solution instantly compliant in area of consent, security profile, and customer consent user experience. The key elements that a profile encloses are:

  1. You do not need to worry about implementing advanced access control (authorization and enforcement) tools.

    • We deliver fine-grained authorization (consent) capabilities which means that customers have direct control over the data they share. For example, consent can be limited to one of many customer’s accounts.

    • Cloudentity provides FAPI compliant authorization servers which can be set to a profile compliant with a specific Open Banking directive where your developers, fintech companies, and partners can register their applications, issue tokens for service consumption, and more.

      FAPI? Not a problem

      Financial Grade API is a security and interoperability profile closely aligned with OAuth framework. It becomes a global standard adopted by most of the Open Banking jurisdictions. As Cloudentity is FAPI-compliant, we can easily help you achieve the same.

      If the innitiative your financial institution is driven towards does not require FAPI-compliance, do not worry. Your solution can be easily adjusted to include latest security standards and practices like OAuth grant types, client authentication methods, and more.

    • Cloudentity authorization servers support various OAuth and OIDC authorization grant types and client authentication methods.

    • We can leverage the authentication factors your financial institution uses to fulfill the requirement of Strong Customer Authentication (that some of the directives require).

    • Cloudentity comes with a built-in policy engine responsible for enforcing authorization policies on application and request levels.

    • You get two authorization policies types: Cloudentity policies with a built-in UI editor and OPA policies written in REGO language.

    • You can integrate major API gateways and Service Meshes to discover your APIs within the Cloudentity platform using our Authorizers and enforce all access control measures for your APIs.

    • Use Cloudentity multi-tenancy model to spin up multiple authorization servers. If your bank has branches in multiple countries and needs to follow different directives, this is a way to go! Additionally, you can have different tenants for development, testing, and production environments.

    • We provide a developer portal functionality that allows the developers to register and manage their client applications. Additionally, applications can be dynamically registered with the use of Cloudentity APIs compliant with various OB reforms.

  2. You can use Cloudentity Consent APIs compliant with Open Banking UK, Open Banking Brazil, and Australian Consumer Data Right reforms.

    • You do not need to develop APIs like getting consents, accepting or rejecting consents, revoking consents, and more. They are ready at hand and you can start building consent pages right away.

    • We support various strategies for acquiring consent including redirect flows, decoupled flow, CIBA, and app to app method.

    • We deliver a fine-grained consent application that you can easily integrate with. For example, you can fetch customers accounts that are displayed on the user’s screen. You can brand the consent application or adjust it in any way with ease - it’s Open Sourced!

    Need a Sandbox? Check out Open Banking Quickstart Project

    Cloudentity delivers Open Sourced Open Banking Quickstart GitHub project that you can use when creating your applications for a better understanding of how the Open Banking data sharing flow works and how you can integrate with Cloudentity platform.

    The Open Banking Quickstart project simulates an Open Banking ecosystem that consists of data recipient’s fintech application (Financroo) and financial institution (Go Bank). Go Bank exposes OB Data APIs and utilizes Cloudentity for user consent and authorization to enable access to APIs to fintech applications. The quickstart lets emulate read and read-write Open Banking scenarios that show how Cloudentity supports these flows. In particular, it lets understand the concept of sample consent application that renders custom fine-grained consent page that becomes part of the OAuth flow.

    Sounds interesting? Spin up a Docker container with your own sandbox: Open Banking Quickstart

  3. Elevate our support for customer journeys.

    • We implement our solutions for customer journeys according to the Customer Experience Guidelines and Principles of a given directive.

    • Journeys we support include data sharing with redirect flows, decoupled flows like CIBA, or embedded strategies that leverage Strong Customer Authentication.

Ready? Join Us on OB Journey

To get you started with enabling your institution to become Open Banking compliant, we identified some steps that irrespective of the jurisdiction you may take first. For instructions, see the Open Banking Enablement Journey Quickstart article.