Community banks in today’s world are feeling a lot of technology pressure: they know they need to innovate to keep up with bigger banks and fintechs, but are often limited by their banking core providers. Legacy architecture makes it at best slow and expensive, at worst impossible, to pick and choose other software providers to work with. Many banks feel “stuck” using whatever products their core provider has built in, even if they’re sub-par.
According to the ABA, more than two in five U.S. banks still run their core banking processes based on back-end systems designed nearly 40 years ago. And while community banks are still of vital importance, struggles with technology is often cited as a reason why their numbers are declining as more and more merge or sell to larger banks.
At DocFox, we have these conversations every day with our customers. They rely on the strength of their community relationships and local knowledge to provide a better, more personal banking experience. They want a tech strategy that plays to their strengths. But how do they get around their core?
The Core Problem
When it comes to innovation at community banks, three things are true:
-
- The biggest barrier to tech innovation is usually the bank’s core
- Slow innovation limits the bank’s overall strategic ambition
- Not executing on strategy hurts the bank’s customer
To get around this problem, banks are faced with a few choices. They may be so fed up with their current core they decide to go through the pain of a full core conversion… but then end up stuck with a new version of the same problem, limited by whatever technology their new core dictates is available.
As an alternative, many banks use point-to-point integrations to work with new vendors, connecting each new system to the banking core and other critical systems. This strategy however, can become incredibly resource-intensive and create serious tech risk at the bank. While the first point-to-point integration may be relatively straightforward, every new system the bank wants to use multiplies the number of point-to-point integrations needed to keep each system communicating with the others. As these hard-coded integrations proliferate, the odds of something breaking go up, and the consequences get worse. Projects take longer to complete as the ongoing costs — and risks — of system maintenance snowball.
However, a growing number of banks have found there is a third option: using API-based middleware systems to gain freedom from the core. At DocFox, this is something we’re intimately familiar with, as our technology leverages the same types of APIs, letting us plug into a bank’s core (and other systems) on their behalf.
What is an API?
Before we go too far, let’s make sure we’re all on the same page about what exactly an API is.
An API, which stands for Application Program Interface, is the code needed to connect two different systems so they can exchange data. Think of it like a log-in screen for a system. While you’re used to logging into a system using a username and password, one system can “log in” to another system in much the same way using an API as the connection between the two.
While in the past, APIs were written by technical folks for a technical audience, modern APIs are easy to use, with standardized technologies and languages familiar to a large developer base. They are easy to enable, reuse, and self-service, and are the building blocks for much of the innovation you see today.
APIs can do many things, but the main use case for banks is as a multi-layered integration platform. By combining different types of APIs, the platform makes each piece of integration modular and easier to reuse in the future:
-
- Presentation APIs handle the presentation and formatting of data, whether for individual systems such as online banking, or a portal for external users. They are often lightweight and quick to produce.
- Business Logic APIs handle the logic for any particular business process and make it reusable. Think of specific, repeatable activities someone at the bank might have to do, like changing a customer’s address or issuing a new account number.
- Data Access APIs expose the data in underlying systems via an interface that provides access and makes it much easier, faster, and cheaper to integrate with those systems.
How APIs Can Set You Free From Your Core
Now that you know a bit about what APIs are, here’s why you should use them: APIs enable scalability and ROI well beyond their first-use case or the project that results in their creation.
With APIs, the true value is in how they can be reused on multiple projects. Let’s say you build an API allowing a customer to submit a change of address on your website. You then plug it into any system that would need to know what that new address is: your core, your CRM, your physical mail provider, etc. Once you’ve made that investment you can then quickly and easily add another set of connections to that same API — for instance, a presentation API to also allow customers to change their address from their mobile phones — without building an entirely new workflow integration. Similarly, once you have built APIs to access the data in your core banking structure, you can then leverage those connections for other use cases and no longer need to connect everything directly. If this change of address workflow is properly architected, it doesn’t matter which system the change is made in, it will automatically flow through to every other system you’ve connected to your middleware layer. Unlike previous point-to-point integrations, these APIs are less brittle and can keep integrations localized because each one is performing just one set of tasks.
Beyond that, APIs also make it easier to switch to a new system: from the simplest systems all the way up to your banking core. What if you want to remove a system in your tech ecosystem in favor of a new vendor? Without separate API layers, that requires breaking every single connection between every system it’s connected to, point-to-point. Then you’ll have to spin up the new system, and reconnect it to every other system it might need to communicate with. All before you can ever start using the new system. That’s a lot of pain.
Instead of “rip and replace”, middleware lets a bank “swap in and out”. This is because each system is only connected in one place – to the middleware layer. With APIs, you can connect your core systems to your current APIs and make the transition gradually, starting with testing groups before adding more and more users over time. At DocFox, we’re here to help in those transitions, and can consult when it comes to testing and strategy for success.
Finally, adding APIs is often key in facilitating Fintech partnerships or offering Banking as a Service (BaaS) products. An API-based implementation layer makes these partnerships dramatically easier and less costly for community banks.
Thanks to API-based “middleware” integration platforms, community banks relying on legacy core systems no longer have to stick with whatever software they get out of the box. Instead, they can take back control, deciding for themselves which vendors have the best systems to fit their bank and their customers. This enables banks to turn their technology from a weakness into a competitive strength, and offer their community a truly best in class customer experience.
Want to talk more about how smart API architecture can advance innovation at your bank? Want to learn more about how DocFox leverages APIs to streamline core integrations? Reach out to a team member today — we promise not to geek out too hard!
