Introduction

The economics of cross-border bank integration are inherently unpalatable in comparison with in-country integration.

• There is no chance of branch network rationalisation.
• There is limited scope for back office integration given the language issues needed for customer contact.

So the benefits have to come principally from IT cost savings. We at HowBanksWork.com believe in the following rule of thumb.

• Moving to a common systems platform for a pair of banks in two countries will fail any normal economic test (e.g. NPV, Payback, IRR). I.e. the IT cost savings will in no way justify the costs of systems development to integrate the systems of banks in two countries. This is in contrast with a merger between two banks in the same country where there is usually a good business case for systems integration project across two banks.
• Adding two new countries to a bank’s systems will probably break even in a reasonable timescale. However, since IT is normally the critical scarce resource in most bank investment projects it is still doubtful whether two new countries integration would get high up the investment priority list (for example in competition with new product launches, development of new channels, implementation of Image and Workflow systems etc.).
• Adding three new countries represents a good investment opportunity. I.e. the IT costs of having four countries on independent platforms are sufficiently high that sizeable savings can be made by putting them onto one platform. (Most investment banks acting across Europe have already moved to this state however the same is not true of retail and commercial banks.)

Graphically this looks like

 

To explain why the rule of thumb is the way it is we examine each of the main areas of the business case for cross Border Systems Integration, one at a time.

1. The elements of project cost of an in-country bank systems integration project.
2. The extra project costs of a cross border integration.
3. The effects of integrating more than one country on the project
4. The ongoing IT cost savings of a cross border integration.

1. Project costs of an in-country system integration

When two banks from the same country merge there are three broad areas of project cost.

• Target systems configuration and preparation.
• Migration Engine Development and running.
• Infrastructure Upgrade and “Saving” capacity

We outline what we consider is included under these categorisations in the next 3 sections.

Target Systems Configuration and Preparation

The target systems are the set of systems that the “moving bank” will have to end up on. In an ideal circumstance they would be the receiving bank’s systems unmodified; in practice a range of factors such as

• the legal entity and banking licence structure of the moving bank (will the moving bank retain its existing legal entity status)
• the internal organisational structure of the moving bank in terms of divisions and customer segments (will they be the same as the receiving bank)
• the payments settlement processes (are both to settle externally or will the receiving bank settle on behalf of both)
• customer data separation and competitive positioning of the two banks
• retention of any “moving bank unique” products and services

mean that a lot of cost is incurred in changing the receiving bank’s systems. Some of this change will be simple parameter value setting but in most commercial and retail banks quite a bit of this will involve coding and testing by IT departments.

Migration Engine Development

Whether the migration of the moving bank is to be phased (by branch, product, channel or function) or whether the migration is to be a “big bang” cutover, the development, testing and execution of the migration is a big cost. Given the volumes of data that retail and commercial banks handle there is bound to be some data migration software to be built and tested. There will also be significant manual business processes to complement the automated parts of the engine which will also be expensive. In a phased migration there will also be temporary interfaces developed to move data to and from the partially migrated bank’s old systems to its new systems.

Infrastructure Upgrade and Development

One of the main areas of IT savings will come from infrastructure and IT operations. (There will be the opportunity to close a data centre, to rationalise contracts for telecoms, hardware and software, and to cut technical support staff costs). Unfortunately there are up front costs to be overcome. An area that usually presents a challenge is the desktop fleet. At one extreme the entire moving bank’s branch and back office network, in terms of PC’s, servers and printers has to be replaced in order to support the receiving bank’s software. The best that can be hoped for is a mixture of software and hardware upgrades and given the thousands of such workstations spread over a mixture of head office locations and a branch network this is a substantial cost. In the data centres too there are one off costs as there will be requirements for “swing” capacity on data centre components such as mainframes, UNIX and AS/400 servers, routers, bridges and other telecoms switching equipment. This additional capacity has to be purchased to run the moving bank on the receiving bank’s systems but represents a “bubble” of cost because the moving bank’s old equipment cannot usually be released for quite a while.

