Financial Information Systems

Increase Business

There is a clear consensus of opinion that the way to increase business with existing customers is to better understand their needs. Greater efficiencies and better quality systems would allow bank staff to identify potential business opportunities. The identification of such opportunities, or rather the inability to do so, was cited as major shortcoming of existing core banking systems.

Existing systems do not necessarily provide unified account and transaction information, especially on a real-time basis. This information tends to be segregated according to the product area. The problem is less of an issue in Private Banking that have front end applications to help consolidate such information; yet even here integrating information from other applications that support specialised products is a major concern. Thus, attempts to launch innovative and new products can be a major headache if the IT systems cannot integrate the information with other (legacy) systems.

Whilst a significant number of banks around the world are planning a major core system replacement over the next three to five years, more than half are currently investing in functional area improvements such as payments, securities and management information systems (MIS). The majority of large banks are running propriety systems; but even vendor provided solutions require a significant overhaul due to the age and architecture of some of the solutions on offer. The good news here is that many vendors have recognised this and have been working to adapt their solutions over the last three years.

One approach that many banks are using is middleware to help overcome the shortcomings of their legacy infrastructure. By adopting hub and spoke architecture, back-end core banking systems can be integrated with front-end delivery channels. Many middleware systems can perform a certain amount of data transformation to allow a degree of pseudo compatibility between different applications, different data definitions, and different architectures. However, middleware can only do so much; if the core banking system cannot process a product, then it is a major problem.

Various surveys provide a consistent message: their core systems hamper competitiveness. Issues regarding lack of flexibility, excessive costs, and integration difficulties are of major concern to many banks. Practical issues impacting day-to-day operations such as response times, excessive time spent on back-office administration, processing errors, lack of sophisticated information to help the sales process all highlight the potential for significant improvements to be made. The requirements for what must be done are reasonably clear; but few have the technology roadmap in place to deliver these goals in the foreseeable future. Of course, the replacement of core systems is a major undertaking with some high-profile failures or painful transitions from the past. As a result, many banks prefer a more cautious approach; perhaps with lower risk alternatives such as workarounds and extensions to existing systems.Sooner or later, banks will need to implement change as the price of continuing to remain in business. There is a clear need to create an architecture that allows for simple implementation and ease of maintenance. Further, a high degree of compatibility is needed to allow for integration with various ‘external’ services.

A Service Orientated Architecture is very much the way forward for the future. Also, standardisation and harmonisation of data definition and data exchange is needed to avoid replication of effort for maintenance and intervention.

The challenge is to create an architecture model that can be applied to any ‘service’ that interacts and collaborates with a core banking system and its services. This document sets out the high level outline for such an architecture and the likely business requirements that might impact upon its design.

There are many components already developed that can provide one or more ‘services’ within an overall architecture model. However, when designing a product that might be implemented with many different interpretations, a high degree of openness will need to be incorporated.

The next step would be to investigate the available components and provide a more detailed framework for a SOA that can satisfy the main requirements for implementation and support, i.e. lower cost, more agile and more responsive.