IT due diligence for M&A deals
- As a result of externally driven transformations, consolidations through M&A transactions continue to increase in the financial services industry
- Due diligence in the analysis phase often focuses on legal and financial aspects and ignores IT as a critical aspect for long-term success
- Complications, arising from underestimating the technological due diligence, often lead to a lack of synergy effects
- Analyzing the IT architecture is a cornerstone of IT due diligence (IT-DD)
- The CORE IT-DD Framework makes a holistic assessment of the technological fit with the target object possible
With the financial market crisis of 2008/2009, banks changed from hunters to being hunted, from shapers to reactors. Banks are subject to a significantly changed regulatory framework, which ties up capital on the one hand and drives operating costs on the other. New players such as Fintechs and Big Tech are entering the market with new business models or more efficient business operations and are competing for a constant number of customers. The dwindling income from commissions is being supplemented by plummeting interest income due to the prevailing low level of interest rates.
One effects of this pressure can be seen in the reduced number of banks in Europe and the US - whether caused by their market exit, mergers with or takeovers by other institutions.
From 2009 to 2017, the number of banks in the USA has decreased by 28%, in Europe by 25% (Figure 1) (Handelsblatt, 2020), (Swiss National Bank, 2020), (European Central Bank, 2020).
The intensity of consolidation in Europe varies greatly from country to country. For example, France experienced a 41% reduction in the number of institutions between 2009 and 2017. In the same period the number of banks fell by only 16% in Germany. Yet a comparison of the absolute figures (European Central Bank, 2020) - 316 in Germany to 290 in France - makes it clear that a larger number of banks are exiting the market in Germany. In a detailed analysis, two key figures - bank per inhabitant and GDP per bank - suggest that this trend will continue in the coming years, especially in Germany and Switzerland. Crudely put, Spanish banks on average serve a large city, whereas in Germany they serve only a medium-sized town. Dutch banks manage four times the wealth relative to German banks.
The exploitation of economies of scale and synergies is one of the main motivators for mergers and acquisitions, not only in the financial services sector. Banks in particular offer vast synergy potential due to their inherent fixed cost structure. The often extensive branch and ATM networks, an individual core banking system and other bank-specific IT infrastructure are prominent examples of those fixed costs. Examples of other identical and very invariable cost centres are accounting, risk management, or the nowadays increasingly significant items regulatory, compliance and reporting in banks.
The consolidation of two or more organizations makes it possible to harmonize determinants of fixed costs and thus eliminate redundant fixed cost drivers. This way, a considerably increased number of customers can be served at fixed costs that remain the same or, as the case may be, have increased disproportionately. Thus, the costs per transaction decrease, profitability increases and consequently, on the level of the consolidated company, so does the profit, at least in theory.
The question of where and, above all, how theory and practice diverge inevitably directs attention to the IT infrastructure in banks. More than ever before, the IT infrastructure is a critical success factor for every bank. The core banking systems, for example, can be regarded as the linchpin of every bank - they are involved in most banking operations. Many of these systems are based on a mainframe infrastructure. This is not to be criticised per se, but these systems require specialists, who are often in high demand, and expensive spare parts for maintenance. They therefore make up a considerable fixed cost item. Modern technologies are also difficult to integrate, which is detrimental to flexibility and time to market. The costs in these systems to meet the constant pressure to change regulations and innovate on the product side are therefore considerable and ongoing and thus must also be regarded as fixed costs.
The dilemma is revealed in the deeper detail view: The IT systems of two banks in the merger must offer an identical or very similar functional scope; both banks ultimately offer the same products to their customers. If all products can now be mapped on one single IT system, a second system is obsolete, can be switched off and the associated fixed costs saved, theoretically. However, the low level of standardisation, particularly of the core banking system, prohibit a hasty yes to the question of the harmonisation of IT systems. Misjudgements here can result in rampant costs - from increased need for adaptation to the necessity of parallel operation for a few residuals.
The interrelationships described here as on the example of banks can be found in this or a similar way in other companies which offer standardised services with often self-developed IT systems.
As simple, obvious and tempting as the advantages of an M&A deal are, as many problems can hide in the details. The M&A literature is equally full of examples of success due to leveraging considerable synergies by merging two companies and achieving more turnover at relatively lower cost, as it is of examples of failure. In literature and practice, comprehensive and standardized frameworks for the execution of such a transaction can be found, which often divide the ideal-typical M&A process into the analysis, transaction and integration phases. However, as soon as the level of detail is increased, the practical execution is often completely different.
In fact, many M&A deals - despite theoretical knowledge and established frameworks - do not or not completely lead to the expected positive results after a few years. The success rates vary widely, but extensive studies indicate that more than half of the M&A deals show a significant negative deviation from the target (Meckl & Röhrle, 2016). Rarely is this fact causally driven by changed external factors or significant strategic mistakes. Instead, it is often mainly due to the fact that cost synergies cannot be leveraged as planned or additional revenues cannot be realized. The reasons for the low success rate are manifold. To name just two of these significant examples, in some cases systems are simply not consolidated as planned or a lack of cultural fit leads to overarching problems.
The managerial obligations require to examine whether and above all how the hoped-for synergy effects can be realised; also known as due diligence. Root and cause however, often can be found here already. In this first step of the analysis phase, the framework conditions for the deal are defined and thus the foundation for success or failure is laid. Studies have shown that in a large number of cases - whether due to insufficient focus or a lack of strategic and, in particular, technical knowledge of the subject matter - the anticipated synergies are assessed too optimistically. (Lewis & McKone, 2016) As a result the price paid in these cases is often too high, or attempts are made to realize the planned synergies in the wrong way. Inversely, it can be postulated that the parties involved should place a special focus on this phase.
Deals in which due diligence is generally underrepresented or not carried out at all are quite the exception. However, it can often be observed that the focus of due diligence is primarily on financial and legal aspects. These are undisputedly relevant areas, but at the same time the influence of IT on business success and synergies is often significantly underestimated. A noteworthy example of the possible consequences of underestimating IT in the M&A process is the purchase of the English bank TSB by the Spanish Banco Sabadell. Errors during the transaction phase in the IT-DD resulted, among other things, consequently in problems in the operational harmonization of the post-merger phase. This caused additional costs of £330 million. (TSB Bank plc, 2020).
Despite theoretical knowledge of this causal relationship, this is not an isolated case. Further studies show that in 51% of M&A deals no IT-DD was actually carried out [Ernst & Young, 2019]. And even if an IT-DD is carried out, most companies (60%) do not involve IT in important decisions (TUM - Technical University Munich; Deloitte & Touche GmbH, 2014) (Figure 2). The lack of an adequate IT-DD also makes operational harmonisation more difficult and thus contributes to the fact that in 70% of cases (Posnick & Schoenborn, 2007) of the cases no successful IT harmonisation is achieved. Since a large part of the synergies in M&A deals depend on IT (Sarrazin, Hugo, & West, 2011) consequently, many companies (47%) are dissatisfied with the IT synergy achieved and would be willing to allocate more money to the IT-DD ex-post deal [Ernst & Young, 2014].
To ensure a successful transaction, an improved methodology and execution in the transaction phase of an M&A deal is required. Especially in the financial industry, the evaluation of the technical aspect of a potential acquisition or merger is of high importance. Knowing about the above-mentioned interdependencies of IT systems in banks, based on project experience a technological framework has been developed, which answers the essential questions of a technical assessment in five dimensions (Figure 3).
An absolutely essential step before starting any due diligence is to determine the integration scenario. Depending on this, the main focus of the examination is determined. This provides the framework for the analysis - which can also be carried out independently - in each of the five dimensions.
In order not to go beyond the scope of this article, the examination of the IT architecture of the target organization will be explained in the following by way of an example. An extension of the catchy wedding metaphor for M&A transactions seems suitable to simplify these explanations:
If the signing of the contract of an M&A transaction is a wedding, which is celebrated eventually in a successful relationship, the due diligence is the phase of getting to know each other and growing together. The various stages include the first date, the first kiss, a holiday together and the first apartment shared by a couple. In the first part of the IT due diligence, the analysis of the IT organization, the protagonists of this love story get to know each other during a speed date. The basic compatibility of two people/organisations is checked. The central question of the examination is: Is there mutual sympathy? However, this first getting to know each other will not be dealt with in detail in this blog post, but rather the analysis of the architecture baseline is in focus. This step in the IT-DD takes place after the review of the IT organization, which means that the protagonists have come together after a successful speed-date and now the next step can take place: The first shared apartment!
The search for housing begins with the question of what kind of apartment shall it be: a cottage in the country or flat in the city, how many rooms and how big, old or new building?
Applied to IT-DD, this first aspect is the analysis of the basic principles of the architecture, i.e. software design, functionality, and scalability. This allows the potential of the software architecture to be evaluated. This is fundamentally important and can only be changed with difficulty in the further course of the project and thus contributes significantly to the success of the project.
"Software architecture is the set of design decisions that, if made wrong, can cause your project to fail." (Eoin Woods)
The aimis to identify procedural similarities and differences. These can be illustrated by a functional representation in a domain model. A potential compatibility between the systems can be identified by representing and analysing derived components and responsibilities by means of domain intersection.
If these requirements are given, the evaluation follows, whether the object of interest also corresponds to the further ideas. In the chosen metaphor of the search for living space, one has now chosen an object and the viewing is about to begin. How do you like the floor plan of the apartment, what is the height of the rooms and floors and what renovations are necessary? In other words, the evaluation of the general conditions.
Translated into the realms of IT system, the individual framework conditions can be divided into technological and professional ones. The paradigms for selecting the infrastructure, which hard- and software is available, as well as programming specifications of the custom solutions fall into the domain of the technical. The most important influencing factor of these technical framework conditions are the non-functional requirements, primarily performance, availability, and usability. The organization and structure of the IT departments, resources available, and standards fall under the technical framework.
The objective of this review is to determine whether the systems meet the common demand for non-functional requirements. The following questions must be answered in the end: whether the systems can handle the expected load, are available without restrictions during peak load, if optimal usability for the end users (user experience) is supported and whether modifiability and operability are guaranteed.
Compliance with quality standards of software development and documentation is hereby mandatory. A comprehensive analysis of the used tech Stack in this step is recommended to classify integration scenarios.
After this rigid and detailed examination of the property, one should broaden one’s gaze again and subject the surroundings to a thorough evaluation. Questions we ask ourselves when looking for an apartment are the link to traffic and local public transport, what are the shopping and sports facilities, are there schools or kindergarten and what is the internet connection like?
The environment is analysed using the context view (Starke & Hruschka, 2016). In this all systems and actors outside the own system, with whom direct communication takes place, are listed, as well as the delimiters from neighbouring systems. The consideration has to take place again from a business as well as technical point of view. The technical context here is formed by the technical functions and processes that are actually provided by the system and those in neighbouring systems. The technical view focuses on the communicating components of the system and the respective interfaces. Especially the clarification of the external interfaces is a difficult task; the error rate is high due to the level of detail, but the consequences are far-reaching.
The aim is to achieve a uniform and common understanding of the system components, their interfaces, data and access concepts. The responsibilities for the individual system components and their interactions must be defined in this process. The technical descriptions should be used as a basis for further discussion. Some questions for which answers are shown in the context view are: Which external systems must be integrated? What does the system do and what does it not do? Where is the system limit?
If a sufficient degree of fulfilment of the requirements at all levels has been established, the next steps are now to be taken to generate the desired benefit. In the search for an apartment this is quite simple: the signing of the rental or purchase contract. But even so close to the goal, there can be pitfalls: How is the deposit to be made, are salary statements to be provided or is a notary appointment necessary, are there any land charges and what is the concrete financing plan?
Translated to the IT systems, this is a little more complex and requires a solution strategy. This strategy puts quality objectives and their associated solution approaches into a relationship with each other. Decisions on the top-level decomposition of the system are made with the help of architecture patterns. A compact tabular representation documents formative decisions, concepts and views in order to meet the most important quality requirements for the IT systems. The solution strategy acts as a bridge between architectural requirements and the desired solution. The aim is to make important decisions, to regard these as the cornerstones of the architecture and to determine them as guidelines for implementation.
Even with dry ink on the contract, it's still some time until moving in. But already, on the way home, furnishing the flat becomes the talking point. Furniture stores are visited, blogs are read, sketches are drawn and discarded.
Translated to the IT systems, this is the step of the iterative architecture work. From an initially abstract vision, a detailed, concrete and solution-specific target architecture for integration is developed in a multi-stage iterative process. The decisions should be recorded as should the answers to the following questions: What exactly was the problem? Which alternatives were considered? What were the evaluation criteria? What was the decision? What compromises were made? This serves the comprehensibility of the decisions in order to not ignore decisive aspects in a further iteration loop or adjustment during the revision.
After carrying out the first aspects of the test, the couple is already a few steps closer to the wedding. But before the "I dos" are said and the M&A deal can be finalized, three more stages must be completed: the review in the software development department, the evaluation of the business & IT operations and the evaluation of the security & compliance department. The timing and intensity of the review of the individual dimensions depends strongly on the future integration scenario.
The relevance of an adequate due diligence as a key prerequisite for a successful M&A transaction is undisputed. A focus on market-side earnings and organizational savings potentials as well as legal risks often leaves the IT infrastructure unilluminated or looks at it piecemeal in a different dimension. It has been shown that the perspective can be dangerously narrow and can lead to underestimation of risks or overestimation of potentials. The complexity and organizational penetration make it necessary to provide IT systems with their own due diligence.
The wave of consolidation in the financial industry has on the one hand painfully highlighted the consequences of inadequate IT-DD, but has also created a wealth of experience. The blueprint of an IT-DD synthesized here can be easily transferred to other sectors and industries in combination with the expert knowledge of the respective professional domains; technical-architectural conditions are universal.
The pitfalls that continue to arise when conducting a framework-based IT-DD often lie in a lack of common understanding and shared language. The necessary focus on one's own IT systems often makes it difficult to understand the systems with which one wants to merge. It is therefore advisable to consult external expertise. In addition to technical and ideally industry-specific knowledge, any support should bring along the methodological competence that guarantees the targeted completion of the frameworks for an IT-DD. Skilful moderation by third parties can also prevent a suboptimal solution from being pushed through by the acquiring party in the often-predominant seller-buyer relationship.
In the above-mentioned financial sector consolidations to come, the buyers in particular have all the levers in their hands and can achieve successful integration and leverage intended synergies with the help of an IT review.
Ernst & Young. (2014). The right combinationManaging integration for deal success.
Ernst & Young. (2019). IT as a driver of M and A success.
Europäische Zentralbank. (2020). Statistical Data Warehouse.
Handelsblatt. (2020). Europas Geldhäuser.
Lewis, A., & McKone, D. (2016). So Many M&A Deals Fail Because Companies Overlook This Simple Strategy.
Meckl, R., & Röhrle, F. (2016). Do M&A deals create or destroy value? A meta-analysis. European Journal of Business and Economics.
Posnick, J. E., & Schoenborn, J. A. (2007). Executives Report that Mergers and Acquisitions Fail to Create Adequate Value.
Sarrazin, Hugo, & West, A. (2011). Understanding the strategic value of IT in M&A.
Schweizer Nationalbank. (2020). Jährliche Bankenstatistik.
Starke, G., & Hruschka, P. (2016). Arc42 in Aktion: Praktische Tipps für die Architekturdokumentation.
TSB Bank plc. (2020). Results, reports and presentations.
TUM - Technische Universität München; Deloitte & Touche GmbH. (2014). Dear CFO, why IT does matter within M&A transactions.