Every bank integration is different but a reasonable rule of thumb is that each of these areas of cost could be about a third of the total. The minimum that a commercial or retail bank integration project within a country should cost would be at least £100 million with a big bank integration costing up to £500 million not unheard of.

2. The extra Project costs of a cross-border integration

In the previous section on in-country bank integration projects costs it was shown that the costs can be broken down into three broad categories. We believe the extra costs of a cross border bank integration are as shown.

This leads to the first cross border integration project costing some 75% more than that of an equivalent in country integration (however see section 3 called Project costs for integration with more than two countries for a discussion of project costs of subsequent cross border integrations).

Migration Engine Development

Is the most predictable in terms of the impact of the integration being cross border.

There is very little difference to the migration engine costs. The same data needs to be loaded into the target systems whatever the country of the moving bank.

The extra costs are essentially those caused by the increased difficulties in understanding of mappings:

• Data mappings
• Product mappings
• Process mapping.

These analytic activities are much harder when the two banks do not speak the same language, in practice this should affect the timescales more than the costs as it will take the up front analysis longer to get the mappings correct. (Clearly, if done wrong, the mappings could lead to “Extract Transform and Load” software rework and re-testing costs).

Infrastructure Upgrade and Swing Kit

The primary aim of the IT infrastructure departments of banks in a systems integration project between banks is to achieve common standards for infrastructure hardware and software. This allows economies of scale in central components such as server clusters and mainframes by running multiple banks and reducing the amount of knowledge and skill needed to support them.

In principle the cost of upgrading the infrastructure is much the same whether the moving bank is in the same country or not as it is nearly all supplied by international vendors such as IBM, Microsoft, Sun etc.

The big fly in the ointment is language and in particular special character support (e.g. £, €, ñ, etc.). Because the vendors mentioned above supply their infrastructure to all countries they all have pretty good special character support, however banks working in one country tend to be a bit careless about special characters. They will have written their applications with special characters hard coded into screens and reports software and often in files too (e.g. for electronic data supplied to customers). The infrastructure people can put the moving bank onto a different infrastructure with different code pages but this eats away at the point of IT integration. The alternative is to start spending money parameterising the special characters in the application software or putting in fixes in the infrastructure to suppress special characters – this costs serious money.

Target Systems Configuration and Preparation

The difference in cost between an in-country and cross-border integration on this area of cost is enormous; it is so large we devote a whole chapter to The Functional Developments that are required.

In addition to the functional development costs that are specific to a particular area of the bank there are two general points that can be made:

Language

In a European context it is impossible to force the staff and customers of a reasonable sized Retail or Commercial bank to cope with screens, outputs and documentation in anything other than the language of their country. Most commercial/retail bank systems in the UK and Europe have been written in house and are not multilingual (there are exceptions in Belgium, Catalonia, Switzerland). Generally they were written using a number of different formats and programming languages over many years but all assuming that the presentation language was never going to change. Rewriting all the screens and reports to become capable of supporting many languages is a major, not technically difficult, but expensive task.

Currency

Although the Euro has gone some way to reducing the plethora of base currencies in use across Europe there are still a lot to go;

• British Sterling
• Swiss Franc
• Danish Krona
• Polish Zloty

One of the main changes to do with currency (in addition to special character support such as €, £) is the concept of making the systems currency blind. Most of the domestic banking systems (e.g. current accounts processing, or standing order processing) do not have any concept of currency. The systems just add and subtract numbers. What gives them currency meaning is the inputs and outputs (screens and reports) and these need to be modified to become parameterised for currency as they will almost certainly contain hard coded representations of currency.

The other main area to do with currency is related to the implicit assumptions of base currency. A lot of systems that have to be currency aware (e.g. foreign currency account systems) are written with the receiving country’s currency as base currency hard coded. (For example UK banks will use and manipulate exchange rates in a ratio peculiar to that country rather than the convention used in the other European countries). This sort of processing has to be generalised in a systematic way across all systems that have to be currency aware so that no implicit assumptions are made about the base currency of the system.

