Composable Banking Platform through Open Bank APIs

1         Introduction 

Someone wrote that the next couple of decades will see as much innovation as in the last 500 years. The technological accomplishments hitherto unheard and unforeseen include adaptive software, social networking sites, smart spaces, knowledge societies and enterprise mobility. In recent times, behind the scenes at banks, I’m pretty convinced, as things are progressing other sectors, banks are slowly waking up to the potential of enterprise mobility and APIs—something that has taken a long time, as they slowly come out of their bank vaults, where they were hiding during the economic meltdown..

In this article, I discuss about the future of Digital Banking and emergence of “Composable Banking Platform” through Open Banking APIs. The explosive growth of apps is causing significant challenges for the banking industry, says Gartner, as the visibility of customer banking apps in public stores decreases as more third party applications come online. As we recover from the financial crisis, we see that the banking industry is warming up to the world of APIs.

It will simplify the integration of complex business systems into daily life – and it will see the developers playing a decisive role in which technologies win, driving adoption from the bottom up.

Within the next two years, 25% of the top 50 global banks will have launched a banking app store to improve app discovery, user experience and collaboration, says Gartner.

2         What are Open Bank APIs? 

The Open Bank APIs let third party software developers write applications and services to help account holders interact with their banks, building societies and other financial service providers.

Actually, Open Bank APIs make it easier for banks to provide access in multiple languages, support the visually impaired, spice up its customer interfaces with cool graphics or 3D animations, or let customers interface their accounts to personal financial management (PFM) packages. Today Banks are in a race to be relevant and to be in tune with times.

3         Open Bank APIs adoption and challenges

Before financial institutions can deliver an enhanced user experience, banking CIOs have to get used to, or rather embrace, another concept: open technology and open platforms. A well-crafted API strategy is dependent both on more open infrastructures and data feeds to enable the development of new applications, while being done in a safe and secure environment. That can be a highly sensitive issue in the world of financial services.

No one is calling for the Wild West here -- we all know the regulatory requirements and customer expectations governing our industry; privacy and security are top priorities to retain customer trust, and uncontrolled data and platform access can undo all kinds of competitive advantages. But the ability to open platforms to API development is a perfect illustration of how the world and how we need to compete in it has changed. It's a critical imperative to make data and platforms more open than ever before.

Innovation in our field is now driven by the ease with which vast amounts of data can be accessed, collated and packaged. This freedom, which comes with new expectations for privacy and security, takes developers and users alike many steps forward in harnessing new capabilities, and that, in turn, benefits banks.

Today, with mobile devices becoming ever more important and new applications emerging from a broad base of sophisticated users far beyond the development community, the environment is even riper for new innovations and advances. We might not see only one killer app, but many.

4         Reference Model for a Composable Banking Platform (CBP)

Composable Banking Platform or Open Banking is the self-service discovery, provisioning and creation of new banking services by ecosystems inside and outside the bank. Open banking systems include assets and functions that are accessible and usable in the context of the end user across intra- and inter-enterprise boundaries. APIs, ecosystems, apps and app stores are key to enabling open banking and open bank systems.

CBPs will enable new bank revenue streams through integration of APIs into emerging and flexible ecosystems of developers and partners. CBPs enable a mass world to be customised for the individual, complete with all of a person's favorite applications and the ability to feed his or her data into those applications as he or she chooses.

4.1        Users

Users are people (contrasted from applications or things that could also access APIs, which are included in the device layer). Examples include employees, retail customers, commercial banking customers, investment banking customers, IT employees, business employees, partners, other banks and regulators.

4.2        Devices

Devices will access and leverage apps through app stores. Examples of devices include smartphones, tablets, things (e.g., the Internet of Things), wearable technology, TVs, autonomous vehicles and others.

4.3        Banking App Store

Banks and nonbanks use public application stores like iTunes, Google Play, Windows Stores and others to deploy apps they have built for banking customers. Increasingly, banks are also providing their own app stores to enable user discovery and an enriched user experience.

