The Role of Agile Integration in Open Banking

In the mid 90s, Bill Gates famously said that “banking is necessary, banks are not.” There is certainly a lot of truth in this statement. We all need banking services in some shape or form. But who delivers these services to us is secondary. In fact, Accenture concluded in a study conducted in 2016 asking over 30,000 people in 18 countries that if the tech titans like Google, Amazon, or Facebook would offer such services, 31% of the respondents would switch to them. This clearly imposes a significant threat on traditional banking institutions.

Another challenge that banks are facing worldwide are the increasing demands for regulatory compliance with respect to openness. Such regulations include, for instance, Payment Services Directive 2 (PSD2) in Europe, the Amendment Bill to Japanese Banking Law in Japan, the National Payments Corporation of India (NPCI) with the Unified Payment Interface, UK’s Open Banking standard by the Competition and Markets Authority (CMA), or the Open Banking Regime by Australia’s Federal Government. Banks approach these regulatory challenges in many different ways. Some see it as a serious business threat and only do the bare minimum for compliance; others see it as an opportunity and with smart investment start building banking platforms for the future.

Our suggestion for building the banking platform of the future resides on the principles of agile integration, which is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, agile integration resides on the three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed. We described the details in an earlier post.  

Based on the principles of agile integration, we conceived a reference architecture for financial institutions to suggest a banking platform of the future that also complies with the regulations for openness. Our reference architecture includes twelve core components, which make up a comprehensive platform. 

Here are more details about the main function of each components, starting from right to left:

1. Core Banking:  These are the core banking services that often rely on up to 30 year old technology.
2. Third Party Services: Most banks also consume and offer services from external suppliers.
3. Integrations / Transformations: This component covers data and service integration or protocol transformation or mediation.
4. Backends-for-Frontends (BFFs):  BFFs are an effective architectural pattern to prepare services for specific frontend applications. A Web app has different characteristics than a voice-enabled chat bot.
5. API Manager: This component is the central element of an API management solution where the various policies such as rate limits, different API consumer segments, or monetization of API access are configured.
6. Dashboards / Analytics: Dashboards provide comprehensive intelligence about the health of the banking platform on various levels. These are also essential to inform strategic decisions.
7. Gateways:  These are the control instances of API traffic and make sure that only authorised calls are permitted and logged.
8. Developer Portals:  These are the outward facing interface for the API consumers. Their purpose is to allow developers to consume API documentation, register for APIs, manage credentials and analytics.
9. Identity Provider (IDP) and Single Sign-on (SSO) Solutions: Financial institutions handle a lot of sensitive data that must be secured via end-to-end identity management. Often several IDPs are deployed within a bank and leveraged in different subsystems. We recommend to have an IDP federation in place.
10. Container Runtime / PaaS: Modern IT infrastructures should leverage the benefits of container platforms such as demand-based scaling, deployment flexibility across different environments such as on-prem, private or public clouds, and DevOps capabilities.
11. Own Channels: Finally, banks need to have capabilities to expose their services and data to customers via different channels such as Web sites, mobile, or IoT apps and must not exclude any future new types of channels.
12. Third Party Channels: The banking platform must also allow third parties to create customer channels. It is important that the customer experience is consistent between the channels.

The European PSD2 is probably the most often cited regulatory requirement for financial institutions and has gone into effect already. In August 2019, the Regulatory Technical Standards will roll out. All banks in Europe must comply with these new standards. Mark Boyd wrote a report about PSD2 with his analysis of what it means for banks and how banks can address it. From his report, we took a summary of the main PSD2 requirements.  

Looking at these requirements, we can provide a road map to a banking platform through the twelve components of our reference architecture and our approach to agile integration.

Financial institutions have a choice: Do the bare minimum to comply with new regulations, which may be the cheapest way short-term. Or invest in a future-proof banking platform leveraging modern standards to become the future banking service provider for developers, partners and customers. We believe that agile integration delivers the core principles to build such a banking platform of the future.

To get more details about agile integration, read our Digital Innovation Through Agile Integration whitepaper.