Legacy Systems are not the problem.
The problem may be 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.)
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: integrating with a core system is real and it is “now”. The problem isn’t legacy systems; it’s that bank managers don’t understand and can’t explain the current realities.
Think about this: community financial institutions have an extremely critical need to increase efficiency. I doubt there’s any opposition to this statement. 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) bank management is in denial of the legacy problem, that is, they don’t think the problem is “real”; (2) 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.
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. Are you sure you are 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. Either way, the loss is yours.
Marketing, IT, and Retail Support people haven’t been able to successfully communicate the need 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 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.
Of course, the larger point is that the bank needs a product to compete with the fintechs and that product can’t be developed with legacy systems, but only with the purchase of a core integrator. So, stop the loss by making it possible for the bank to compete with the fintechs.
By the way, this is an institutionalized mind-set, related to the old way FIs would get into the new product business: they would license an app from a third-party. That’s how banks grew into overdraft protection. They signed up with a third-party service provider who did the back office (which the bank’s legacy systems could not do) and the bank earned a fee. The difference now is that core integration makes it possible for the bank to build the app themselves—and if the bank doesn’t have a tech staff, then there are people out there, like me, who can handle that, get paid once and then be on hand to fix any issue that may come up.
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.
Management 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.
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 seven 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.)
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.
# # #
A&M Solutions has a 50 year track record of success in marketing, consumer compliance and marketing-tech. We built the first online deposit account app back in 2012 (which is still running with 99% uptime today). We understand how tech and bank marketing should work together.
30 Westgate Parkway, Suite 185, Asheville, NC 28806 | 828-230-5802