Banking app stores include enterprise, private, hybrid and public banking app stores that support:

1.       App discovery: Enabling users to find the apps they want and need through search, categorisation, past behavior and other methods.

2.       App downloads: Enabling users to download an app they want.

3.       App ratings and feedback: Enabling users to provide ratings and comments on apps.

4.       Idea posting: Enabling users to post an idea for an app and interact with developers.

5.       Recommendation engine: Recommendations for other apps a user might want based on their past behavior or role.

4.4        App Performance Monitoring

App performance monitoring tracks the execution of software algorithms that constitute an app, measures and reports, determines whether the app executes successfully, records the latencies associated with execution step sequences and determines why an app fails to execute successfully or at expected levels.

This requires:

1.       End-user experience monitoring:  The capture of data about how end-to-end app availability, latency, execution correctness and quality appear to the end user.

2.       App topology discovery and visualisation:  The discovery of the software and hardware infrastructure components involved in app execution, and the array of possible paths across which these components communicate to deliver the application.

3.       User-defined transaction profiling:  The tracing of user-grouped events, which comprise a transaction as they occur within the application as they interact with components discovered in the second dimension (application topology discovery and visualisation). This is generated in response to a user's request to the app.

4.       App component deep dive:  The fine-grained monitoring of resources consumed by, and events occurring within, the components discovered in the app topology discovery and visualisation dimension. This may include server-side components and client-side devices and interfaces.

5.       IT operations analytics:  The combination or usage of techniques, including complex operations event processing, statistical pattern discovery and recognition, unstructured text indexing, search and inference, topological analysis, and multidimensional database search and analysis to discover meaningful and actionable patterns in the typically large datasets generated by the first dimensions presented here.

4.5        Banking Apps

A banking app is a software packaging construct where value is derived from how purposeful it is for users. The more narrowly focused an app is on doing one thing well, the more valuable it's deemed to be. This contrasts with the traditional application packaging construct where value is tied to capabilities — the more things it does, the better it is perceived to be. A few examples of narrowly focused banking apps that create new value using digital assets includes photo-generated savings goals, transaction pre-staging, digital property inventory and digital banking advisors. Banking apps categories include Web, mobile, social, TV and others.

4.6        Gateway

The gateway layer serves as a control plane. It is largely composed of application services governance including:

1.       Virtualisation:  Decouple the control plane (e.g., the gateway) from the physical plane (e.g., services)

2.       Integration:  Enable integration with/access to internal services/APIs

3.       Transformation:  Convert data from one type to another without modifying the meaning of the data

4.       Composition:  Integrate multiple, diverse sources of data and application logic

5.       Orchestration:  Coordinate, combine and arrange multiple services/APIs

6.       Security:  Communicate securely, reliably and flexibly (see API Management section)

7.       Monitoring:  Monitor API usage and performance for threat detection, quality of service and business management

8.       Routing:  Ensure the correct version of a service is invoked by the correct API

9.       Optimisation:  Manage different API constituencies through usage throttling, developer consumption quotas and traffic prioritisation

10.   Load balancing:  Intelligent traffic routing to the most available resource that is hosting a particular kind of service

4.7        Services / APIs

Services are anything with an API. Services implement a specific capability, are a shared resource and may run anywhere (on-premises, cloud, external). A few examples include UX coordinators, orchestrations, task processors, event monitors, analytic engines, infrastructure services and sources. APIs (and apps that use them) are essentially a new channel to reach users.

4.8        Application Services Governance

The design, implementation, publication, operation, maintenance and retirement of APIs and services need to be governed and managed carefully, which is what "application services governance" does.

4.8.1        API Management

API management capabilities enable the successful delivery, promotion, operation, measurement and continuous improvement of APIs. Some of the API management aspects are:

• Enabling developers.
• Authentication  & Authorisation
• Threat detection -  Data privacy capabilities that act in unison with authentication and authorisation
• Traffic management -  Managing different API constituencies through usage throttling, developer consumption quotas and traffic prioritisation
• Service routing & orchestration 
• Managing the API life cycle:  Managing each phase of the API: planning, design, build/implementation, operate/run (version management, change notification, issue management), maintenance and retirement.

