Technology Planning and Implications Involving Recent M&A Activity in Financial Services

By Siddesh Mahadik

Mergers and acquisitions are in the news again, and this time it is the financial institutions themselves that have been merged, or forcibly acquired in H1 2023 due to the recent banking crisis. Few notable examples include¹:

New York Community Bancorp/ Signature Bank (March)
First Citizens/ Silicon Valley Bank (March)
JPMorgan Chase/ First Republic Bank (May)
UBS/ Credit Suisse (June)

The Credit Suisse acquisition by UBS is the largest in financial services history, and it is the first time two globally systemically important financial institutions (SIFIs) have been merged. These recent bank failures, and subsequent acquisitions has significant impact on world economy. These mergers, often forced by regulators, were needed to keep the economy stable and avoid a repeat of the 2008 Lehman crisis.

M&A Impact Assessment

These merger & acquisition implementations are vast, complex, risky and difficult to manage. The runbooks offered are varied and manifold, but I will keep this article focused on the technology, architecture and governance implications.

At a broad level, for any such M&A, the impact assessment can be broadly classified into three main categories

Business model – which clients, businesses, geographies, products & services, channels do we continue to work with/in
Operating Model – what are capabilities, processes, sourcing models, vendor partners, controls put in place to operate
IT Model – finally the applications/platforms, information/data and underlying infrastructure needed to transition to the final target state

Every category merits a separate whitepaper of its own, but I will focus on the last layer, which is the IT /data implications of these mergers. There are other key considerations like culture, risk, financials, accounting, and legal that need to be addressed, but are outside the scope of this document.

The M&A lifecycle typically follows a 3-step process:

Pre-Day 1 due diligence
Day 1 close
And then culminating in the post-deal integration phase

Pre Day 1 Due Diligence

In this phase, the entities complete a series of due diligence checks to confirm that there are no red flags that could prevent the acquisition, or make it undesirable. From a technology point of view, this could include:

Affirm high level IT strategy can be aligned to that of combined organization post-acquisition. Understand potential synergies and duplication opportunities
Confirm there are no major security and IT risks (e.g., significant data leaks)
Validate tech spend / application capabilities / staff footprint is appropriate for the institution, or if any major correction is needed
Identify quick wins and help set up 90–100-day plans immediately post-acquisition

The due diligence phases typically lasts for multiple months, but it was highly accelerated and was closed in few days or weeks due to regulatory pressures in above instances. Care should be taken to ensure that information shared during this due diligence process cannot be adversely used by the acquiring entity if the M&A falls through. Hence, only relevant and sanitized information is typically shared post legal review via data clean rooms²during this process.

Day 1

Mergers, or acquisitions will typically have a day 1. This is the day when the legal entities of the 2 firms are formally and legally merged. Day 1 typically has certain minimum thresholds that need to be met including due diligence checks completed, regulatory approvals obtained, top level legal entity structure implemented, day 1 org finalized, certain critical reporting, regulatory and control requirements are implemented.

Efforts are made to ensure disruption to IT / IT changes is minimal to avoid any major business impact, often by change freeze, heightened awareness or exception approvals. However, IT will be need conclude the mandatory day 1 changes including the regulatory, risk and financial changes to be officially ready for day 1. This might include regulatory shareholding reporting, balance sheet P&L reporting, control room updates. In addition to functional changes, non-functional changes like increased volume and throughput will also need to addressed due to combined data loads between the 2 entities.

Post Day 1

Once day 1 is successfully concluded, organizations will typically start with some version of a 90-120-180-day plan. This in essence, is the next level plan to come up with a 2–4-year roadmap to completely wrap up the integration. It is in this phase where most of the actual technical integration work occurs.

Firms having mature business and enterprise architecture practices can usually accelerate their analysis as they have enterprise tooling, processes and repositories to quickly assess impact across the various business and IT dimensions³.

The organization getting acquired, is usually smaller and/ or failing, and hence may need to align with the acquiring organization and not the other way around. This implies that usually the starting point of the combined organization is the acquiring organization application portfolio, and will continue to survive, i.e., it will be the strategic target state. This may be considered as the preferred approach as it accelerates decision making and allows the firms to NOT end up with a case of “analysis paralysis.”

Moreover, it almost never just an application-to-application evaluation across the 2 firms. Other factors that need to be considered are total onboarding costs, integration costs, upstream/downstream dependency management, and delivery risks/ time. It may be perhaps deemed better that the acquiring organization’s at-par or somewhat sub- par application is selected to survive over the acquired organization, since the overall costs/risks of onboarding and integration will be relatively high. It could be perhaps cheaper, better and more efficient to enhance the capabilities of the subpar application instead with little to no additional integration.

