What is Open Banking?

Open Banking is the practice of consumer-initiated, secured and explicitly approved data sharing among financial institutions, investment companies, and third-party financial service providers.

Privacy & Data sharing benefits both customers and banks. Customers get better, faster, and more secure access to services offering financial transparency and streamlined journeys, from account setup and payments to financial and third-party products purchases while protecting what data they share Financial firms gain significant insights about classes of customers and services as part of Know Your Customer ( KYC) initiatives. Firms can use a data-driven approach to provide other useful information or facilitate access to other services at customers’ fingertips. Open Banking protocols, such as PSD2 and FDX, set the stage for powering new and future B2B2C applications by providing a mechanism from which to incorporate third-party services into a standards-based and secure data exchange ecosystem.

At a high level, Open Banking is about facilitating multiparty data exchange and secured transactions. It involves four participating actors:

• Data and Transaction Provider – This is the bank or financial institution that is holding or managing consumers’ financial assets like checking or saving accounts, investment portfolios, loans, and mortgages.
• Data recipient or 3rd party transaction processor – This is a 3rd party financial institution or a Fintech application provider that is receiving information about consumer’s financial assets or initiating financial transactions like payments or wire transfers.
• Trust Broker – Centralized Open Banking Registry, acting as a governing body facilitating trust among Data Providers and Data recipients.
• Data (Financial Assets) Owner – This is the consumer, usually a client of both Data Provider as well as Data recipient, wanting to integrate both securely.

One Foundation – Regional Standards

Different versions of the emerging financial enablement regulations exist in different regions: FDX – the USA, CDR – AUS, OB – GBR, BRA. All regional rules are strict and precise about the proper security of financial APIs. All security profiles around the world have much in common; most importantly, they each use the OIDF’s Financial Grade API specification (FAPI) as-is or as a foundation for their regional security profile.

Open Banking Process

Each of the Open Banking interactions can be divided into the following categories:

1) The initial establishment of trust between the organizations involved in data exchange

2) Consent of the data owner or financial assets owner to share data or initiate a transaction

3) Secured data exchange or secured open banking transaction

Technology Needs

To facilitate this process, any Open Banking initiative requires the following capabilities:

API Management – Open Banking initiatives are all about the standardized interoperability achieved by implementing RESTful-based Application Programing Interface (API). These APIs enable the participation of the different actors that are part of the Open Banking ecosystem in secure data exchange. Each Open Banking exchange participant needs to either consume or serve the API set defined by the standard. On top of the management of the API lifecycle (design, development, deployment, and operations), institutions are also required to provide detailed reporting regarding API use.

API Security – each Open Banking transaction must be checked and verified before being processed. These verifications, checks, and balances touch each layer of the networking stack, from simple protocol validity verification through mutual TLS enforcement to confirmation of the consented scope of the Open Banking transaction against the actual operation.

Customer Consent – One of the most crucial considerations in Open Banking is incorporating customer privacy and consent. Whether to meet data privacy regulations or boost user trust, financial institutions must provide customers the ability to stipulate how their sensitive personal and financial data is to be used and shared. Depending on the user, service, and data privacy obligations, Open Banking consent management covers personal data collection, access, sharing, redaction, protection, subject inquiry response, usage audit, and destruction. So far, each of the Open Banking initiatives have adopted a slightly different approach to consent design to make it applicable to the regional requirements, laws, and financial model. However, regardless of the region, all Open Banking standards have one thing in common; the consent model is tightly coupled into the authorization and security mechanism, making it challenging to implement Open Banking on top of the traditional Identity Provider products and solutions.

Identity Orchestration – Open Banking requires the orchestration of identity for both consumers (people) and identity for services and applications participating in the Open Banking ecosystems. From consumers’ perspective, integration with existing identity pools and strong authentication is required, which can be achieved using well-established federated identity protocols or bespoke integrations. On the other hand, the service and machine identity is a much more challenging task that requires integration with 3rd party trust providers (national central banks or registry) to facilitate:

• securing the initial registration,
• machine/service/organization identity assignments,
• machine authentication for the applications, mobiles apps, services, and devices participating in the data exchanges,
• enforcement and verification of the identity status based on the adopted lifecycle.

Authorization – Modern authorization is the glue providing trust and security for any of the Open Banking interactions, including but not limited to:

• orchestrating consumers strong authentication,
• capturing and verifying the consent to share the data between the involved parties,
• providing the security and enforcing the trust as part of the Open Banking transactions.

