EDITOR’S NOTE: Prior to joining BankBeat as a contributing editor, Anna Burgess Yang spent 15 years as a senior implementation specialist and product manager at a fintech company, where she provided risk management guidance to community banks. We asked her to dip into the well of her experiences managing software integrations to help our readers understand the myriad challenges that emerge, from a technology perspective, when two institutions come together.
During the many years I spent working with community financial institutions, providing guidance around technology and risk management solutions, the number of mergers and acquisitions steadily increased. I would receive a phone call or email informing me of the merger after it was publicly announced, the gist of which was this: “We’ve bought a bank/sold our bank — now what do we do about the software solutions we have in place?”
Equally important to the merger of the bank’s assets and people is the merger of technology. And this is an aspect that is often treated as an afterthought. I worked with one community financial institution, and during the consolidation of their systems, the point-of-contact said to me: “We did all of our due diligence on the bank … but we didn’t look at their technology or processes until after the deal closed. And it has been a lot harder than we anticipated.”
Some banks would come to me with teams and a clear vision for the merged technology. Some would have an idea about where to begin but needed guidance to ensure everything ran smoothly. And some would contact their technology vendors about three weeks before their merger was scheduled to take place and say, “By the way, we’re merging.” (Hint: Don’t take this approach.)
While every bank merger is unique, there are some steps that would occur in nearly all instances. If you find your bank on the buying or selling end of an acquisition, think of this as a “playbook” to merge your technology. After all, technology is a critical component of what makes the bank run.
1. Identify all current technology
The first step toward merging technology should be to form a team that can perform an assessment and make decisions. This team should include IT administrators and representatives from each department who rely on applications to get their work done. The team needs to identify all current applications and environments used by both institutions. You’re looking to answer these questions: What is used? Where does it reside?
The environment questions (server-based, cloud-based, hybrid cloud, hosted, etc.) fall primarily to the IT administrators to answer. What the team needs to know for selecting technology going forward is the merged institution’s overall attitude toward the environment. For example, is a cloud application preferred, or should more weight be given to the features and benefits of the product or solution?
The team should then make a list. Core providers, account opening, and loan document platforms are likely at the top, but what other technology does each bank use? What systems are used for underwriting, tickler tracking and reporting? Do either of the banks image their loan or deposit documents?
The merger team should be considering: 1) where there is overlap (both institutions have different systems for the same bank function, such as underwriting), and 2) where there are gaps (the technology may not have been necessary before, but will be needed in light of the larger merged institution).
2. Review contracts and inform all vendors
Many vendor contracts have strict notification requirements for cancellation, or are multi-year agreements. From the compiled list of technology, each institution needs to review every related vendor contract. If the contract cannot be located, reach out to the vendor for a copy and request information regarding notification of termination and contract length.
Requesting such information will likely set off alarm bells with the vendor, but better to be upfront. As soon as you are publicly able to do so, inform the vendor of the pending merger. Some contracts have clauses regarding what happens to the contract in the event of a merger, particularly if pricing is based on asset size, number of locations, number of seats, or amount of data.
If the notification period for termination is imminent, ask the vendor what needs to occur to notify of potential non-renewal while you evaluate your options. Ask if longer contracts can be renewed for shorter periods to allow your merger team time to review. Most vendors would rather work with you in the short-term, in hopes of retaining your business, than play hardball and risk losing the business of the now-larger merged institution.
3. Complete vendor review and assessment
Every application should be assessed through the lens of the new, merged institution’s needs. One institution may have had a large agricultural loan portfolio, while the other may have been mostly commercial, so the underwriting needs were different. Retail products offered may be varied. The systems that may have worked for the separate institutions can no longer meet the needs of the combined institution. Sure, you could maintain separate applications and workflows, but that doesn’t serve a long-term goal of operating as a single organization.
When you reach out to the vendors of your various platforms, make it clear that you need to be “re-sold” on the value proposition. While the application may have some internal expertise within the organization that uses it, the knowledge may not extend to additional use cases. In other words, the ag lender may not be able to properly assess if an underwriting system will meet the needs of new commercial lender counterparts. Better to let the vendor show you how the application will serve both lenders. And in the process, you may learn how the application can also serve a larger institution in ways that hadn’t been considered (or needed) previously.
It is also important for the evaluating team to consider new solutions altogether. It is possible that existing systems cannot meet the combined needs of the merged institution. While adding something new into the mix sounds overwhelming, the go-forward needs must be the ultimate goal, rather than forcing products to work that fall short for the merged institution.
Fortunately, you can buy some time. If you determine that neither bank’s current solutions are the best fit during the assessment, set that project aside. Rather than rush through finding a new solution, put it on the calendar to begin a search and find a new solution within six months to a year. Let each institution continue to operate on what works for them in the meantime, provided that the disparate systems don’t create too many internal headaches.
4. Decide how to handle the data
No matter what solution you choose — from either one of the existing bank solutions or a new solution — you’ll need to determine what to do with the data. Each bank may have had its own tickler system, and one of the two is selected as the go-forward solution. But what happens to the ticklers stored in the other bank’s application?
The process of moving data is commonly referred to as a conversion. Core conversions are the mission-critical project of a bank merger, but many conversions will simultaneously occur among the other technology solutions. Banks have three options when it comes to converting data.
Programmatic conversion. Banks work with their vendors to extract data from one solution and move it to the other solution. One or both vendors may charge for these services, but this process saves a lot of time.
Manual conversion. Banks move the data from one solution to another manually, re-keying all of the data in the chosen solution. This is often a result of the cost associated with a programmatic conversion but requires a lot of effort by bank staff.
Do nothing. There are instances where the data in one solution is not worth migrating to a new solution. This is often the result of poor usage of the product. In this case, the merger team recommends a “start over” approach because the data is unreliable.
Another scenario is that one of the two banks does not have a system in place but relies on a tool such as Excel. Going back to the tickler example, one bank may have stored its data in a dedicated solution, while the other bank had a series of spreadsheets. The data outside of a system also needs to be reviewed, considering the same three options above.
5. Develop new internal processes
No matter what go-forward solution is chosen, any internal processes will need to be reviewed in the context of the merged institution. Every bank is nuanced in its approach to processes, from timing to how data is entered.
The merger team should consult people who use the current systems on a daily basis. A reminder for an annual loan review may be “padded” by 60 days prior to its actual due date. These details are likely only known to the people who use the system.
The users need to come together and decide on a go-forward plan: Who will complete the work? What are the various tasks to be completed? When will that work be done? How will consistency be enforced among the newly merged team of employees?
6. Complete internal training
The final step is to complete internal training for all bank employees that will be using the system of choice. Even for those who may have been using the system previously (if it was already in place), the new processes need to be introduced.
Change is hard, and with so many balls in the air during a bank merger, it can be easy to prioritize technology behind other projects or only focus on the major systems like the core accounting system. Existing products can often be overlooked, and then it becomes a scramble to determine how to move forward. Considering all technology early in the process should make the transition as smooth as possible for everyone.