As we journey through 2024, I’m exploring some pivotal trends steering credit unions into future success. My first trend was ‘AI is Changing Existing Applications.’ My second trend was ‘Platform Engineering Becomes More Systematic’ and my third, ‘Open Finance Matures Worldwide.’ Now, let’s explore the fourth trend:

Multi/Federated API Gateways Become More Common

The world, especially the financial world, runs on APIs. Cloud-centric API management platforms (generally made up of a gateway with associated API design and usage policies and a developers’ portal) are the vehicles for building API usage and have become a standard feature most applications use. There are several flavors, from the traditional, mature gateways like Mulesoft, to cloud-specific gateways like Azure, to open-source ones like Kong, which come at various degrees of microservices friendliness or are even targeted at specific usages, like micro-gateways or service meshes. Beyond this simple explanation, analyst reports compare different API management solutions in detail in reports like this one.

What is a muti-gateway strategy, and why is it important for credit union leaders to understand it? If your organization is outsourcing your cloud and IT services (e.g. to a service organization – CUSO), being an expert is unnecessary, but having a general understanding might be helpful, as your CUSO really needs to have a Multi/Federated API Gateway strategy (see below). If your credit union is building an in-house API platform and has control of your IT systems, chances are you’re already running one or more API gateways. In this case, having a deeper understanding of how to implement or improve a multi-gateway strategy is essential.

Hold on - where are these multiple gateways coming from?

Different departments in large companies tend to use whichever API management platform suits their needs best: sometimes it’s open source (you don’t need a business case to freely download one), sometimes it’s part of a wider solution (i.e. to manage consent to view financial data), or it’s the favorite platform of the incumbent system integrator. Other times, it’s part of a larger cloud or application infrastructure deal and thrown into it for low cost or free.

Once a gateway is there, APIs are developed and run on them. If you develop on AWS platforms, you can put the API on an AWS gateway in a few clicks. “They just come up like mushrooms,” an API product manager once told me. Managing (before even thinking of governing) APIs that run on multiple gateways becomes very time-consuming. It is a straight multiplication of resources, since the administration platforms of different API management systems are quite different.

API consumers and providers demand more security, easier access and modern ways to work with credit unions. Offering digital products and integrating legacy systems data and outside resources continues to be complex. Having a multi-gateway strategy enhances platform engineering too (see ‘Platform Engineering Becomes More Systematic’): it enables credit unions to address the challenges of managing multiple API gateways, documentation, cloud vendors, and tools with a centralized approach. It allows credit unions to have consistency in quality and governance across different contexts. Multi-gateways offer flexibility and control to keep the APIs healthy and secured inside the platform before they’re published.

API Strategy is Complex

Different types of gateways are associated with various usage scenarios and offered with multiple pricing models. Although running an API management system (gateways and developers’ portal) from a single provider continues to be the best practice, finding evidence of the usage of another gateway to support different use cases or as a consequence of broader cloud (or multi-cloud) services choices, is becoming very common, especially in medium to large companies all over the world.

Ask your IT department (if you have one) how many API gateways they run for your organization. It’s not uncommon for them to be unsure of the answer because of (conscious or not) distributed governance arrangements. As previously noted, each API management platform comes with its own administration interface, making it more challenging to have a consistent, credit union-wide portfolio view of the APIs, avoid duplication, enforce policies consistently, avoid shadow APIs, provide unified API documentation, promote reuse, and so on.

APIs are consumed based on how they fit the needs of the consuming application, regardless of which API gateway they are threaded through. Some policies (authentication or rate limiting) need to be applied to all APIs, no matter which gateway they are attached to, throughout the enterprise, which leads to duplication of administration efforts and multiplication of maintenance bills, if not creation of technical debt.

Multi/Federated API Gateways Take a Different Slant for CUSOs

APIs are no strangers to CUSOs, especially the innovative ones. Some offer APIs into their platforms, some develop APIs for their clients. Soon, they will be hosting APIs for their clients.

In fact, a straight implication of the upcoming Consumer Financial Protection Bureau’s (CFPB’s) Rule on Personal Financial Data Rights (see ‘Open Finance Matures Worldwide’) in the US is that credit unions will have to publish APIs into their customers’ financial data while managing the associated consumer consent to do so. Credit unions outsourcing to a CUSO will look at the CUSO to provide that service. Most credit unions will just seek basic regulatory compliance, foregoing all the open-banking-related business benefits the regulation offers. But, a widely proven fundamental rule holds: compliance is a cost; open banking is a strategy to new revenues. Innovative credit unions and their CUSOs are starting to believe in that rule.

So CUSOs in the US (or anywhere open banking regulations are in force or upcoming) either run, or will have to run an API management platform in the near future to provide simple compliance services (dealing with competing offers from banking data aggregators) or enable / support / enhance an open banking strategy for their clients. This second option is by far the most interesting and has several multi-gateway implications.

Some CUSOs will be able to standardize on a single API management platform internally, but their credit unions won’t. The credit unions will run APIs on other API management platforms, such as their chosen cloud providers or an out-of-the-box banking solution to embed an open-source gateway / micro-gateway / service mesh (like an external identity check). A credit union will want its CUSO to be aware of API traffic, even when the APIs are not hosted by the CUSO, if only for debugging when an application goes wrong. CUSOs running a multi-gateway API management platform can provide this service. CUSOs without multi-gate API platforms will experience much more resource-intensive service and probably not economically viable, at a loss of their clients.

What are the Next Steps for Credit Unions?

Whatever API management platform you run, ensure its administration supports multi-gateway deployments. You may end up with more than one platform, but fewer API management platforms are better, so favor multi-gateway offerings.

Some visionary API management providers, including Sensedia, offer multi-gateway/multi-API management administration. They provide an initial set of features to monitor API traffic on multiple gateways, determine which APIs sit in several developers’ portals, and govern them. These features are a good starting point. As business becomes more complex, the need to push, monitor, and manage the exceptions of central policies from a single point to multiple gateways will become a significant differentiator, far more than it is today.

If you already have several gateways, multi-gateway is a top priority today. Finding which APIs are consumed from where is generally NOT straightforward. Take action today to avoid multiplying resources and spiraling maintenance bills to support them.

‍