Driven by a strongly increasing number of private banking customers in the 1960s, first systems which could process large amounts of data have been adopted in banks. 

These systems were mainframes (see [1]) and used terminals and punch-card-readers as input/output devices [HEU06]. The mainframes’ primary purpose was to process the data which has been entered via punch cards. The systems could calculate the current balance as well as the interest accrued by batch processing the data. All systems were designed account centric with one punch card representing one account. 

Many of the systems which we now refer to as legacy systems have been built in this phase. According to [GRU02], legacy systems are continuously adapted mainframe systems which could only be renewed or replaced by taking a disproportionately high effort. Because many companies avoided taking effort to replace legacy systems they are still remarkably present. This leads to the fact that COBOL, which is a programming language used for many of the early banking systems, nowadays is still of importance for IT in banking. Also hardware-oriented languages such as assembler have been used for system development [MOR05a].  

Nevertheless, the complexity of these mainframe systems at that point of time was rather low because account keeping was the only real application. Mainframes were rarely connected and the needed functionality for basic accounting operations was limited. Because of high storage prices the focus during the development was to optimize memory usage. The business environment faced by banks at that time was rather stable which led to few necessary changes on the systems [MOR05a]. 

During the 1970s different applications have been added to the account processing systems. These systems were designed according to the division loans, savings, and securities which evolved at that point in time as shown in [1]. The applications were still executed at the mainframe which made it necessary to share processing time between them. Time-sharing data processing frequently allocated a very small amount of time to each application [MOR05a]. Therefore, it was possible for employees to simultaneously run their applications on the mainframe. Like in the previous phase terminals still acted as user interface [HEU06]. 

On top of the different applications for account management new applications for order processing and order management for loans, savings, and securities have been developed in the 1980s [MOR98] as shown in [1]. Moreover, employees have been able for the first time to directly access data on the mainframe using fourth generation languages (4GL) such as SQL. With the emergence of PCs much more power was given to the user which led to a more personalized way of data processing. With word processing applications and spreadsheet processing applications this power was only tentatively used, though. 

At this time complexity of IT systems was getting comparatively high for the first time and the industry faced serious changes. The necessary adjustments on the IT-systems were only possible with unreasonably high effort [HEU06]. 

The introduction of PCs resulted in a client /server architecture in banks in the 1990s which were affected by the emergence of the internet [HEU06]. Banks intensified their electronic networks, nationally as well as globally. Object-oriented programming changed application development within the banks. Workflow systems were added on top of the order processing and order management systems resulting in additional complexity as shown in [1]. 

Banks also started to interchange via electronic data interchange (EDI) with their customers. Business customers demanded EDI in the first place. With the internet boom in private households, the first generation of e-banking applications for private customers was offered [MOR05a]. In the following years the number of private banking accounts used over the internet outgrew the number of business accounts used over the internet by far [WIL04]. The fast changes of the IT environment and the heavy demand for EDI solutions made ad-hoc solutions necessary, thus resulting in almost unmanageable complexity in many banks. [HEU06] reports that Credit Suisse, in this phase, used more than 600 applications developed using different technologies. These applications implemented partially redundant functionality and redundant databases and were affected by numerous uncontrolled dependencies and point-to-point connections. The overall complexity of IT in banks obviously reached a critical stage. 

Although the fifth phase is still in progress and therefore difficult to foresee, many assumptions on how web based data processing will revolutionizes IT in banks can be made. Also some facts are already obvious. Some business processes are implemented solely web based. Customers can trigger many business processes via the web which also further reduces media breaks due to customer interaction. E-banking is frequently used by a large number of customers [WIL04]. Standardization and modularization advances. The system landscape is now dominated by a mixture of legacy systems mainly acting as back-end layer and applications developed in the 1980s as well as modern technologies used for web applications [MOR05a]. The overall complexity in many bank’s IT departments is still difficult to manage and projects exceed their time and budget constraints or even fail because of the system’s complexity [HEU06]. 

In consequence of the long technological history in banks the IT is highly integrated and complex. Although IT is known to be a competitive factor in the banking industry, legacy systems still emboss large parts of the back-end layer and the high investments needed to replace them are in many cases avoided [GRU02][MOR05a]. 

The current structures predominant in many banks are organized around a central core banking system. This core banking system is in most cases a not standardized, self developed legacy system which has been continuously extended in order to fulfill the growing business needs (see [1]). The legacy systems are monolithic entities with proprietary interfaces, separating the banking divisions and hence leading to many redundant features [HOM04], [KRU05]. For instance the sales applications have to be developed separately for each division although the same basic functionality is used across all division. This redundancy also raises maintenance costs significantly. Although the life cycle of the core banking systems developed in the 1970s and 1980s is known to be finished, many financial institutions hesitate to renew their core banking systems because of the high acquisition costs [MOR05a]. 

However, some banks have already replaced their core banking systems with standardized state-of-the-art systems. These financial institutions report benefits in terms of lower costs for maintenance and customization because of the modular structure and standardized interfaces. Another main advantage is the shift from a solely account centric view to the ability to additionally provide a product centric and a customer centric view [KRU05]. 

On average IT costs account for about 15% to 20% of a bank’s general expenses [MOR05a]. According to [GRI08], the costs can be further divided into 'run the bank' costs and 'change the bank' costs. 

Run the bank costs represent the amount spent for the operation and maintenance of IT systems. Benchmarks indicate that this part of the IT costs amounts to about 80% of the overall IT costs. 

The remaining 20% of the IT costs are spent for change the bank projects. These projects promoted on the one hand the continuous evolution of the IT in banking which should ultimately also lead to reduced run the bank costs. On the other hand, adjustments due to regulatory changes as well as new development projects often demand large parts of this budget. Frequent investments in change the bank projects and better cost allocation should ultimately lead to an equal distribution of the IT costs. About 50% to 60% of the overall IT budget spent on run the bank and 40% to 50% spent on change the bank is considered as optimal [GRI08].