How banks can get the most from API content

The financial industry has been facing the need to transform for years—and the need for digital innovation reached a new high in 2020, with digital channels filling in for physical banking options that were reduced or suspended during the pandemic. The challenges of meeting today's digital demands are very real in an increasingly competitive and complex industry. From customer engagement and completing multiple transactions via different channels and touchpoints, to meeting regulatory and compliance requirements, it’s a lot to keep up with, let alone innovate.

Add to it rigid software systems based on outdated COBOL coding and legacy banking siloes, and it’s not hard to see why making the digital transformation is a big ask for many FIs. But 2020 made it clear: FIs have no choice but to jump on the digital bullet train.  

Banks can simplify the transformation by using APIs and other technologies. Because it’s not about reinventing the wheel each time; it’s about repurposing existing systems while embracing new technologies to deliver a path to faster and smarter innovation. 

Here's an anology: Let’s say your FI is based in France but a German traveler stops in needing to make a somewhat complicated transaction—but they speak very little French. Luckily, your branch manager speaks German and can translate, explaining to the teller what the customer needs. That’s essentially what an API does for software applications; it enables different applications to talk to each other.

And using a containerized approach with Kubernetes combined with any one of the different distributions available, like Docker, is the way to go. Containers have the application and all dependencies for the API, allowing developers to take advantage of open standards and interoperability between disparate systems.

Why should FIs move to APIs? Because the reliance on legacy software technology like COBOL is outdated. Take this story from Wealthsimple Magazine: A man named Thomas  learned how to perform COBOL coding in 1969—over 50 years ago. He’s been retired from his COBOL coding banking job for years, but he’s still getting phone calls from staff wanting him to update his code and add more features to it. And he’s not alone. Most of the COBOL coders have retired and there's a shortage of them actively coding today.

But the financial industry is heavily reliant on COBOL. The same article says, “Over 80% of in-person transactions at U.S. financial institutions use COBOL. Fully 95% of the time you swipe your bank card, there’s COBOL running somewhere in the background.”

And it's not just FIs who rely on it. In fact, it’s hard to find an industry that doesn’t. The trouble, though, is that COBOL coding is monolithic and tightly coupled—making re-use of individual functions difficult at best. It’s rigid, not conducive to adding new technologies and lacks the agility and flexibility FIs need to innovate and compete.

APIs aren't new; they were initially created to handle a series of specific tasks. But they've evolved in exciting ways, going from using commands to interface with the code to using APIs. They enable an architecture that uses containerized applications built as a collection of loosely coupled objects that interact with each other to create the application—and they can also be easily re-used for extensions or in other applications. Their versatility makes innovation simple—they can work on cloud-based systems, computer hardware, operating and database systems alike.

Developers can build, connect and integrate applications quickly and at scale to extend the reach of the bank's financial ecosystem. This means it’s easier, faster and cheaper to build new applications or reuse chunks of code for other applications since the building blocks are already in place.  

What’s more, APIs can interact and communicate with existing systems. This makes it simple to quickly integrate new services, applications or niche offers to deliver the promise of digital-first without the need for a huge capital outlay to develop a specific in-house application.

This increased agility evolves the traditional banking model. APIs can extend beyond banking barriers and FIs don’t have to build out new services, products or experiences themselves—fintechs can help. By creating more partnerships with fintechs or niche providers, FIs can deliver more services and retain satisfied and profitable customers. The more partnerships you add, the more experiences you can offer. 

APIs hold the key to making digital transformation simple, fast and affordable. And using a containerized approach with Kubernetes combined with a continuous integration approach means FIs can quickly and easily deploy these new offers across their business.

While APIs and open banking are exciting, finding the best strategy to implement them is key. Selecting the right partner to help you make the most of these technologies involves taking a good hard look at where your FI is in terms of innovation and deciding how much assistance you’ll need.

Partnering with companies that have a developer framework and deeply understand transactions, for example, can save FIs a lot of effort in development and deployment. Such a partner can leverage their knowledge, expertise and years of development wrapped up in their APIs to build them out to meet your specific needs—as well as see additional opportunities to use them for more than their intended purpose or extend the APIs through a continuous integration pipeline.

For most industries, the last decade has seen technology dramatically change the status quo. And the financial industry has continued to face huge challenges in adapting banking operations to embrace (and keep pace with) the changing technological landscape. But there are plenty of opportunities for FIs to lead with innovation that can compete with fintechs and other disruptors, and it starts with APIs. They're a smart, fast and affordable way for FIs to innovate at scale—so easy, in fact, that FIs who embrace them might wonder what took them so long to get there.