The Financial API-based set of requirements and implementation guidelines around OAuth2/OIDC Security Profile and Secure Token Service capabilities provides a secure way of authorization delegation between bank APIs, bank consumers, and Fintech applications.

Accelerating Open Banking

Looking at the capabilities listed in the previous chapter, it’s impossible to find one solution to address all of them. That’s why Cloudentity and Google are partnering to deliver a unified solution to address the Open Banking requirements and provide a simple solution that can be rapidly adopted and integrated.

Cloudentity provides a flexible and scalable solution for modern application authorization, consent, and identity orchestration to enable Open Banking initiatives within an enterprise’s existing hybrid, multi-cloud, and microservices infrastructure. The approach ensures continuous authorization and personal data privacy for the high-value, sensitive information in the care of financial institutions.

Through Cloudentity’s cloud-native authorization fabric, financial institutions can decouple identity and authorization, orchestrate service and app on-boarding, enable fine-grained authorization policy as code, assure privacy consent, and integrate with API management products to gain transaction-level enforcement at hyper-scale.

Google Apigee provides robust, flexible API Management and API Security platform enabling Open Banking facilitators to rapidly design, build and operate a set of Open Banking APIs.

The previous chapter identified three primary stages of the successful open banking interaction: trust establishment, consumer consent, and open banking transaction.

Let’s dive into each of them:

1) Trust Establishment

This flow may differ based on the regional regulations; however, it usually involves the central directory (the registry) responsible for brokering the trust between the Data Recipients (Fintech Applications, financial data consumers) and Data Providers (Banks, financial data providers).

To successfully broker and enforce trust between the Fintech application provider and Financial Institution, most Open Banking initiatives utilize the Dynamic Client Registration (DCR), also secured by the cryptographically signed document (Software Statement) describing machine identity used to interact with the Financial Institution APIs. Therefore, the outcome of the above exchange is a secured registration of the machine identity represented as an OAuth Client.

Applying combined Google and Cloudentity solutions, customers can take advantage of the unique Open Banking profiles with DCR implementation and registry integration targeted for the specific regional requirements. Thanks to this approach, there is no need to code custom DCR verification logic nor manipulate the DCR request; Authorization Control Plane will automatically decode, verify the request, create the requested client, and propagate the necessary OAuth client metadata to the integrated Apigee instance.

Looking closer at the steps in the above exchange:

• • Fin-tech provider enrolls its organization with the central Open Banking Registry. This process varies depending on the Open Banking jurisdiction.
  • After successful verification and enrollment, the Fin-tech provider obtains a set of keys and certificates and the Software Statement representing his offering (Service, Mobile App).
  • Having a valid Software Statement, Fin-tech initiates their application or service registration using Bank’s DCR endpoint. Depending on the regional implementation, there might be a need to enforce the mTLS communication; this can be done directly by ACP or orchestrated and verified by Apigee. In the case of the 2nd option, Apigee checks and injects the origin’s client TLS certificate to ACP as an HTTP header.
  • As part of the DCR logic, ACP verifies the validity of the Software statement based on the regional requirements and provisions the service identity in the form of the previously mentioned Oauth2 client record.
  • ACP returns the client Id and required client metadata back to the Apigee proxy, where this information is also recorded as an Apigee application (Apigee has to be aware of the OAuth client identity to properly audit and report on API activity from that application)
  • Fin-Tech provider receives the Oauth2 client id as well as all necessary metadata. This service identity is used in all of the subsequent interactions with the Bank.

2) Data Owner Consent

In the Fintech application, the user initiates a request for information from a particular bank. If this is the first time the user requests information from a specific bank, the application prompts them to select a bank to be connected to. 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).

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

After successfully finalizing the consent authorization request and consent process, the Fintech application receives a unique Open Banking OAuth access token enabling interaction with the Bank’s API. In this flow, the consumer’s journey starts with the Fintech app and is then redirected to Bank’s Authentication and Authorization platform to facilitate a secured consent grant.

The diagram below represents the example systems’ interactions in a bit of a detailed view:

Let’s dive into it:

