Consent is a Key Component for a Successful Embedded Financial Solution: Read Why
3236
Of your peers have already read this article.
5:00 Minutes
The most insightful time you'll spend today!
When banks and other financial institutions make their products available via non-banks, we call that Embedded Finance. Think, for example, of a retailer offering financing for people buying goods; or a budgeting app gathering bank transactions to help you categorize and understand your spending patterns. The finance – the money management – has been embedded into the retailer or the budgeting experience.
This last example falls under the Data Exchange category of Embedded Finance , and it’s often also called Open Banking. In many countries this active data exchange is actually mandated by law, with specific Open Banking standards encoded into law for all financial institutions. As of this blog post, there are approximately 37 countries with such laws already in place or currently being worked on.
In an Embedded Finance scheme there are three main players: The financial institution offering their products and services, a third party provider (TPP) making 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 most important ingredient for these schemes is consumer trust. If a consumer does not trust that their data will be safely shared with a third party, and that they can easily understand the terms they have agreed to and stop sharing their data whenever they want to, consumers will simply not participate. When a consumer agrees for their data to be shared, this is called consent.
What components do I need for a successful Embedded Finance solution?
Banks’ products and services are made available to other parties via APIs, thus a fundamental component is an API Management platform. An API Management Platform lets you design, secure, analyze, and scale APIs anywhere with visibility and control.
Also, we need a component to manage consents given by end users. Consent Management refers not only to the capability of checking whether a certain action by a third party (eg: access an end user’s account balance) is valid according to the consent granted by the end user to that TPP, but also the availability of tools for end users to check existing consents, modify them or revoke them, as well as tools for financial institutions to perform similar actions on behalf of their customers.
Finally, we need an Identity Platform capable of authenticating an end user and establishing their identity.
A Google Cloud based embedded finance solution uses Apigee as the API management platform, Identity Platform or your own identity platform of choice, and a consent management service (CMS). Google Cloud has partnered with two leading providers in the consent management space: Clarip and CloudEntity.
How do these components work together?
The main roles and responsibilities of each of the three components are quite clear, but there is a certain degree of flexibility on how to orchestrate the interactions between the components, and which component performs which function when there is an overlap of functionality between them.
Google Cloud has tested the following interaction patterns:
- Interaction Pattern #1: Apigee as the main orchestrator
In this interaction pattern, Apigee interacts with both the consent management service and the identity platform, coordinating end user authentication with the identity platform, and authorization and consent with the consent management service. Apigee acts as the “broker” between users, their identity, and their consent.
- Interaction Pattern #2: The consent management service abstracts the identity platform.
In this case, the consent management service manages all the interactions with the identity management platform, and the identity platform acts as the “broker”. Apigee only interacts with the consent service.
The three components share a common pool of client apps and end users. One of the components is typically designated as the source of truth for these entities, while the other components that need to know about these entities synchronize that information from the source of truth.
The identity platform is typically the source of truth for end user identities and the consent management component will synchronize that information by pulling it from the identity platform.
The consent management service is the source of truth for user opt-in and current consent status. Apigee will either check with the service the validity of a consent every time a request comes through, or to make it more efficient, it will validate the main attributes of the consent based on information stored in Apigee. To maintain consistency, the consent management service should tell Apigee to invalidate any tokens associated with a consent when it is revoked via other means (for example, if an end user revoked consent from a consent dashboard).
For client apps, either Apigee or the consent management component can act as the source of truth, with the other component synchronizing the information. In the context of Open Banking in particular, standards often mandate that financial institutions support Dynamic Client Registration. This means having endpoints that new clients can use to register themselves as clients for the Open Banking APIs. In this case, the synchronization of clients can easily be incorporated into Dynamic Client Registration.
Let’s look now into more detail about how the three components interact. There are two user journeys that are particularly relevant:
Authentication/Authorization/Consent
This is the beginning of the typical consumer client journey, when an end user starts using a third party app that requires access to that user’s data. The third party app needs to authenticate itself, and request authorization to access the user’s data. This will trigger the authentication of the end user and consent granting: Consent granting being the process of, the user authorizing the operations the app will execute on their behalf, and establishing the list of accounts on which these operations will be performed. The authorization is represented by an access token, which the app will need to include in all subsequent requests.
This is quite a complex journey with many steps involved in order to make this as secure as possible. To make it easier to understand, we will simplify some of the steps (apologies in advance to you OIDC/FAPI experts out there!).
At a high level, these are the steps involved in this user journey:
- End user starts using an app
- The app requests permission to access user’s data
- The identity platform (IdP) authenticates the end user
- The consent management service obtains consent from end user
- An access token is issued for the app, encapsulating the authorized permissions, accounts, etc. A refresh token is also issued – the access token normally has a short life (measured in minutes), but the app can use the refresh token, which typically lasts much longer (days or months), in order to obtain a new access token without the need of going through the end user authentication/authorization/consent process again.
The way these steps are orchestrated varies depending on the interaction pattern among the components.
Pattern #1: Apigee orchestrates all interactions
When the client requests permission, Apigee will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback URL that Apigee registered in the IdP configuration.
Apigee will then redirect the client app to the Consent Management service, so that the consent form is displayed. Once the user grants consent, selects the desired permissions, and selects the accounts it will apply to, the Consent Management Service will update Apigee with the status of the consent, via a callback Apigee registered in the consent configuration.
Now that the end user has authenticated and granted consent, Apigee can now issue an authorization code, and associate all the necessary information, for instance, details about the consent, the authorization code issued by the Identity Platform (IdP), the identification of the end user in the IdP, etc. Apigee will return this authorization code to the client app via a callback endpoint that the app provided when registering with Apigee.
The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the IdP, abd update the status of the consent before issuing an access token to the client.
Pattern #2: The Consent Management Service is the center of the Architecture
In Pattern #2, Apigee will only communicate with the Consent Management Service, which acts as an authorization server for the app and will also coordinate all interaction with the IdP.
When the client requests permission, Apigee will forward the request to the CMS. The CMS will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback the CMS registered in the IdP configuration.
The CMS then displays the consent form. Once the user approves the consent and selects the desired permissions and accounts it will apply to, the Consent Management Service will return an authorization code to Apigee, via a callback Apigee registered in the CMS configuration.
From now on, the flow is the same as explained above. Apigee will issue an authorization code, associate all the necessary information and will return this authorization code to the client app via a callback endpoint. The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the CMS, before issuing an access token to the client.
Let’s now look at the other relevant user journey:
Access shared data
Once the third party app has been authorized, it will then start requesting that end user’s data. For instance, it may request the list of accounts or the balance of a particular account.
When that request goes through, a series of checks need to be performed: Is this third party app still authorized? Has it been granted the right permission for the operation being requested? Is the account involved included in the list of accounts authorized by the end user? Apigee can perform all these checks by inspecting the access token presented by the third party app.
There is, however, one other check which cannot be done simply by inspecting the token. Imagine for a moment that in-between the user granting consent and the app requesting the user’s data, the end user decided to revoke that consent. This could be done by other means than the app itself, for instance by checking all consents granted to all apps in a consent dashboard accessible via other channels such as an “Internet Banking” site. When the app requests the user data, the token is still valid, however the consent has already been revoked. Therefore, in this user journey, Apigee will check with the Consent Management service to check if the consent is still valid. This adds a bit of overhead, which can be minimized by other means. For instance, one popular optimization is to make sure that the Consent Management service asks Apigee to revoke any access or refresh tokens associated with a given consent when that consent is revoked via other channels. If that guardrail is in place, then Apigee can determine if a request should be allowed simply by validating the access token and using the consent information stored alongside the token.
The following diagram summarizes the interactions required between Apigee and the Consent Management component. The interaction is essentially the same in both interaction patterns.
What’s next?
In this article we have described how Apigee, a Consent Management service, and an Identity Platform are the fundamental ingredients of a successful and secure Embedded Finance solution. We have also looked at how these components interact with each other to keep user consent consistent and available. Both interaction patterns described are valid and have been proven to work. So which one may be right for you? The answer ultimately depends on your particular requirements, the choice of consent management service, and your choice of identity platform. As a rule of thumb, if you have multiple application experiences, identity systems, and sources of consent, an Apigee-centric architecture is a great solution. If you are looking at a Consent Management service in the context of an Open Banking implementation mandated by a centralized authority (eg: Open Banking Brazil, Consumer Data Standards in Australia), CloudEntity is a good choice for consent management, as their product is also Certified Financial-grade API (FAPI) OpenID Provider, with profiles for the various Open Banking standards. CloudEntity integrates with Apigee using Pattern #2.
For more details on both Clarip and CloudEntity’s offerings and how their particular solution works with GCP please check:
- Clarip: Universal Consent Management Platform – GDPR
- CloudEntity: Certified OpenBanking & Consent (UK, Brazil and Australia) at scale
For more details on Apigee API Management, see https://cloud.google.com/apigee
You can also learn about our solutions for retail banking or contact sales.
5 Ways You Need to Know to Reduce Costs with Containers
3177
Of your peers have already read this article.
2:30 Minutes
The most insightful time you'll spend today!
“Cloud Wisdom Weekly: for tech companies and startups” is a new blog series we’re running this fall to answer common questions our tech and startup customers ask us about how to build apps faster, smarter, and cheaper. In this installment, Google Cloud Product Manager Rachel Tsao explores how to save on compute costs with modern container platforms.
Many tech companies and startups are built to operate under a certain degree of pressure and to efficiently manage costs and resources. These pressures have only increased with inflation, geopolitical shifts, and supply chain concerns, however, creating urgency for companies to find ways to preserve capital while increasing flexibility. The right approach to containers can be crucial to navigating these challenges.
In the last few years, development teams have shifted from virtual machines (VMs) to containers, drawn to the latter because they are faster, more lightweight, and easier to manage and automate. Containers also consume fewer resources than VMs, by leveraging shared operating systems. Perhaps most importantly, containers enable portability, letting developers put an application and all its dependencies into a single package that can run almost anywhere.
Containers are central to an organization’s agility, and in our conversations with customers about why they choose Google Cloud, we hear frequently that services like Google Kubernetes Engine (GKE) and Cloud Run help tech companies and startups to not only go to market quickly, but also save money. In this article, we’ll explore five ways to help your business quickly and easily reduce compute costs with containers.
5 ways to control compute costs with containers
Whether your company is an established player that is modernizing its business or a startup building its first product, managed containerized products can help you reduce costs, optimize development, and innovate. The following tips will help you to evaluate core features you should expect of container services and include specific advice for GKE and Cloud Run.
- Identify opportunities to reduce cluster administration
Most companies want to dedicate resources to innovation, not infrastructure curation. If your team has existing Kubernetes knowledge or runs workloads that need to leverage machine types or graphics processing units (GPUs), you may be able to simplify provisioning with GKE Autopilot. GKE Autopilot provisions and manages the cluster’s underlying infrastructure, all while you pay for only the workload, not 24/7 access to the underlying node-pool compute VMs. In this way, it can reduce cluster administration while saving you money and giving you hardened security best practices by default.
- Consider serverless to maximize developer productivity
Serverless platforms continue the theme of empowering your technical talent to focus on the most impactful work. Such platforms can promote productivity by abstracting away aspects of infrastructure creation, letting developers work on projects that drive the business while the platform provider oversees hardware and scalability, aspects of security, and more.
For a broad range of workloads that don’t need machine types or GPUs, going serverless with Cloud Run is a great option for building applications, APIs, internal services, and even real-time data pipelines. Analyst research supports that Cloud Run customers achieve faster deployments with less time spent monitoring services, resulting in reinvested productivity that lets these customers do more with fewer resources.
Designed with high scalability in mind, and an emphasis on the portability of containers, Cloud Run also supports a wide range of stateless workloads, including jobs that run to completion. Moreover, it lets you maximize the skills of your existing team, as it does not require cluster management, a Kubernetes skillset or prior infrastructure experience. Additionally, Cloud Run leverages the Knative spec and a container image as a deployment artifact, enabling an easy migration to GKE if your workload needs change.
With Cloud Run, gone are the days of infrastructure overprovisioning! The platform scales down to zero automatically, meaning your services always have the capacity to meet demand, but do not incur costs if there is no traffic.
- Save with committed use discounts
Committed use discounts provide discounted pricing in exchange for committing to a minimal level of usage in a region for a specified term. If you are able to reliably predict your resource needs, for instance, you can get a 17% discount for Cloud Run (for either one year or three years), and either a 20% discount (for one year) or a 45% discount (for three years) on GKE Autopilot.
- Leverage cost management features
Minimum and maximum instances are useful for ensuring your services are ready to receive requests but do not cause cost overages. For Google Cloud customers, best practices for cost management include building your container with Cloud Build, which offers pay-for-use pricing and can be more cost efficient than steady-state build farms.
Relatedly, if you choose to leverage serverless containers with Cloud Run, you can set minimum instances to avoid the lag (i.e., the cold start) when a new container instance is starting up from zero. Minimum instances are billed at one-tenth of the general Cloud Run cost. Likewise, if you are testing and want to avoid costs spiraling, you can set a maximum number of instances to ensure your containers do not scale beyond a certain threshold. These settings can be turned off anytime, resulting in no costs when your service is not processing traffic. To have better oversight of costs, you can also view built-in billing reports and set budget alerts on Cloud Billing.
- Match workload needs to pricing models
GKE Autopilot is great for running highly reliable workloads thanks to its Pod-level SLA. But if you have workloads that do not need a high level of reliability (e.g., fault tolerant batch workloads, dev/test clusters), you can leverage spot pricing to receive a discount of 60% to 91% compared to regularly-priced pods. Spot Pods run on spare Google Cloud compute capacity as long as resources are available. GKE will evict your Spot Pod with a grace period of 25 seconds during times of high resource demand, but you can automatically redeploy as soon as there is available capability. This can result in significant savings for workloads that are a fit.
Innovation requires balance
Put into practice, these tips can help you and your business to get the most out of containers while controlling management and resource costs. That said, it is worth noting that while managing cloud costs is important, the relationship between “cloud” and “cost” is often complex. If you are adopting cloud computing with only the primary goal of saving money, you may soon run into other challenges. Cloud services can save your business money in many ways, but they can also help you get the most value for your money. This balance between cost efficiency and absolute cost is important to keep in mind so that even in challenging economic landscapes, your tech company or startup can continue growing and innovating.
Beyond cost savings, many tech and startup companies are seeking improved business agility, which is the ability to deploy new products and features frequently and with high quality. With deployment best practices built into GKE Autopilot and Cloud Run, you can transform the way your team operates while maximizing productivity with every new deployment.
You can learn if your existing workloads are appropriate for containers with this fit assessment and these guides for migrating to containers. For new workloads, you can leverage these guides for GKE Autopilot and Cloud Run. And for more tips on cost optimization, check out our Architecture Framework for compute, containers, and serverless.
If you want to learn more about how Google Cloud can help your startup, visit our page here to get more information about our program and apply for our Google for Startups Cloud Program, and sign up for our communications to get a look at our community activities, digital events, special offers, and more.
The Latest in Spring Cloud GCP: Upgrading the Sample Bank of Anthos App
1402
Of your peers have already read this article.
3:30 Minutes
The most insightful time you'll spend today!
We’re excited to announce that Spring Cloud GCP version 4.0 is now generally available! In this post, we’ll be describing what the new major version has to offer, and demonstrating the process of using the migration guide on one of our reference architectures, Bank of Anthos.
What’s new?
With this release, Spring Cloud GCP officially supports Spring Boot 3.x. However, this migration involves a number of breaking changes as outlined in the migration guide. The full list of changes made is available on Github, but the one of the most significant differences is that Java 17 is now a minimum requirement.
Another notable feature of this release is the addition of starter artifacts – Spring Boot starters for Google Cloud – that provide dependencies and auto-configurations for 80+ Google Client libraries. Just as the name suggests, these starters can serve as helpful starting points when working with a new client library. For now, they’re in preview.
These starters are not included in the BOM by default and need to be added as a dependency to your project before they can be used. For example, if you wanted to get started with Cloud Text-to-Speech, you would include the following:
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-texttospeech-spring-starter</artifactId>
<version>4.0.0-preview</version>
</dependency>The upgrade process
We prepared a migration guide to help answer any questions involved with moving from 3.x to 4.x. Let’s follow those instructions to migrate Bank of Anthos.
We’ll start by cloning and building the application before the upgrade, according to the quickstart and development guide:
PROJECT_ID=<YOUR-PROJECT-ID>
gcloud services enable container --project ${PROJECT_ID}
git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos/
gcloud services enable container.googleapis.com monitoring.googleapis.com \
--project ${PROJECT_ID}
REGION=us-central1
gcloud container clusters create-auto bank-of-anthos \
--project=${PROJECT_ID} --region=${REGION}
gcloud container clusters get-credentials bank-of-anthos \
--project=${PROJECT_ID} --region=${REGION}
skaffold run --default-repo=gcr.io/${PROJECT_ID}/bank-of-anthosAt the end of this, you should see a “deployment stabilized” message:
Deployments stabilized in 9.657 secondsWith the environment set up for development, we’re ready to move on to the actual migration. The migration is already complete at time of writing, but here’s the full list of changes made:
- We began by checking the current Java, Spring Boot and Spring Cloud GCP versions.
- Our Java version is okay, but the other two are out of date, and will need to be updated.
We can also add the Spring Cloud GCP BOM to manage our versions going forward while we’re here.
- Our Java version is okay, but the other two are out of date, and will need to be updated.
- Then, in no particular order, we can make the following code changes:
- Remove the explicit type declarations from our ResponseEntity instantiations.
- Replace all javax.* imports with Jakarta.* counterparts, since Spring 3.0 makes use of Jakarta EE 9.0
With those changes in place, the app is upgraded and ready to re-deploy!
Live example
For a finished example of this migration, check out the Bank of Anthos repository on Github. It’s an excellent sample application that showcases a polyglot Java & Python app, served on Kubernetes and Google Cloud. All CI/CD and configurations are open source, so it may be instructive as you approach this migration.
Thanks for reading, and feel free to provide comments or feedback on Twitter, or in the issues section of the repository.
Modernize your Windows Server Workloads using Google Cloud Platform
DOWNLOAD RESEARCH REPORTS6259
Of your peers have already downloaded this article
1:30 Minutes
The most insightful time you'll spend today!
Application Modernization is an important enabler of Digital Transformations (DX), which fuel competitive advantage through increased productivity and business agility. Public cloud infrastructure proves to be a solid foundation for application modernization by providing Self-Service Provisioning capabilities, cloud-based & cloud-native technologies, and easier access to technology innovations such as AI/ML.
Windows Server-based enterprise applications rely on the underlying infrastructure for platform performance, security, and availability. A better performing cloud platform enables them to perform better and hence prove to be more resource-optimized and cost-effective.
Download this IDC report to understand why you should move your Windows Server workloads to Google Cloud and the benefits you can derive.
Upgrade Your Contact Center with Knowlarity’s AI-powered Speech Analytics for Higher CX
DOWNLOAD E-BOOK6217
Of your peers have already downloaded this article
7:00 Minutes
The most insightful time you'll spend today!
Did you know, everyday about 56 million hours worth of phone conversations, equalling to 420 billion spoken words are handled by contact centers? Knowlarity, a renowned cloud business communication service provider with nearly 6,000 customers and over a million virtual users, leverages AI-powered speech analytics that offer insights to gauge customer preferences and emotions, campaign performance, agent’s effectiveness and much more. Knowlarity’s programmatic speech analytics platform is built with Google Cloud to optimize contact center performance by transcribing and analyzing millions of calls to impact savings, operations, CX, customer loyalty and retention, and revenue generation.
Download the e-Book to learn more about Knowlarity’s speech analytics for your business’ contact centers and elevate your agents’ performance by leveraging ML, natural language processing (NLP) and AI capabilities.
A Road to Possibilities: Google Maps Platform Website
7259
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
For more than 15 years, developers have used Google Maps Platform to deliver location-based experiences to their end users and used location intelligence to optimize their businesses. Along this journey, we’ve made a variety of changes to better support our community as needs have changed and new industries and technologies have emerged. We started rolling out a new website experience, at https://mapsplatform.google.com, to help you better understand the products and solutions best suited to address your objectives. Plus, now you can directly connect to the developer documentation for each product to get started quickly, and you can visualize usage and associated costs to have a better idea of what to expect before getting started.
Getting to your solution faster
Maps, Routes, Places are building blocks that let you develop implementations for any use case. Building for specific use cases, however, typically requires using a combination of APIs and SDKs. To help you quickly understand what’s possible and what you need to build for your use case, you can now visit the solutions tab to select from a list of popular use cases or industries. Once you’ve selected a use case or industry, you’re taken to a page where you can explore relevant products, read helpful blog posts, see how other customers have deployed for similar use cases, and more.
Direct access to developer documentation
Did you know there are more than a thousand pages of developer documentation created to help you get started, unblock you when you’re stuck, and share best practices? Now when you explore a product or solution from the Google Maps Platform website, you can easily navigate back and forth between our website and documentation. Just tap on JS, iOS, Android or API under the product name to get to the documentation you need.
Budgeting for your project
To help you calculate pricing for your project, we’ve introduced a new pricing calculator. Once you find the product and API or SDK you plan to use, pull the slider to reflect your estimated number of monthly requests. This will automatically update the “monthly cost” column for each product and API or SDK you plan to use. If your estimated monthly requests exceed the slider limit, contact our sales team to learn about volume discounts that start at 20% off.
We hope our new website makes it easier to discover our products and solutions, estimate your budget, and start building with our documentation so you can deliver helpful experiences to your users and optimize your business.
For more information on Google Maps Platform, visit https://mapsplatform.google.com.
More Relevant Stories for Your Company
App Engine Basics to Help You Build and Deploy Low-latency, Scalable Apps
App Engine is a fully managed serverless compute option in Google Cloud that you can use to build and deploy low-latency, highly scalable applications. App Engine makes it easy to host and run your applications. It scales them from zero to planet scale without you having to manage infrastructure. App
Announcing reCAPTCHA Enterprise’s Mobile SDK to Help Protect iOS, Android apps
reCAPTCHA Enterprise is Google’s online fraud detection service that leverages more than a decade of experience defending the internet. reCAPTCHA Enterprise can be used to prevent fraud and attacks perpetrated by scripts, bot software, and humans. When installed inside a mobile app at the point of action, such as login,
Wunderkind Leverages Google Cloud to Address the Growing Needs of its Customer Base
Editor’s note: We’re hearing here how martech provider Wunderkind easily met the scaling demands of their growing customer base on multiple use cases with Cloud Bigtable and other Google Cloud data solutions. Wunderkind is a performance marketing channel and we mostly have two kinds of customers: online retailers, and publishers like
Enhancing Developer Productivity with Skaffold v2 GA
For years, Google has been committed to maximizing developer productivity. In 2019, we announced the general availability of Skaffold, a command-line tool that facilitates continuous development and delivery for containerized applications. Today, we're excited to announce that Skaffold V2 is now generally available. Skaffold V2 expands Skaffold’s supported platforms and
