Steps to Achieving Successful APIM in Banking

Photo by Glenn Carstens-Peters on Unsplash

With your starting point in mind, it’s time to take steps for achieving a successful APIM program for your bank. These include changing how you think about APIs. The old app-to-app contract model is no longer the only way to do it. It is necessary to build or modernize your API management toolset. You’ll need an API governance model, one that can bring together business and technical stakeholders. 

Then, it will be time to convert existing capabilities and data to APIs and build an internal API registry, so people know where to find them, and so forth. You don’t have to follow every single one of these steps to make gains in APIM. Even just thinking about what’s entailed in the steps will help you achieve a better understanding of the potential for APIs at your bank and what it will take, in APIM terms, to reach that potential.

1. First, Change How You Think About APIs

Managing APIs to make them part of your bank’s business strategy should involve changing how you think about them in the first place. It’s not anyone’s fault, but for many years, IT personnel have viewed the API as a piece of code, a bit of technology. A better way to look at the API is as a product. An API is a technical product that facilitates a business outcome.

Then, it’s useful to shift your perspective on how you use APIs. Think of the customer experience first, rather than application features. For example, it’s not so much that you need to integrate your credit card application with an airline mileage account. It’s more like your customer wants to know how many miles he/she earned on their last statement. It’s the same underlying requirement, but viewing it from the customer’s perspective will help you make the API, and its implementation, more valuable to the customer, and thus the bank. 

Think from the “outside in” regarding devices, business partners, and customers. Situate yourself outside the bank branch—out on the street, or in the customer’s home. What does he or she want to achieve from that distance? What do partners need to accomplish? That way, you can align APIs with the services you offer, along with those you plan to provide in the future. Understand how APIs are at the nexus of business, UX, technology, and security. An effective API, as well as any APIM solution, needs to take all these elements into account. 

2. Build or Modernize the API Management Toolset

APIM needs the right API management tools. If you don’t have the right tools, you need to either build them or acquire them. Or update what you have. To enable new customer experiences and business strategies, you will need a solution that delivers API Management across the full API lifecycle. From design to development, deployment, and retirement, the solution must provide effective control over the API. 

The APIM toolset should enable you to assign API access privileges to specific users or machines. In some cases, this might mean utilizing a third-party authorization scheme like OAuth. In addition to access control, the system has to be able to set usage limits, e.g., user X gets 10,000 API calls per day and so forth. This is necessary to avoid overloading internal systems with unlimited API calls. 

You also have to be able to monitor the health of your APIs in real time. If an API slows down or goes offline, you need to know—and have a failover ready to go, which is also a capability in most modern API management platforms. 

3. Create an Internal API Registry

The APIs need to be discoverable by consumers. To this end, an internal API registry is essential for getting the most out of them. If you already have an API registry, it’s a good idea to think about modernizing it. The goal is to facilitate discovery by internal and external parties. It will be necessary to describe the APIs in the registry in both technical and business terms. Rich detail about the API and its usage potential will help greatly. Done right, the internal API registry will lead to innovative uses of your APIs inside the bank as well as with outside partners. It will also enable reuse of APIs, which drives better Return on Investment (ROI) for API development. 

A further benefit of an internal API registry concerns cost and productivity. With an effective registry in use, it becomes possible to allocate expensive development time to new innovative developments, rather than “reinventing the wheel” by building an API that already exists. 

4. Establish a Governance Model for Managed APIs

The expansion of API use, which is something you hope will happen, necessitates a renewed emphasis on API governance. A governance model for APIs can cover many different subject areas, and they can get complicated. However, keeping things simple, API governance is a matter of determining—and then enforcing—rules that dictate who oversee various aspects of the API program. 

For example, an API governance model should cover who can authorize the development of an API, or an application built using APIs. It should specify who gets to decide about access privileges, especially those granted outside the bank. Governance deals with legal contracts and financial chargebacks related to APIs. Governance controls the lifecycle, as well as compliance. APIs in banking must be considered in the context of legal compliance. After all, APIs frequently expose private customer information, so the governance model should specify how customer permissions are secured, and the like. 

5. Connect Business and Technical Stakeholders

Modernizing APIs and adopting an advanced APIM solution at a bank is at least partly an organizational matter. Users and producers of APIs come from different areas of the banking business, and they need to be represented in the API management and governance processes. For instance, the loan payment processing team may not interact much with the marketing or the credit card issuing teams. However, when APIs are involved, these groups may have quite a few things to discuss. If a banking app needs to show a customer the status of a loan payment, the arrival date of a new credit card, and a special offer, then all three teams will be represented by APIs.

It is also necessary to bring business and technical stakeholders together in API management. The business side of the conversation will be about fulfilling needs for new products and services. The technical side deals with realizing those goals. The two groups can and should collaborate and synergize their efforts. The business team may not understand the full capabilities of APIs, especially when API-driven apps are under consideration. The technology team, for its part, may not automatically get the full depth of needs on the business side. By aligning business and IT elements of the organization, a bank can establish a cohesive API strategy that achieves desired business outcomes. 

6. Convert Existing Capabilities and Data to APIs

The step of “building APIs” might seem obvious, but strategic use of APIs requires new approaches to their development. Traditionally, creating an API meant exposing a data source or “wrapping” an existing application function in an API. There is nothing wrong with this, but it’s not a good way to make APIs that can contribute to transformative outcomes. 

