Olaf van Gorp
Open banking is now a reality, it being embraced by banks across the globe. What’s more, open banking may in fact have been instrumental in the wider digital transformation of banks, which 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, primarily focusing 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, resulting in a more challenging API landscape that has to be managed.
This blog provides some direction on how this can best be approached.
Open banking has evolved from what many initially perceived as an almost revolutionary — or certainly disruptive — movement into 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 (including the UK) still leads the charge, as 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.
Interestingly, 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 which 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 that made banks shift from a traditional product-driven approach to a much more customer-centric approach. Furthermore, by also introducing new technology and new technology paradigms (APIs, in particular).
Two distinct accelerators can easily be identified:
Yet, despite accelerating factors, 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, as 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.
Assuming 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.
Once approached from a wider strategic perspective, however, things quickly become more challenging. For example, how to maintain a level of global governance across the enterprise, 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 and the like that are deemed essential at the global level, or that are necessary for reasons of regulatory compliance.
The creation of consistent, compliant API products is highly facilitated by having critical features applicated 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, which is 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. What is of critical importance is that this information is up to date. This can be achieved by having the API portal as an integrated part of your overall API management solution. 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.
To illustrate what such a solution would look like, let’s look at an example that highlights some critical features of an enterprise-wide API management solution approach that takes into account the challenges listed above.
With larger banks and other enterprises, we typically see decentral, sometimes semi-autonomous organizational units (business departments, geographically distributed enterprise units, etc.) that have their own services output. This needs to be reconciled with the availability of global services that are offered as part of centralized enterprise governance, for example to ensure compliance with critical policies demanded by enterprise security or external regulation.
To effectively address this dichotomy between ”centralized governance” versus ”decentralized execution,” an enterprise-grade API management solution should allow for the applicable organizational structure to be represented as part of the solution, with the centralized governance function provided by central API management platform management. At the same time, it should allow for delegation of organizational specifics to the appropriate organizational levels. In other words, decentralized aspects can be facilitated through some form of federated architecture, for example by having organizational units represented by distinct tenants (in a multi-tenant setup), or by having the management solution offering an alternative organizational subdivision.
Read More in Our White Paper >> Federated Architecture For Enterprise API Management
In terms of operational API management, enterprise units may deploy their own API Gateways (for reasons of data protection, regulatory constraints, exclusive operational management, preferred on-premises versus cloud deployment, etc.). Allowing for centralized management of all API Gateway instances/clusters through centralized Platform management greatly facilitates enterprise concerns like overall API accessibility and security, ensured availability, and operational monitoring, to name some critical aspects.
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, to represent different brands, address different target audiences, etc.).
As the API delivery process itself is dynamic in nature (with changes and updates being continuously provided), 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.
The Akana API management platform has the flexibility to fit your organizational structure, with centralized management providing global governance, and federated architecture to facilitate decentralized elements.
Experience the capabilities of the Akana platform with a free 30-day trial.
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.