The problem of plenty: multiple host systems in banks
Globally, there are many banks operating on multiple host systems, the result of cherry picking the best in class systems of the day to meet different needs or occasionally, merger and acquisition. Consequently, they have ended up with a legacy of disparate host or core systems, usually segmented by lines of business, such as deposits, retail loans, corporate loans, and trade finance.
Ram Devanarayanan, principal consultant, and Venkatesh S G, industry principal, Infosys Finacle, consider the problems this throws up and look at possible solutions.
All is well until the banks start “misusing” their host systems’ capability interchangeably across lines of business. Once they begin to do that, they set in motion the suboptimal practice of maintaining products across different business lines and systems, which necessitates the creation of different processes for viewing, originating and servicing customers in each line of business. Next, the banks miss out on the big picture by building system specific products. They compound their issues by using multiple core systems (because a single solution does not serve all their purposes), each bringing a different front end to the table. Because these legacy systems have poor integration and interface capabilities, banks are forced to maintain multiple front ends, customer views and so on.
An efficient front end system or distribution layer does not help in improving a bank’s operating efficiency if it is saddled with multiple core banking systems eating into its IT budget. Yet, banks persist with these systems despite their drawbacks. One reason for this is that core banking transformation – especially in large banks – is a complex, expensive and risk-laden exercise. Also, the benefits take years to kick in; in these difficult times, banks prefer to invest in projects, which deliver immediate business results.
That being said, some banks have taken the brave step of addressing the core banking challenge in different ways, ranging from enforcing process discipline to replacing entire systems.
A Spanish bank with a solid multichannel strategy was planning to change its back end core systems not long ago. Its primary motives were to reduce the high IT and operating cost as well as shorten time to market. The bank was having trouble integrating processes across its two core systems. Launching a new product took twice the effort, because the interdependent processes had to be tested across these systems first. The sluggishness of multiple back end systems prevented the bank from capitalizing on its multi channel offering.
A bank in Slovakia (again, having multiple core systems) acquired another one in order to launch a new business line but ended up using it to support some of its old products. The unfortunate result was a snarl of products and processes across systems.
Many banks also end up duplicating entries as some of these systems do not interface with each other, adding to both inefficiency and probability of error.
Report duplication and clutter overload are other undesirable consequences of maintaining multiple core systems. Moreover, the need to consolidate information from multiple systems adds to the cost of report generation.
Enterprises could spend as much as 75% of their IT budget on simply keeping the lights on. No doubt, the high cost of maintaining legacy systems and the support involved, has a lot to do with it. In many cases we have seen that the cost of replacing a legacy system with core banking is lower than the cost of maintaining it.
Interfacing and integration are the other big challenges. When there are multiple core systems, any new system or peripheral device has to be tested across them all before it can be launched. This slows down the bank’s time to market and speed of innovation and seriously impacts its competitiveness.
In a vicious cycle of sorts, banks are sometimes forced to build peripheral systems to manage data across multiple core systems. A bank in the Nordic region had two systems, which stored customer and customer relationship information. Any change in the back end system had to reflect in these as well. Staff also faced the problem of having to log into multiple systems while attending to a customer.
Multiplicity of core systems also impacts people and training; most users have to be trained in multiple systems, which increases costs. Since most core systems have different front ends, UIs and processes, this adds to the complexity of training. The problem multiplies when the bank makes any changes to the existing systems. To cite an example, employees of a UK bank had to toggle between systems to handle different customers. Sometimes, the existence of more than one back end system forces banks to define their processes twice, even when they pertain to near identical products.
Possible Solutions
The easy one, of course, is to ensure proper discipline to make sure that systems are not used across business lines without looking at the big picture. While this might involve few system changes, it will enforce a number of changes to processes, raising questions about practicability and user adoption.
The second option is to maintain best of breed systems as they are, and create a common front end to interface across multiple systems. In this scenario, banks can manage all enterprise systems centrally. Customer processes, from origination to servicing, across all channels are handled by a common front end system, which in turn interfaces with multiple back end systems segmented by line of business. A bank in France is planning to implement such a solution in its European entities; it will have a manufacturing layer or product factory, a back end engine and a common distribution layer. The product factory will have multiple systems based on line of business; the back end processing engine will act as the layer between manufacturing and distribution; distribution will handle customer on boarding, account maintenance and closure. Banks can also implement a middleware to reduce the integration complexity.
The third – easier said than done – option is to replace all or most systems with a Universal Banking Solution. There are many core banking vendors who can replace a bank’s existing systems without compromising flexibility and agility. But only a few offer a modular and componentized core banking solution, which enables banks to choose what they would like replaced and what they would not, and thereby gives them the flexibility to retain best of breed solutions and peripheral systems. This approach not only reduces cost, but also the risk and disruption of core banking implementation. It also enables banks to implement priority solutions like mobile banking first, and enjoy their quick wins, much before project completion.
In general, large banks take the modular risk-mitigated phased approach to core banking transformation. Within that – depending on their state of evolution or business priorities – they can choose to transform by innovating upon products and services, or processes, or customer experience. It is fair to say that today, most banks are past the first two, and are clearly focusing on customer experience to differentiate their offering from the competition.
Conclusion
There are many banks with multiple core systems and most have started to make changes to improve efficiency, cost effectiveness and time to market. While they have chosen different paths, depending upon their past history, present situation and future objectives, they are united in their search for a homogenous system, which can work well with others, enhance customer service, cut IT costs, and above all, enable them to conquer the market through innovation and agility.