3. Project costs for integration with more than 2 countries

As will be seen in the Functional Differences section, and the Modification to Target Systems Configuration and Preparation section, there are important software changes to be made and the approach to making the changes can make the second and beyond bank integration easier or harder. For example, an approach might be to take a clone of the receiving bank’s systems and then modify them such that they can support the new bank. This would lead to higher IT support costs in the future as the receiving bank would have two similar but different sets of systems to support. A lower future cost of ownership model would be to re-engineer the receiving bank’s software so that it can handle both banks. This would be made by making explicit various aspects of the system that are either assumed or that are specified differently in different parts of the receiving bank’s system. An example might be the concept of country of banking operation. Most banks do not have a specific table with country of operation stated as a data item for use by their main customer accounting systems. If they did it could have a number of associated attributes such as

• bank holiday data
• currency
• savings tax rate and other tax rules.

This data would be automatically populated to a number of systems as each bank was configured into the system. This is an example of “generalising”, i.e. making the systems better able to cope with future change. It is expensive to implement because, in this example, each reference to a country specific attribute such as a bank holiday table or some lines of code on tax would have to be re-written to make use of the “country of operation” table. Having achieved this expensive one time change to generalise the country of operation, future countries of operation should be added at much lower cost.

It is expensive to modify systems to generalise things, however it would make adding future change cheaper. The IT department will normally make a trade off between generalising the software and “bending” the existing systems to get the moving bank back on in a reasonably quick timescale. Also not all aspects of generalisation are needed to take on a particular cross border bank. For example Irish and English banks have a common account numbering structure and German and Austrian banks have a common language. The result is that after third additional country the receiving bank will probably have generalised most of the concepts needed so that future integrations of countries are relatively easy.

Graphically this looks like;

 

If a bank undertakes a cross border integration and then integrates with another bank in the same country this second integration is much more like an in-country integration as all the difficulties of providing an IT service in the new country have been overcome.

4. Ongoing IT Cost Savings in Cross Border Integrations

There are two broad areas of cost saving in IT when two banks integrate

• A reduction in IT operations costs as a result of data centre closures, lower staff costs from having common infrastructure components and lower contracts costs from greater economies of scale from suppliers.
• A reduction in the annual application development costs as two different sets of software do not need to be maintained, enhanced and developed.

Both represent about 50% each of the annual IT savings costs that can be achieved through a Bank systems integration project. When the bank integration project is cross border the savings that can be achieved are a bit smaller than that of equivalent sized in-country integration, but not a lot. Furthermore the savings per country do not change much as extra countries get added.

Graphically this looks like;

 

 

If a bank does a cross border merger and then merges with another bank in the same country then the ongoing IT cost savings are effectively those of an In-country integration as the receiving bank now has all the infrastructure to support one or more banks in the newly acquired country.

The reasons for the differences on the IT operations side are

• There are extra international telecoms costs caused by data centres having to support a foreign country that are not incurred with in-country rationalisation.
• There are some desktop, ATM, and Branch support costs that can be rationalised in an in country integration because of overlapping geographies of branch networks. This should not be overstated however as most of these activities are outsourced and priced per workstation.
• There will be some need for country (language) specific help desk support which could lead to slightly higher running costs for a cross border integration than for an in-country integration.

On the application development side

• With each extra country there will be some country specific mandatory change to be handled (Government reporting, tax issues etc.).
• Because of Geography and language differences there will be an inherent lack of efficiency in the analytic processes in developing new systems (and/or modifying existing systems) that are to be common to both sets of countries.

Conclusion

We believe we have shown that:

1. The project costs for a cross border integration are higher than for in-country integration and why that is so.
2. The project costs for cross border integrations decrease with each additional country that gets added so that the fourth or more country will normally cost no more than an in country integration.
3. The IT cost savings for a cross border IT systems Integration are less than in country merger and do not vary much per country as countries get added.
4. The overall business case for a cross border IT systems Integration is substantially worse than an in country merger. The case becomes progressively more appealing the more countries (i.e. banks in countries) that can be added.