This document describes architectural options for providing your customers with a seamless and secure embedded finance solution. To provide this solution, Google Cloud has partnered with Cloudentity in creating a reference architecture that uses Apigee for API management, Identity Platform for user identity, and Cloudentity for authorization and consent management. This document is intended for developers and technical users. It assumes that you're familiar with open banking standards and related specifications including financial grade API (FAPI), and authentication protocols including OpenID Connect.
When a consumer agrees to share their data with a specific entity for a specific intent and time period, this is called consent. User consent and secure access to consumer data is an essential aspect of embedded finance and open banking use cases. If a consumer doesn't trust that their data will be safely shared with third parties, and unless they can easily understand the terms that they've agreed to and can easily stop sharing their data whenever they want, consumers will rarely participate. The architecture in this document uses Cloudentity to help fulfill user trust requirements.
Architecture
In this architecture, a consumer interacts with a third-party embedded finance application. The application makes secure requests to a financial provider's APIs which are managed and published by Apigee. Apigee coordinates user authorization and consent activity with Cloudentity, and it also proxies communication to the financial provider's backend APIs and systems. The following diagram illustrates the architecture:
The architecture includes these primary components:
API management platform: Banks and financial provider products and services are often made available to other parties through APIs. Therefore, the fundamental first component of this solution is an API management platform.
An API management platform lets you design, secure, analyze, and scale APIs anywhere with visibility and control. An API management platform can handle communication and orchestration with multiple backend systems, including caching of information where applicable. Apigee is Google Cloud's full lifecycle API management platform, and providers can use it to securely expose consumer data and other services.
Consent management provider: The second component manages consent that's granted by end users. Consent management refers to these capabilities:
- Checking whether a certain action by a third party is valid according to the consent granted by the end user (for example, accessing an end user's account balance).
- The availability of tools for end users to check existing consent grants, modify them or revoke them, and for financial institutions to perform similar actions on behalf of their customers.
The Cloudentity platform provides the capability for consumer consent management, and registration and management of third party provider (TPP) financial technology (fintech) applications. It also abstracts the complexity of connecting to identity providers, and it provides additional compliance for third-party communication that use FAPI specifications.
Identity provider: The final component is an identity provider (IdP) that's capable of authenticating the end user and establishing their identity. The example architecture uses Identity Platform as the IdP, but you can substitute an IdP of your own choice.
Deployment topologies
If the primary components can communicate with each other, you can deploy multiple topologies for this reference architecture. Connectivity between the primary components can occur over the internet, or through private access networks.
- API management: Google Cloud offers Apigee API Management as a fully managed service. Google Cloud also offers Apigee Hybrid, which lets you deploy API proxies in any public cloud or on-premises environment. Similarly, Cloudentity offers its platform as a globally distributed, public software as a service (SaaS) application. It also provides options for you to deploy instances in Google Kubernetes Engine (GKE).
- Consent management: Consent consumer experience (CX) is important because your customer must be fully informed about the data that's shared according to the consent that they provide. Cloudentity's concept of custom consent application is an extended integration point that provides you with the customization flexibility to develop consent pages that adhere to CX guidelines through various digital channels. This application should have connectivity to Apigee, to retrieve the list of accounts the end-user can choose to include in their consent, and to Cloudentity, to record the consent details. The application can be deployed in Google Cloud as a Cloud Run service.
- Identity: The IdP can be deployed in Google Cloud or on-premises. Most customers already have an IdP to manage their external users. This reference architecture can integrate with any existing IdP.
The following diagram shows the simplest topology:
In this simple topology, Apigee is configured with internet connectivity to backend systems and Cloudentity. The Cloudentity instance is a SaaS instance, and it has internet connectivity to Identity Platform. This topology is simple enough to be quickly deployed and it enables rapid experimentation.
A topology that's more suitable for a production environment deploys Cloudentity within Google Cloud's Virtual Private Cloud. In such a topology, all communication between the three components and the backend services happens through private network access, as shown in the following diagram:
In this production topology, external clients access Apigee and Cloudentity through a global External Load Balancer. For simplicity, the diagram only shows one deployment region.
Component interaction flow
In this architecture, the interaction flow between components helps to ensure that the user data that's exposed by APIs is shared only with authorized TPP applications, according to the user's consent. The following diagram shows the high-level interaction flow; for brevity, the diagram excludes low-level technical and specification details:
The preceding diagram shows the following high-level flow:
- A consumer opens an application to use a TPP fintech application.
- The TPP application initiates an authorization grant flow with Cloudentity, which is acting as the authorization provider for the financial institution.
- Cloudentity verifies the legitimacy of the TPP application.
- Cloudentity redirects the consumer to the IdP that's configured for the institution.
- The consumer completes authentication with the IdP.
- Cloudentity prompts the consumer to provide the required consent.
- The consumer accepts or denies the consent request.
- Cloudentity provides an authorization code to the TPP application to get an access token and a refresh token.
- The TPP application uses the access token to make embedded finance API calls that are protected by Apigee.
- Apigee accepts the API traffic and it verifies the authenticity and validity of the access token.
- Apigee verifies the consumer consent arrangement status.
- If all the preceding checks pass, Apigee allows the traffic to the backend system and serves back the API response to the TPP application.
- The TPP application receives data through the requested APIs and it serves its functionality to the consumer.
Use cases
Embedded finance is when banks and other financial institutions make their products available through non-banking channels. Examples of embedded finance include retailers that offer financing for people buying goods, or a budgeting application that gathers bank transactions to help you categorize and analyze your spending patterns. Finance, or money management, has been embedded into the retailer or into the budgeting experience. Banks and financial institutions use this pattern to enable use cases like the following:
- Extending first party products and services beyond the bank, such as in
these ways:
- Embedding payments into third-party digital or offline experiences, such as paying restaurant bills by using QR codes.
- Offering instant loans or pay later capabilities during checkout with an e-retailer.
- Adding foreign exchange capabilities to small and medium businesses.
- Bringing third-party products and services into the bank's own
experiences, such as in these ways:
- Offering rebranded products to existing customers as an extension of current products.
- Bringing external financial education and advice tools into the bank's existing experience, for example, cash flow forecasting, loan calculators, or personal financial management features.
- Bringing external tools to power banker or operations experiences, for example, a banker calendar appointment tool for customers or credit card rewards platform functionality for servicing.
- Sharing and consuming data with, or from, partners, such as in these ways:
- Meeting regulatory compliance and providing customer data to other trusted parties by using open banking protocols.
- Reducing or eliminating screen scraping of customer data, instead bringing control to customers within applications.
- Consuming third party risk and open banking data offered by other institutions for credit decisioning.
In an embedded finance scheme, there are three primary parties: the financial institution offering their products and services, a TPP that makes use of those products or services, and an end user who is a customer of the financial institution and is interacting with the TPP. The following diagram shows the relationship between these parties:
About open banking
The example use case for sharing and consuming data with, or from, partners is in the data exchange category of embedded finance. This type of data exchange is which is often called open banking. In many countries, this form of active data exchange is mandated by laws and regulations. The following diagram shows what's required for open banking:
The diagram shows the components of an open banking implementation:
- Data APIs: Apigee exposes payment and accounts data to fintech applications based on country-specific regulations.
- Consent APIs: Cloudentity provides consent APIs that are used before data is shared. These APIs are standardized, and the API security profile includes OAuth access control.
- Access control: Google Cloud and Cloudentity manage access controls that offer strong customer authentication.
- Customer journeys: Cloudentity provides consent management portals that follow CX guidelines for consent amendment and withdrawal.
The diagram also shows the interaction between the main parties in an open banking exchange. This interaction includes the fintech application, the consumer, the data holder institution, and an open banking trust registry.
Design alternatives
The following sections describe the possible interaction patterns between Apigee and Cloudentity. The open source code that accompanies this architecture implements interaction pattern one. If you need to improve overall API latency, we recommend that you consider interaction pattern two.
Interaction pattern one
Cloudentity directly handles all authentication, authorization, and consent requests, and it interacts with the IdP as required. In this pattern, Apigee handles all business API requests, and it communicates with Cloudentity to verify that the consent that the end user granted to the API requester (TPP) allows the requested operation. Apigee caches the consent information for the duration of the access token, or until it receives a notification from Cloudentity that the consent has changed or has been revoked. If further requests are received, Apigee can use the cached information to decide whether to allow the request or not.
Interaction pattern two
Apigee acts as a facade to Cloudentity. In this pattern, Apigee forwards all authentication, authorization, and consent requests. Before it returns the response to the clients, Apigee records necessary information like access tokens and consent details. Apigee doesn't dynamically communicate to Cloudentity when a business API request is received. If the consent is revoked through another channel, Cloudentity notifies Apigee, and all the information is removed to prevent further access.
Design considerations
This section provides guidance to help you use this reference architecture to develop an architecture that meets your specific requirements for security, reliability, cost, operational efficiency, and performance. Each of the following sections describes specific considerations for both Apigee and Cloudentity. Where relevant, the sections provide considerations specific to this reference architecture.
Security, privacy, and compliance
This section describes design considerations to enhance the security posture of your embedded finance architecture or to meet additional compliance requirements. As discussed in the Deployment topologies section, when you design your architecture, you should consider the deployment options for all three of the components: Apigee, Cloudentity, and your IdP. You should also consider the connectivity options between them, whether over the internet or through private access.
Apigee
When you configure Apigee, we recommend that you do the following:
- Deploy APIs on specific regions to comply with data residency requirements.
- Consider communicating with backend systems and Cloudentity over private VPC connections.
- Follow Apigee's Securing a proxy recommendations to improve security when you develop APIs.
- Consider using Google Cloud Armor with Apigee to provide multi-layer API security, including mitigation of OWASP (Open Web Application Security Project) top 10 risks.
- Consider using Apigee Advanced API Security to protect your APIs from malicious agent attacks, like bots. Advanced API Security is an add-on and it requires an Apigee subscription license.
- Use appropriate consumer data standards (CDS) in your APIs. The example APIs that are included in the accompanying open source code follow the Australian CDS standard, but you can adapt them for other standards.
Cloudentity
Cloudentity offers default compliance with security profiles that are mandated in many standards, such as OpenBanking UK, OpenBanking Brazil, OpenInsurance Brazil, Consumer Data Standards Australia, FDX, and FAPI. If you don't need to comply with a specific standard, but you're planning to expose your API for consumption to an open or closed ecosystem, you can improve your security posture by adopting one of these security profiles, such as FAPI.
Cloudentity services can be consumed as a SaaS offering or as a customer-deployed offering. The following considerations can help you choose between the SaaS and customer-deployed offerings:
- Cloudentity SaaS:
- Compliance: The Cloudentity SaaS offering has both SOC 2 compliance and ISO certifications.
- Data residency: To adhere to the data locality requirements in SaaS, you can choose from one of the US, EU, or AU regions that's available. There are some integration points between Cloudentity and other systems. And there can be backend, encrypted communication between the Cloudentity SaaS instance and other components over public networks.
- Identity Provider: Cloudentity sends the communication to an IdP to finish the authentication. On successful callback from the IdP, the Cloudentity SaaS instance tries to reach back to the provider for more information as required.
- Consent application: Cloudentity sends the communication to a consent application to capture the consumer consent. This application regularly requires consumer account data. To eliminate any consumer account-related access from the Cloudentity instance directly, we recommend that the application run within the organization's infrastructure. There is token-based trust between a Cloudentity SaaS tenant workspace and the consent application. Cloudentity supports token rotation scheduling. As a best practice, we recommend that you support token rotation with the applications.
- Webhooks: Cloudentity exposes webhooks that can be subscribed to by applications within the organization to see and consume those events. Webhooks usually contain audit events, and calls are secured by token or API key-based authentication. As a best practice, we recommend periodic review of the subscribers and the events that they are subscribed to. Within Cloudentity, the subscription is granular at each event type, and subscribers should only be allowed to subscribe for the minimum data that they require.
Cloudentity customer-deployed:
- Connectivity: If you use an on-premises or private cloud deployment, you can deploy the software on a specific Google Cloud region and configure private connectivity to Apigee and the IdP. Most of the integration points mentioned earlier, like IdP, consent application, and webhooks, can be confined within the private network configuration instead of over public networks.
For more information, see the deployment guide for Cloudentity on Google Cloud and best practices and security hardening of customer-deployed Cloudentity software.
For either Cloudentity offering, we recommend that you do the following to help improve your overall data access security:
- Anonymize consumer data: Consent applications must protect account or other consumer data that is required to be captured. We don't recommend storing account data within Cloudentity. Before other consumer data is stored within the Cloudentity consent management system, it should be anonymized or captured using pairwise pseudonymous identifiers.
- Rotate tokens: Use the token rotation and scheduling functionality.
- Use preconfigured authorization settings: Don't relax the preconfigured Cloudentity authorization server settings for open banking initiatives unless required. If you require another authorization server for another initiative or application access, we recommend that you create another workspace within the tenant instead of relaxing server settings on the profile for open banking initiatives.
- Use single sign-on (SSO): Cloudentity administrator portal access must be connected to existing SSO systems. You can then apply delegated permissions to limit access to administrators.
Reliability
The following information can help you to improve the availability and scalability of your workload in this architecture, and to make it resilient to outages and disasters.
Apigee
To improve reliability, you can expand an Apigee organization across multiple regions. Multi-region expansion allows improvements in the following ways:
- High availability: In case of a regional failure, traffic can still be served by the remaining regions, increasing the overall availability of your APIs.
- High capacity: Additional regions provide extra capacity for serving your API traffic. They also allow space for any unexpected spike in traffic without adding much pressure on a single environment, which can increase the overall capacity of your APIs.
- Low latency: Additional regions can lower the overall transaction latency for clients by serving their requests in a geographically closer region.
For more information, see Expanding Apigee to multiple regions.
Paid Apigee instances have by default an SLA of 99.9% for monthly uptime. You can choose to deploy Apigee instances across multiple Google Cloud regions in an active-active configuration, which allows Google Cloud to offer a 99.99% monthly uptime SLA for Apigee. For more information, see the Apigee SLA.
Cloudentity
Cloudentity provides its SaaS platform capabilities with a 99.99% uptime SLA, as described in the Cloudentity Software Subscription Agreement. Cloudentity workflows depend on certain external systems like identity providers and the consent application. These external systems must be architected and deployed accordingly to meet the overall target SLA. Availability of external systems isn't covered by the Cloudentity SLA.
Cloudentity SaaS is operated as a highly available service with multiple active environments and data redundancy. Cloudentity has disaster recovery plans in place that let you continue to operate normally, except for catastrophic events that are outside of the plan's scope. To ensure seamless business continuity, it's important that participating external systems are also made available in a similar manner.
For customer-managed deployments, a multi-region architecture can be considered with either active-active or active-passive configuration based on RTO and RPO of the organization. For information about deployment options, see Cloudentity Platform Architecture. We also recommend that you size your Cloudentity infrastructure to autoscale based on expected load and metrics. For more information, see Configuring Cloudentity Pods Autoscaling.
Cost optimization
The following information can help you to optimize the cost of running the workload in this architecture.
Apigee
If you're just starting with Apigee, you can choose the Pay-as-you-go pricing model. If you want more predictable costs, you can choose a subscription model such as Apigee Enterprise or Enterprise Plus. For information about pricing options, see Apigee pricing.
Cloudentity
Cloudentity SaaS pricing is consumption based, depending on the number of authorization tokens that are generated within the platform. Per-unit costs decrease as grants increase. Cloudentity's customer-deployed pricing model is the same as the SaaS pricing model. You can use the SaaS platform to reduce the operational costs of managing on-premises Cloudentity software.
If you choose a customer-deployment model for Cloudentity, you also need to consider the costs of deploying it in a GKE cluster. To generate a cost estimate based on your projected usage, you can use the Google Cloud pricing calculator.
In addition to the costs that are related to an Apigee instance and a Cloudentity SaaS instance, this reference architecture uses another billable component of Google Cloud, Cloud Run, that offers a free tier for limited usage. You can use the Google Cloud pricing calculator to generate a cost estimate based on your projected usage.
Operational efficiency
This section discusses some design recommendations to maintain and operate your embedded finance APIs more efficiently.
Apigee
- To help ensure that Embedded Finance APIs are available and performing as expected to maintain uninterrupted service, consider using Apigee API Monitoring.
- To help ensure that your APIs stay up and running as intended, you can use the additional tools provided by Apigee Advanced API Operations. It automatically detects unusual patterns in API traffic—called anomalies—such as spikes in latency or error rate. Advanced API Operations is an add-on that requires an Apigee subscription license.
Cloudentity
The Cloudentity team internally manages and operates Cloudentity SaaS. You can access rich analytics, metrics, and audit events from the Cloudentity dashboard and by using the Admin API. Metrics can be consumed within the target organization using webhooks and API polls from the SaaS platform.
You can connect customer-deployed Cloudentity software to any tool of choice. Cloudentity supports OpenTelemetry, so that you can integrate monitoring and logging tools seamlessly. You can either access raw logs from the clusters, or use the analytics, audits, and metrics APIs to pull information into your SIEM or other systems.
Whether you use the SaaS or customer-managed option, Cloudentity provides fine-grained analytics on response times and success rates through APIs which can be consumed from alerting systems.
Performance optimization
This section discusses some design recommendations that can help you to ensure more efficient performance of your embedded finance APIs.
- Apigee instance location: To minimize latency, locate your Apigee instance in a region (or in multiple regions) that's geographically close to your API clients and backend systems.
Cloudentity instance location: Locate your Cloudentity instance as close as possible to both the Apigee instance and the IdP instance. Depending on the type of Cloudentity service that you use, apply the following guidelines:
- Cloudentity SaaS: Choose a region that adheres to the data locality requirements and is closest to the Apigee instance.
- Customer-deployed: Choose a region that's as close as possible to the Apigee instance, ideally in the same region where the Apigee runtime is located.
Cloudentity recommends that you configure monitoring for endpoint responses and overall system status to continuously evaluate the health of the platform. You can consume Cloudentity metric APIs and status APIs to fit into your monitoring and alerting infrastructures to detect and notify of deviations and issues. For information about monitoring customer-deployed software, see Utilize Performance Metrics Monitoring.
Interaction patterns:
- The sample code that's provided implements interaction pattern one between Cloudentity and Apigee. This pattern relies on Cloudentity managing consents and issuing JSON Web Tokens (JWT). Apigee can independently verify JWTs, but it will check with Cloudentity for the details of the consent (validity, scopes, and included resources) and cache that information for a short period of time. Cloudentity is configured to notify Apigee when a user's consent is revoked, so that Apigee can invalidate the cached information.
- For better overall API latency, you can implement interaction pattern two. In this pattern, Apigee acts as a facade to Cloudentity during the authentication, authorization, and consent flow. This pattern allows Apigee to store all relevant information for issued access tokens and their associated consents. Therefore, Apigee doesn't need to periodically check back to Cloudentity to get the latest information for a given consent.
Deployment
To deploy this architecture, see Deploy an embedded finance solution using Google Cloud and Cloudentity.
What's next
- Deploy a working example of this reference architecture on Google Cloud.
- Learn more about the Google Cloud products that are used in this reference architecture:
- For an introduction to embedded finance, its relationship to open banking, and the importance of consent management, read Managing Consent in Embedded Finance.
- Explore other Google Cloud solutions for financial services.
- For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.
Contributors
Authors:
- Renjith Babu | VP of Solution Architecture (Cloudentity)
- Debora Elkin | Technical Solutions Architect
Other contributors:
- David Rush | Customer Engineer and Apigee Specialist for Financial Services
- Christin Brown | Global Technical Solutions Director
To see nonpublic LinkedIn profiles, sign in to LinkedIn.