The Starting Point to Future-proof your Bank

Photo by Erik Mclean on Unsplash

A bank that wants to become more competitive will likely have to update its existing API solutions to meet today’s requirements. The question becomes, then, where to start? The process of API modernization can appear daunting. The entire bank’s technological stack and enterprise architecture are seemingly up for grabs. Yes, it is not a simple matter. However, it is possible to find the right starting point for the journey and advance towards a more future-proof bank.

Identifying Your Institution’s API Maturity Level

The first step in making APIs do a better job of serving your banking business goals is to identify your institution’s API maturity level. This is not a formal scale, though some analysts offer such models. Rather, it’s wise to map your current API state to one of these essential states of maturity:

1. No/fFew APIs with little-to-no coordinated API management—A bank that has developed a few APIs for specific purposes, but without much thought to managing the API lifecycle, security, and so forth. 
2. Some APIs, mostly internal facing, with limited API management—APIs are part of the bank’s architecture, but they are mostly based on the one-off, app-to-app “contract” model. The APIs do not connect to entities outside of the bank. There is little or no organized management of the APIs or their API lifecycle. 
3. Centrally managed APIs—The bank has an API management solution in place. APIs are controlled and monitored throughout their lifecycle, with version management, access controls, usage throttling, and more. (See page 15 sidebar on Full Lifecycle API Management) API reuse occurs, but it is primarily between internal business units of the bank.
4. Mature API management—The bank has complete knowledge of the state of all its APIs. API owners can define and enforce a wide range of usage and security policies to their APIs. The bank publishes APIs for secure use by external entities. Developers have the tools they need to build dynamic, customer-centric applications that call on APIs both inside and outside the bank. 

From the perspective of API maturity, your starting point should be your current level. Your goal should be to reach the next level. You can also jump levels. Even if you are at level 1, where your competitive environment demands it, you can move directly to level 3 or even level 4 with the right tooling and organizational changes. 

Identifying Your API Needs and Business Opportunities

The maturity model is general. It speaks to your overall approach to APIs. To find an effective starting point for API modernization, you will also have to figure out your specific API needs and understand how they relate to business opportunities. The challenge here is to be generic enough to devise a workable strategy for the entire bank, but specific enough to be meaningful. 

For example, you might determine that you need your APIs to be capable of external-facing interactions with other entities. This might mean integrating your back-end banking systems with an insurance company or airline rewards point system. With those sorts of use cases in mind, you can start to figure out how your APIs and your API management will need to change to be successful. Your starting point is “Make our APIs work externally, for the purpose of building partnerships with other businesses that will enable us to add more value to the customer.”

Alternatively, you might perceive the best opportunities to use APIs to be around building entirely new business models. In this case, you are looking at using APIs to build a banking platform. The starting point is a place where you create these capabilities, most likely incorporating tools that let your developers build applications that consume multiple APIs inside and outside the bank. Your starting point here might be something along the lines of “Make our APIs the basis for a completely new line of business.”

To find out more, view our CXO playbook for bankers on how best to optimize your API strategy for digital distribution.

Photo by Erik Mclean.