As banking requirements advance, the systems and software required to service core banking operations grow ever more complex. The solution, it appears, is a flexible system that can adapt and fit into its new environment.Dan Barnes reports.
Having a heart transplant doesn’t sound too appealing if you aren’t in a life-or-death situation. However, the world of finance follows Darwinian principles and one’s level of fitness can mean the difference between survival and extinction. When Deutsche Postbank wanted to evolve into a full retail banking operation, a heart transplant is effectively what it opted for.
During the 1980s, Deutsche Postbank broke away from government ownership, offering limited, basic retail-banking products. When it wanted to expand the range of services in the mid-1990s, the bank realised that it would have to find easily installed, inexpensive systems that would provide it with a good level of infrastructure and reporting capability to meet regulatory requirements. As Ludger Dorr, director of strategic projects at Deutsche Postbank AG, explains: “When we wanted to get the German banking licence, we had to move quickly. Therefore, we made the decision more than 10 years ago to build our system using standard software. At the time, there was one common standard software in the German market – Kordoba – so we decided to implement this.”
Although the bank had fulfilled its initial requirements, the system did not appear ideal for future business growth. “Kordoba was refined for mid-sized banks, so we had to implement more than 18 different Kordobas to run our business,” says Mr Dorr. “That is one reason we began looking again at the software for our core banking operation – we needed consolidation. We saw there was no real potential from Kordoba because it was based on the 1970s BS2000 (Siemens operating system).”
In 1997, software company SAP began working on a large-scale banking-specific proposition in Germany, building upon its previous work that had been limited to systems for the domestic mortgage bank industry. Toward the end of the 1990s, the company began to look for ‘charter’ partners – that is, partners who would be prepared to pioneer work – and sided with Postbank and UBS. At Postbank, the IT group had realised that migration to new software would be difficult and that they lacked the necessary skills to build new systems in-house, particularly if they wished to retain the commercial benefits of using standard software.
Mr Dorr says that SAP was able to offer a solution. “We had a very high demand for flexibility and security so we looked for a software company that was able to do the development, that would still exist in 10 years time and onwards, and would be able to meet our demands and those of the bank in the future. SAP gave us a clear commitment that they would be able to develop such standard software within 10 years. Therefore, we decided to develop core banking systems in collaboration with SAP and, today, I can say that it was the right decision.”
Aside from a short break to deal with Y2K (the potential for a millennium bug), the project has been ongoing ever since, with the last implementation of the savings module expected by the end of 2006.
Global approach
“The SAP principle has been to build a single adaptable system,” says Gerald Faust of SAP. “We have one solution for the global market, not one for the US and another for the Chinese markets. That’s the basic approach for SAP, along with learning from other industries that have already matured, such as the automotive and manufacturing industries. What we see from an object-function data-model point of view indicates that we are well prepared. So we really only have to make enhancements to our software, not restructure it or start again from scratch.”
When developing the core system for Postbank, SAP was aware that the standard software only comprised part of the overall solution – about 60%-80% – with the rest of the delivery occurring during the implementation project. In a world of ‘unique propositions’ and ‘bleeding edge’ technology, some may feel that standardising systems may stifle competitive advantage. However, Mr Dorr disagrees: “We did some work to look at our product portfolio. We looked into our business processes and tried to create a standard. We believe retail banking to be commoditised so we do not differentiate ourselves via product, we differentiate through cost. Our marketing guys would tell you something different but that is my perspective from operations.”
Cost reduction is key
SAP claims to have found that cost reduction is the key for many banks, quoting customers that require 80% of their processing power just for systems management. Using systems that run on the same technical foundation is an advantage here, helping to get rid of the ‘spaghetti culture’ noted in many banks’ IT infrastructures. The larger banks that SAP is developing its systems for are naturally more susceptible to this phenomenon due to the larger number of applications and interfaces they have and there are often fewer people who understand the entire architecture.
According to Mr Faust: “The need for cost reduction and complexity reduction will drive them towards a new component-based, service-oriented architecture approach.” In the current climate of service-oriented development, SAP’s modular approach fits well, utilising standard interface modules (termed ‘business application programming interfaces’ or ‘BAPIs’ by SAP) to allow integration between systems.
“With Postbank they just wanted to replace the back-office systems, so we had to be open in terms of interfacing a lot of different systems,” says Mr Faust. “The BAPI is object-oriented from the view of a back-end system and this is what we will transfer to the XML-based, service-oriented interfaces that are being requested from a business perspective. Therefore, I believe it is easier for us to carry out change compared to our competitors. We have more than 350 BAPIs so we can call every function via an interface or they can be called from different systems.”
“Postbank has seen a number of benefits from implementation,” says Mr Dorr. “There are two main advantages gained from our core banking system. First is the quantitative advantage. We were able to reduce our total IT running costs by 10%. Our time to market for new products has been reduced down to only a few weeks. That is much better than was possible with the Kordoba system, which took roughly nine months to one year because the process involved hard coding. We have seen a reduction in complexity costs of 30% within operations. So the real quantitative advantage is that we are now able to work very cost efficiently.”
The bank has realised other strategic advantages. “The ability to integrate with other banks’ systems means that there are business opportunities opening up that were not possible before,” continues Mr Dorr. “That might be an advantage in the future where we could see consolidation in the German market.
“At Postbank we have the opportunity to transform our operations into profit centres. Through this investment we were able to handle the domestic payments business for Deutsche Bank.”
As a result of agreements to process Dresdner and Deutsche Banks’ domestic payments, Postbank is now processing roughly 10 million transactions a day, constituting roughly 15% of the German domestic market. The core systems project has not only achieved its intended purpose, but being ahead of the game has enabled the bank to create business models that would have been impossible for it previously – and are still impossible for many competitors. Through replacing the very heart of its operations, Postbank has gained a new lease of life and is now stronger than ever.