The new approach should follow a distinct thought process about the API’s purpose and desired functionality for the end user. It’s critical to be user-focused. Who is the user? How will he or she use the application for which this API is being created? Once you have determined the user’s intended experience, you can look at where the required functionality comes from. It’s worth keeping in mind that the user might be a partner firm, rather than a consumer. Partner experience is an important factor to keep in mind when evaluating which capabilities and data should be converted to APIs.

This is more of the thinking from the “outside in.” You’re not just taking an app and exposing it. Think about the form factor. For example, if an API is generating a customer’s transaction history, how much of that can you fit on a smartphone screen? This will be the most likely user interface, so it may make sense to limit the number of records being “gotten” for any one cycle. 

7. Expose APIs Externally to Build the Ecosystem

As your new APIs become available, you want to expose some of them for external use. For banks that are working with the Open Banking Standard and comparable regimes, this is a “must-have.” For example, to comply with the EU’s second Payment Services Directive (PSD2), a bank must open its payment processing services to third parties via an API. Some banks are taking this kind of process a step further, creating ecosystems to access and attract new customers. With secure, external-facing APIs, banks can build products together with partners and vendors. They can also deploy new business models like Banking as a Platform (BaaP) and Banking as a Service (BaaS). 

You might want to operate your APIs with different consumption models. Some might be free and public. Others could be private and restricted, invisible except to those who know about them. There should be agreed-upon standards of behavior accompanying any external API use. Such standards can be enforced through policies, such as rate limiting. An API marketplace might be the best way to approach external API consumption. 

Exposing APIs externally is a step that requires tight API security. You need to be in control of who has access, with the ability to authenticate users who don’t work for your bank. This may involve identity federation. External APIs need strict rate limiting and monitoring for signs of Denial of Service (DoS) attacks and other threats. The structure of the API itself should be subject to security review and policies, e.g., making sure that an external user cannot access sensitive data through the API. 

A related, recommended practice is to let end-users be able to see some aspects of the security that’s protecting them. This will serve to build their confidence that their digital transactions are safe. Reassurance about security is part of the customer experience that prevents defections to non-banks and other digital finance services.

8. Explore Where Building API Products and Mashups Will Benefit the Business

APIs are products, but they can also become parts of other products with even greater functionality. Indeed, one of the great advantages of modern APIs is their potential to be integrated into new, dynamic applications and mashups that orchestrate their operations across business processes. New tools, such as Choreo by WSO2, enable rapid, low-code creation of new applications using APIs. 

The thing to bear in mind at this point is, as you may know, these sorts of ideas have been tried out before—often with less than stellar results. You need to have the right tools, as well as policies, to be successful with API products and mashups that invoke APIs. 

9. Determine How to Support Different API Security Models 

API security is an extensive field of work, so it’s impossible to get into full detail here. The best practice for APIM at a bank, however, is to be prepared to support different API security models. For example, if your bank practices DevSecOps, which embeds security into the development and releasing (DevOps) process, it is optimal to make API security part of that workflow. At a more granular level, your APIM solution and policies should align with how your bank does cybersecurity, e.g., if your bank has a Security Incident and Event Management (SIEM) solution, then your APIM platform should integrate with it, and so forth. Getting API security right means partnering with the security and compliance teams. 

10. Establish Effective Performance and Security Monitoring

API monitoring is a core element of any APIM program at a bank. Monitoring takes two forms: performance and security. Regarding performance, the APIM solution needs to track how APIs are performing in real time. This might be a matter of service quality, e.g., you have a Service Level Agreement (SLA) that specifies an API response time. Or, you might just want to have strong performance to ensure good UX. At all times, monitoring needs to tell your API managers if there is a problem. If an API is overloaded and sluggish, that needs to be handled. Or, if an API fails altogether, system owners must know immediately so they can remediate accordingly.

API security monitoring is necessary for detecting the presence of threats. APIs are attractive for malicious actors, as they promise access to systems and data behind the firewall. As a result, API behavior has to be closely watched for anomalies that could indicate an attack is underway. The signs of an attack might be subtle. For example, if an authorized user invokes the API a thousand times in an hour in the middle of the night, that would suggest an account takeover. The APIM platform should connect with security operations (SecOps) systems and incident response workflows to ensure a suitable response to a detected threat such as this.

11. Create a Center or Excellence (COE) and/or Program Office

It is a highly recommended practice to establish an API Center of Excellence (COE) or program office. The structure and size of this center will evolve over time. In the beginning, as the APIM solutions and new policies are introduced, it will likely be larger. Over time, it will shrink to its permanent size. The goal of the COE or program office is to create a central location (either digital or physical) where any stakeholder who touches APIs can get answers about how to do things, policies, security, compliance, and other relevant API practices. The COE can serve as the entity that validates API designs and signs off on changes in security policy, to name just two examples of the many roles it can play. 

The COE or program office can also help everyone involved understand their Total Cost of Ownership (TCO) and ROI for any aspect of their API program. The center can explain to anyone who needs to know how to do real-world API implementations. Working this way, the center can help stakeholders understand how to prove the value of their proposed projects and ideas. If your bank has struggled with APIs in the past, a COE or program office provides a good mechanism for correcting old, wrong assumptions about how APIs work and what they can do. It can help people see their full business potential. 

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