Obviously, there will be certain exceptions to the application selection default bias, which could include:

Acquisition is done specifically for superior technical capabilities
It is a merger of equals, and every application/capability needs to be carefully evaluated
Acquiring org does not have any technical capabilities (manual processes), or is significantly sub-par

For scenario #2 (merger of 2 equals/ similar scenario), the application/ or application portfolio between the 2 organization may need careful detailed evaluation, there are multiple parameters that need to be considered, and could be its own deep dive topic. Typically, focus will be business alignment (customer and client coverage, product features, business model fit), total cost of ownership, IT enterprise alignment (platform bias, vendor vs. in house, application modularity), time and risk to integrate/decom.

Roadmap Planning

As part of the 90-120-180 day plan, the 2 organizations will typically collaborate and come up with a roadmap for the next 2-4 years to consolidate, rationalize and “right-size” the application footprint. It will usually include work slotted across the four categories below:

Lights on: This is absolute must do work to keep the application running and stable. This includes critical upgrades, patches, vulnerability fixes, BAU support, bugs and minor maintenance changes
Continue Build: Businesses still need to make money, be compliant with different regulations/polices and excite end users. All this requires building new features into the application or product. While this is mostly done in the target state/surviving application to minimize regretted spend, there may be valid scenarios to continue the build out on interim/to retire application. This could include work that is
1. committed to regulators and cannot be rolled back
2. address serious control gaps /deficiencies/ audit points
3. harmonizes logic/rules/features in the retiring app to the target state product as an interim step
4. Needed to meet a significant business opportunity, even if all/most of it can be considered regretted later (for e.g., build $1m application to receive $50m in annual revenue)
Integration: This includes integrating the application, and more importantly the plumbing of the application to the upstream /downstream data providers. This may require data model changes, historic data loads, data transformation & validation changes, and will relevant for both retiring and target apps
Decommission: Many of the applications will need to be eventually decommissioned to reduce the application footprint, especially where is significant overlap between the 2 firms. Decommissioning an application/product is usually not trivial work, and requires lot of planning and coordination and includes archiving data into strategic archival repositories, refactoring/archiving codebase, removing inventory entries and permission roles, exiting contracts and license arrangements and shutting down infra including servers/HW/SW

Many of the applications will get deemed as non-strategic post the 90-120-180 day plan, and hence enhancing and future proofing these applications will have very little purpose. The Change book of work for these applications will be halted, and resources will be pivoted to strategic apps, or integration/decom/lights on work.

Organization Model

Once the muti-year application roadmap is created, teams from both organizations will typically collaborate, often working closely together in an agile manner to implement this roadmap. The level of cohesion across the 2 organizations will increase as time goes on, usually following the below pattern:

Day 1: separate distinct teams/organization managing separate app portfolios with little to no governance changes. This is needed to keep the applications up and running, and have clearly defined roles and responsibilities as communicated to regulators / stakeholders
Interim state Post Day 1: Individuals get embedded across the 2 organizations with enhanced oversight/governance from a revised governance model. Staff transition will typically happen over multiple phases from lights on portfolio to strategic portfolio. A residual team will remain to carry out decom and integration work
Fully Integrated: Teams operate in unison across the entire organization with single governance and reporting structure. Legacy governance/reporting lines/ team and apps cease to exist

Org model evolution for Organization A acquiring Organization B

Conclusion

Every integration journey has its own unique set of risks, issues, challenges and timelines but many if not all the themes (Day 1, Post Day 1, Org Model change, Roadmap Planning) be common for this transition. The intent of this article was to give a glimpse into the technical, architecture and governance complexities and challenges as the firms embark on this transformation.

About Author

Siddesh currently leads the Employee Conduct organization within Compliance at Credit Suisse and is based out of NY. He leads a team of 20-40 engineers, architects and product managers across three continents to build compliance products and facilitate the UBS-CS merger. He has 14+ years of technology experience leading complex projects including integrations, divestitures, managed services, and outsourcing arrangements. He has led multiple technology strategy and architecture engagements for senior business and IT stakeholders. He holds a Bachelors in Computer Engineering from Mumbai University and Masters in Information System from Carnegie Mellon.

The views represented in the article was held by the author alone, and may not represent the views/opinions of his/her employer.

References:

1: https://www.ft.com/content/fe55c9d0-31de-44b8-840d-f972fcdef0b9

2: https://www.ey.com/en_us/mergers-acquisitions/how-to-realize-synergies-sooner-with-a-clean-room

3: https://www.architectureandgovernance.com/elevating-ea/accomplishing-a-successful-ma-using-enterprise-architecture/