Merger Integration: Ensuring a Smooth Transition

In the past 20 years, history has proven conclusively that when a bank merger fails, it’s usually for one of two reasonsu00e2u20ac”the acquirer either paid too much, or it botched the integration of the acquired bank’s technology after the deal was done.

The pace of banking industry consolidation has slowed considerably in recent years, taking with it some of the sky-high premiums that acquirers paid at the market’s peak in the late 1990s. And that’s a good thing, because there is a strong correlation between price and success in the bank merger business. A successful merger is one that delivers a higher rate of return to the acquirer’s shareholders within a reasonable period of time. Paying too high a takeover premium usually forces the acquirer to rush the integration process to quickly eliminate excess costs, thereby avoiding any negative impact on its own shareholders. And in this particular undertaking, haste frequently leads to costly mistakes.

But the integration challenge remains, and it’s nearly as difficult as ever. Certainly the most experienced acquirers have honed their integration skills. “Banks have learned a lot over the past 20 years,” says S. Kere Lewis, a managing director at McLean, Virginia-based consulting firm BearingPoint Inc. “It has become a core competency.” But if the industry’s most active consolidators have gained a level of competency through sheer repetition, it’s also true that technology integration has become more complicated as the industry itself has changed. “Twenty years ago this stuff was a lot easier,” says Greg Chestnut, a partner at the New York-based consulting firm Accenture. “Mostly you just had branches. Now you have large ATM networks, call centers, the Webu00e2u20ac”and putting them all together is a challenge.”

There is a myriad of decisions that must be made during a post-merger integration project. How many call centers or data-processing sites should the new bank keep? Which bank’s loan processing or teller platform system is superior? In most cases, the acquirer has a strong preference for its own technology infrastructure, because that’s what it knows best. Lewis says that an acquirer is often forced to choose between one of two imperatives. Should it try to accommodate the functionality of the acquired bank’s technology platformu00e2u20ac”saving, for example, a unique Internet banking feature that its own system lacks? Or should the acquirer simply move all the acquired bank’s customers to its various banking systems in an effort to rationalize the combined technology infrastructure as quickly as possible and cut costs?

Most acquirers prefer to retain their systems whenever possible “so they’re not running two [technology] shops in the same house,” says Lewis. This is generally the quickest path to post-merger cost savings. But when the acquiring bank chooses not to retain some functionality that the acquired bank’s customers have come to value, it has, in effect, taken something away from them. “This is the key business risk around the conversion exercise,” Lewis says. “It’s based on keeping as many customers as you can. At the end of the day, you don’t want to set the acquired bank’s customers back.” While there is not necessarily a right or wrong approach to this problem, it needs to be thought through carefully.

Indeed, planning and forethought may be the single most important ingredients in a successful post-merger integration. And according to Chestnut, the planning process must start during the due-diligence phase, which is when the acquirer needs to take a close look at the target’s entire technological architecture and decide how the combined bank will operate. “Basically you’re designing the new bank and what it will look like,” he says. And when these design decisions haven’t been made before a deal is struck, “it can make the business case [for the merger] more difficult,” Chestnut adds.

Once a deal has been agreed upon, the next step is a rigorous mapping exercise where the features and functionality of the acquired bank’s technology architecture are plotted out in detail and the post-merger plan is put together, including a schedule for completion of the various phases. “The business and technology people from both banks need to do this,” says Chestnut.

In fact, the most difficult aspect of post-merger integration isn’t the technical requirements of, say, migrating Bank A’s branch customers to Bank B’s retail deposit systemu00e2u20ac”it’s project management. Creating and executing a highly detailed plan to combine the technology infrastructures of two banks is an exercise in process management. It’s the complexity of the undertaking itselfu00e2u20ac”with thousands of separate tasks that must be performed by hundreds of people working under pressure to meet tight deadlinesu00e2u20ac”rather than the underlying technology that makes post-merger integration so challenging. And this is why active consolidators are generally better at it. They simply have more experience.

Large, active acquirers also tend to have dedicated integration teams that have refined the technique of project management in a bank technology environment. Not surprisingly, this same capability is often lacking in smaller banks that have relatively little merger experience and can’t afford the luxury of a dedicated integration team. Part of the problem is experience, but another factor is the culture at many community banks, beginning with the fact that most of them have lean staffs. “It’s a big deal to pull senior management out for half a day and plan,” says Darla Brogan, a senior consultant at Louisville, Kentucky-based Professional Bank Services.

As with their larger counterparts, Brogan says it’s crucial that community banks go through the same mapping process following an acquisition. But, she concedes, this can be quite difficult when its senior managers have relatively little merger experience, or have never worked in a larger organization. “It’s hard to envision what [merged companies] will look like when you’ve never seen anything else,” says Brogan.

One solution to the integration problemu00e2u20ac”particularly for smaller banks that lack the resources or experience to handle this undertaking on their ownu00e2u20ac”is to rely on a technology vendor for help. Fiserv Inc., a Brookfield, Wisconsin-based outsourcing firm that provides transaction-processing services to approximately 1,500 banks and software to another 1,200 banks that do their own processing, often is called upon by its clients to help with integration projects. The company does about 200 technology conversions a year for banks, thrifts, and credit unions, according to Pat Foy, president of the bank service group. About half of those projects are the result of an acquisition, and the company maintains a group of merger specialists that is available for conversion projects. Instead of developing their own post-merger-integration core competency, smaller banks can rent it from Fiserv.

Fiserv will even create a dedicated integration team for its bank clients that are active acquirers. One such client is South Financial Group, a $9 billion banking company headquartered in Greenville, South Carolina. Southern Financial bought three community banks in 2002u00e2u20ac”two of which were in Floridau00e2u20ac”and Fiserv handled all three integration projects.

Banks are generally reluctant to attempt system upgrades during an integration project since it makes the process even more complicated, but working with a vendor may facilitate this objective if the vendor provides the software. American Management Systems Inc. in Fairfax, Virginia provides banks with a suite of products across the credit-granting function. Two of its clients were Wachovia Corp. and First Union Corp. Wachovia was using an older version of AMS’s loan servicing software, while First Union was using a customized software application that it had developed on its own.

After Wachovia and First Union merged in May of 2001 (keeping the Wachovia name), the integration team decided that the new organizationu00e2u20ac”which was roughly 30% largeru00e2u20ac”should upgrade to a more recent version of the loan servicing application that AMS was developing jointly with the old Wachovia. AMS handled the software installation in 2002, explains George Schindler, a vice president for banking and credit at the firm, and the First Union loan files migrated to the new application once the installation was complete.

The new bank chose to upgrade an important application during the integration process in part because it was worried about the scalability of the older AMS software as the new organization continued to grow. But if the new bank had not been able to rely on a technology vendor like AMS to handle the conversion, it’s doubtful whether it would have chosen to upgrade. Says Schindler, “This freed [the new] Wachovia of the burden of integrating the loan servicing platform so they could focus on growth.”

Who Do Youu00c2 Call?