4.8.2        SOA Governance

API management shares many classical SOA governance technology functionalities, especially during the operational/runtime stage (by far, the stage where services/artifacts/APIs spend most of their lifetime), when services or APIs are deployed in production, and are actively used by several consumers.

4.8.3        Developer Portal

Developer portals contain metadata about the artifacts used and reused in a company's API management and SOA projects. In most cases, these are services or APIs (implemented on-premises or in the cloud), but can be any reusable artifact, such as pieces of process logic, or an entire micro-process (e.g., issuing an e-invoice). Some of the aspects of developer portals include:

• Discovery metadata: Enabling developers to find the services exposed through an API, compare changes between versions and identify the correct version for their needs.
• Developer access provisioning: Enabling developers to self-register, create accounts and access, and manage credentials. Includes developer API key registration and developer API key management.
• Collaboration and connectivity: Enabling an open developer discussion that advances usage and business objectives. Includes API provider blog, developer discussion forums, developer issue reporting, and change notification registration.
• Developer enablement administration: Enabling the ability to manage developers. Includes developer discussion forum management, developer portal content management and API documentation management.
• API discovery & publishing: Making an API available for public use or for private use within a company.
• API access: Enabling developers to access an API. Includes developers across a public/private continuum from the enterprise, partners, other banks and customers (retail, commercial and investment banking).
• Billing: Enabling developers to monetise the usage of their APIs, often through basic or premium-type plans.
• Testing & Support

4.8.4        Policy Management

This is the ability to define, implement, monitor, enforce and manage desired behavior and exceptions around a specific decisional path to govern (in a way previously agreed on within the organisation) a specific, day-to-day activity in SOA/API management, or a particular type of use/reuse of APIs or SOA artifacts. The primary elements of policy management are:

• Design:  Using a repeatable and transparent design methodology for APIs. For example, create developer personas, map interaction scenarios, design legal and technical contracts (especially for external developers), implement effective and transparent governance and deliver great support.
• Product management:  APIs should be treated as a product with its own life cycle, instead of a short-term project. For the API product manager, developer personas and scenarios are critical components of understanding the audience, because developers are the customers. Continuous learning is required so that developers' changing needs are understood and met. Apps should be managed as products in this same way.
• Compliance to internal standards at design time:  Creating and complying with internal standards when designing an API. For example, protocol, format, commands, endpoint structure and error handling.
• Compliance to regulatory compliance:  Creating and complying with regulatory compliance when designing an API.
• Service dependency:  APIs create extended enterprises that depend on each other's services for increasingly critical business. This will require the ability to manage multiple runtime dependencies on services banks do not control.
• Security and scalability:  Security policies (which are a vast functional domain in isolation) in API management generally are required to support open Web protocols such as OAuth. In SOA governance, features are needed such as integration with the existing enterprise infrastructure (e.g., Active Directory), and the ability to provide federated identity management.
• Operational and runtime policies:  Real-time visibility and control at each stage of the API life cycle. For example, access and credentialing, data privacy and communication integrity, managing SLAs, monitoring/reporting/logging/auditing, orchestration, change impact, throttling and load balancing.
• Developer access  Policies for developers' access provisioning are typically oriented to internal users in SOA governance, but take on much more complexity in API management, because they must manage external programmers, which are well beyond the company's control.
• API monetisation policies:  The promotion of API usage, targeting all the communities of developers that might be interested in it. "Freemium" and tiered pricing are examples of API monetisation policies.

5         Conclusion

APIs, apps, app stores, developer/partner ecosystems and other technologies provide CIOs with the ability to enable mobility and innovation, increase product and service accessibility and create new business models.

Composable Banking Platform provides banking CxOs and line of business leaders with a way to transform what it means to be a bank. Drumbeat for ‘CBP’ or Open Banking API is growing louder day after day.