Core Banking Solutions_ an Assessment_2

download Core Banking Solutions_ an Assessment_2

of 15

Transcript of Core Banking Solutions_ an Assessment_2

  • Core Banking Solutions: An Assessment

    Dr. S. S. Satchidananda Sanat Rao

    Rahul Wadhavkar

    International Institute of Information Technology Bangalore

    CBIT-IIITB Working Paper WP-2006-8

  • Core Banking Solutions: An Assessment

    ABSTRACT

    In this paper, we provide an assessment of the core banking solutions (CBS) which the banks the world over are increasingly implementing for computerizing their transactions. We also provide generic guidance for its implementation. We identify the risks implementation and the methods for mitigating those risks. We also outline the main benefits accruing from the CBS and the emerging trends. The paper sets out the features of the leading Indian CBS softwares.

    Working Paper - 8

    Dr. S. S. Satchidananda

    Sanat Rao Rahul Wadhavkar

    CBIT Centre of Banking and Information Technology International Institute of Information Technology

    26/C, Electronics City Bangalore 560 100

    ------------------------------------------------------------------------------------------------------------------------------------------------ Dr. S. S. Satchidananda ([email protected]) is Research Director and Professor of Banking and Finance at the Centre of Banking and Information Technology, IIITB. Sanat Rao is the Head, Product Development, Banking Business Unit, Infosys Technologies Ltd., Bangalore Rahul Wadhavkar is an executive in the Banking Business Unit, Infosys Infosys Technologies Ltd., Bangalore. The views expressed in the paper are those of the authors and does not necessarily reflect the position of the organizations they belong to.

    CBIT-IIITB Working Paper WP-2006-8

  • Table of Contents

    I. Introduction - 4

    II. What is a Core Banking System? - 4

    III. Elements of Core Banking Solution - 4

    IV. When to change a Core System? - 5

    V. Integrated solution versus Best of Breed vendors - 5

    VI. Risks - How to evaluate a Core Banking Solution? - 6 VII. The Implementation Process - 9 VIII. Steps taken for Risk Mitigation of the Project - 11 IX. Benefits of Core Banking Solution - 11 X. Emerging trends - 12 XI. List of Global Core Banking Vendors - 13 XII. Their Product Offerings - 13 XIII. CBS Implementation in the Indian Banking Industry - 13 XIV. Features of Some major Core Banking Systems in India - 14

    CBIT-IIITB Working Paper WP-2006-8

  • Core Banking Solutions: An Assessment

    1. Introduction Strides in the field of technology have redefined the role and structure of an IT department in a Bank. Rapid strides in the field of technology redefined the use of technology in a banking. The fact that using better technology and systems, banks can garner more customers, retain existing ones and channel more of the customers business to its counters has forced business department to now look at IT as an effective marketing tool. On the operational side, the power of IT in reducing transaction costs, providing better customer service and offering an over-all customer convenience has basically made this a win-win situation for both banks as well as its clients. These have become the main drivers for getting IT the importance it has got in banks in recent times. The nerve centre of technology in a banks IT dept. is the Core Banking System. This paper aims at understanding the role of core systems, the scope of core systems, evaluation methodologies adopted by banks in selecting core systems, typical pitfalls in implementations, and recent and future trends in the core systems. II. What is a Core-Banking System? Core banking systems are basically the heart of all systems running in a bank and it forms the Core of the bank's IT platform. Amongst other functionalities, it provides the customer information management, central accounting and the transaction-processing functions, which by far are the most fundamental processes in a bank. With the advancement in technology and with passage of time, core systems now-days tend to cover more and more functionality giving the bank an integrated solution for most of its operations in different business lines. Alongside, it also provides a central operational database of customers' assets and liabilities giving facility to generate a 360 degree view of the customers relationship with the bank, which is fundamental for the CRM strategy of the bank. Core banking systems reside either in the heart of a bank's data center or in other words can also be termed as the heart of the data-centre itself. III. Elements of Core Banking Solution By and large a typical traditional core banking system would be composed of five components: 1. Customer Information File 2. General Ledger System 3. Transaction processing 4. Plain Vanilla Loans and Deposits Systems 5. Basic MIS reporting

    Based on systems available in the market, we have classified them into five levels, primarily on the basis of the functionality offered with level one being the most traditional system offering basic functionality and level 5 being the latest state of the art systems with advanced features.

    CIF GL Transaction engine and Posting

    Level 1 Loans System

    Deposits System

    CIF GL Transaction engine

    Level 2

    CIF GL Transaction engine

    Retail Loans System Deposit System

    Trade Finance

    Report Writers

    Level 3

    Trade Finance

    CIF GL Transaction engine

    Retail + Corporate Loans + Deposit System

    Report Writers

    Services Based Architecture

    CRM

    Internet Banking

    Systems have been classified on the basis of functionality available for addressing needs of various business lines. Most systems from Level 3 onwards can be classified as mature systems, which offer a moderate spread of functionality required to run a medium sized bank efficiently. Systems falling in level 4 and beyond can be classified as more advanced system primarily aimed at large banks operating in multiple business-lines and offering a large gamut of products and services to its customers. These banks would typically be amongst the larger banks in the country or the sector they operate in. So is by default a higher level system always preferred? - a classic trap most banks tend to fall into. A system sought by a bank should depend purely on the suitability of a solution to their current needs and those in a perceptible future. Hence, quiet clearly a system in a higher level does not really mean it is best suited if the features it offers are not required and are not likely to be used by the bank however fancy it might sound to have them. The bank needs to look at its own usage pattern in the current scenario and in near future, which should ideally span for around 5-7 years in our opinion. The objective is to look at your requirements and device an evaluation strategy, which suits the banks business rather then looking at what other banks bargained for when they replaced their systems. This is where business and IT need to come into unison, much before the evaluation process starts.

    CBIT-IIITB Working Paper WP-2006-8 4

  • IV. When to change a Core System? How do I know? When does a bank really take a decision to change it system? We feel the five most factors are Technology proves to be an impediment to

    business Most of the older systems in place today were built before open systems and standards were available. Hence they were primarily built in closed proprietary environment making it very difficult to adopt new technologies, databases, communication protocols between different solutions etc. thereby rendering the entire system very rigid. On many occasions we hear of a novel product offered by competitive banks and then wonder how the same could be handled in our system. At times, banking products which provide the bank with a good opportunity to make a spread are dropped due to lack of support from the existing infrastructure. By the time a request to enhance the system is made and the functionality actually enhanced, some other bank has caught on to the idea and grabbed the advantage of being the first mover. Similarly, in a Merger and Acquisition scenario, the acquirer cannot support the business requirement of the acquired thereby forcing the bank to continue with disparate systems or build complex interfacing solutions. So quite clearly there are signs in a bank where available technology tends to slow down or impede business prospects. Scalability Issues The system is unable to provide the same service levels with the estimated growth in business, which could be either through acquisitions or developed organically. A slow response time is one of the most common cause for a drop in customer service in a bank. It is crucial to ensure that the system in use is scalable enough to support the projected growth in business volumes without affecting the response time. Cost of Maintaining the system rises,

    without any perceptible benefit accruing to the bank

    Cost of maintaining an existing system could raise because of various reason from the system becoming resource hungry, non-availability of resources especially the human talent with certain skill sets, product gathering a large code-base which is primarily unstructured thereby taking an unreasonably large time even for some simple enhancements etc. Large scale Manual Handling of

    Transactions resulting in longer turn-around times.

    Related to the first point, if the bank does not want to let-go of an opportunity, then the new products would tend to get processed procedurally in the system leading to over-all inefficiency. This in most

    cases also leads in improper MIS on the customer business; profitability affects the 360 degree view etc. Increasing the regulatory burden and Inability of the system to handle new regulations. Newer regulations like OFAC, Basel 2, Anti money laundering if not adhered to not only put the bank at a risk, but also might attract a higher capital requirement. Severe Interfacing issues When banks add business lines, quite rarely would they wait for their existing system to scale up to the functionality required for the new area of business. The general tendency is to acquire a ready solution catering to the specific line of business. This requires interfacing, on-line interfaces are complicated to build and batch interfaces do not give a correct picture real time. As more and more of satellite products add up, interfacing becomes a nightmare. More time tends to get spent on reconciling information from one system to another rendering the system inefficient. Old systems using old technologies do not interface easily with third party applications. Viability of the Vendor supplying the Core

    System Hard economic times have seen many vendors either scale down the size of operations, work in a Maintenance Mode or are either eventually taken over by other companies. If any of this were to happen, the system is bound to suffer due to the reduced attention and importance it would get from the vendor. Quite clearly, no bank can prosper if the platform on which it is on tends to get shaky. Though most banks go in for escrow arrangements, these often tend to be theoretical fall-back as in practice it is extremely difficult for the bank to take over and maintain the code. V. Integrated solution verses Best of Breed Vendors. A dilemma which banks most often tend to face is whether to go in for a full fledged single core banking solution or opt for a basic core system and get the Best of Breed solutions from niche vendors. Core Banking Solutions now-a-days offer integrated Treasury, Trade Finance, Cash Management applications. We would say these traditionally do not form a part of the standard Core Banking suite of solution. However, one of the critical benefit which a bank derives from an integrated solution is it eliminates or reduces need for interfaces, but is useful for only those banks which actually offer these services to their customers. On the other hand other vendors supply "best-of-breed solutions" that focus only on specific functions such as separate loan accounting systems or general

    CBIT-IIITB Working Paper WP-2006-8 5

  • ledgers. Such niche systems invariably bring a better functional fit to the business requirement. History has shown that large universal banks which have multiple business lines running parallelly tend to use different systems for different business lines. Small and Medium sized banks (based on global standards) prefer integrated banking systems. With an integrated system the banks by-and-large reduces the interface issues. Using an integrated solution also helps in giving a complete 360 degree view of the customer which may be difficult to achieve using disparate systems. With disparate system also comes in the problem of maintaining multiple CIFs on the customer which only leads to additional complexities. Having said that it would be only appropriate to qualify that the use of a fully integrated solution or nice products depends purely upon the bank, its size of operations, level of interdependency between system required, ability within the bank to deal with multiple vendors and maintain such systems. There are several banks (most of them are very large banks) in the world who have managed efficiently the use of disparate systems from different vendors all over the world. These banks typically tend to have large IT teams and have IT budgets running into millions of dollars. So there appears to be no clear answers to the question of an integrated solution approach v/s Best of breed vendors. In our observation niche products do tend to offer better functionality but also bring along with a set of different problems in maintaining different systems. Broadly, the advantages and disadvantages can be best summarized by

    Best in Breed Integrated Advantage Use of Best of Breed

    Vendor Availability of

    advanced functionality (since the vendor specifically concentrates only on the particular area,)

    Allows the bank to follow a component based approach replacing only the required product without affecting the entire bank

    Faster product development

    Advantage Use of One

    product, from one vendor with the same look and feel.

    Effective 360 Degree view of customer relationship across all modules.

    Homogeneous Architecture

    Better control over the solutions provider

    Lesser Interface issues.

    Disadvantages Hassle of dealing

    with too many vendors,

    Interfacing different products across

    Disadvantages Banks dependency

    on one Vendor hence vendor viability very important

    different versions become difficult. STP across products not possible.

    Scalability across all system cannot be guaranteed as they come on different technology, are supported by different vendors

    Different User Interface for each product

    Architecture tends to become messy

    These system are typically large and typically are much more expensive

    Customisation might be required to meet functional requirements as functionality may not meet the exact requirements of the bank

    It is better for the bank to decide on this issue up-front before the start of the exercise. Once done, the evaluation criteria should then be designed accordingly. VI. Risks - How to evaluate a Core Banking Solution? How to start the process? As analysts put it, changing a core banking system for a running bank is like changing the engine of a 747 Jet mid air! The success or failure of such project often has a career altering effects on the people involved. Research by some analyst indicate that as low as 25% of the total core banking projects embarked upon are completed successfully keeping with the schedule. Once having decided to go through with the initiative, the due diligence at the banks side commences with first selection of the vendor and then a few steps which usually need to be taken to mitigate risks. Key Product / Vendor Selection Criteria The project usually kicks off with a vendor briefing where the banks lay down their intent on seeking a core banking software, approximate timelines when the project is expected to go live and so on. Interested vendors would be requested to furnish details about themselves, the product, existing customers etc. This is the first level screening. An RFP which is prepared in consultation with various business teams within the bank gets circulated to these short-listed vendors. The RFP response by a vendor often is a good estimate of the percentage fit of the product to the banks requirement. Banks also often fall into the trap of making an extensive RFP covering every small aspect of banking and operations. In our opinion, this often tends to dilute the focus from the crucial areas. It sometimes is much better to ask only crucial questions on important functionalities and expect elaborate descriptive answers. This often leads

    CBIT-IIITB Working Paper WP-2006-8 6

  • to a better understanding of the actual functionality in the product. Questions leading to or referring to this functionality can be asked in a way, which would elicit more information on the required module. The crux in our opinion is to avoid asking elementary questions on functionality, which you would anyway expect the product to have to have after the first level of screening. This will help in keeping the RFP crisp which would assist none other than the bank itself during the later stages of evaluation. Based on the responses, the short-listed vendors would be invited for a POC. Some banks also give scripted scenarios to be shown during the POC this not only gives a better idea of the product capabilities from its own perspective but also helps in keeping the POC exercise on track. What are the key parameters does the bank need to look into? Functionality In any core banking replacement exercise, business has an over-whelming say in selection of a package. The reasons for this being quite obvious it is finally the business which pays for the solution! Hence the business aims at ensuring that they actually drive the technology rather than the technology driving them. Bulk of all POCs have most sessions on functional strength of the product. Areas to look into are modules which support the existing lines of business, adaptability to best practices of business, operational procedures (STP, ease of use etc), user interface, Parameter set-ups in the product, scope for customization to suit bank specific requirements, and last but not the least, support for current and future regulatory reporting. Broadly, the system should be configurable, so that the bank can create new products and adjust product terms, pricing, processing etc. Configuration should not require any programming to change the product characteristics. This should be achieved through simple parameter changes, changes to business rules definition. The aim should be to ensure that close to 70-75% of the business requirements are met. Technology By the time technology tracks during a POC start, the bank already has a good idea of the product fit at this stage. The aim here should be to ascertain the use of proven technology platforms, robust and a scalable architecture, and a non-resource hungry solution. Other point which the bank may also want to consider is the availability of resources with the required skill sets to maintain the system in future. The buzzword in technology these days is the Component Based Architecture. This is basically a design characteristic, which breaks down the system functionality into the simplest grass root level so as to make it available across the enterprise. E.g. .A Component based architecture reduces complexity in the product, enables faster product development and also brings in more agility into the

    solution to integrate across different solutions belonging to different vendors in the same bank. A solution with this architecture is certainly preferred over the traditional ones. Some of the other crucial areas to evaluate a solution on are 24X 7 capabilities, fall-back mechanism, scalability, (ability to process maximum number of transaction of a certain mix in a given time), Resilience (Level of certainty that the transaction entered will be executed in the system) etc. Better architected system will support multithreaded messaging with failover characteristics, leading to higher transaction confidence rates and minimum down-time, Vendor Viability As indicated earlier, by selecting a solution and a vendor, the bank virtually gets into a relationship, which could have long lasting impact on functioning of the bank. Selection of a vendor who is and would remain financially viable in the long run and is not dependent on a few customers for survival is crucial. Apart from pure financial viability, technical competence, development capability and infrastructure with the vendor, functional expertise, quality of support, quality practices followed, alliances and partnership, marketing and sales infrastructure, quality of top management etc. also have a quality impact on the deliverables of the vendor. There are research reports available by leading analysts such as Gartner on how to access vendor viability which embarking on important projects. Costs Commercial discussions typically occur with the selected few vendors - much after the short listing from the POC. These typically are those vendors who have cleared all the above criteria and are generally not more than two or three in numbers. Customer References Customer visits tend to give the banks team an insight into the product capabilities when deployed in a live environment. It is important that the bank selects a reference of more-or-less the same size / nature of operations. The bank at this stage can relate to what was demonstrated during the POC and see it in production environment, but the onus of finding information at this stage rests with the bank. It is crucial to ensure that the visits are well planned by the bank preferably in teams of 2-3, with each team having a clear agenda of the issues it needs to explore more. This would help the bank consolidate the findings and enable a fair comparison between vendors. Implementation Methodology One of the most crucial evaluation parameters is the implementation methodology the vendor proposes to follow for the project. The strategy proposed should

    CBIT-IIITB Working Paper WP-2006-8 7

  • CBIT-WP-2

    IIITB Working Paper 006-8 8

    be in-synch with the nature of the bank, its size of operations and most importantly, the vendors comfort level and experience with the adopted strategy. Different solution providers are comfortable with different implementation strategies. It largely depends upon the type of banks and their size the vendor has dealt with in the past. Analysts broadly classify implementation into three areas Big Bang

    The entire bank moves onto the new platform at one point in time

    Regional Migration In this approach the bank works on geographical patters moving different regions one by one onto the new platform

    Line of Business In this approach the bank moves different lines of business slowly on the new platform.

    Another approach which was undertaken in the past was that of parallel runs. Here, the banks runs its old system parallelly alongside the new one, transactions virtually have to be entered twice once in the old system and then in the new. Balance sheets, GL figure etc are tallied with that from the old system during a test period. Once confirmed, the old system is then phased out. This is however a very tedious approach and generally is not observed these days. The advantages and Disadvantages of various systems can be broadly summarized as follows:

    Advantages Disadvantages Big Bang Project completed

    in a much faster time-frame

    Benefits of the project accrue to all business lines, across regions simultaneously and fast

    Employee interest in the project remains as the project completion is in sight

    Important for the

    vendor to have experience in such an implementation

    Perceived to be risky especially if the vendor is in-experienced.

    Regional Solution can be

    implemented starting from region with lesser volume and then move to regions with higher volume. The risk to that extent is reduced.

    Longer

    implementation times. By the time the last of the region is moved to the new platform, it might be time for the bank as a whole to move on to the next version of the product

    Gives the bank a feel of how the solution is fitting the requirement, gives an opportunity for rectification, corrective actions without scope for much damage

    Typically, the regions which give the highest volume are migrated the last. So in a way, benefits of the new system accrue to the more crucial regions at a much later stage ROI on the project gets delayed to that extent

    All regions do not derive the benefits at the same time. Till the time all regions are migrated to the new system, reconciliation between transactions in the old system in some regions and the new system in the other would take an effort.

    Line of Business Solution can be

    implemented starting from one line of business to another across all geographies. Important business lines can be migrated quickly so ROI of the project is not delayed.

    Taking a peace-meal approach reduces the risk to that extent.

    The product needs

    to be architected in such as way that it can be segregated / implemented business-wise.

    Creates some instability as some business lines are on one platform, others on another. Transition period is likely to be shaky due to lack of a 360 degree view, disparate customer CIFs etc.

    Training of users across different regions based on business-lines might create

  • Initiation

    Detail System Study

    Core Team Training

    Business Process

    Definition

    Build Custom Components

    Data Migration Unit Testing

    To Be Process

    Process Review

    Build Interfaces

    Infrastructure Datacenter, Hardware

    Network

    Integration Test

    User Acceptance

    End User Training Pilot

    Effectiveness Review Roll Out

    CBIT-IIITB Working Paper WP-2006-8 9

    A standard Implementation Path .

    VII. The Implementation Process

  • Some of the key implementation activity described in brief: - Current System Study In order to ascertain the finer aspects of the banks business, a current system study is usually done at the customer site. At the end of the current system study, a detailed document of the gaps needs to be prepared and submitted to the customer. Objective of current system study is to understand Banks existing business practice, Accounting principles, functional requirements arising out of different banking products offered to customers, Audit and Control needs, reporting needs (statutory and internal), User expectations, countrys Central Bank regulations etc. The project team comprising of representative from the vendors side as well as the banks side decide on an action plan to address the gaps identified in the process. Business Process Re-engineering This process enables the bank to re-look at its age old practices and try to adapt to new methodology in order to bring in efficiencies in the system. Business Process Definition The objective of this process is to map the business processes closely to the system. This is where generally the chart of accounts, GL structures etc, product definitions are crystallised. Data Migration Data Migration is a very critical activity in the Implementation process. This basically means transferring of the data from the old system to the new system seamlessly with the least possible disruptions in the day-to-day business of the bank. The success or failure of data migration can make the difference between the success and failure of the entire Implementation. System Integrated Testing System integration is a systematic approach to build the complete software structure along with the interfaces as specified in the design from unit-tested (individually tested) modules. While doing system integration testing, tests are conducted to find defects associated with interfacing. The purpose here is to ensure than all modules which may be customised to meet the banks requirement work in a complete unison in an integrated scenario. The system testing environment needs the appropriate hardware, system software and any other software to support the integration as in a live environment. The objective is to do the system test on an environment that is as close to the production environment as possible. Another important aspect of this exercise is Stress testing. Objective of stress testing is: It helps in detecting any problem with the 9 Infrastructure (H/W, N/W) - It helps in testing

    the growth projected by the bank so that it is scalable in the next 1-2 years.

    9 network, database, application and other interfaces

    UAT User Acceptance Testing is a functionality test (to validate the software product against the requirements specification by testing the entire system. It tries to show discrepancies between a product's attributes and the requirement). Generally the Core team from the banks side undertakes User Acceptance testing. This is usually done on the migrated data.

    Pilot implementation This can be either Big Bang (centralized Bank) or implementing one branch or identified set of pilot branches and then rollover of branches (De-centralised Bank). The objective of pilot implementation is to have proof of concept for all modules.

    Implementation challenges The implementation process on an average can take anywhere between 6 months to a year depending, on the degree of customization required. If the vendor has in place good implementation processes, the implementation time can be reduced. Generally a few branches are chosen and networked under the new system, and once all the issues are settled, it will be slowly extended to other branches of the bank. This process is called going live. The challenges a bank tends to face during implementation are numerous including technical and at a business level. But more than the technical challenges it is the business challenges like BPR that might throw a spanner in the implementation of CBS. Business Process Re-engineering BPR basically implies that the current processes used to perform a function are inefficient. With the implementation of CBS the processes have to be aligned with the best of the breed processes that comes along with the CBS. Hence BPR means review of current processes. It might be possible that a process can be scrapped altogether, combined with another process and make it a single process, replacing an entire process with a new process. All of this necessitates that the bank revisits each and every process, identify the bottlenecks and prepare for a change. Invariably implementation of CBS is accompanied by BPR and the banks must be ready for this change. Another challenge is the porting of legacy data to the new system. Since data is very crucial and secretive to a bank it is very important that the data is migrated from the current system successfully into the new system. Care has to be taken in porting. Before the implementation the bank might share some of its data with the implementation partner for testing purposes.

    CBIT-IIITB Working Paper WP-2006-8 10

  • Top management commitment is another aspect crucial for a successful implementation. The top management should be very committed and positive to the project. It should field its best employees from IT and business into the project and they should stay put till the project is completed. Another important aspect from an Indian perspective is the management should also allay any employee fears about retrenchment. All the concerned employees must be informed and well trained to accept the new system. VIII. Steps taken for Risk Mitigation of the Project Typical Risks encountered in a Core Banking project are o Lack of Ownership of issues o Lack of Scope / Requirement clarity o Ability of the Core Team to take decisions o Expectation Management Stake holders at

    different levels have different expectations o Ambiguous Roles and Responsibilities o Resistance to Change People, Processes,

    Procedures o Poor Quality of Data o Delay in procurement of visa, work permit o Scope Creep/Scope Change o Lack of Top Management commitment o Delay in finalization of requirements and

    process definition for all the operations o Delay in freezing and sign-off of customization

    and interface requirements Often banks after selecting the vendor believe that the success of the project rests with the vendor. It always remains a joint onus between the solutions provider and the bank, with the bank basically playing the role of a Super Project Manager. The bank needs to identify a project team to work on it full time, form a mechanism to handle escalations and so on. Some of the Steps which the bank can take to mitigate the usual pitfalls are 1. Perform a system study / Gap Analysis (if not

    done during the pre-sales stage); identify functionalities which are show stoppers and good to have. This is where the IT would need to play a balancing role. Once decided, freeze on the requirements and watch out for scope creeps.

    2. It is important to ensure that the bank looks at

    this exercise not only from an IT perspective but also from an Organisation and Methodology perspective, re-examining its existing process flows and work patterns. The emphasis here is breaking away from the paradigm set in the bank and be open to change age-old procedures for

    the better. Banks generally have a tendency to tweak the system to meet their current business practices and process flows whether right or wrong. Analysts point out that the more the bank changes the system, lesser is the benefit it is likely to achieve from using it. Some banks also tend to under-take a complete Business Process Re-engineering exercise which would help it re-look at its existing business practice. In this background, it is important that the solution the bank has selected has the standard industry best practices incorporated, which would make it easy for the bank to adapt to better processes in a short span of time.

    3. Classic way to monitor the progress of the

    project is to break it down into a number of smaller milestones. This should ensure that the project remains on track.

    4. Banks often go all out in trying to get all

    functionality on Day 1. In the interest of the over-all project, functionality which is identified as non-crucial, non-show stoppers should be phased over a period of time.

    5. There is always a tendency to expect facility to

    process non-banking business related transactions such as facilities management, HR modules, etc in a core banking software. We feel core banking systems are basically designed to handle banking transactions. Much smaller, cheaper and efficient packages are available to cater to such niche areas. This approach would help the bank keep its architecture clean. This in our opinion should ideally not be made the criteria for comparison.

    IX. Benefits of Core Banking Solution The success or failure of any project primarily depends upon how much ROI it generated or how much savings were enabled due to the exercise. This more often tends to be the yardstick for measuring the success or failure of a project. We feel the benefits derived can be basically classified into two broad areas viz. Economic benefits and Performance or Subjective benefits. Economic Benefits The cost savings from a project of this magnitude are typically visible over a period of a couple of years from implementation. The ROI compounds as new lines of business and geographic areas move on to the new platform. The return of investment typically slow in the first few years till such time the real benefits of the system start accruing to the bank. Research reports indicate that large core banking replacement projects enter a positive NPV as late as the 5th year. Cost benefits in the long run may accrue to the bank due to all of the performance benefits

    CBIT-IIITB Working Paper WP-2006-8 11

  • mentioned above (as most of them have an indirect linkage to cost) as well as from other areas such as: 1. Lower transaction processing costs within the

    branch and through other delivery channels 2. Reduction in license fees towards other

    software, which gets replaced by the core banking system. This can constitute as savings for the bank almost immediately.

    3. Reduced maintenance costs in terms less

    complicated code to maintain, easy for the bank to build its own customization, lesser time required for testing etc.

    4. Reduced staffing as lesser number of system

    now need to be managed 5. Cheaper and faster hardware and Database

    Hardware and Database costs have dropped significantly in recent times that enable the bank to leverage on this to deliver faster transaction processing speed etc.

    Performance Benefits 1. Flexibility: - Lack of flexibility more often tends

    to create an impediment in building new functionality, eliciting data for newer regulations like the BASEL 2, accessing better information on customer so as to enable cross selling, addition of newer business lines, offering new products in the existing business lines and so on. New generation core systems provide flexibility in terms of being modular in nature and supporting an integration layer, which can be used very effectively to hook on to third party applications.

    2. Customer Centric New solutions tend to give

    a complete 360 degree view of the customer transactions the objective being to try and give a complete perspective of the customers relationship with the bank so as to enable cross selling opportunities. Some of the core systems use data mining tools to cull out relevant data from customer transactions and try to get a meaningful message out of this.

    3. Real Time Capabilities Most transactions done

    in the newer core banking solutions are on-line real time not only within the package but across all delivery channels. This tends to create a lot of efficiency within the system on one hand as well as reduced risk on the other.

    4. Straight Through Processing This is a new

    concept, which enables the system to process transactions end-to-end almost without any human intervention. E.g. a successful implementation of an STP functionality for an inward funds transfer (MT 103) message itself

    could save the bank significant costs in terms of reduced staffing requirement. A feature like this also ensures almost 24 X 7 processing of such transactions which only leads to better customer service and good-will.

    5. Lesser Down-time, smaller or no EOD / EOM

    cycles. 6. All of this eventually results in addition of new

    customers, retention of existing customers and an over-all better customer service.

    X. Emerging trends Many Public Sector Banks in India are actively considering ways and means of improving and deepening relationships with existing customers. They are also exploring methods to acquire new customers. A variety of things are being done to achieve this. These include developing new marketing, sales and product strategies, evolving creative customer service techniques, introducing new technologies and making changes in organization structure. However, technology based solutions are a particular attraction because they seem to carry the promise of solving all problems at the flick of a switch. Customer Relationship Management (CRM) plays a very important role in establishing and maintaining customer relationship by providing better customer value. Banks now routinely calculate customer value based on such factors as on accounts average balances, account activity, services usage, branch visits and other variables. Banks can use this data and give leeway to customers like say reduced interest rate, waiver of charges etc. Banks can use CRM to analyze the data logged in by the Core banking solution and segment the customers into different slabs and provide focused services. Banks are now looking at tighter integration of all their service channels. Another use of CRM is that it ties up all the delivery or contact channels like call center, field sales. Hence it is imperative that CBS has support for call center/IVR, which has access to online customer data. Todays new generation banks are building more direct and lasting relationships with more carefully selected customers instead of the age old practice of selling to any customer who comes along. The question that would crop up is how do you select the customers? The banks can use the huge information that is stockpiled in its databases collected as part of the transaction through CBS. Then mining this database yields rich info on individual preferences, which helps in segmenting the customer base and providing new products targeting a particular segment. After decades of casting a wide net to lure as many customers as possible, banks are now mining their vast database to identify winning customers and weed out the losing ones. (Sort of an A, B, C

    CBIT-IIITB Working Paper WP-2006-8 12

  • analysis). By integrating all their delivery channels and by collating information from different products and services banks get a single unified view of the customer, thus enabling the banks to offer higher levels of service and customized products. Banks provide more value to customers through multiple delivery channels like ATM, phone, Internet banking. Customer support in the form of call centers to cater to the grievances of customers is also provided. Another important area which appears to be gathering momentum is Payment Systems. It is now important for the bank not just to execute the funds transfer request for the customer but also to give an option for the customer to select from multiple payment system for doing the same transfer. The customer would have the choice of selecting a payment system based on the costs and urgency of the payment.. Hence, ability to integrate the core banking solution with the payment system network and offer clients to execute payments directly from the Internet along with the facility to select payment system is going to be imperative for all progressive banks. This off course is a function of what Payment systems are operated in the country by the central bank. In India recently RBI has introduced RTGS which hopefully should catch-on to become a popular mode for making high value payments, especially for Corporates On the automation side, processing the transactions through STP has also caught momentum. This primarily addresses two issues, one of bringing in the operational efficiencies and second of reducing the risks. Research reports indicate that the percentage of global trade failures and crystallized transactions resulting from unmatched trade data is of the order of around 15% of the total trades, which in monetary terms is upwards of billions of dollars. The STP technology framework seeks to provide these efficiencies by providing a seamless data flow both within the enterprise as well as across the market, without any manual intervention. Trends indicate that almost all the major core banking vendors have done considerable amount of investments in making their products STP enabled, at-least for a few key processes within the bank. Other significant developments have been on the regulatory side such as compliance with accounting standards like GAAP, IAS, Anti money laundering bill, Bank secrecy act, US patriot act, Sarbanes Oxley act, wealth management, asset liability management, Basel 2 compliant risk management solutions. The regulatory aspects seem to have become a primary concern and focus in almost all banks, be it Tier 1 or Tier 2. Understandably so, 09/11 provided an impetus to compliance and regulatory initiatives in banking all over the world.

    XI. List of Global Core Banking Vendors Region-wise

    XII. Their Product Offerings

    * (Information in the tables is based on the Celent report The Global Vendors of Core Banking Solutions: The Heat is On by Christine Barry) XIII. Core Banking Implementation Status in the Indian Banking Industry The trend of computerization in Banking which was initiated in the late eighties, can now be said to have more or less completed its first phase. Banking as a vertical has witnessed numerous hurdles in its nearly two decade relation with IT adoption. Surmounting all of that, last year (2004) more or less witnessed completion of the first phase of this maturing co-existence. Core banking application implementations are today supposed to have peakedall private sector and MNC banks have been followed by the large PSU banks as well as the IT-savvy co-operative banks down this route. experts agree that barring a few large banks which would go on-line in the next 12-15 months most others have already jumped the core banking bandwagon and are coming to grips with technology. A large number of PSU banks are undertaking large scale IT initiatives not just to

    CBIT-IIITB Working Paper WP-2006-8 13

  • implement the core banking solution but also to streamline their operations. One of the key of the key area focused on is centralization of trade finance operations, retail loans processing and credit approval processing. It is important that the core banking solution selected enables the bank to take up such initiatives in the bank. This is expected to help drive up volumes and speed for these banks while

    aintaining the same level of quality of service.

    ee these issues ickling down to Tier 2 and 3 banks.

    ajor Core B ys

    s cle cea bafs

    m In the coming months, we can also expect an influx on IT spending on a host of new areas like CRM, Business Intelligence, Payment Systems and STP initiatives etc. Though these areas have been highlighted as areas of concern only by Tier 1 banks in the country, coming years will str XIV. Features of Some m

    anking S tems in India Feature Fina Pana X

    Internet Banking

    Yes Yes Yes

    Phone banking

    Yes Yes Yes

    ATM facility Yes Yes Yes Utility bills

    Yes Yes Yes

    paymentMobile banking

    Yes Yes No

    Platform used

    Windows NTUnix: Solaris, HP UX

    RDBMS cle

    acle 9i

    ver / Oracle

    Ora9i, MSSQLserver, Informix

    Or SQL Ser

    Browser orer

    ic end

    Internet Expl

    Visual Basfront

    Multi currency

    Yes Yes Yes

    Multi lingual Yes No Yes Transaction Handling

    TPS an

    sting

    11180 transactions per second

    4500 NA Has plto get the load tedone.

    Security i tier of

    security

    roduct.

    Mult Multiple levelsuser password

    Multiple levels. In factour security features are as good as of any other p

    Technology used ,

    Java VB, NET C++, J2EE.Net

    Report generation tool

    Integrated Report

    Yes No

    Writer Workflow automation

    Yes No Yes

    Support forcredit card

    mentParty

    No Yes

    manage

    Third

    Sweep facility

    Yes No Yes

    Automatic renewal for

    ts

    Yes Yes Yes

    deposiCRM module

    Yes No Yes

    Risk Management

    Third Party

    No No

    Complof US GAAP

    iance Yes NA NA

    standard Photo / signature verification

    Yes Yes Yes

    Collateral management

    Yes Yes Yes

    NPA Management

    Yes Yes Yes

    Facility fescrow

    or

    accounts

    NA No No

    CBIT-IIITB Working Paper WP-2006-8 14

  • References 1 District Managers (2004) Feedback received from the District Managers of the National Bank for Agriculture and Rural development in Orissa State during an interaction 1Reddy Y V, (2003) Mid-Term Review of Monetary and Credit Policy for the Year 2003-04, Reserve Bank of India, Mumbai Pp 29, Para 53. 1 State Level Bankers Committee (2004), The Report of the Committee on Low Credit Off-take in Orissa, Proceedings of the State Level Bankers Committee, Pp.19-21 1 Tomar J. S. (1997) Managing Rural Banking in Banking Reforms in India, Tata McGraw-Hill Editors Subramanian & T. K. Velayudham Pp.409. 1 See The Report of the Committee on Low Credit Off-take in Orissa, Proceedings of the State Level Bankers Committee held on 26 February 2004 Pp.19-21 1 Varde,Varsha,(1997) Rural Banking From Nationalization to Rationalization in Banking Reforms in India Ed: Subramanian & Velayudhan TK Tata McGraw-Hill 1997 Pp. 440 1 http://www.indiaagriline.com/english/corp 1 Reserve Bank of India, (XXXX), Advances to the Priority Sectors by Public Sector Banks, Appendix Table III.24, Trend & Progress of Banking in India, Reserve Bank of India, Pp.231.. 1 Mohan, Rakesh, (2004), Financing Services Sector Growth, M.A.Master Memorial Lecture at Indian Merchants Chamber, Mumbai. 1 See Chapter XVIII Pp.651-704. Specifically, Table 24 on Page 697 ibid shows that the net margin on agricultural lending by commercial banks was negative at (-) 1.8 percent. Kamat CC, (1978), Report of the Working Group on Multi Agency Approach on Rural Lending, Reserve Bank of India. Ojha P D, (1990), Service Area Approach: a new challenge for Banks Indian Overseas Bank Monthly News Review, p.p 15-23. Reserve Bank of India, (1998), Report of the Committee to examine certain operational aspects of Rural Lending. Reserve Bank of India, (1954), All India Rural Credit Survey Committee Reserve Bank of India, (1981), Report of the Committee to Review Arrangement for Institutional Credit for Agriculture and Rural Development , CRAFICARD, RBI. Reserve Bank of India, (1982), Report of the Study Groups on the Working of the Lead Bank Scheme, Mumbai.

    Internet References 1 Oracle 10g grids http://www.oracle.com/database/ 1 IBM DB2 Product Family http://www-306.ibm.com/software/data/db2/ 1 IBM Websphere Application Server Family http://www- 306.ibm.com/software/info1/websphere/index.jsp?tab=products/appserv 1 Oracle Application Server http://www.oracle.com/appserver/ 1 BEA Weblogic Server http://www.bea.com/products/weblogic/server/index.shtml1 Pramati Server http://www.pramati.com/ 1 Controller of Certifying Authorities, Govt. of India http://www.cca.gov.in/ 1 EU data grid project http://eu-datagrid.web.cern.ch/eu-datagrid/ 1 The TeraGrid Project http://www.teragrid.org/ 1 Biomedical informatics research network http://www.nbirn.net/

    CBIT-IIITB Working Paper WP-2006-8 15

    Core Banking Solutions:An AssessmentDr. S. S. Satchidananda

    Rahul WadhavkarInternational Institute of Information Technology Bangalore

    Core Banking Solutions:An AssessmentABSTRACTTable of ContentsI. Introduction - 4III. Elements of Core Banking Solution - 4

    Core Banking Solutions:An AssessmentII. What is a Core-Banking System?

    VII. The Implementation ProcessSome of the key implementation activity described in brief: -XI. List of Global Core Banking VendorsXII. Their Product OfferingsReferences