Submit support requests and browse self-service resources.
Olaf van Gorp
Digital transformation in banking is accelerating. Open banking is now a reality. It's embraced by banks across the globe. What’s more, open banking may in fact have been instrumental in the wider digital transformation of banks. This is generally accepted as an inevitable step to ensure continued significance in the market.
Or has it?
A closer look at current open banking initiatives reveals that its scope is (still) rather limited. Today, it primarily focuses on front-end services around accounts and payments. To effectively support a seamless digital customer experience, a much wider array of functions (including mid- and back-office functions) need to be included.
As a result, there is a more challenging digital banking API landscape that has to be managed.
In this blog, we break down:
Open banking has evolved. It was initially an almost revolutionary — or certainly disruptive — movement. Now it is an established practice, offering opportunities that many banks now acknowledge and seek to capitalize on.
Indeed, open banking initiatives are popping up all over the world. Europe still leads the charge in open banking, especially in the UK. This is where regulation in the form of PSD2 has given it an absolute boost. However, significant developments can also be seen in Asia Pac and North America, in particular.
Open banking may in fact be accelerating a more fundamental digital transformation of the banks. In publications staking this claim, you will typically read that banks need to evolve into a digital platform in order to retain their significance. Or, at least, to allow them to better service the needs of a customer base that already takes a seamless customer experience for granted.
Yet, to truly get to that stage, banks have to undergo a profound digital transformation process. This entails much more than exposing a few APIs for open banking purposes.
Rather, it means applying "digitalization” across all functions and processes, or at least those functions and processes that would contribute to that seamless customer experience.
I believe it can be argued that open banking has acted as a catalyst for this digitalization effort. It has done so by introducing new ways of thinking. This made banks shift from a traditional product-driven approach to a much more customer-centric approach. Furthermore, it also introduced new technology and new technology paradigms (APIs, in particular).
Foundations For a Digital EcosystemLearn how to set your digital ecosystem up for success. Get the white paper "Foundations for a Digital Ecosystem."Get the White Paper
Learn how to set your digital ecosystem up for success. Get the white paper "Foundations for a Digital Ecosystem."
Get the White Paper
Two distinct accelerators can easily be identified:
Regulation (like PSD2 and UK Open Banking) has in fact forced banks (in these geographies) to open up their systems in order to provide access to account data and payment data.
New players have entered the banking domain — most significantly the big tech companies whose entry is regarded as a threat to incumbent banks — forcing the more ”advanced” or ”innovative” of these to accelerate their open banking initiatives, in order to stay ahead of the game and/or retain their customer base.
The step from initial open banking efforts to a genuine seamless digital customer experience remains a big one.
To this day, open banking has been largely focusing on the banking front-end:
Creating an interface between the bank and its wider ecosystem with organizations, like FinTechs, that have an interest in accessing the account and payment data currently held by the bank.
Creating or enhancing a seamless digital customer experience is one of the main objectives here. Yet, it is probably clear that a seamless customer experience requires effective integration of mid- and back-office functions as well. At this stage, that is often still missing.
As a consequence, the APIs offered as part of an open banking initiative (at the front-end, so to speak) may only represent the tip of the iceberg. These APIs will depend on mid- and back-office functions to provide an optimal end-to-end experience. Therefore, we may see open banking driving the further digitalization of functions across the bank, encompassing front, mid, and back-office alike.
Here's why digital banking APIs are important for digital transformation in banking.
Let's assume that the bank has decided on APIs as the main vehicle for integration. We will probably see the number of APIs increasing rapidly. Though the majority may not be visible at the front-end as such, they will play a very important part in further optimizing that seamless customer experience.
At the same time, additional banking functions (other than the ones “traditionally” exposed as part of an open banking initiative — think retail accounts and payments) may also follow the API path. For example, standards have already been developed to expose Trade Finance APIs as part of a wider open banking offering. Similarly, initiatives are being developed in the insurance domain.
So, we can see open banking evolving into a more comprehensive digital banking or open finance approach.
Either way, it is safe to assume that banks will see a much larger number of APIs as part of their IT environment than the number they have currently deployed for open banking purposes. This will result in a more complex API landscape that will need to be managed in accordance with the bank’s API strategy.
The step from business case and strategy to implementation is often found to be a pretty daunting one. Banks today acknowledge that open banking and APIs can be a means to drive strategic advantage. But how, exactly? The path from concept to actual implementation is not always clear. Where to start?
The current open banking standards, like the ones offered to support UK Open Banking and PSD2-implementations in Europe, offer an impressive level of technical detail. On the other hand, they do so within the fairly limited scope that open banking presently covers.
Additionally, they do not address the more strategic questions like “How am I going to align this with our wider API strategy?”
Let’s see if we can provide a little more clarity on those questions.
For an initial open banking scope, the various open banking standards provide clear prescriptions and implementation guidelines, both in terms of the functional interface (access to account data, allowing for payment initiation, etc.) and the associated security profile (addressing authorized access, account holder consent, etc.). Though banks have often found this far from trivial — in particular the security part — at least it’s clear what must be achieved here.
But aligning this with your API strategy is more challenging.
For example, how will you maintain a level of global governance across the enterprise? Especially one where APIs are typically created as part of a project by decentralized, DevOps-driven organizational units?
Rather than being a constraining factor, governance should be facilitating these initiatives — without compromising security policies. Creating consistent, compliant API products is highly facilitated by having critical features built through automation, preferably integrated with the wider CI/CD environment. Automated API creation can be driven by metadata, whose values can be assigned by an authorized stakeholder.
Ultimately, the API products need to be discoverable for consumption. That's why they are typically published in an API developer portal. Here, prospective API consumers can find all the information they need to help them effectively access and use the API. This information MUST be up to date.
You can achieve this by having the API portal as an integrated part of your overall API management. An enterprise-wide catalog of APIs with up-to-date documentation and details goes way beyond a stand-alone website to just support open banking APIs.
So, how can you use APIs to drive digital transformation in banking?
Let's look at an example of how you can use an API management solution like Akana for your digital banking APIs.
Larger banks often have de-central — sometimes semi-autonomous organizational units (business departments, geographically distributed enterprise units, etc.)— that have their own services output.
You need to reconcile this with the availability of global services that are offered as part of centralized enterprise governance. For example, you need to ensure compliance with critical policies demanded by enterprise security or external regulation.
So, you have a challenge with de-centralized execution vs. centralized governance.
You can solve this challenge with an enterprise-grade API management solution, like the Akana API platform.
Akana allows for applicable organizational structure to be represented as part of the solution.
In other words, decentralized aspects can be facilitated through some form of federated architecture. For example, you can do this by having organizational units represented by distinct tenants (in a multi-tenant setup), or by having the management solution offering an alternative organizational subdivision.
More on Federated ArchitectureLearn more about federated architecture for enterprise API management. Get the White Paper
Learn more about federated architecture for enterprise API management.
Enterprise units may deploy their own API gateways for various reasons:
Akana allows centralized management of all API gateway instances/clusters through a centralized platform.
This makes it easy to resolve API accessibility and security concerns. Plus, it ensures availability and operational monitoring.
Having the API products published in one or multiple API portals is the ultimate result of the API product delivery process. Depending on the bank’s enterprise requirements, there may be one or several portals. For example, you may want to represent different brands or address different target audiences with different portals.
The API delivery process itself is dynamic in nature, with changes and updates being continuously provided. So, it makes great sense to have the portal as an integrated part of the wider API (lifecycle) management solution. This ensures that changes to APIs are seamlessly propagated and immediately available to the consumers.
With Akana, you can have one or multiple portals integrated into your overall solution.
The Akana API management platform has the flexibility to fit your organizational structure, with:
Sign up to learn if you qualify for a free 6-month trial of the Akana platform.
Technical Sales, Akana
Olaf has over 20 years’ experience with software development and architecture, helping organizations such as Compuware and Capgemini solve enterprise-level integration and governance issues. Olaf has supported the technical sales for Akana API management since 2014, diving deep into security challenges as well as issues specific to financial services, such as PSD2 and Open Banking.