Legacy Systems are not the problem.
The problem is likely you.
I deal with this “legacy system” issue almost every day. The common complaint is, “Our systems won’t let us do this.” But, in the last three years, that excuse has become hollow. (By the way, I’m talking about community banks. That’s what I know. Big banks are not my thing, and besides, those guys aren’t exactly limited by anything, except perhaps, the inclination. NOTE: this principle applies to a lot of companies, not just financial institutions.)
There are, in fact, reasonable and reliable solutions for community banks (both big and small) to “un-silo” their legacy core system . Our company builds them. Boomi builds them. Jitterbit builds them. Other companies do the same. There are systems out there for every platform. The bottom line: the ability to integrate with a legacy (or core) system is real and it is “now”.
The problem isn’t legacy systems; it’s that company managers don’t understand and can’t explain the current realities.
Think about this: companies, especially financial institutions, have an extremely critical need to increase efficiency. I doubt there’s any opposition to this statement. For a financial, two areas that cry out for a heavy dose of efficiency are the deposit and loan operations area.
I have clients who have an automated loan and deposit application system. However, once the application is approved, their loan and deposit ops people still have to manually input the data from the app into the core system. Am I the only one who thinks this is crazy?
Yet, for all the compelling reasons to automate the process, nothing is being done.
So, why all the foot dragging?
In my experience, it’s a combination of three things:
(1) top management is in denial of the legacy problem, that is, they don’t think the problem is “real”;
(2) middle management, those that do recognize the issue for what it is, haven’t learned how to make a strong ROI case for the investment into core integration for third-party apps; and
(3) there’s a suspicion that core integration will cost a fortune. Let’s un-pack those reasons.
Typical top management reaction: We’re doing OK with our legacy systems. Nobody is complaining. Maybe we’re siloed, but, what the heck, how bad is that?
Uh, if that’s how you really feel, then there’s really nothing I can say. It’s sad, but it is what it is.
But something to consider: fintech companies have taken lots of core deposit business from community institutions because they offer products and services that can’t be done using a legacy system. We’re talking about companies like Digit, Acorns, Zelle, and Square. And forgetting the deposit dollars for the moment, think about the exchange fees the bank is losing. Is top managment really OK with that?
Maybe your customers aren’t complaining. But I guarantee you they are taking money from their deposit accounts and giving them to fintech companies. (iN 2022, almost have of people who have a long-standing banking relationship are actively using a FinTech to pay bills, make purchases and transmit money. Either way, the loss is yours.
Middle Management (Marketing, IT, and Retail Support people) haven’t been able to successfully communicate the need for legacy integration to management.
Preparing a project proposal is not easy. Nor is it simple. It’s hard work and requires some focused time to analyze, calculate and present. So, I get it. But there are ways. What has worked for me for banking clients is to go get the ACH logs for your OLB customers and aggregate all the transactions to money-service offerings, to fintechs like Digit, Acorns, Zelle and whomever. The frequency and amount of those transaction will be an eyeopener. The idea here that any manager who has loss-aversion syndrome, will be repelled by the regular loss so many deposits—and the loss of exchange fees, as well. (Same principal applies to non-bank companies. The key is to find and demonstrate the dollar loss. That usually gets top management’s attention.)
What about the cost of core integration? Isn’t it about the same as the budget for the State of Wyoming?
That was a joke, right? (Wyoming’s budget for 2022, by the way, is said to be a bit more than $2.5 Billion.) Here’s the thing, a core integration is often done as the same time as at least one functional transactional application. For example, if you have a CRM, then that is probably attached to a core integration. If you have automatic ACH processing, that also likely has a core integrator in the mix. In that case, the cost of integration is added to the cost of the functional application. (We’re actually talking about APIs here, just to be clear.)
The true efficiency comes when you build a core integration you can attach to multiple applications. In other words, you have a one integration to many applications. This opens up all sorts of possibilities: real time CRM integration, booking loan and deposit application directly (without manual re-keying) to core, integrating BSA/AML surveillance system and many, many others. And it’s that kind of core integration (API) of which I speak.
OK, fine, now to the money part: the core integrator program package, by itself, is in the range of $25,000 to $50,000, depending upon the bank’s computer server configuration. Then, there’s the application cost, which can range in the $25,000 to $125,000 cost–I know that’s a wide range, but some of today’s applications incorporate a heavy AI component, and at the moment, those cost a lot of bucks; most applications are closer to the bottom range of costs.
I realize I have a dog in this fight.
Nonetheless, in my way of thinking, core integration is within the means of most institutions.
Here’s what I think is a solution to get institution management actively (and positively) looking at core integration.
Financial nstitution management, to continue with our example) has to be helped to understand the connection between the following issues:
- The loss of deposits and exchange income to fintech competition, including the monthly and annual total.
- The loss of exchange fees.
- The cost of inefficiencies in the current way manual processes are used.
- The cost to add the integration, both in the first year and five-year projection.
- The dollar amount of savings introduced by the integration plus the application.
What has worked for us?
We do a scoping project that digs out all the information above and turns it into a pro-forma data table. We also provide a Technology Summary that lists the tech stack required to build and connect our tech to the client’s core. Importantly, it also scopes the cost to the company of the employee’s time to install and train on the new system.
Then we dump that into a nice, clean, Board-quality, ten-slide PowerPoint deck with a one-page leave-behind summary. The run time of that Board presentation never exceeds ten minutes.
Sometimes our prospective client takes the deck and runs with it. Other times, we get invited to make the presentation. In either case, the possibilities and the numbers are quite clear.
I often find Management is surprised to discover that we’re never talking seven digits; almost always we’re talking five digits. I’m convinced they mistake core integration for core conversion, which, if true, explains why there is this over-inflated concern about costs. (Not to mention the cost of plummeting employee morale.)
Assuming the favorable outcome of a prelim scope, we ask for $2,500 to pay for a real work scope that nails down all the costs (direct and indirect) and deliverables, including time to develop, install, test and de-bug. (We rebate the scope cost from the cost to do the integration and app development if the project is green-lighted.)
Conclusion
This “we can’t because our legacy systems won’t let us” issue is, for the most part, due to misinformation and—most importantly—misunderstanding of the current environment. Once management understands the actual numbers, they’ll realize they can afford it, and most importantly, it’s the right thing to do. And that’s the job of middle management: corral all the facts and make a dollar-centered presentation of the facts and implications.
# # #