1. 1. The user interacts with the Fintech application and initiates the request to connect it with their Bank
   2. The application registers the intent with the Open Banking Authorization platform. This step can be handled utilizing different patterns; currently, the most popular use is logging intent pattern with explicit intent registration (Open Banking UK, Open Banking Brazil) or implicit intent registration communicated via the authorization request object (Australian CDR). The above diagram showcases the former.
   3. After the successful intent registration, the Fintech application initiates the Authorization request; this can be achieved by value or Pushed Authorization Request (PAR). The essential part here is the request context that includes detailed information on what type of access is requested from a consumer.
   4. After ACP receives the authorization request, it initiates the authentication process (4.1) with the integrated identity provider and collects the information about the authenticated consumer (4.2)
   5. The consumer grants the account and operation-specific consent (e.g., ability to read recent transactions on my checking account). On the diagram above, this step is divided into multiple interactions:
      1. The user is being redirected to the consent application. This application bridged the authorization with Bank’s system.
      2. The consent app fetches the details about the intent context for which this authorization request was initiated, and information about the user accounts that the consumer owns or has control over.
      3. Based on that data, the consent application presents options to grant specific permissions or available accounts.
      4. The consent grant is registered after the successful submission of the request.
   6. After consent is granted, Authorization Control Plane is ready to mint the token that meets all Open Banking requirements, including but not limited to usage of pairwise identifiers, the inclusion of the intent id, and TLS certificate fingerprint of the requester. Let’s take a look at each step of that process as well as the integration between Apigee and Cloudentity.
      1. ACP generates the Open Banking token in JWT format that includes all the necessary claims.
      2. The token is being provided to Apigee OAuth proxy,
      3. Apigee generates the opaque version of the token and stores the original token and the metadata in the local store. This token exchange allows Apigee to perform the first layer of verifications and authorizations in the Open Banking transactions phase.
      4. The opaque version of the token is provided to the Fintech application

3) Open Banking Transaction

After establishing the trusts and obtaining the data owner’s consent, it’s finally time to perform Open Banking transactions. In the previous step, the Fintech application acquired the access token bound to the application identity and consumer consent. Thanks to this token, the Fintech application can perform the transaction. An example of such a transaction would be fetching the list of the most recent financial statements or account balances that can be processed. The outcome of that data processing can be provided back to the consumer.

The most critical part of the flow represented below is step number 2. This is where Data Owner (financial institution like a Bank) is obligated to verify not only the validity of the token but also if the request corresponds with the granted consent and if the token used to verify that transaction was initially issued to the same entity (more about it below).

In addition to the above verifications, the financial institution must check the status of the data recipient application against the previously mentioned trust broker (Open Banking registry).

At the end of the above exchange, consumers can utilize services provided by the Fintech application. Examples of such would be expenses tracking, investment analytics, budget tracking, and many others.

The diagram below dives a bit more into the details:

1. 1. It all starts with the fintech application initiating the open banking transaction. Let’s assume it’s a request to obtain the details about the most recent financial operations on the consumer’s primary account to anchor this flow a bit. As part of the request, the fintech app provides a previously obtained opaque access token and a client certificate corroborating its identity.
   2. The Apigee API gateway intercepts the request in an accounts proxy established to protect and orchestrate any Open Banking operation on accounts. First, it verifies the identity of the client, validity of the token. After that initial pre-check, the following steps are being executed to authorize the request.
      1. Apigee internally exchanges the opaque token for the JWT token that was originally minted by the Cloudentity Authorization control plane
      2. The JWT token is being introspected against ACP to verify if it’s still valid
      3. Apigee also verifies and introspects the consent connected to that token; as an outcome of that operation, ACP provides details regarding what type of access was granted for this specific token. This information includes what accounts data consumers agreed to share and what is the scope of the granted permissions ( example, “Transactions Basic” vs. “Transactions Detail”).
      4. Having the details about the granted permission, Apigee now can verify if the request matches the given consent and
      5. proxy the request to Bank’s system to obtain the data.
      6. Additional verification is performed on the response data to verify if the data returned to the Fintech application includes only information that the consumer agreed to share.
   3. After meeting all of the verifications and requirements mentioned in step 2, Apigee assembles the response and provides the requested data back to the Fintech application.
   4. Fintech app processes the data and provides the requested information to the consumer.

Summary

In order to take advantage of Open Banking, you will need a solution that can accelerate your program. Apigee provides the best-in class API Management and Security as well as Cloudentity’s complete end to end approach for authorization and consent management (including regional regulations) into one integrated product. To learn more, read the Google blog "Consensual Embedded Finance is safer and more fun" and visit Apigee and Cloudentity.