roadmap to successful core banking system replacement

w w w . t h e a s i a n b a n k e r . c o m

Management Report:Roadmap to Successful Core Banking System Replacement Critical Success Factors and Best Practices

Neeti Aggarwal, CFA

Published September 2006©2006 The Asian Banker

Management Report:

Roadmap to SuccessfulCore Banking System ReplacementCritical Success Factors and Best Practices

IMPORTANT NOTICEAlthough the author and publisher have tried to provide information as accurately as possible, they accept no responsibility for any loss, injury or inconveniences suffered by any person using this document. The author and publisher have taken all reasonable care to ensure the data and information in this report is accurate and presents a fair representation of the subject matter.

First Publication: 15 September 2006

ISBN: 981-05-6643-3

© 2006 The Asian Banker. All rights reserved

The Asian Banker, incorporated in Singapore as T.A.B. International Pte Ltd, claims all rights as owner of intellectual property in this report. No part of this document may be reproduced, stored in a retrieval system or transmitted in any form by any means, electronic, mechanical, photocopying, recording or otherwise, without the written permission of the publisher and the copyright owner.

IMPORTANT NOTICE

ABOUT THE ASIAN BANKERAsia’s fi nancial service landscape is undergoing tremendous change and evolution. Liberalisation, consolidation and rapid technological advances have opened up tremendous opportunities for fi nancial institutions and, it is vital for banks to benchmark themselves against their competitors and to keep abreast of global developments.

Decision-makers need accurate, incisive, timely and continuous information to bring their organisation to the next level, meet competitive challenges successfully and manage their own future. The Asian Banker has long recognised the importance of information as a strategic management and decision-making tool and is positioned to provide banks and partner organisations useful, crucial and timely business intelligence.

The Asian Banker achieves this through three synergistic services:

Asian Banker Research: current, continuous and in-depth research on best practices and market developments and trends

Proprietary & generic research servicesSubscription-based research support services for different programs

Asian Banker Publications: incisive news and information on transformational issues

The Asian Banker JournalAsian Banker E-newsletters on different segments in the fi nancial services industry such as operations & technology, wealth management, CRM, retail distribution and payment systems amongst othersAnnual Publication: The CEO Collection; The Asian Banker 300 Banks RankingSpecial Reports on M&A; Internet Banking; Payments Systems; Retail Banking; CRM; Risk Management; Wealth Management and Operations & Technology

Asian Banker Forums: exclusive gathering of industry leaders and senior decision makers to network and exchange information

Annual Major ConferencesThe Asian Banker SummitThe Future of Banking in ChinaAsia Pacifi c Heads of Retail Banking Annual MeetingChina International Risk Convention (CIRC)

Roundtable Series / Consultative ForumsWealth Management Advisory ForumConsumer Credit Advisory ForumRisk Advisory Forum

Industry Briefi ngs

Contact:THE ASIAN BANKER10 Hoe Chiang Road#14-06 Keppel TowerSingapore 0899315Tel: (65) 6236 6500 Fax: (65) 6236 6530http://www.theasianbanker.com

••

••

••

•

•

•

ABOUT THE ASIAN BANKER

ACKNOWLEDGEMENTWe would like to convey our sincere thanks to Mr Hubert Knapp for sparing his valuable time and providing us with important insights into core banking systems for the preparation of this report.

Mr Knapp is one of our International Resource Directors. He is currently a Managing Partner in Immacon Pte Ltd and holds a dual responsibility as Executive Partner in Motif Technologies Bangkok.

Mr Knapp has 25 years of experience in the fi nancial services industry. He specialises in core banking enabled change, business transformation, credit risk management and strategy development. His career in banking and consulting covers assignments in Germany, United Kingdom, Switzerland, Turkey, Nepal, Sri Lanka, ASEAN and many other parts of the world.

He has managed retail and wholesale banking operations for major global banks in Europe and Asia. After his stint as Deputy General Manager of a joint-venture merchant bank in Indonesia, his interest turned to fi nancial services consulting. His consulting assignments constitute a highly diversifi ed portfolio that includes some of the largest commercial banks in Asia.

ACKNOWLEDGEMENT

Core Banking TransformationCritical Success Factors and Best Practices

Table of Contents

1. Core Banking Trends in Asia Pacifi cMarket Trends1.1 Prominent recent deals in the region1.2 Geographic dispersion of deals in recent years and 2006

estimates1.3 Activity within countries and their vendor preferences1.4 Estimates of system and software spending in Asia

Pacifi cTechnical Trends1.5 Evolution and convergence of core banking systems1.6 Technology integration in Asian countries1.7 Trends in platform usage among Asian countries1.8 Trends in deployment approach

2. Bankers’ Perception Survey on Core Banking System Selection 2.1 Survey results on key reasons for replacement2.2 Survey results on factors considered in system selection2.3 UNIX versus mainframe – survey results on

considerations in system selection

3. Core Banking System – An Overview3.1 Core banking system – an introduction and defi nition

3.1.1 Defi nition of core banking system3.1.2 What to expect in core banking replacement

3.1.3 Rationale for front-end systems replacement3.2 Overview of the core banking system replacement

project3.3 Approaches to replacement

4. Phases of Core Banking Replacement and Critical Considerations 4.1 Phases of core banking replacement – an overview4.2 Timeline of replacement project stages4.3 Phase 1 – Business justifi cation and blueprint

4.3.1 Developing business objectives4.3.2 Delta methodology – assessing future requirements

4.4 Phase 2 – Selection 4.4.1 Reasons for replacement 4.4.2 Considerations in determining selection criteria 4.4.3 Key considerations in vendor selection4.4.4 The right architecture and platform4.4.5 Selection process

4.5 Phase 3 – Implementation 4.5.1 Key challenges and critical success factors4.5.2 Implementation process

4.6 Phase 4 – Deployment4.6.1 Deployment process4.6.2 Deployment approaches

4.7 Risk mitigation4.8 Financial implications

5. Core Banking Replacement Building Blocks5.1 Application architecture and core banking

5.1.1 Key issues5.1.2 Deployment strategy

5.2 Service oriented architecture5.3 Interface considerations 5.4 Coexistence

Table of Contents

2 Asian Banker Research Report

Table of Contents

5.4.1 Branches5.4.2 Call centres5.4.3 ATM transactions5.4.4 Other online interfaces5.4.5 Batch interfaces – inward clearing5.4.6 Batch interfaces – outward clearing5.4.7 Other transaction implications

5.5 Data conversion and data cleansing5.6 Product rationalisation 5.7 Process rationalisation

6. Critical Success Factors and Best Practices6.1 Project organisation and programme management

6.1.1 Stage 1 project organisation6.1.2 Stage 2 project organisation6.1.3 Stage 3 project organisation

6.2 Critical success factors and best practices in system selection

6.3 Critical success factors and best practices in vendor selection

6.4 Best practices for vendors (for successful implementation)

7. Unique Core Banking Replacement Considerations7.1 A large multinational bank7.2 A small commercial bank7.3 An Islamic bank7.4 “Internet only” banks7.5 Mergers and acquisitions of banks

8. Country Trend Analyses 8.1 India8.2 China8.3 Japan, Korea and Taiwan

Asian Banker Research Report 3

8.4 South East Asia – Indonesia, Malaysia, Thailand and Singapore

9. Vendor Assessment9.1 Vendor and product assessment 9.2 Market positioning

10. Conclusions10.1 Conclusion 1 – for bankers10.2 Conclusion 2 – for vendors

A1. Appendix I – Case StudiesA1.1. State bank of IndiaA1.2 Union bank of Philippines

A1. Appendix II – An Average Request for Proposal


Table of Contents

Executive SummaryIncreasing consumer demands, high costs and widespread dissatisfaction with ageing systems are making it increasingly diffi cult for Asian bankers to put off decisions to replace their core banking systems. We feel that the banking industry worldwide is nearing a time when replacing core banking systems would be a necessity rather than an option. However the complexity of the task is such that it is often compared to a heart transplant, involving huge risks, high costs and substantial time and human resources.

The critical need for replacement stems from rising customer expectations and existing technical limitations. Banks are fi nding it imperative to expand their channels and services while managing operational and technical costs even as margins are shrinking due to stiff competition. But this is hampered by technical limitations as many traditional fi nancial institutions are shackled by a series of heavily siloed non-integrated back-offi ce legacy systems in which customer information resides in multiple and unconnected locations. Attempts to integrate these through layers of middleware have just made the structure more complicated in many cases. On the other hand, abandoning the antiquated structure itself presents a major challenge from the organisation and fi nancial perspectives. But competitive pressures are forcing banks to take speedy actions, as can be seen in our analysis of trends in Asian markets.

Analysing the Asian markets and the recent core banking replacement decisions, we found that there has been a gradual rise in the number of core banking deals in the last two years. Interestingly, almost half of the deals during this period have come from state-owned Indian banks. These banks had faltered due to competitive pressure from private banks and have found it imperative to purchase (in most cases for the fi rst time) new core banking systems and upgrade themselves technically to improve product innovation, agility in decision making and cost effectiveness. We expect the Asia-wide trend to continue in the year 2006; but as the Indian market nears saturation, there are likely to be fewer deals from this country in the following years.

Looking at the trend in countries that have fi rst-generation technical sophistication, we have discovered that core banking replacement is considered a cyclical industry as banks come to the market about every 15 years to replace an ageing system and improve their effi ciencies. In the last two years, many banks in countries like China, Taiwan and Malaysia have shown initial signs of awakening to the need for technical advancement. We expect to see increasing activity in China with foreign banks getting full access to the sector in 2007 under WTO stipulations and with China’s hosting of the

Execut ive Summary


Olympics in 2008. On the other hand, we have found that banks in countries like Japan and Indonesia are still mulling over the wisdom of replacing.

Once a bank has decided to replace its system, it embarks on a complex process involving a series of critical choices. To start with, the bank has to decide on the most appropriate approach to system replacement. The choices vary with the availability of technical skills, complexity of the project, availability of products and costs involved. As banks weigh their options, they often have to consider the pros and cons of “buying” versus “building” and “purchasing” versus “outsourcing”. We have discovered that most Asian banks increasingly prefer to focus on their core business rather than lock their resources in building a system and there is a distinct trend towards the purchase of packaged solutions. However for large multinational banks, a ready packaged solution often does not meet the complex requirements and hence may require further development (as in the case of HSBC) or substantial customisation at the minimum.

To better comprehend the complicated process of core banking replacement, we begin with a defi nition of the core banking system. We defi ne it as a highly effi cient “customer accounting” and transaction processing engine, for high volumes of back-offi ce transactions and customer-level accounting and reporting of the deposit and loan products processed in the bank. However it does not include the front offi ce. Thus we believe that the bank has to fi rst determine whether it really needs to replace its core system or it can manage with just front-offi ce replacement. In many cases, it is likely that the bank needs to replace both along with the general ledger – which would be a project of even bigger magnitude. If the bank has to change both front end and core banking, we recommend it be done through the same vendor to avoid integration issues.

Our research shows that banks which go ahead with replacement should make a clear transition from their legacy system to the new system. Partially bringing old elements such as codes, process automation and loss-making legacy products into the new environment will lead to sub-optimal returns.

We have divided the process of core banking replacement into four phases. The fi rst phase is business justifi cation and identifi cation of business requirements through delta analysis. We believe that the bank should, fi rst and foremost, determine its long-term strategic goals as these would guide the bank towards the critical requirements for its system. With the business objectives in mind, banks need to analyse the capabilities and defi ciencies of their existing core banking system to determine the new system’s requirements – yet during our research, we discovered that only 70% of the banks in our sample do so. In addition to setting the objectives, the bank should establish the business and fi nancial justifi cation for the project at this


Execut ive Summary

early stage of the process.

The second phase of the project is selection of the system and the vendor. Selection of a core banking system will affect not only the growth and fi nancials of the organisation but also its viability and competitiveness. Hence banks need to critically evaluate all available options and select the system that provides the right DNA (the architecture) to meet its business and strategic requirements. We believe that the selection process should involve business representatives from all functional divisions owing to the pervasive nature of these systems within the organisation. Viewing the project as just an IT project would be a recipe for failure.

The selection process begins with the issuance of a Request for Proposal to various vendors. Each of the bids is assessed on both qualitative and quantitative terms across a matrix of selection criteria. The critical requirements from a new system are fl exibility and scalability to cater to future growth. We advise banks to ensure that with the new system, they are not simply shifting to a bigger box which may become a constraint again in a few years’ time, as this would defeat the whole purpose of replacing the system. Equally important is that banks should not be enamoured with “bells” and “whistles” (which are more often than not the front-end features) and should look for a system that has the requisite processing power rather than just a user friendly front-end screen.

We have discovered that one of the challenges is picturing the banking landscape in years to come due to the rapid pace of change in the banking business. Thus the right selection would be one with a forward-looking fl exible architecture that has the ability to support the business ambitions of the bank and allows for future modifi cations with ease. This can come from Service Oriented Architecture (SOA). SOA is a relatively recent development which, in its purest sense, is centred on loosely coupled components which support generic services and are based on web technology. In a core banking context, it essentially means reducing barriers in antiquated infrastructure and creating real-time integration of disparate systems and sharing of databases on a fl exible and easily upgradeable infrastructure. We advise banks to look for a system that has the fl exibility of SOA and to integrate their systems and components in an SOA-based framework within the bank.

Banks need to select not the “best” system available but the one that is most appropriate for their particular requirements. Different banks and their unique requirements are discussed in section 8.

Equally critical is selecting the right vendor. We believe that it is imperative for banks to consider vendors as long-term partners in growth in today’s fast-paced environment. The critical vendor assessment criteria include trust


Execut ive Summary

in the vendor’s ability to meet the business objectives (through optimum customisation and localisation of the product) as well as the vendor’s reliability, implementation capabilities and fi nancial strength. Vendors that have a track record of providing international-quality products while meeting the local needs of banks are more likely to achieve long-term success. The mix of product and services coupled with pricing are critical considerations. We have rated leading vendors in Asian markets based on our assessment and a survey done among bankers – this is discussed in our section on vendor assessment.

Platform choice is one other critical factor in selection. While mainframe remains unbeaten in its robustness and stability, UNIX-based systems are becoming more popular. We have discovered that banks in Asian countries are increasingly shifting towards the more agile and fl exible UNIX systems, which are perceived to have lower operational and maintenance costs. While this is true for banks that have lower transaction volumes, it may not be so for large retail banks. We believe that mainframes continue to have a distinct advantage in terms of stability and scalability. Hence for mission critical projects, mainframes would still be preferred for their reliability. However for small banks (and those banks that are acquiring a core banking system for the fi rst time and whose transaction volumes are not very high), a UNIX-based system could meet their requirements. As more than 50% of the deals in Asia have come from small banks, UNIX-based systems have become more common.

The third phase of the project is implementation. The key objective is to operationalise and pilot the transformed future state, including technology, process and organisational change. This involves developing detailed designs, including system designs for confi guration and customisation and designs for interfaces and data conversion. The other critical elements of this phase are building and testing the system, implementing pilot projects and conducting business acceptance tests at each stage. We recommend that banks limit customisation of the core banking system to what is essential as it may affect the core processing ability of the system. Rather, the banks should customise the front end which interacts with the users.

At each stage, the bank should undertake delta analysis to determine the effi cacy and success of the project; this would determine whether it progresses to the next stage. Delta analysis and sign-off at each stage are essential to ensure that deliverables and expectations match, or else the project can easily digress from its initial plan and increase in scope through incremental changes which will lead to schedule and cost overruns.

The next and fi nal phase of the project is deployment. This is probably the most critical and challenging stage, where the bank undertakes the actual


Execut ive Summary

deployment of the new system. The process involves numerous logistical issues such as data conversion, interfacing and coexistence.

Banks can approach this transition in two ways – big bang implementation and gradual deployment. Big bang essentially means all systems go live at the same time. While this is quicker, it is also riskier. Instead we recommend phased implementation, where deployment is done in small clusters, though the bank has to tackle the tricky issue of coexistence. We believe that the gradual step-by-step approach is appropriate in most cases as it entails lower risks, facilitates change management and allows changes to be incorporated in the technical framework as it is being installed (to provide a better fi t with the business).

Data conversion and data mapping are two crucial elements that the bank has to deal with during deployment. The data migration and conversion process is often hampered by lack of available information on the old system. Mass migration requires a large capital investment, takes a few years to implement and poses a signifi cant risk of service interruptions that can reduce customer satisfaction. The other critical challenge is to maintain smooth operations and develop interfaces across delivery channels during transition through coexistence of two systems.

We believe that banks should predefi ne the milestones at each stage of the replacement process and ensure they are adhered to. At any stage, if the bank fi nds that it cannot achieve these milestones, it may review its project and decide whether and how it wants to continue the project.

Our research into change management during replacement shows that the majority of banks upgrade their system or implement a new one to meet existing users’ process and work culture requirements. Instead, however, we recommend that banks align their products, processes and work culture with the new system. In other words, the replacement should be undertaken together with product and process rationalisation coupled with work culture transformation in order to optimise the returns from the new system.

This embracing of new technology requires tremendous effort in change management, which demands extensive user training and re-engineering of processes across the organisation. There is often resistance to change and employee dissatisfaction during the transition. We believe this can be countered only through effective communication and developing the right business environment.

We have discovered that just 30% of recent replacement projects had active CEO involvement. However our research shows that successful projects require the backing of a strong leader from top management with a strategic


Execut ive Summary

mindset and the duty to see the project through. Strong leadership support and a capable steering team (which can harness the bank’s resources, take quick decisions and motivate staff to see the project through) are critical for success. Banks need to develop strong internal teams that have effective communication and technical skills, to share decision-making with the service provider to overcome problems. The complexity of the process and inevitable hiccups will demand that banks engage in the process with thorough planning and programme organisation.


Execut ive Summary

1Core Banking Trends in Asia Pacifi c

This section examines the trends in core banking transformation among Asian countries and covers a wide spectrum of issues ranging from pattern in deals, replacement approach, platform selection, implementation and key architectural trends. The aim is to learn from recent decisions and understand the market dynamics of this region.

Core Banking Trends in Asia Pacifi c

Market Trends1.1 Prominent recent deals in the region1.2 Geographic dispersion of deals in recent years and 2006

estimates1.3 Activity within countries and their vendor preferences1.4 Estimates of system and software spending in Asia Pacifi c

Technical Trends 1.5 Evolution and convergence of core banking systems1.6 Technology integration in Asian countries1.7 Trends in platform usage among Asian countries1.8 Trends in deployment approach

1.1 Prominent Recent Deals in the Region

Major Asian Core Banking Deals in Last two Years

In keeping with the worldwide trend, Asian banks have been active in replacing and upgrading their core banking systems in the last few years. We believe high demand and competitive pressures are forcing many banks in the region to improve their technical base.

Analysing the recent decisions, we noticed three signifi cant trends. Firstly, more than 50% of banks that decided to replace their core banking systems were small banks with an asset base of less than $1 billion. Medium to large Asian banks are taking considerably long to mull over the wisdom of replacing. Secondly, banks are increasingly favouring the UNIX platform. Part of the reason for this observation is that most of the recent deals came from small banks, for which the UNIX platform is more feasible. Thirdly, no vendor dominates the region, but Asian service providers have been given preference by banks while vendors with strongholds in Europe and the United States fi nd it diffi cult to develop a solid position here.

Looking at the geographic dispersion of recent decisions, we discovered that the concentration of replacements has varied in the last two years. However the Indian banking industry has taken a clear lead in core banking transformation. Most of the deals came from state-owned banks like Bank of Baroda, Allahabad Bank and Central Bank of India.

•

•

•

Market Trends


Core banking Trends in Asia Pacif ic

No vendor dominates the country but Infosys and TCS have taken a fair share of the pie. There has been a distinct preference for local vendors as they offer international-quality products and yet understand the unique Indian requirements.

Leading Vendors in Asian Countries in Last two Years

In China, SAP clinched the core banking systems deal awarded by China Minsheng Bank, marking the entry of this global vendor in the region. Chinese banks are increasingly considering replacement; however following implementation problems in a few Chinese banks, they are now more cautious about taking the plunge. Taiwan banks did not enter into a single deal in 2004 but showed sudden activity in 2005. I-fl ex has emerged as the top vendor in this country.

The Philippines was rather subdued with just two deals in 2005 (as compared with fi ve deals in 2004) – both came from smaller banks and were won by Nucleus Software. The last major deal in the Philippines was that of Union Bank of Philippines which replaced its system with Finacle of Infosys. Malaysia, on the other hand, continued to witness a fl urry of activity with many small banks upgrading their ageing systems primarily through local vendors.

Internationally, one of the biggest deals in the past year was for HSBC’s global operations, which was won by Temenos. The bank is understood to be improving further on the present solution. Within the region, DBS Bank’s core banking deal was another feather in the cap of Infosys, a

•

•

•

Core banking systems market continued to be active in 2005

No vendor emerges as a clear leader in Asian region, but some vendors have higher market share in certain countries



leading player in the region, particularly in India.

Analysing vendor dominance in the region, we discovered that I-fl ex, Infosys, TCS-FNS, Nucleus Software and System Access have been popular among second-tier banks in Asia. For large banks, the preferred vendors include Temenos, TCS, SAP and Infosys. Leading international vendors such as Fiserv and Fidelity have shown little activity in the region in the last two years.

TCS-FNS and Infosys are strong in this region, particularly in India. Temenos, however, has had no signifi cant deal in Asia in the recent two years though it continues to be a fi erce contender for deals from top-tier banks across the world. Its last big project in the region was for Industrial Bank of Korea.

Globally, Islamic banking is a fast growing sector with banks demanding a system specifi cally catering to this segment. Within Asia, Islamic banking has been popular largely in Malaysia and Indonesia. The leading vendors for Islamic banking in the region are Silverlake, Infopro and Microlink who have done a fair number of deals in Malaysia.

In summary, we believe that international vendors have found it diffi cult to establish a stronghold in Asian markets as there is distinct preference for vendors who are perceived to have knowledge of the unique local market conditions in addition to a solid track record. Please see our section on vendor analysis for more details.

•

•

•

•



1.2 Geographic Dispersion of Deals in Recent Years and 2006 Estimates

Number of Deals in Last two Years and Our Estimates for 2006

20

15

10

5

0

India

MalaysiaOthers

TaiwanChina

Indonesia

Philippines

Vietnam

Singapore

South Korea

Thailand

Number of deals in 2006(e)

Number of deals in 2005

Number of deals in 2004

Legend

Source: Asian Banker Research

Regional Breakdown of Deals Within Asia for 2005

India50%

Malaysia11%

Greater China16%

Indonesia5%

Philippines5%

Others13%


The deals include only core banking deals in the region. It does not include other applications and systems such as treasury and trade processing.

We believe that activity for core banking systems will increase steadily in the next 2-3 years in Asia Pacifi c. The trend in individual countries will, however, vary based on local market conditions.

Clearly, India continues to dominate Asia’s core banking systems market with its 50% share of the total core banking deals by commercial banks in the region. This is because the emergence of technically advanced

•

•

Market Trends

Indian market is fast reaching saturation; China and Taiwan are opening up



private banks in the country has forced most state-owned banks to substitute (and in most cases acquire for the fi rst time) a centralised core banking system to improve their competitiveness and retain their market share. However we expect the trend to slow down in the next couple of years as most leading banks have already entered into core banking deals. A few banks that have not yet upgraded their systems are fi nding it increasingly diffi cult to compete and are currently evaluating available products and vendors.

Taiwan witnessed a recent surge in core banking deals, though mostly from smaller banks. In China, the number of deals has been rising slowly but steadily as more and more banks evaluate the need for replacement; however most of these deals have been from smaller banks. We expect the current trend in both Taiwan and China to continue this year.

Malaysia has also been active with four deals in 2005, though most of these were again from smaller banks. However we believe some big banks like Maybank are actively considering core banking replacement. We expect to see more core banking deals in Malaysia with Islamic banks favouring local vendors who can meet Islamic banking requirements.

Most other countries saw just a few small deals with the exception of Singapore, where DBS has entered into a core banking deal for its retail business. Thailand and Korea were noticeably absent from the scene in 2005, but we expect activity in both countries to pick up over the next couple of years.

•

•

•



1.3 Activity Within Countries and Their Vendor Preferences

Activity in Banking Sectors for Core Banking Replacement in Last two Years

05 10 15 20 25 30

VendorPreference

InternationalVendors

LocalVendors

Less active, international demand High activity, international demand

Less active, unique local needs Highly active, unique local needs

Trends indicate likely shift in future

% of banking sector replacing CBS in last 2 years

Singapore

SouthKorea

Taiwan

Vietnam

Philippines

Thailand

India

MalaysiaIndonesia

China Legend


The level of activity is represented by the percentage of commercial banks in each country that have awarded core banking system deals in the last two years. It is based on number of deals and gives the same rating to big and small banks.

We believe that almost 25% of the Indian banking sector has entered into core banking replacement deals in the last two years. In absolute terms, the number is far higher than that of any other country – though as a percentage of the whole sector, it may not be as signifi cant. Most banks in this country have preferred local vendors owing to not just the international level of expertise and reputation of the vendors but also their higher level of trust in them. Contributing to this is also the fact that many Indian vendors have advanced in these last few years to become some of the leading vendors in the world.

Interestingly, the banking sectors of Thailand and Korea saw no new deals in 2005 despite being active in 2004. However there was increased activity in Taiwan and China. Increasing competition from foreign banks in these countries is forcing banks to evaluate their core banking replacement needs. We believe the core banking transformation in these countries is set to accelerate over the next few years.

•

•

Market Trends

Indian banks have favoured technical advancement through local vendors

Other Asian countries expected to continue to show demand for core banking transformation



Most Chinese banks have shown a strong preference for systems that are designed to suit their specifi c and unique requirements. For this reason, smaller Chinese banks have preferred domestic vendors while larger banks have preferred international vendors that can meet their local needs. Similarly, many Malaysian banks have preferred local vendors that can meet their Islamic banking requirements.

Banks from developed markets like Singapore and Hong Kong have fi rst-generation technical sophistication and are undertaking a cyclical replacement of their ageing systems. In contrast, banks in countries like India, Pakistan and Vietnam are purchasing core banking systems for the fi rst time now. For obvious reasons, activity among the banks that lack technical sophistication will increase.

We believe that most Asian banks prefer to select vendors that either involve local people through a setup in their country or partner local vendors. This is because there is a perception among the bankers that a local is more likely to understand and adapt to the unique local needs of a particular country. However in many countries, the availability of international-quality products from local vendors is a limiting factor which has forced banks to look for alternatives.

•

•

•

China banks have preference for systems that cater to their unique needs



1.4 Estimates of System and Software Spending in Asia Pacifi c

Investments Made by Asian Banks in Core Banking System Software and Services

800

600

1,000

400

200

0.14

2004 2005 2006f 2007f0

(%)($million)

0.10

0.13

0.12

0.11

Estimated spending by Asian banks on purchase of CB system software and services

Legend

Spending as % of total revenue of Asian banks


The estimates of investments only cover the cost of system software such as licence fees and the service cost. It includes only core banking systems replacement by banks and excludes other system applications such as treasury and trade processing.

We have discovered that the cost structure of core banking deals varies considerably due to multiple factors such as the scale and complexity of the replacement process. However, generally, we believe that the total investment required to purchase core banking systems is made up of software and service cost which constitutes 30%, system integration cost of 20-25% and hardware and infrastructure cost of 45-50%.

Based on our analysis of recent deals, the system and service cost for a small bank (with a size of $1 billion or less) comes to $5 million-10 million. For a medium-sized bank ($1 billion-50 billion), it is $25 million-30 million. For large global banks (more than $50 billion), the deal size is likely to be higher depending on the extent of transformation being undertaken.

•

•

Market Trends

Steady increase in spending likely to continue; no signifi cant jump expected in near future

Deal sizes have varied from about $5 million for small banks to more than $50 million for large wholesale banks



A critical cost item is system software cost; this includes the cost of software licences, which varies depending on project. For example, for FNS customers, software licence cost has varied from $1 million to over $7 million, with an average of $1.8 million in 2005.

Overall, we have seen a steady rise in investment made by banks in Asia over recent years. We expect the trend to continue. However, as a percentage of total revenue, we believe the investments are likely to show a declining trend as the banks have witnessed even higher growth in revenue. We also believe that there is stiff price competition among vendors and that this will keep the costs in core banking replacement under control.

•

•



1.5 Evolution and Convergence of Core Banking Systems

Evolution of Core Banking Systems

Business Platform J2EE, .NET

EAI, BPM, WS

Parameterisation

Legacysystems

1970 1990 2004 2005

Web XML Web services Service-oriented architecture?

China Bank: Kirchman

ICICI: Finacle

HDFC: I-flex for retail

KDB: FNSBanco de Oro:

ICBSChinatrust:

FNS

HDFC: I-flex for corporate

OCBC: Silverlake

StanChart:testing open

sysKasikorn: IBM

Taishin: FNS Baroda: Finacle

B.Shanghai:Temenos

HSBC-Temenos DBS - Infosys Central Bank

of India - TCS China Minsheng - SAP


Convergence in Core Banking Systems

Parameters

Mainframesystems

UNIXsystems

J2EE, .NET platforms; EAI, BI, WS integration toolsTowards

core banking systems today


The fi rst generation of banking technology was represented by the IBM mainframe, which had immense data processing capabilities but was not as effi cient in back-offi ce accounting functions. Nonetheless its reliability

•

Technical Trends

Evolution of core banking industry in Asia shows increasing convergence of technologies and focus on architecture of systems



and scalability remain unbeaten today. In the next stage of evolution came parameterisation of processing rules and enhancement in automation from back- to front-offi ces. Here, the UNIX platform solutions have shown high functionality, with some of them using relational database technology to maintain accounting and administrative data.

UNIX systems have borrowed ideas freely from mainframes such as logical partitioning, the ability for isolation, the ability to share across partitions, and common interfaces. Integration tools and other technological advancements have brought about a certain level of standardisation and convergence of technologies today at the platform, application and architectural layers.

Banks are increasingly looking for solutions that have the technical capability to meet their unique functional requirements while improving their competitiveness. There is also increasing demand for component-based modular systems that do not have integration issues.

Trends in Requirements

• Architecture that supports flexibility, growth and services such as Service Oriented Architecture (SOA)

• Systems capable of global deployment – multi-channel, multilingual with high connectivity

• Customer centric focus with increased connectivity across processes and functions. Integrated solution increasingly available

• Convergence of old and new technology with increased scalability and flexibility


Service Oriented Architecture (SOA) is a relatively new concept that has gained popularity quickly. Herein, business applications are constructed from independent reusable interoperable services that can be reconfi gured without a vast amount of technical labour. The concept is based on web services and components that are brought together to perform specifi c business tasks. It essentially means reducing barriers in antiquated infrastructure and creating a real-time integration of disparate systems and a sharing of databases on a fl exible and easily upgradeable infrastructure. We discuss this in more detail in section 5.

On the architectural front, J2EE and .NET are two architectural frameworks that have evolved in the last few years. These are new-generation fl exible

•

•

•

•

Banks need to adopt Service Oriented Architecture



and interoperable architectures that facilitate the complete meshing of core banking solutions with the complex technology fabric of the bank.

The key attributes that banks require from their architecture are fl exibility, scalability and agility. With customer expectations increasing, banks have moved towards centralised systems with customer-centric architecture, where they drive the business through a single view of the customer and the paramount consideration in all decisions is the consumer.

IT Service Providers in the Region

• Vendor consolidation through mergers and acquisitions.

• Partnership among vendors to mix and match solutions.

• Standard protocols and fierce competition among IT service providers leading to increased product offerings and price competition.


The growth in demand for core banking systems in Asia Pacifi c has prompted many international vendors such as SAP, Temenos, Fidelity and Misys to focus increasingly on the region. At the same time, vendors that began their operations in Asian countries have grown to become recognised names across the world; these include companies like Infosys, I-fl ex and TCS.

Desire to become the leading player in the market has led to mergers and acquisitions among IT service providers. At the global level, Fidelity’s acquisition of Sanchez broadened its reach to a larger collection of banks. Among leading vendors in Asia, TCS acquired FNS in a leap from their previous alliance. Another example of consolidation in the industry is Oracle’s acquisition of a stake in I-fl ex. These players are developing an increasingly strong foothold in the core banking systems market.

Greater convergence makes it diffi cult for bankers to differentiate between vendors’ value propositions. However standard protocols and fi erce competition have led to more product offerings and price wars – a boon for the industry as a whole.

•

•

•

•

Asian vendors are increasing their global reach

Desire to become leading player has led to consolidation in the industry



1.6 Technology Integration in Asian Countries

Technology Integration in Asian Countries

‘Acc

ount

cen

trici

ty’

‘Cus

tom

er c

entri

city

’

Thailand

India (State Banks)

Philippines

China

Malaysia

Indonesia

Hong Kong

Taiwan

Singapore

Australia

India (Private Banks)

Japan

Korea

Branch

compute

risatio

nBra

nch

network

ing

Centralis

ed

data centre

Core b

anking syste

ms

advancement

Robust mid

dleware

and basic C

RM

Web serv

ices and

custom

er centri

city


We tracked the technical advancement of banking sectors and architectures in several Asian countries. We discovered that the integration of technology and the movement from account centricity to customer centricity have varied signifi cantly among Asian countries. Developed countries such as Japan, Singapore, Hong Kong and Australia have shown distinct technical advancement not only on the core banking front but also in their banking systems architecture, achieving customer centricity through integration.

On the other hand, developing countries like China, Thailand, Philippines, Indonesia and Malaysia are far behind. These countries are now moving towards data centralisation (having advanced from branch automation), but many of the banks have yet to achieve core banking sophistication. Architectural integration is still at the initiation stage in these countries. However we believe that competitive pressures are forcing banks to expedite this process.

In India, relatively new private banks have given a new direction and a signifi cant boost to core banking integration in the banking sector of this country. State-owned banks are already beginning to arm themselves with more integrated systems to face this competition.

•

•

•

Technical Trends

Developed countries have shown distinct technical advancement



1.7 Trends in Platform Usage Among Asian Countries

Recent Core Banking Acquisition Trends Among Asian Banks

● South Korea

● China

● Pakistan

● Taiwan

● India

● Vietnam

● Singapore

Primarily UNIX-basedSystem Users

● Japan

● Hong Kong

● Philippines

● Thailand

● Malaysia

● Indonesia

Primarily Mainframe-based System Users

Likely to shift to UNIXSource: Asian Banker Research

Traditionally, Asian banks – particularly those in Korea, Japan and China – use mainframe-based proprietary systems. The robustness, stability and scalability of these systems have been proven over the years and continue to attract these banks. But in the last fi ve years, market dynamics have changed considerably and banks are increasingly considering the UNIX-based systems.

The shift in preference has been brought about by competitive pressures in the market which have forced banks to look for systems that can meet their functional requirements with fl exibility and agility. Accelerating the trend is the fact that most Asian banks are smaller compared with many European and multinational banks and hence UNIX systems are considered adequate for their scalability requirements. Another major factor that draws many bankers to UNIX is the cost savings. Changes in regulatory requirements (under Basel II) have also forced banks to look for an integrated and fl exible system.

For these reasons, we have seen an increasing shift among Korean and Chinese banks towards UNIX-based systems. However Japan and many South East Asian countries still seem to be adopting a “wait and

•

•

•

Technical Trends

Many countries continue to be primarily mainframe users but there is a strong shift in favour of UNIX systems

Competitive pressures and cost effectiveness of UNIX-based systems are driving the shift



see” approach. In mature countries like Singapore, there are very few deals as well; but in the country’s most recent deal, DBS opted in favour of a UNIX platform.

In the Indian subcontinent, most commercial banks are adopting core banking systems for the fi rst time. Thus most banks have taken advantage of this new-generation technology. As there is no problem of integrating with the existing system, implementation is cheaper and less complex. Moreover, the traditional preference of Indian banks (and Indian vendors) is for a UNIX environment.

While smaller Asian banks have favoured UNIX-based systems owing to their cost effectiveness, we believe that mainframe has proved to be more reliable and scalable for a larger size of operations. As transaction volumes increase, the total cost per user in mainframe decreases, making it more competitive.

•

•



1.8 Trends in Deployment Approach

Deployment Approaches in Recent Core Banking Decision

LongDuration

ExistingImplementation

Time

ShortDuration

Gradual Implementation Big Bang ImplementationImplementationApproach

Singapore

HSBCBank

ChinaMinsheng

Bank

CentralBank of

India

AllahabadBank

MuslimCommercial

Bank

Bank of Panshin

UnionBank of

Philippines

Bank ofEast Asia

Hua Xia Bank

IndustrialBank of Korea

CathayUnitedBank

StateBank of India

DBSBank

ChinaDevelopment-

Bank

Bank Asset SizeMore than $100 billion

$20-100 billion

Less than $20 billion


The banks have two options in deployment. “Big Bang” implementation largely involves a new system which goes live at the same time that all the processes are shifted onto it. This is believed to be the quickest but probably also the riskiest way to deploy the project. While the risks are high, the integration problems are minimised as old and new systems do not coexist. A phased approach, on the other hand, involves gradual deployment across branches/functions generally through “big bang” in small clusters. Here, the banks have to face the sticky issue of coexistence of two systems.

Our research shows that in Asia Pacifi c, the traditional phased deployment approach is distinctly preferred for its reduced risks and gradual change in processes. Though the choice of approach varies with banks’ unique requirements, top-tier banks in general have preferred the gradual approach. This is because their scale of operation makes “big bang” not only extremely diffi cult but in some cases also unfeasible.

Most banks with an asset size greater than $100 billion have preferred phased deployment and the time required has stretched over many years. For example, it is expected to take about fi ve years for HSBC. Similarly, ABN AMRO plans to gradually implement its system in the Greater China region and some other Asian countries over a period of

•

•

•

Technical Trends

Bigger banks continue to prefer gradual deployment while some smaller banks choose “big bang” approach



fi ve years. For State Bank of India and Central Bank of India, it is likely to be around four years. We believe that it is critical to keep the rollout time and the period that two systems coexist as short as possible.

On the other hand, a few smaller banks have taken the quicker approach of “big bang”. These include: Union Bank of Philippines whose system by Infosys was implemented in just one year; Industrial Bank of Korea by Temenos; and Cathay United Bank, Taiwan by TCS-FNS.

•



2Bankers’ Perception Survey on Core Banking System SelectionWe have conducted a series of surveys in the Asian banking sector to strengthen our research on various aspects of core banking transformation. Our surveys have given us an insight into how bankers assess various vendors in the region, key considerations in the selection of a new system, and platform preference among Asian banks. We have discovered that some of the common perceptions lack sound foundation.

Bankers’ Perception Survey on Core Banking System Selection

2.1 Survey results on key reasons for replacement 2.2 Survey results on factors considered in system selection2.3 UNIX versus mainframe – survey results on considerations in

system selection

2.1 Survey Results on Key Reasons for Replacement

Perception Survey on Key Reasons for Replacement

% of executives citing area as a problem10 20 30 40 50 60 70 80

Other

Errors in operation

Errors in data

Availability

Errors in processing

Scalability

Timing problems

Technology

Simplification

Integration

Cost

Flexibility


A survey done in Asia Pacifi c countries last year found that infl exibility, high cost and diffi culty of integration were the three main problems that banks faced in legacy systems.

•


Banker ’s Percept ion Survey


2.2 Survey Results on Factors Considered in System Selection

Perception Survey on Factors Considered

Ran

king

Importance

Cost

Short product time-to-market

Availability of third party applications

Ease of integration

Vendor reputation and track record

Straight through processing/ real-time capability

Truly modular and integrated, single sign-on

Functionality

Scalability

Reliability/ stability


With increasing standardisation and convergence, banks believe that it is now easier for them to switch from one vendor to another for multiple systems. To assess the importance that banks give to various parameters of selection, we conducted a survey a few months back.

The survey highlighted the importance of cost in the selection of a core banking system in Asia. Most banks considered cost savings – through lowering of maintenance cost or operational cost – as one of the key benefi ts that was motivating them to change their core banking systems.

Another key reason cited by many bankers was their desire to improve competitiveness through faster rollout of products, product innovation and differentiation. Availability of third-party applications and ease of integration were other critical factors that the bankers looked for in system selection. Vendor reputation and track record also came high in the list. Trust in the vendor’s ability as well as the vendor’s reliability and fi t with the project are often cited as considerations in the selection process.

Interestingly, architectural features such as STP, fl exibility and scalability were much lower in the list. However, we believe that these are essentially the features that will determine the functionality of the system in future.

The survey results indicate that many bankers tend to give undue importance to cost and other considerations in their selection process, which often leads to awkward consequences.

•

•

•

•

•

Cost remains the key consideration when choosing a core banking system, regardless of platform


2.3 UNIX Versus Mainframe – Survey Results on Considerations in System Selection

Perception of Strengths of Each System

Interestingly, mainframe systems are perceived as old, while UNIX systems are perceived as new, which is not always true.

Stability

OldArchitecture More Vendors

vs Monopoly

Scalability ApplicationAvailability Instability

4232

21

3747

3711

5

MAINFRAME SYSTEMS UNIX SYSTEMS

Availability of Internal Skills

Many banks in Korea and Japan use internal programmers to customise their systems.

Total Cost ofOwnership

UNIX systems can be approximately 50% cheaper than mainframe technology.

For operational expenses, UNIX systems can be 30-40% cheaper than mainframes.


In a survey done some months back, we asked bankers what they saw as the strengths and weaknesses of UNIX and mainframe systems. We found that while there are an increasing number of banks favouring UNIX systems due to low cost of ownership, scalability and recent technical advancements, stability is still perceived to be the biggest strength of mainframe systems.

According to one banker, keeping legacy systems running consumes 60-70% of IT budgets, leaving little resources for technical enhancements to gain competitive advantage. According to one bank in Korea, “When we purchase a UNIX system, we enter a buyers market as there are many products available and we can choose. But when we purchase mainframe, we enter a sellers market and may have to wait.” Another banker feels that while UNIX technology is improving, it may not match the scalability of mainframes yet.

Banks that have invested in their system are aware that a considerable amount of time, money and effort is involved in customising and adapting these systems. Replacing these systems is a painful and risky exercise. However the fact remains that many of these legacy systems are unlikely to give banks the innovation and technical advancement that can be provided by solution providers who have been constantly upgrading

•

•

•

Stability is the biggest perceived strength for mainframe systems, while lower TCO is the biggest perceived strength for UNIX systems



their technology. Banks are increasingly realising that their expertise is in banking and not IT development.

According to a leading global vendor, Asian banks have always been very interested in UNIX solutions and so, proportionately speaking, we have more UNIX centres in Asia than in the United States. We believe this is because the core banking market today is dominated by Indian banks, which have traditionally preferred UNIX-based systems.

While the debate over preferred technology continues, it goes without saying that what may be considered suitable by one bank may not be appropriate for another bank. For example, big banks with an extensive scale of operation may fi nd it risky to switch from mainframe systems to UNIX technology primarily because of complexities, high risks and huge costs involved in the process. However a small bank which is building its core banking system from scratch (or replacing it) may prefer lower-cost open systems.

Open Versus Proprietary – Perception of Features

Strengths

Weaknesses

Strengths

Weaknesses

Reliability - Highly reliable

Scalability - Highly scalable, essential for larger banks

Robustness - Robust applications with good track record

Security - Substantially higher levels of system security

Cost - Cost to acquire and maintain

Agility - Perceived slower development and adaptations to trends in technology

Hardware/Software - Fewer hardware and software suppliers can lead to challenges in negotiating a reasonable pricing if the bank does not posses sufficient bargaining power

Skills - Smaller and hence more expensive pool of skilled resources available in the market

Cost - Perceived lower total cost of ownership (TCO). However, in real life operations, the TCO in complexity of operation increases with the numbers of users and transactions volume

Architecture - Considered more flexible architecture. Our analysis however shows that some of the mainframe solutions have a more contemporary architecture

"Add on's" - Perceived higher availability of third party applications. However, our analysis shows that such applications can also be integrated into mainframe architectures

Hardware/Software - More choice of hardware systems, and application software provider

Functionality - Integrated universal Banking solution often provide higher level of functionality (at the cost of scalability)

Skills - Larger pool of skilled resources available in the market

Reliability - Less stable than mainframe systems (but this could be acceptable for smaller banks)

Scalability - Lower level of scalability. Scalability comes at the cost of overly complex operating environments

Security - Lower level of security than mainframe systems. Viruses have been found in Unix based environments

Deployment -Not yet proven on large scale though becoming increasingly popular among smaller banks

UNIX SYSTEMMainframe SYSTEM


•

•



Open systems have proved their ability to perform from the security and technology points of view. According to one banker, “5-10 years ago a large bank would go for mainframe, no questions asked. But in the last 5-10 years things have changed. Any bank today, no matter how big, may consider switching to open system.”

On the other hand, most big banks still favour the reliability and stability of mainframes. Some bankers are inclined towards proprietary systems as they are used to working on them. Switching to a new technology would not only involve a huge amount of cost and high risks but also require effort to get used to the new processes.

According to one vendor, “Open systems are most appropriate for Asian banks due to their smaller size compared to many international banks. They don’t need the scalability of mainframes and the scalability of open systems has really increased in recent years.” One leading bank in Korea states that the trend in Korea today is to shift towards UNIX systems from IBM “due to the availability of small packages that can be easily integrated in our system [whereas] when we use mainframe we need to code them which would be a time consuming proposition”.

The right choice varies with banks’ requirements

As can be seen from the survey, platform choice is a dilemma that all bankers face when they consider replacement. Our in-depth analysis shows that for smaller Asian banks, a UNIX platform could be more feasible as they may not need the scalability of the mainframe and UNIX can be cost effective for a small number of transactions. However our research shows that for large retail banks, mainframe is likely to still be the preferred choice because:

It is more reliable and keeps the system running through most upgrades. Hence the downtime is low.

It has the capability to support a large number of users, supports multiple applications and allows better resource management. This is especially important where transaction volumes are high.

It requires less server capacity than UNIX for the same amount of work and has higher continuous availability (due to less downtime).

On the cost issue, UNIX-based systems are generally believed to have a lower total cost of ownership (TCO). However the benchmark, we believe, should not be total cost of ownership but total cost per user. Our research indicates that when the bank has large volumes of transactions and users, the operational cost of mainframe could be lower on a per-user

•

•

•

•

-

-

-

•

Strengths and weaknesses of proprietary and open systems, as perceived by respondent banks

Our research and analysis of the platform features reveal a different picture



basis. Also, while making the cost comparison, banks must consider the switching costs (shifting from existing mainframe to UNIX) and the cost of the coexistence of two systems during the replacement process.

Please see our section on platform choices in section 4 for more details



This page has been left intentionallly blank

3Core Banking System – An Overview

There are various defi nitions of “core banking system” circulating in the market. We have defi ned the core banking system (as we see it) and researched on aspects that are (and also those that are falsely believed to be) included in the replacement. This section provides an overview of the replacement and transformation process. We believe there should be clarity on the components of core banking system replacement even before the process is initiated.

Core Banking System – An Overview

3.1 Core banking system – an introduction and defi nition3.1.1 Defi nition of core banking system3.1.2 What to expect in core banking replacement3.1.3 Rationale for front-end systems replacement

3.2 Overview of the core banking system replacement project3.3 Approaches to replacement

3.1 Core Banking System – An Introduction and Defi nition

Core banking replacement is becoming a hot topic in banking. We have discovered that many banks are considering core banking system replacement because of the following perceived needs:

Ageing Technology Infrastructure – Ageing technology that is increasingly diffi cult and expensive to maintain and support

No Common Customer View – Multiple customer views and complex processes are not easily integrated with the existing technology infrastructure

No Product Factory – Innovative, highly interdependent product bundles are not supported by the existing core banking system; it is laborious to launch new products and services

Long Deployment Cycle – Technological infl exibility demands lengthy development cycles

No/Limited Basel II Support – New and more complex Basel II-driven risk frameworks are not supported

Due to such perceptions, the business users demand an immediate replacement of the core banking systems. Here are some examples of the justifi cation given for this investment to address all of these issues:

“We are losing market share. We need to replace our core banking system now to increase our competitiveness and regain lost markets.”

“We need to replace our core banking system to have a better understanding of our customer.”

“We need to replace our core banking system to be able to bring new products to the market faster.”

“We need a core banking-enabled product factory.”

These and similar statements are what we hear when talking to leading bankers throughout the region.

The software vendors of course are responding to these needs, by claiming:

•

-

-

-

-

-

•

-

-

-

-

•

Perceived needs justifying replacement of core banking system


Core Banking System Overview


“Our system will transform your organisation and make your bank more competitive.”

“With our system, you will be able to signifi cantly enhance your CRM capabilities and gain market share.”

“Our solution will automate your lending process, improve your collateral management capabilities and make you Basel II compliant.”

The key questions which now arise are:

Are the bankers’ perceptions about the outcome of a core banking replacement correct?

Does a “traditional” core banking replacement project address all of these issues?

Do the statements made by software vendors truly refl ect what their clients can expect from a core banking replacement project?

To answer these questions, it is necessary to clearly defi ne what a core banking replacement really is

3.1.1 Defi nition of a core banking systemWe have discovered that there are multiple defi nitions of core banking systems today. However based on our discussions with industry experts, we can defi ne core banking, in simple terms, as a highly effi cient “customer accounting” and transaction processing engine for high volumes of back-offi ce transactions. The purpose of a core banking system is thus to give banks the ability to process large transaction volumes in a fast and effi cient way; clearing, transfers and interest/fee calculation are all the fortes of core banking. But let us explore this in more detail and look at some of the myths regarding core banking replacement projects.

What Core Banking Systems Do

A core banking system is a transaction processing engine with customer-level accounting and reporting of the deposit and loan products processed in the bank.

Core banking also deals with transactions such as interest and fee calculation, pre-processing for statement printing, end-of-day processing, and consolidation of daily individual transactions as

-

-

-

•

-

-

-

•

•

•

Core banking system is simply the core processing power of the bank


Core Banking System is Transaction Processing Engine

Deposits Loans

Common Services

Product Definition & Management

Core Banking System

Cha

nnel

Inte

grat

ion

App

licat

ion

Inte

grat

ion

Rep

ortin

g

Core Banking replacement does not provide you with a front end,

CRM or multi-channel capabilities.

Core Banking replacement does not provide you with an industrial- strength general ledger system,

and ERP capabilities.

Replacing the Front End is a separate system and a separate project

Replacing the General Ledger is a separate system and a separate project

Core Banking replacement does not provide you with an industrial-strength customer

information repository which allows ease of integration of disparate core systems

Core Banking replacement gives you raw power. It provides you with a highly efficient engine for all your transaction processing needs

General Ledger System

Front-endSystem

Core Banking System

Customer Information Repository


“accounting entries” which are posted into the bank’s GL system according to its chart of accounts structure for the daily trial balance sheet preparation. The chart below illustrates the scope of a core banking replacement project.

What Core Banking Systems Do Not Do

Core banking systems do not deal with the customer-facing front end of the bank. Core banking systems also do not deal with the analytics embedded in an industrial-strength data warehouse design.

Core banking systems do not include a comprehensive CIR (Customer Information Repository) though they do include a CIF (Customer Information File) or CIS (Customer Information System) focused on their own processing and reporting needs. These components have only the necessary customer information or capabilities embedded.

In a Service Oriented Architecture solution, the CIR will sit on top of the core banking systems, as it is assumed that a bank will always have multiple core systems which need to interact and share customer information. The chart below illustrates a typical banking architecture and shows where the key components reside.

•

•

•



Conceptual Application Architecture Framework

Sales & ServiceDelivery

BusinessIntelligenceCore Systems

Delivery ChannelsApplication supporting the bank’s delivery channels. Integrates into the customer relationship management and core systems

Data Warehouse & Data MartsEnterprise data warehouse with relevant data marts

Relationship & Risk Management InfrastructureCommon customer view and central customer liability. “The customer belongs to the bank” and not a booking unit

Data MiningUtilise existing information in the data warehouse e.g. to find customer behaviour pattern

Imaging and WorkflowImaging and workflow capabilities e.g. for the commercial lending process

Middleware InfrastructureIntegration infrastructure to link the bank’s systems. A modern architecture is built around an enterprise service bus utilising an SOA

New Age ChannelsInternet-based virtual delivery channels, including Web and WAP services

Customer Information Repository

Dat

a W

areh

ouse

Cha

nnel

Inte

grat

ion

Phy

sica

lC

hann

els

Virtu

al C

hann

els

Other Support Systems

Workflow ManagementDocument Imaging Capability

Core Banking

Deposits Loans

App

licat

ion

Inte

grat

ion

Cha

nnel

Inte

grat

ion

Rep

ortin

g

Common Services


Source: Immacon Research

3.1.2 What to expect in core banking replacementTo start an effective core banking replacement programme, the bank must manage the expectations of all parties involved. Therefore we believe that it is very important to clearly understand what a “core banking replacement” really is. In some cases, a bank might not even need to change the core banking system but just refresh an ageing front-end system. In other cases, a bank might need to do both, i.e. replace the core banking system and simultaneously replace the front-end systems of the bank. This of course is a project of much greater magnitude and is analogous to changing the wheels in a fast moving car.

What you see is not what you get

Many banks evaluate core banking systems based on functions and features. The objective is to get as many bells and whistles as possible. As the initial selection is very much driven by the business user, the vendor would score highly with a “pretty” front end and usability.

The irony here is that the user will not get what he sees. We have discovered that it is a common and understandable misconception of business users that front-end screens relate to core banking. This more often than not leads to sub-optimal results for the core banking project.

It is crucial to recognise that what the user sees is the front end of a banking application architecture (a teller system, an advisor workstation, a kiosk or an internet front-end) but not the “core banking system”. Core

•

•

•

•

Critical for banks to understand what they would get in core banking replacement



banking is about raw processing power: transaction throughput, interest and fee calculation, parameterised product setup, clearing, interfacing with existing systems and transaction sources, etc. The good-looking screens have little to do with critical aspects of core banking and are no indicator for the quality of the core banking system.

3.1.3 Rationale for front-end systems replacementTo make matters more complicated, it is often important to also change the front-end applications, to better reap the benefi ts of the core banking replacement. For the front-end replacement, it is critical to make sure that the front-end applications can be integrated with the back-end systems with minimal effort. For a contemporary core banking and front-end replacement project, it is advisable to deploy SOA and an enterprise service bus.

To deploy a front-end solution for a new core banking project, there are three options:

Package solution with minimal customisation: This is typically the going-in position of banks that are accustomed to “best of breed” package implementations. The potential advantages are faster implementation and lower customisation costs. However, the bank that takes this approach must be determined to follow through and use the package capabilities as provided. Many banks fi nd it diffi cult to sustain this approach as the project progresses and the limitations of the package become clearer.

Package solution customised to the bank’s desired processes: This approach requires the bank to defi ne its multi-channel front-end operating model, processes and performance metrics prior to selecting the front-end package. The advantage of this approach is that the upfront design can help establish a realistic business case and give clear requirements for vendor selection and contracting. However, this approach requires experienced business process designers capable of defi ning the future operating model of the bank.

Custom built solution: This approach requires technical and business process designers capable of defi ning the future business and technical architecture to build and implement the solution. Few banks in the world are suitably equipped for such an undertaking at this time.

During package selection, the bank will typically need to choose from the following scenarios:

•

•

-

-

-

•

Banks may also need to replace front end to reap benefi ts from core banking replacement



Same vendor for front end and core banking: Here, front-end and core banking replacement solutions, though separate systems, come from the same vendor and the vendor is responsible for integrating the front- and back-offi ce applications. This, we believe, is a sound option as the bank deals with only one party and the integration between the two systems is taken care of. However, not many core banking vendors offer this option. In addition, problems could arise if the integration has been done through the traditional approach of tight coupling and does not utilise the benefi ts of an SOA or enterprise bus.

Front-end solution and core banking replacement solution come from different, unrelated vendors: This option is often presented as the “best of breed” approach. Our research shows that in practice, however, this has proven to be the least desirable option. There are integration issues to deal with and often both the front end and the back end (core banking) need to be highly customised to fi t with the solution chosen. Moreover, who decides what is “best of breed”?

-

-

We recommend that banks choose the same vendor for core banking and front end



3.2 Overview of the Core Banking System Replacement Project

Core Banking System Replacement Project – an Overview

Reasons forreplacement

Gap analysis ofexistinginfrastructure

Select rightplatform

Select rightarchitecture

Evaluatefinancialimpact

Risk-returnanalysis

Select softwarevendor andintegrator

Identify rightapproach toimplementation

Project Stages

Developmentof businessobjectives

Selection ofapproach

Developmentof selection

criteria

Biddingprocess

Systemselection

Selectionof serviceprovider

Implementationand launch

Ongoingtechnicalsupport &

enhancement


Replacing or even upgrading the core banking system is a complex and high-risk proposition requiring substantial resources and time. Most banks prefer to defer the decision till the change becomes imperative. The decision making process includes providing fi nancial and business justifi cation to the management and evaluating the risks and returns; it is a time consuming process that requires the involvement of not just the IT people but also decision makers across functions. We believe that opportunity costs are high and hence a successful bank is one which can take fast decisions and has adequate management support to carry them through.

Risk-return analysis has to be coupled with development of business objectives, gap analysis of the existing infrastructure and delta analysis of future needs. We believe that it is critical at all stages of selection and implementation that banks keep business objectives in mind as the primary consideration.

•

•

Core banking replacement is almost like a heart transplant involving high cost, high risk, and substantial effort and time



Core Banking Replacement Stages

Replacement Stages Through the Project

Effi

cien

cy/ P

erfo

rman

ce

Projectstart

Euphoric "We will change

the world"

Disillusioned"This is hard but we

have passed thepoint of no return"

Reality Strike"The honeymoon

is over"Scapegoating

"It’s somebody else's mistake""How can we get out of this"

The Emperor’s New Clothes"We got the old systems in

new clothes"

Masters of the World

"We made it"

ContinuousImprovements


Many projects in the past have failed to meet their intended objectives. While there can be numerous causes for failure, the key reasons include inadequate planning, lack of risk mitigation and inability to make the right decisions at the right time. The mismatch between deliverables and expectations often arises from inaccurate estimation of requirements and scope of project and corresponding unplanned changes in the proposed project.

Please refer to risk mitigation in section 4 for more details. We also discuss the replacement phases and critical considerations of each phase in section 4

•



3.3 Approaches to ReplacementApproaches to Core Banking System Replacement

In-housedevelopment and implementation

Purchase of system software and

servicesComplete

outsourcing

Ownership of hardware and software

Software either developed in-house or purchased from vendor

Implementation of system done in-house

In-house IT expertise required – suitable for large banks

Approach adopted by many banks in Japan and Korea

•

•

•

•

•

Ownership of hardware

System integrator hired for software

Vendor customises, integrates and implements solution according to the bank’s requirements

Critical to select the right software and vendor with domain knowledge

Approach adopted by many medium and small banks

•

•

•

•

•

Outsourcing of software and hardware

ASP hired to meet the core banking needs of bank

ASP maintains the accounts and branches through its own data centre, and meets all the core banking needs of bank

Charges calculated on per transaction or per branch basis

ASP provides expertise but may commoditise service

•

•

•

•

•


Our research shows that banks can choose from multiple approaches for upgrading or replacing their core banking systems. The most appropriate approach would vary with the availability of technical skills, complexity of the task, availability of products and costs involved.

Many banks, particularly large banks, have preferred to develop systems in-house to suit their business requirements (as can be seen in many banks in Japan, Korea and China). This is primarily due to the complexity of their operations and their desire for fl exibility in developing a system to meet the unique requirements. However this requires extensive capital investment and channels substantial resources away from the banks’ core business.

The debate on ‘Build’ versus ‘Buy’ continues among a few top-tier banks that have the ability to build their own systems. But increasingly, banks are awakening to their shortcomings as an IT developer and becoming more inclined to focus on their core business instead.

Banks select a replacement approach based on their individual requirements. For example, HSBC has chosen a middle path by taking Temenos as its partner in co-developing an international core banking system. The bank and the IT company would thus pool their resources and technologies to develop the best solution.

•

•

•

•

Bank’s approach to core banking replacement depends on the availability of fi nancial and human resources

Buy vs. Build



The substantial cost, resources and expertise involved in building a new system has forced many banks (particularly medium- and smaller-sized banks) to turn to purchasing packaged systems from vendors and thereafter customising to suit their requirements (either by themselves or asking a system integrator to customise). For example, State Bank of India hired TCS as its system integrator; TCS purchased the system from FNS and customised it to meet the bank’s needs, and then the bank itself implemented the fi nal system.

We have discovered that many medium-sized banks want a vendor that provides (or purchases) the system software and implements it. Cost issues aside, this approach is more feasible for banks that lack IT resources or prefer to have the technical expertise of the vendor due to the complexity of the task. It has been used by various banks in the region such as Union Bank of Philippines, Industrial Bank of Korea, Central Bank of India and Ta-Chong Bank. However the customisation should be more on the front end while the main package should provide the requisite core processing power.

Some banks may prefer a third alternative: complete outsourcing to an application service provider (ASP). This frees up resources for banks as they need not own the hardware or the software for their core banking activities. Management of the data centre and branches may be outsourced to a vendor that is adequately equipped and has a proven track record in providing these services. In return, the banks could pay the ASP on a per-transaction or per-branch basis.

While a few second-tier banks in Australia and Japan have turned to outsourcing, this approach is gaining more attention in other Asian countries only now. In line with this trend, HP recently signed a ten-year outsourcing contract with Bank of Baroda, wherein it will implement and manage an enterprise-wide SOA including a core banking solution (provided by Infosys) across the bank’s domestic and international operations. Several small cooperative banks in India that do not have adequate resources but fi nd it essential to enhance system quality (to face the competition in the market) are also understood to be taking this approach.

Essentially in outsourcing, the costs are lower compared to in-house development and, more importantly, the complex technological projects are left to experts who offer economies of scale. This frees up the bank’s capital and other resources and takes security concerns away from the bank. However some reasons often cited against outsourcing are: security risk, diffi culty in maintaining competitive advantage as the ASP’s services are the same for other banks, and country risk involved when outsourcing overseas.

•

•

•

•

•

Increasing shift towards packaged solutions among smaller- and medium-sized banks

Outsourcing an option considered due to low cost and vendor expertise



4Phases of Core Banking Replacement and Critical Considerations

Replacing a core banking system is a complex and high-risk proposition. This section analyses in detail the key requirements, critical considerations and challenges in each stage of the core banking system replacement project. Going further, we discuss the factors that we believe are essential ingredients for success. This section is targeted at both business decision-makers as well as IT people involved in the transition process.

Phases of Core Banking Replacement and Critical Considerations

4.1 Phases of core banking replacement – an overview4.2 Timeline of replacement project stages4.3 Phase 1 – business justifi cation and blueprint

4.3.1 Developing business objectives4.3.2 Delta methodology – assessing future requirements

4.4 Phase 2 – selection 4.4.1 Reasons for replacement 4.4.2 Considerations in determining selection criteria 4.4.3 Key considerations in vendor selection4.4.4 The right architecture and platform4.4.5 Selection process

4.5 Phase 3 – implementation 4.5.1 Key challenges and critical success factors4.5.2 Implementation process

4.6 Phase 4 – deployment4.6.1 Deployment process4.6.2 Deployment approaches

4.7 Risk mitigation4.8 Financial implications

4.1 Phases of Core Banking Replacement – An Overview

In our analysis of best practices for core banking replacement, we have identifi ed four key phases required for a successful core banking replacement project, namely:

Core Banking Replacement Project Phases

Understand Business Imperatives

Achieve Consensus on Business Driver & Approach for Core Banking Replacement

Define Core Banking Transformation Strategy eg. Replacement or Transformation

Develop “Delta” Transformation Blueprint- Business Scope & Objective- Reference Technical & Business..Architecture- Platform Preference- Process Transformation Scope- Organisation Alignment- Visualisation of “New World”- Business Case / Financial Impact ..Analysis- Risk-Return Analysis

Develop “Long List” for Vendor & Integrator

Request for Information

Finalise Platform Choice, Refine Requirements and Develop “Short List”

Agree on Selection Process- Delta or Traditional GAP- Scoring or Judgement

Prepare Request for Proposal

Update / Refine Business Case

Bidding & Contracting Process

Award Contract

Delta Definition

Delta Resolution

Design

Build & Test

Pilot

Training & Change Programme

External & Internal Communication

Logistics

Rollout Schedule

Big Bang or Phased Deployment

Project Phases

BusinessJustification &

BlueprintSelection

“Delta Driven” Implementation Deployment

4 - 6 Months 4 - 6 Months 18 - 24 Months Dependent on ChosenDeployment Approach

Source: Immacon SOBIT Methodology

The Business Justifi cation and Blueprint Phase sets the stage for the core banking replacement project. During this phase, a bank takes stock of its current environment, revisits its business strategy and establishes business drivers for its future technology and process infrastructure.

The Selection Phase is when a bank shortlists suitable vendors and integrators and decides on the vendor management approach. As a project of this magnitude cannot, in most cases, be done by one vendor/integrator, it is important at this stage to decide on which of those hired will be the prime vendor.

“Delta Driven” Implementation is recommended over the traditional “Gap” driven approach. The disadvantage of the “Gap” driven approach is that the specifi cations for the new system, more often than not, resemble a detailed description of the existing “Old World” legacy system. In

•

•

•

•

We divide core banking replacement into four phases


The Phases Of Core Banking Replacement


contrast, the delta driven approach focuses on requirements beyond the existing legacy systems. This approach looks at the future operation, the “New World”, and how a bank can optimise the selected core banking solution. The objective is to develop a “legacy free” environment as soon as possible.

The Deployment Phase is the fi nal stage of any core banking project. In this phase, the enterprise-wide deployment of the new core banking system is conducted. To be successful, it is important that both bank and vendor have agreed at the outset on one deployment approach. The most debated options are the big bang and the phased deployment. In addition, there are a number of variations to these two popular options.

•


4.2 Timeline of Replacement Project Stages

Core Banking Replacement Project PhasesProject Phases


BlueprintSelection

“Delta Driven” Implementation Deployment

4 - 6 Months 4 - 6 Months 18 - 24 Months Dependent on ChosenDeployment Approach


As time management guru Alan Lakein has taught us, “failing to plan is planning to fail”. Thus the fi rst phase of the core banking replacement project provides an overall plan for the initiative. It is important for business decision-markers to agree on the business objectives and justifi cation for the replacement, followed by detailed planning of what should be achieved with the new core banking solution. At this stage, we believe that it is also important to decide if the core banking replacement project should be approached as a transformation or as a replacement project. Wavering in the objective of the project would be a costly mistake.

Our research shows that a typical core banking project takes 18 to 24 months from the time the bank acquires a solution to the commencement of deployment. Smaller banks using a proven solution with little or no customisation can of course expedite their schedule. The chart below shows an illustrative implementation schedule of a typical core banking project.

Illustrative Core Banking Implementation Project Schedule

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

Phase 1: Business Justification & Blueprint

Assess Current Operations

Understand Business Imperatives

Blueprint & Visualise Future Operations

Prepare Implementation Roadmap

Develop Business Justification

Phase 2: Selection

Issue RFP & Receive Responses

Issue RFI / Refine Vision

Select Systems & Service Provider

Conduct Negotiation & Contracting

Phase 3: "Delta" Driven Implementation

Detailed Design

Delta Analysis

Build & Test

Pilot

Phase 4: Deployment

Training

Logistics

Change Management & Communication

Go Live

Fine Tune

Phase4 to 6 months

6 to 9 months

18 to 24 months

The 'future state' defined in the blueprint and visualisation is input to the RFP requirements and the solution design and underpins the change management and business transformation efforts.

The selection timeframe is dependent on the number of vendors involved and the level of detail required by the RFI and RFP documents.


•

•

A typical core banking replacement project takes 18-24 months though the duration varies with the extent of change and size of bank



4.3 Phase 1 – Business Justifi cation and Blueprint

4.3.1 Developing business objectivesObjective: Develop business objectives and establish the vision and justifi cation for the target future state.

Core Banking Replacement Justifi cation & Blueprint Development

Sign Off

UnderstandBusiness

Imperatives

AssessCurrent

Operations

Blueprint &Visualise the

FutureOperations

PrepareImplementation

Blueprint

DevelopBusiness

Justification


BlueprintSelection “Delta Driven”

ImplementationDeployment

Project Stages


Key Requirements From Core Banking System Replacement

• Integration - Seamless integration of system and operations for time saving and cost effectiveness

• Single Customer View - Ability to have easy access to a single and precise view of customer relationship

• Product Factory - Customer-centric system that facilitates develop-ment and deployment of new products and services with ease and real-time information

• Straight Through Processing - Improved, faster and comprehensive banking functionality

• Multi Channel Sales & Service - Ability to implement cross channel sales effectively and efficiently

• Data Warehouse - Large volume of data made easily accessible to facilitate quick decision making

• Flexibility - Ability to adapt to constantly changing requirements of business in future


Developing business objectives of core banking system replacement



While banks are awakening to the need of advanced and more fl exible systems to meet the requirements of banking industry today, we believe that each bank needs to initiate the process by developing clear business goals and objectives of core banking replacement to meet its own unique requirements. These objectives would facilitate involvement of business into the project (which would otherwise have the risk of being seen as an IT project) and also would give clear directions to the selection process.

Assessing business demand, future business directions and anticipating future requirements would ensure that the bank can suitably select the system that can meet its expectations. The ability of ageing IT systems has become limiting factor for ambitions of future growth. In many banks numerous back processes are as a consequence of maturity of a 10-15 year old system. New systems are now required to provide considerable synergies and effi ciencies towards meeting long term targets.

While the broad requirements from the system functionality would be similar for most banks, unique requirements would vary. Improving competitiveness and garnering market share is one common objective cited for replacement. In some banks it may actually be a case of ‘survival’ rather than choice that forces the management towards replacement.

A global bank is likely to require more scalable system with multi-channel, multilingual capability across geographic locations. Similarly Banks in India and Pakistan may believe that product differentiation and service oriented features are more important to meet the needs of growing middle class and maintaining competitiveness. For example in growing economies banks would rather grab a larger chunk of market share than just riding on growth. These unique needs should guide the bank in developing its long term strategic objectives.

These Business objectives should in turn act as key guiding factor in establishing selection criteria. These should be forward looking to ensure suitability of the new system in long term as a bank replaces its system once in 10-15 years. Nonetheless in today’s fast paced environment it is extremely diffi cult for one to judge what the face of market would be after few years and hence the bank has to ensure fl exibility in the system.

4.3.2 Delta methodology – assessing future requirementsOur research into replacement case studies shows that it is imperative for banks to take stock of their current operations in the “old world” environment, and comprehend the technology infrastructure and shortcomings. Thereafter, the banks should understand their current business imperatives and anticipate future needs. These should be the key drivers for the core banking replacement strategy. Yet, we have

•

•

•

•

•

•

Banks need to initiate the process by developing clear business goals

Requirements for core banking system varies between banks

Business objectives should be the guiding factor throughout the replacement project

Delta methodology requires banks to anticipate future needs and plan accordingly



discovered that often banks fail to do so, which results in an expectation/deliverable mismatch at a later stage. This can also lead to unexpected delays in implementation and incremental changes in the project.

For this reason, we believe that banks should form a clear understanding of the target “new world” and use this to develop a Transformation Blueprint supported by an Implementation Roadmap. One methodology that the banks can use is delta analysis. Herein the blueprint and implementation roadmap should defi ne the new world and how to get there, e.g. business and technical architecture, technology platform, process transformation and organisation alignment. The Delta Transformation Blueprint should be complemented by a business case and/or a business justifi cation, a fi nancial impact analysis and a visualisation of the new world.

The biggest challenge a bank is likely to face in the Delta approach is the scarcity of experienced resources. This approach requires seasoned banking practitioners with the ability to deal with a clean-slate approach, a good business appreciation of technology and the ability to switch comfortably between the big picture and the nitty-gritty operational details.

Delta analysis is forward looking and it is driven by three key concepts:

Delta Methodology

Key Concept 1:New World / Old World

“Leaving the legacy behind”

Key Concept 2:Delta Analysis

Moving towards a “legacy free” new world

Key Concept 3:Go / No Go Milestones

“Put a stake in the ground” before proceeding


•

•

•



These key concepts, we believe, need to be addressed in each phase of the project: the new world / old world transformation blueprint is developed during phase 1 (Core Banking Business Justifi cation); the delta analysis is addressed during the selection and implementation phases; the go / no go milestones are applied throughout each phase of the project.

We believe it is crucial that the project stops after the completion of each milestone until the milestone is signed off. This may sound draconian but the temptation to start the next phase while sign-offs are debated must be avoided at all costs for a project of this magnitude. Ultimately, this approach can save the bank a lot of time and money. It will also ensure that milestones are taken very seriously.

Because each milestone forms the basis upon which the following phase will be built, this approach ensures that the next layer is not built on an incomplete foundation. This can result in fewer changes and reworking in subsequent phases and a more adaptable system as it is easier to make changes to a solution built up consistently. The remainder of this chapter will explore the best practices in this methodology in more detail.

New World / Old World

Old World

New WorldBank Transformation Stage 1

stcudorPycageLgnikaM

ssoL

edoCycageL

Old World

noitamotuAssecorPycageL

Do Not Cross

Key Concept 1:New World / Old World

“Leaving the Legacy Behind”


•

•

•



Delta Analysis

Old World

Old Core Banking Systems

AS 400

UNIX

Mainframe

New World

New Core Banking Systems

NewCore Banking

System

The Delta not “A Gap” will drive the development of the Delta Definition Documents

SOBIT Core Banking Implementation Methodology

ReportingLocal Practices

Policies & ProceduresProducts

Processes

Stakeholder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DeltaAnalysis

Key Concept 2:Delta Analysis

Moving Towards A “Legacy Free” New World


Go / No Go Milestones

DesignGo / No Go

DesignSign-Off

PilotGo / No Go

DeploymentGo / No Go

Milestone:Next phase will be kicked off once previous phase’s sign-off is completed

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

Phase 1 Phase 2 Phase 3 Phase 4 Phase 5

Phase 1: Business Justification & Blueprint

Design Integration

Conduct Delta Analysis

Phase 0: Setup and Initiation

Programme Initiation

System Selection

Phase 2: Selection

Business Realignment

Build

Integration

Test

Phase 3: "Delta" Driven ImplementationPilot

Phase 4: Deployment

Training

Logistics

Phase

Project will stop until milestone is signed off

Go / No Go DecisionMilestones

Project Flow

Project will continue to the next phase

Stop

Go

Key Concept 3:Go / No Go Milestones

“Put A Stake in the Ground”Before Proceeding


• In summary, successful core banking replacement projects we have seen are driven by clear business objectives, a strong business justifi cation,



a blueprint for the future and a roadmap on how to reach the target – all developed in the fi rst phase of the project. This is followed by an initial delta analysis in the selection and implementation phases of the project and the conscious sign-off of project-embedded milestones in each phase. If one of these milestones is not signed off, the project stops. This disciplined approach can save the bank a lot of money and agony.

• Key activities to consider for the business justifi cation stage of the project are:

Defi ne the business objectives and desired outcome of the project

Assess the current operations and existing IT infrastructure against the business objectives

Develop and visualise the blueprint of the future state of operations and the enabling technology

Defi ne the implementation approach and timeline to achieve the future state

Formalise the business justifi cation for the future state

-

-

-

-

-

Delta methodology would facilitate business justifi cation



4.4 Phase 2 – SelectionCritical Considerations in the Selection Process

Consider long-term strategic goals of the bank

Develop a rating system detailed to provideobjective & subjective assessment

Invite bids from vendors that have strong experience in similar projects, reputation and track record

Eliminate the products and vendors that do not meet the essentialcriteria

Final selection shouldcomprisedetailedanalysis of vendor and its partners in the project

Financialassessment is important but decision should be based on product and vendorcapability

Project Stages

Identify key deliverables to meet long-term

needs

Developselection

matrix. Identify ‘Go’ / ‘No Go’

criteria

DevelopRequest for

Proposal and invite bids

Initial filter to eliminate

unsuitablevendors

Invitepresentation

fromshort-listed

vendors

Financialassessment

and final selection


4.4.1 Reasons for replacementKey Demands from New Systems

Problems with legacy system Demands for new system

Flexible, scalable

Component-based architecture

Competitive edge

Customer-centric with singleview of customer

Easy information access

Higher efficiency

STP ability

Product differentiation easy

Lower operational andmaintenance cost

Lower TCO

Outdated architecture

Lack of flexibility

Lack of scalability

Long product rollout time

Slow response time

Product innovation difficult

High operating cost

High maintenance cost

Scarce trained manpower

Product-centric

Disparate systems lackinginformation accessibility



Identifying the critical current and future needs to be met by new system


The bank needs to consider its objectives and conduct a delta analysis to guide its development of selection criteria for the new system.

Widespread dissatisfaction with ageing, expensive and infl exible technology is one of the prime reasons for change. In countries like India where private sector banks boast technically advanced systems, it has become imperative for public sector banks to replace their systems as well to lower the attrition rate and survive in this competitive environment.

Many banks have decades-old legacy systems that either fail to support the latest products or do so with complex and time-consuming effort. The operational and maintenance costs are steep and available manpower for maintaining them is dwindling. According to one vendor, ”Just keeping these systems running can often consume more than 70% of the IT budget, leaving little money to gain advantage over competitors.”

While these systems have been stable, they are highly infl exible and hence largely unsuitable in today’s competitive environment. Many of these systems were implemented at a time when banks did not engage in fee-based transactions. Rather than being customer centric, they are largely account centric.

Branches need excess staff to maintain systems and back-offi ce functions, thus adding to cost. The time required to bring a product to the market, the speed of transactions and end-of-day processing requirements have also forced banks to look for alternatives to legacy systems.

Information in many of the legacy systems is stored in independent silos. This makes gaining insight into customer needs and integrating customer information across functions extremely diffi cult, as these involve the collation of a large amount of data from disparate systems held in different formats. For example, in legacy systems, a credit card division may not know about the customer’s savings account. The banks that still have no centralised customer-centric system are realising it is essential to acquire one as this would provide them with a single customer view and easily accessible and deployable real-time information, thereby improving the banks’ effi ciency across functions.

The aim is now to eliminate duplicate systems, integrate legacy and sub- systems with middleware, install and integrate databases and add applications. The banks need to adopt scalable and fl exible systems which can meet multi-channel delivery requirements, can integrate information and processes across the organisation, are easy to upgrade and can adapt to changes. This is essential to meet consumer demands and maintain competitiveness in the sector. Absence of an adequate system could even hamper the viability of an organisation.

•

•

•

•

•

•

•



4.4.2 Considerations in determining selection criteriaFocus of Banks with Regard to Selection Criteria

54321

Business Direction/Goals

Scale and Complexity ofOperations

Product Features

Cost/Financial Impact Business Culture Process

Human Resources

Existing System/ Technical Capacities

Ideal Bank

Average Bank

Legend


Scale of 0 to 5 measures level of importance (0 = Not important at all, 5 = Very important)

Selection of the system is a strategic decision which can impact not just the growth and fi nancials of the organisation but even its viability and competitiveness. Therefore it is essential that banks select the system that provides the right components and architecture to meet their objectives.

The architectural components that can meet the functional requirements of the bank, given its business goals, must fi rst be mapped out. This would also determine whether the bank should replace the core banking system in a few functional segments (or geographic locations) or go for a complete replacement, and whether it needs to replace just the core banking system or the front end and GL as well.

We believe existing system and technical capabilities would be a decisive factor in evaluating whether to upgrade the existing system or replace. Gap analysis for features such as scalability, fl exibility, availability of human resource, costs and processes of the existing system would determine the technical capabilities and type of architecture required of a new system. Integration of the new and existing systems within the bank and the problems therein would also determine the system architecture required and the risks involved in the change process.

The complexity and scale of the bank’s operations would shape its scalability and fl exibility requirements for the architecture and platform. For example, a large retail bank may prefer mainframes due to reliability

•

•

•

•

Critical factors that determine the selection criteria

The bank needs to develop selection criteria based on its unique requirements and business objectives



and scalability. Multi-channel delivery, high transaction volume and user compatibility with lower downtime would be critical considerations. A small bank, on the other hand, may prefer a UNIX solution because of availability, fl exibility and agility.

Finally, the right technology should come at the right price. Cost and fi nancial impact are critical inputs in system selection. Most systems require heavy investments but these ideally should translate into costs savings and revenue growth in the long term. For a smaller bank with limited resources, cost may be a more decisive factor than in a bigger bank.

4.4.3 Key considerations in vendor selection Focus of Banks in Assessing Core Banking System Vendors

54321

Track Record

Product Functionality

Cost / Financial Impact

ReliabilityCommitment to Business

Financial Viability

Ongoing Support

Ideal Bank

Average Bank

Legend


Scale of 0 to 5 measures level of importance (0 = Not important at all, 5 = Very important)

Banks cannot bring about transformation in their systems alone. Most banks see a core banking project as a highly risky proposition, so they would invariably like to partner a vendor whom they can trust and believe to have the ability to handle a project of that size and nature. The vendors are generally solution providers and, in most cases, service providers who implement the solution within the banks. The two often join hands with a hardware supplier to form a consortium to bid for the project. Where there are multiple vendors, banks need to decide who would be the prime vendor.

The evaluation of vendors involves multiple assessment criteria, foremost being delivery track record, fi nancial viability, technical capability, product features and cost.

•

•

•

Critical considerations in assessing IT service providers

Evaluating vendor track record and fi nancial viability is a must, but equally important is for the bank to assess its comfort level with the vendor’s ability



Banks need partners that have the proven track record to provide them with the right product and service mix. There are relatively few vendors that have successfully completed core banking projects of the size and complexity of tier 1 banks. But for tier 2 and tier 3 markets, there is more competition. The IT partners’ track record and reputation should be evaluated in the context of the banks’ unique requirements. For example, banks in China look for customisation and localisation capability. Similarly, Indian banks have shown a preference for local vendors.

In addition, the IT partner’s fi nancial strength (to ensure long-term viability), ability to continually upgrade products and track record in post-implementation services are critical factors for lasting success. Investing a huge amount of resources on a product is useless if the vendor who provided it is no longer around to service it a few years later.

The alliances and relationships between the IT partners are other factors that need to be considered. For example, State Bank of India and Central Bank of India who both hired TCS as their system integrator were provided with a system from FNS, now owned by TCS, and hardware from another vendor. The standing relationship between these two companies was a defi nite plus in their favour.

4.4.4 The right architecture and platformCritical Requirements from System Architecture

Flexible,Scalable,Stable

Modular, Integration

Customer-centric,Single View of Customer

StraightThrough Processing

ServiceOrientedArchitecture

Critical Requirements From System Architecture

• Ability to meet the long-term growth and ambitions of the bank

• Component-based structure that can be modified and developed with ease

• Integrated customer information to facilitate better customer relationship across functions

• System functionality to support global deployment


Banks have to select the right architecture for the banking system in general and the core banking system specifi cally to suit their unique

•

•

•

•

Vital to assess vendor’s fi nancial strength for long-term viability and technical enhancement

Understanding the need for the right architecture



requirements. Most banks today are shifting their systems to attain more fl exibility and scalability, similar to moving out of the confi nes of a small box. What they need to ensure is that the new system is not like a bigger box which quickly becomes a constraint again in a few years’ time.

Flexibility – With a convergence of fi nancial services and a highly competitive environment, banks need to display a high degree of fl exibility, agility and effi ciency in its processes and product and service development. Whatever the platform and solution that a bank selects, it has to be fl exible to meet the constantly changing banking requirements.

Scalability – Scalability is a particularly important factor for retail commercial banking. A bank can expect healthy growth rates in this segment of the market and must plan for an increase in transaction volume. Another factor to consider is the bank’s strategy in terms of product offerings and delivery channels.

Functional requirements – It is essential to have a comprehensive MIS (management information system) to cover all products, all customer groupings and all geographical locations. In addition are customised requirements such as multi-channel, multi-time-zone and multilingual processing ability to meet the specifi c needs of a bank. However the bank has to determine which of these needs require changes in the front end and which demand core banking replacement.

Modularity – We believe that the system architecture has to be modular. This means that one part of the system can be changed without affecting other parts, thereby enabling banks to easily change and enter into particular segments of operations. For long-term effi ciency, banks need to transcend relationships and dependencies across systems and business units through integrated technology.

Straight Through Processing (STP) – One key feature which has led to the success of core banking systems today is front- to back-offi ce straight through processing. While this is essentially the ability to have a series of underlying business events generate multiple accounting events without having to physically transfer the data from point to point, this translates into a substantial decline in cost of ownership and control because of the need for less reconciliation. Further, it allows banks to reduce manual intervention and redeploy their existing resources.

The architecture of the banking system should integrate the core banking system such that there is customer centricity with a single view of customers across functions. In a customer-centric environment, the

•

•

•

•

•

•

The functionality and architecture of the system along with its suitability to meet business goals would be the key concerns

Imperative for banks to have modular architecture with STP and single view of customer

Integration of core banking system within the banking system architecture equally important



consumer is paramount and drives all business decisions from technology to organisation structure.

Business Process Modelling (BPM) is mainly a mechanism for the orchestration of processes, with its ability to precisely model and possibly change the context in which enterprise components are used. Convergence of SOA and BPM is vital to the implementation of SOA-based core banking solutions.

Service Oriented Architecture (SOA) is a relatively recent addition to the architecture of banking systems. SOA in its purest sense is centred on loosely coupled components which support generic services and are based on web technology. In a core banking context, it means reducing barriers in antiquated infrastructure and creating real-time integration of disparate systems and sharing of databases within a fl exible and easily upgradeable infrastructure.

Those components should be fl exible so they can be reused or combined to create new business functions both within and across enterprises. They should embody best practices and should enhance the bank’s ability to outsource and extend processes to business partners. The generic nature of the components means they are intended to traverse silos and departments, thereby facilitating the breakdown of barriers which only exist for historical, technical and antiquated organisational reasons. We discuss SOA in more detail in section 5.

Selecting the Architecture

Most mainframe-based core banking solutions are designed for raw horse power. The idea here is to support high transaction volumes. Core banking solutions built on other platforms are typically focused on functions and features and do not offer the same level of stability, availability and end-user response time. While these types of solutions usually cater to small- and medium-sized banks, they have recently been touted to larger banks with some success.

Other mid-range solutions were initially built for the wholesale market and then repackaged as “Integrated Universal Banking Solutions” for the broader banking market. Some of those integrated solutions are impressive in terms of functions and features, extending beyond deposits and loans to include treasury and trade fi nance products and providing a common customer information system across the package. However, these solutions need to be carefully assessed with regard to their support for the bank’s branch network, which differentiates a universal bank from the traditional wholesale banking operations for which these systems were initially designed.

•

•

•

•

•

SOA critical for future fl exibility



Selecting the Platform

An important consideration for the replacement of a core banking system is the platform upon which the solution will operate. Typically, banks choose between mainframe and UNIX platforms for their core banking environment. This decision should be made after the conclusion of the RFI (Request for Information) process at the latest, so that the RFP (Request for Proposal) is issued only to vendors with solutions for the selected platform.

The platform decision is critical as it can automatically exclude certain platform-specifi c core banking systems. To the business user, this may seem counterintuitive; after all, it is the core banking system we want to select. However, as explained earlier, the functions and features of the core banking system are not the sole determinants of the appropriate solution. First, the solution must be able to handle the bank’s requirements for volume, availability, reliability, scalability, security, response time and other non-functional qualities. For these, the choice of platform is paramount.

There are many aspects which should be considered in platform selection for mission critical systems:

Virtualisation of the resources of computer operations – Resources in the platform of choice should be virtualised and centralised, enabling better management of the operations. A key consideration should be the level of distribution of these resources across various systems. Distribution of resources over a large number of servers can lead to an unacceptably high level of complexity, especially in an “open system” environment, due to the ever increasing number of servers required to maintain the scalability of such systems.

High availability – Using parallel sysplex or geographically dispersed parallel sysplex, the mainframe is able to achieve availability of up to 99.999%. Alternative platforms should be measured against this benchmark. This will facilitate clear decision-making and buy-in of all stakeholders when faced with lower availability guarantees.

Security – Security has always been a concern for banking systems. The mainframe platform enables the bank to manage security from a single point instead of multiple systems and thus helps reduce the security risk exposure. However, as the security infrastructure for non-mainframe environments is constantly advancing, banks should consider the available security components as part of the overall cost of either platform option.

•

•

•

-

-

-



Platform cost – Typically, platform cost is calculated as either total cost of ownership or total cost per user. However, measuring total cost is not straightforward and often results in an underestimation of UNIX costs due to lower overall availability and the greater number of unplanned outages. We have, for example, found that the average expected revenue loss per hour of system downtime could amount to well over $1 million. Considering that unplanned outages can occur as often as once or twice a month, the costs can climb quickly.

In summary, we believe that the total cost should not be the driving factor in platform selection for a retail bank. For a mission critical system, considerations such as availability, scalability, reliability and security are of far higher priority. Cost should only be a barrier for banks that cannot afford the most suitable platform and are willing to compromise on the service level of a mission critical system.

On the other hand, for small wholesale banks and banks that do not have large transaction volumes, the UNIX platform could prove to be effective. Given the technical advancement in UNIX systems in recent years and the increased availability of UNIX hardware, software and technical skills, UNIX is rapidly becoming a preferred choice for smaller banks and new banks. As these banks have only a handful of branches, limited multi-channel requirements, lower security requirements and tolerance for unplanned system downtimes once or twice a month, the price-performance equation here makes the non-mainframe solutions a viable option.

However, for those banks that intend to shift from mainframe to UNIX, or vice versa, the switching cost and the cost of coexistence of two systems need to be added to the total replacement cost.

4.4.5 The selection processObjective: Select and acquire the enabling technology and service provider.

-

•

•

•

Cost should not be driving factor; identify what is most suitable based on needs

For smaller banks, UNIX could prove to be effective but banks need to consider switching cost



Core Banking Selection Process

Sign Off

Issue RFI / Refine Vision Issue RFP

Select System & Service Provider

ConductNegotiation & Contracting




Project Stages

Source: Immacon SOBIT Methdology

Selection of the right core banking solution is critical for the success of a project. We have seen retail banks selecting a wholesale core banking solution and wholesale banks selecting a core banking solution meant for retail banks. We are also seeing more and more bankers attempting to make technology decisions, deliberating about Java versus Cobol, UNIX versus mainframe, SOA, etc. Needless to say, the outcome of such decisions is often sub-optimal.

It is important that bankers focus on business solutions and not on a technology solution. However we believe that business should have the fi nal say on the solution, and the choice should be based on business needs and not technology considerations. It is also important during the selection process that IT fi rst picks out proven core banking systems and then considers their underlying technology platform, programming language and tools, not in the reverse order. We believe that a failure to do all this can lead to very costly errors.

Issue RFI / refi ne vision – If time allows, the selection process should start with a Request for Information (RFI). The RFI should be kept simple, concise and open-ended. As the name implies, the objective of the RFI is to obtain information for deciding on the fi nal shortlist to kick off the Request for Proposal (RFP) process. If the RFI contains too much detail, it can render the RFP process obsolete and make the preliminary analysis in the RFI stage very laborious. As the bank has to analyse and weigh the RFI responses, it is important to keep the workload of the reviewer to a manageable level.

A brief, well-written RFI (and RFP) addressing the critical points the bank is interested in would be more worthwhile for the bank’s reviewers and management, than a long “laundry list” of functions and features which describes more or less the existing system of the bank and not

•

•

•

•



the future. The RFI process should focus on the essential requirements for the future, bearing in mind that quantity never replaces quality. At the end of the process, 2-3 fi nalists should have been shortlisted for an in-depth review during the RFP stage.

Issue RFP – An RFP is issued after a shortlist has been prepared. At this stage, the choice of platform should already have been made. The RFP should concentrate on the requirements for the new world, and should demand full compliance with the bank’s visualisation or at least a brief description of what requirements cannot be met by the core banking solution and for what reason. The RFP should not be sent to more than three vendors for a major component such as trade services, multi-channel delivery and core banking. By now, the bank should also have an understanding of how the selection would be conducted and know if it is necessary to obtain a proof of concept. Ultimately, the key drivers here are cost and timing. Where a bank can afford the money and time, a pilot of the new solution is recommended. To achieve an objective assessment, many banks are using a scoring method to document and tabulate the results. See Appendix 2 for more on RFP.

Select system and service provider – A sub-optimal selection will have dire results for all. One of the challenges the selection team faces is that they have to not only select the vendor but also justify why this vendor was chosen over others. Hence, it is important to have a solid and transparent selection process in place. In addition, it is crucial that the selection is conducted for “new world operation” and does not degenerate into a selection of “the emperor’s new clothes”, e.g. where legacy operations are deployed with new technology. Our analysis shows that successful organisations avoid taking legacy baggage into the new world.

Conduct negotiation and contracting – This stage is completed with an agreement on fi nal pricing and contractual arrangement with the vendor and service provider.

To summarise, the selection phase starts with gathering of information and shortlisting of solutions for the subsequent RFP process. This allows the bank to refi ne its assumptions about the future-state vision based on fi ndings during the RFI process, and sets the stage for developing a comprehensive RFP for the shortlisted vendors. Upon receipt, the RFP responses are evaluated as inputs for the selection of the fi nal vendor. This whole process is completed with the conclusion of negotiations on pricing and contractual arrangement.

•

•

•

•



4.5 Phase 3 – Implementation4.5.1 Key challenges and critical success factors

Key Challenges During Implementation

• Integrating with an ageing existing system with limited information on software code

• Data migration and seamless and smooth transition with zero error

• User training and coping with resistance to change in processes and work culture

• Localisation and customisation of solution to suit the unique requirements

• Matching expectations and deliverables

• Incremental changes leading to cost and schedule overrunsSource: Asian Banker Research

Critical Success Factors

• Strong management support and initiative within the bank

• Execute large projects in phases; develop pilot projects

• Adequate and thorough testing at every level

• Banks to have strong internal steering teams with good leadership, communication skills and technical knowledge

• Ready helpdesk for user enquiries and complaints

• Vendors should involve people with requisite expertise and knowledge of local business

• Select strong partners in implementing projectSource: Asian Banker Research

Core system replacement or even upgrading is a major challenge that can create disruption of service, customer dissatisfaction and employee disappointment. Transition from one system involves not just technical complexities but a plethora of unforeseen problems in areas such as matching of expectations and deliverables, adaptability of system within the organisation and change management.

•Seamless and smooth transition to new technology and processes with zero error is the key challenge



The foremost challenge is data migration and seamless transition to the new system. This includes the diffi cult task of data cleaning, as some data may be very old and irrelevant. Mass migration requires large capital investment and an implementation schedule stretching over several years. It also poses a signifi cant risk of service interruption that can cause a dip in customer satisfaction.

There can be various problems in the process. For example, the old system may have been account-based and not customer-based, requiring information to be collected from multiple systems and migrated to a centralised location. Some banks put in their system more than 15 years ago and the people who implemented it are no longer with the banks – such systems are undocumented and hence make the project more challenging.

For some projects, the coding of ageing systems may be unknown, making data migration and integration a rather diffi cult proposition. For example, when Korea Development Bank switched from an IBM system to an FNS system, it involved shifting to a totally new system architecture. In other cases, the bank may be shifting to a new platform which demands coexistence of two platforms for a certain period of time and a huge data conversion exercise.

Customisation of the system to meet the unique requirements of individual banks is another critical area where things could easily go wrong and lead to an expectation/deliverable mismatch. While rolling out a time-consuming project, there may be developments in the market or a realisation of the need for increased functionality which demand further customisation in the product. As the implementation period gets extended with these incremental changes, the project becomes more likely to have cost overruns. This is where the sign-off at each stage would be of immense help.

The project at some stages may just seem too big in scope and magnitude. But ensuring that any changes do not lead to unnecessary delays and cost overruns is essential. Motivation will decline while resistance will increase day by day. Managing these emotions and ensuring that the project is not viewed as just an IT project would be a big challenge.

The most critical success factor in implementation is thus to test at every stage. Banks should develop pilot projects, divide large projects into phases, and conduct user acceptance tests or, rather, business acceptance tests to ensure a match between deliverables and expectations. Also critical is having strong internal teams with good communication skills and decision-making capability. There should be

•

•

•

•

•

•Testing at all levels is the most critical means of risk reduction



a strong steering committee with a clear objective to guide the project to successful completion.

In addition, it is important to provide user training and manage resistance to the change in processes that accompanies such a project. There should be helpdesks ready to handle enquiries and complaints from users – which are likely to be plenty. Along with processes, the work culture would also have to be changed to ensure optimal returns from the project.

Banks need to develop a detailed schedule of implementation and ensure its strict adherence at all levels. For a large bank with hundreds of branches, the project will be a multi-year initiative. Take the example of State Bank of India which is implementing its system across 8,000 branches. Despite taking on 40-50 branches per day, the bank expects to fi nish the implementation only by April 2007, four years after its commencement in 2003.

In many such projects, trained manpower for new systems may not be readily available within the bank. It is for this reason that some banks have resorted to outsourcing their manpower. But the banks need to remember that a few experts with the right experience and knowledge may prove to be more useful than an army of staff.

Finally the bank’s business environment, adaptability to change and commitment to the project are vital for success not just during implementation but also during and after deployment. Vendors should ensure that management is involved in the project from conception till fi nal deployment. We cannot stress enough the importance of strong managerial support and business ownership for a replacement project which could go miles in motivating people in the organisation to achieve success.

4.5.2 Implementation processObjective: Operationalise and pilot the transformed future state, including technology, process and organisational change.

•

•

•

•



Core Banking Implementation Process

Sign Off

Delta Analysis DetailedDesign

Build & Test PilotImplementation




Project Stages


Transformation Approach and Methdology

Phase 1:Delta Definition

Programme Management & Project Control

Phase 2:Design

Phase 3:Build & Test

Phase 4:Pilot

Identify Organisational Change -Determine the changes needed to fit the organisation to the new System.

Identify Essential Modifications to the new System - Every effort should be made to avoid changes to the new System but rather to align the business to the new system. Changes to the new Core Banking System should be limited to those essential in order to meet regulatory requirements.

Identify Integration Delta -Determine the interfaces, conversion modules and coexistence development required to integrate the new System into the bank’s environment.

Business Realignment Design -Define the reengineered products and services and business processes aligned to the new System.

System Design - Prepare the design for system configuration. Also design the unavoidable modifications identified during the Delta Analysis.

Integration Design - Prepare the technical design for the Interfaces, Data Conversion Modules and Coexistence Modules.

Business Realignment - Align the bank’s products and services to the new System. Also align the bank’s processes and procedures to the new System.

Configure & Customise -Configure the system as needed, effect the necessary changes to the organisation, and make changes to the system, where absolutely necessary. In addition, the interfaces between the new System and the many linked systems are created.

Testing - Perform various levels and types of testing to the new system and processes etc. in preparation for correct functioning in the live environment.

Training Preparation - Prepare training plan, materials and course trainers.

Pilot Preparation - Identify and prepare the pilot site, train the pilot users and conduct rehearsals to prepare for the actual cutover.

Pilot Go/No Go - Confirm the completion of Pilot Preparation activities and readiness for cutover of the new System to the Pilot community.

Pilot & Fine-tune - Cutover the Pilot site and users to the new System. Identify and fix problems that did not arise in the testing environments.

Delta Analysis Report Design Specifications Applications Ready For Pilot Applications Ready For Deployment


The core banking implementation phase can be divided into four distinct stages. We came across an interesting concept of delta analysis.

Delta Analysis – A delta analysis is the identifi cation of differences (the “delta”) between the desired state and the selected package, and ways to resolve these differences. One objective of the delta analysis is to identify the package modifi cations required to address country-specifi c regulatory requirements. The package modifi cations are necessary if confi guration through package-embedded parameters is not possible. For the remaining delta, there are a number of resolution options available, such as:

•

•Implementation process involves delta analysis, detailed designs and product modifi cation to meet the bank’s requirements



a. No change / Out-of-the-box fi ts your needs

b. Rationalise process

c. Rationalise product

d. Customise and modify package

The chart below illustrates this approach in more detail:

Requirements Analysis Chart

Delta Analysis & Resolution

Core Package

RegulatoryCustomisation

Core Package


Core Package


Core Package


Core Package


Core Package

Start :Process / Appraisal

Identify Regulatory Requirements

Identify Delta Delta ResolutionOption I:

No change /Out of the box fits

Option II:Rationalise

Process / Product

Option III:Modify package

Customisation

Input on Package

Cost Impact No (should be includedin base price) No No

Yes (Time & Material Cost for Modification)

New Core Banking Solution Procured

Regulatory Modification

New Core Bank Capabilities

New World Operations

Delta

+

Delta Resolution

Accept Package

Change BankProduct / Processto Match Package

Modify Package

DeltaRegulatory

Modifications

© Immacon SOBIT Methodology


Some of the recommended activities to consider for this stage of the project are:

Conduct a delta analysis to identify the differences (the “delta”) between the required future state and the selected solution

Conduct a “solutioning” to determine the appropriate customisation or refi nements to suit the future state

Defi ne and estimate interface, data conversion and coexistence efforts

Typical deliverables of this task include: Delta Defi nition and Resolutions, Confi guration Defi nition, Interface Defi nition, Data Conversion Defi nition and Coexistence Defi nition

-

-

-



Detailed Design – A detailed design of the future solution is needed for the subsequent Build & Test stage of the project. A detailed design done right can save a bank a lot of time and money by avoiding unnecessary rework and change requests. Many projects run into diffi culties because the design is never stable. In those projects, coding starts even before the detailed design is approved. In our analysis, this is one of the major causes of project failure, i.e. the inability to complete and sign off detailed design documentation. The detailed design documentation should include the following, among other things: business design, systems design, interface design, data conversion design and coexistence design (assuming no big bang deployment).

For this stage of the project, the initial project blueprint needs to be expanded and some of the recommended activities to consider are:

Prepare a detailed business design, including rationalised product and process designs.

Prepare a detailed system design for customisation and confi guration of the selected solution.

Prepare a detailed integration design for the interfaces, data conversion and coexistence components.

Build & Test – The customisation and confi guration of the selected solution begins here. At this stage, it is important to freeze the design and to apply a rigorous change management process to any unavoidable changes. Hence, the sign-off of the detailed design documents of the previous stage is compulsory before this stage begins.

At this point, we would like to caution that the term “user acceptance test” should not be taken literally. The real end-user should not be responsible for “acceptance”. What the bank needs is a trained test team of, perhaps, former users who understand and appreciate the need for thorough testing and know how to conduct systems testing. Generally the real end-user does not have these skills. Hence, we prefer to use the term “business acceptance testing” or “business solution testing” over “user acceptance testing” to avoid confusion.

Some of the recommended activities to consider for this stage of the project are:

Customise and confi gure the selected solution

Prepare operational manuals, training materials and train-the-trainer programmes

•

-

-

-

•

-

-

A detailed design done right can save the bank substantial time



Customise and confi gure the interface, data conversion and coexistence integration components

Prepare and conduct system, operations and business solution testing

Pilot – A live pilot is the fi nal “acceptance” test. No matter how hard we try, we will never be able to fully recreate and test a system in a lab environment. But during a live pilot, the system can truly be tested for real-life usability. Of course, the pilot should be representative of the bank’s core operations. We have seen projects with well-executed testing run into trouble as the test and production environments were different, and even in cases where the production environment itself was used for bank-wide testing by the actual end-users reposting real business transactions prior to a big bang deployment. The lesson learnt: the fi nal test is the live environment.

Our recommendation is to use a manageable mid-size branch for the pilot. The pilot should always include a month end, as most banks have special month-end processing which can cause a lot of disruption in a real-life operation if not managed appropriately. The pilot should be used to assess the effectiveness and completeness of the end-user training and the new business processes and procedures, as well as the customers’ acceptance of the new products and new operation. It should also be used to identify bugs and bottlenecks and ultimately to fi ne-tune the applications before deployment on an enterprise-wide scale. This stage of the project will deliver a “future state new world operation” in a live environment. Recommended activities to consider for this stage of the project are:

Plan and prepare for the pilot deployment, including training of the pilot users and dress rehearsals of the pilot cutover and operations

Deploy, support and refi ne the pilot operation

-

-

•

-

-



Reference Implementation Methodology

A comprehensive implementation method may be the one that follows:

Comprehensive Implementation Chart

Configuration Definition

Interfaces

Data Conversion

Coexistence

Product Rationalisation

System Change

System Customisation

System Configuration

Conduct Gap

AnalysisResolution

Business ChangeDelta Analysis

Configuration Analysis

Integration

Process Rationalisation

PilotPlanning

Train Pilot Users & IT Ops

Pilot SitePreparation

Dress Rehearsal

ConvertPilot Data

Pilot End-user Support

Application Support & Fixes

Pilot

3 PilotGo/No Go

Update Procedure Manual

Prepare User Guides

Local Customisation

Core Customisation

SystemConfiguration

Interfaces

Data Conversion

Coexistence

Prepare Training Plan

Prepare Training Materials

Train-the-Trainers

System Integration

Testing

Operations Testing

BusinessSolution Testing

Business Build

System Build

Integration Build

Training Preparation

Testing

Product Designs

Process Designs

Local Customisation Designs

Core Customisation Designs

Configuration Designs

Interfaces Designs

Data Conversion Designs

Coexistence Designs

Business Design

System Design

Integration Design

2 Sign Off Design1 Sign Off Delta

Phase 1:Delta Definition

Phase 4: Pilot Implementation

Phase 3: Build & Test

Phase 2: Design




4.6 Phase 4 – Deployment4.6.1 Deployment process

Objective: Enterprise-wide rollout of the refi ned future state operation.

Core Banking Deployment

Sign Off




Project Stages

TrainingChangeMgmt &Comm

Go Live Fine TuneLogistics


After the successful completion of the pilot, the bank is ready to execute the roadmap for deployment of the pilot operation to the whole enterprise. To do this, a number of important planning tasks need to be updated and fi nalised:

Logistics – Managing logistics is critical for the rollout of a new core banking solution to the branch network. The logistics include rollout sequence (where, when, how many), possible changes to branch layout and bank image, and update and/or replacement of hardware and infrastructure software. It also includes the planning and execution of training logistics for the enterprise-wide deployment. The bank may need the hardware to rapidly build and dismantle mobile training branch environments for hands-on systems training.

Training – We have discovered that once the new core banking system is ready for rollout, training is one of the most important activities required to successfully deploy the new world on an enterprise-wide scale. To do this, the bank’s project team must fi ne-tune and update the training plans and materials taking into account the lessons learnt from the pilot deployment.

Change management & communication – We have found in our assessment of successful re-engineering and transformation projects that effective change management is essential to obtain buy-in and

•

•

•

•

Enterprise-wide rollout of the system poses critical challenges, demanding careful planning and caution at each stage



acceptance of the new operation throughout the enterprise.

Change management done right is a very involved programme touching every level of the organisation, from the CEO to the end-user in the branch. Successful change management for a project as complex, high risk and high profi le as a core banking enabled transformation can ultimately only be led by one person: the CEO. The chief executive is supported in this task by the entire senior management team of the bank. It is critical here that management not only walks the talk but also leads by example.

Communication of the change is divided into two parts: internal and external. Our analysis shows that the effectiveness of the communication can be signifi cantly enhanced through the use of multimedia technology. Usage of these tools ensures consistency in the message and rapid deployment to the enterprise and public alike. The bank will need different communication programmes depending on the audience they want to address.

Go live – We have seen that successful deployment is normally conducted through a carefully prepared rollout plan which clearly identifi es the timing and sequence of each task. The rollout is undertaken by specially trained rollout teams which, among other things, conduct a “train the trainer” programme in their respective rollout clusters. A best practice analysis has shown that it is more effective to train “key branch employees” as trainers for their respective units, than make “external” trainers responsible for the training deployment. This approach is an integral part of the change management programme and fosters ownership and accountability. The employees are likely to pay more attention to the tasks if they know that they will have to train their peers and be accountable for all of the predefi ned deployment activities.

The implementation teams are usually supported by a 24/7 central command centre, which coordinates and directs all implementation activities and has one or two rapid deployment teams available to be dispatched to support trouble spots. The drawback of this approach is that banks will be required to do a lot of methodical planning, conduct massive training of key and branch employees and be held accountable for the results.

Fine tune – The fi nal activity in the deployment stage is the fi ne-tuning of the operation based on feedback received during deployment. Successful organisations have gradually turned this fi ne-tuning activity into a continuous improvement programme managed and led by former members of the rollout team.

•

•



4.6.2 Deployment approachesComprehensive Implementation Chart

Complete End to End

Partial Replacement

Big Bang ApproachGradual Implementation

Integrated solution suitable more for small and medium banks

Easier to integrate solution from single supplier

Phasing of implementation process reduces risks

Suitable more for smaller banks

Risks and complexity higher

Implementation more challenging

Sudden change in processes and culture within organisation

Preferred approach by large banks due to complexity and scale

Lower risk, phased shift in processes

Challenging to have two systems coexist during implementation

Difficult to integrate multiple systems

This approach can be used for smaller as well as bigger banks

Partial replacement less complex as it is for specific functions / locations

Big bang approach can be challenging, particularly for big banks, but is quicker


The replacement approach is actually dealt with by the bank during the project planning stage, but we discuss it here as it has a direct bearing on the mode of deployment. The question foremost in the mind of bankers as they decide to replace their banking system is: should systems be upgraded piecemeal or through an integrated end-to-end solution? Banks vary in their choices. Some want to replace the core banking system of all geographic locations along with other operations such as treasury through a universal or end-to-end integrated solution. Others adopt the best-of-breed approach by selecting separate software systems and vendors for different operations or geographic locations. The selected replacement approach then determines the choice of vendor and systems and thereafter the deployment approach.

We strongly believe that for core banking systems, there should be only one vendor or else there would be immense integration issues. For the front end and back offi ce, there should also be a single vendor if possible, though the project may be divided into smaller parts. However when it comes to replacing banking systems across geographic locations or across operations (retail, wholesale, treasury, etc), we suggest the focused approach for bigger (tier 1) banks primarily because of the complexity of the process. The banks would be able to reduce the complexity and mitigate the risk by breaking down the process into smaller projects, provided integration issues can be resolved.

•

•

The replacement approach

We believe focused, rather than integrated, projects are more suitable for bigger banks



On the other hand, universal solutions may be more feasible for smaller banks mainly due to the lower scale of the project. End-to-end replacement has its pluses as integration would be less of an issue, it avoids successive disruption of services and it provides a standardised technical capability across functions.

While deciding on the replacement approach is easy, deployment is probably the most diffi cult and challenging part of a core banking project and can be accomplished through multiple approaches. The two extremes are “big bang approach” where the entire system goes live at the specifi ed time and “gradual/phased implementation” where the process is divided across various functions, locations or branches.

The choice of approach may vary depending on the complexity and scale of the project. “Big bang” is the quickest but also riskiest due to its low error-tolerance level. If the bank favours this option, then it has chosen to go live with its new core banking system and auxiliary solutions (if any, e.g. multi-channel delivery) at the same time. The advantage of this approach is that it is fast and does not require any coexistence planning.

The justifi cation for big bang comes from the fact that it is diffi cult for two separate systems to coexist and from it being a faster approach. The disadvantage is that it requires extensive training and plenty of full-scale dress rehearsals for the entire organisation. Should any serious problem occur, the bank has only one option: to fall back on the old core banking solution. If such a problem occurs more than a week into the cutover, the bank will have serious trouble as the fallback option most likely does not exist anymore.

For smaller banks, this approach is possible and even feasible. But for bigger banks, particularly for banks spread across countries, we believe that a total big bang approach is not only high risk but also rather diffi cult to implement. Examples of recent big bang deals include Union Bank of Philippines and Industrial Bank of Korea.

We believe the gradual approach, which is essentially step-by-step replacement, should be the preferred mode of implementation among large banks as the complexity and risks in the process are lower. A phased implementation also deploys the entire core banking solution in one big bang similar to the enterprise-wide big bang.

The key difference between a phased implementation and an enterprise-wide big bang is that the phased implementation is conducted in stages, in successive deployment clusters which are closely controlled and

•

•

•

•

•

•

•

The deployment approaches

“Big bang” is the quickest but also the riskiest

Gradual implementation should be the preferred mode among bigger banks



monitored. The advantage of this approach is that the entire solution is deployed at once and can be tested and fi ne-tuned in a tightly controlled environment. Should there be any problem, it can be confi ned to the cluster. We also recommend that the fi rst cluster is deployed as a pilot, to test not only the new core banking solution but also the conversion and coexistence strategy. The disadvantage of the phased approach is that it takes longer than the enterprise-wide big bang and it requires careful planning for coexistence and logistics.

We believe that the advantages of phased implementation far outweigh the disadvantages. If risk mitigation is important for the bank, then the phased approach is worth a serious look. Gradual implementation leads to a phased change in the processes and working environment of the organisation, making the change slower and less likely to meet resistance.

In conclusion, the big bang approach is the most risky option a bank can choose. Big Bang is only recommended for small banks, or for cases where the bank is implementing a solution which has already been customised for its country and implemented here many times. Solutions which have not been customised for a specifi c country or which are implemented as part of a core banking enabled transformation are, in our opinion, not a good choice for a big bang implementation.

•

•



4.7 Risk MitigationInherent Risks in Each Stage of the Project

• Assessing the technical and functional requirements of the bank

• Ensuring adequate financial, business and management support for the change

• Financial viability to provide long term relationship and technical support

• Experience in successfullyimplementing similar project

• Evaluation of technical capabilities of solution to meet the business goals

• Flexibility and adaptability to new developments

• Ensuring smooth, timely and cost effective implementation of new system

• Ensuring adaptation in the work culture and post-implementationsmooth operations

• Commitment of vendor to provide long term support

• Technical advancements and their compatibility with the new system

Project Stages

Evaluation risk & management

commitment

Selection of vendor, service

providersSolution risk Implementation

risk

Long term technical

support risk


Risks and potential losses in replacing a core banking system are very high, making it imperative that banks tread with caution at each step. We have identifi ed fi ve broad stages in the replacement process and inherent risk characteristics of each.

Lack of management commitment is one of the primary causes for project failure. We believe that a core banking replacement project needs business and management support in totality and the project should not be perceived as an IT project. Management commitment should not be limited to simply business and managerial involvement at all stages of the project but extend to strong leadership support that sees the project through.

The evaluation of business needs and objectives must be comprehensive, as inadequate assessment of technical and functional requirements will lead to improper selection and possibly expectation/deliverable mismatch at a later stage. It is critical for the bank to understand the type and depth of functionality provided by the core banking solution in the context of its own requirements and replacement objectives.

Availability of multiple solutions with varying technology and comparable functionalities has made this task more diffi cult. We believe that while an improper selection of solution could lead to short-term benefi ts, it may act as a constraint in the longer term.

In our opinion, the foremost issue in selecting a core banking system is the solution. If the solution is right, then a bank can always opt to bring in

•

•

•

•

•

Inherent risks in replacement project

Banks need to tread carefully as there are hurdles at each step of the change process

Project needs business support in totality

Evaluation at each stage has to be comprehensive

Improper selection of vendor and system can lead to project failure



a third-party service provider should things not go as planned. But that is the worst-case scenario. As a general guideline, a vendor is not just an IT supplier for the bank; instead it should be viewed as a partner that would provide not only the solution and integration services but also long-term relationship and technical support to the organisation. We believe that banks should not just evaluate the fi nancial viability and track record of these vendors, but also ensure adequate fi t with the project and that they are able to trust the service provider. This is especially true for the selection of the systems integrator, which can make or break a project by its decisions on the resources assigned to the project.

Transition from an old system to a new technology is a risky proposition in any organisation. It is more so in the case of banks due to the high risk of potential losses and errors in a scenario where they cannot allow a margin of error.

Risks are present at all corners, whether it is system customisation, data migration, consolidation of multiple systems, integration of multiple processes or user adaptation to new processes. Another risk is the possible lack of long-term support from vendors, which could translate into faster obsolescence of the system and inability to meet expectations amid the constantly changing dynamics of the banking sector.

Analysing various risk elements in the planning stage of the project would help ensure the adequacy of selection criteria and lower the likelihood of expectation/deliverable mismatch at a later stage.

•

•

•

Banks cannot afford any margin of error in the implementation



4.8 Financial ImplicationsInvestments and Costs Implications

Cost Analysis

Recurring Cost

One Time Cost

Planned Unplanned

Core Banking

Hardware

SystemIntegration

UnexpectedCost

Loss of BusinessCustomers

Core Banking software acquisition and maintenance cost

Hardware acquisition and maintenance cost

System integration and consulting cost

Planned CostsUnexpected delays

Incremental changes during implementa-tion

Scope of project becoming too big

Resistance to change

Unplanned Costs


Ownership of the core banking system is very costly and requires strong commitment and business justifi cation in most cases. It is for this reason that most banks take considerable time in coming to a decision to replace or even upgrade their system. The cost components of the total capital expenditure are software and service cost which constitutes 30%, system integration cost of 20-25% and hardware and infrastructure cost of 45-50%.

The software and service cost is highly dependent on the scale and complexity of the project. For example, it could be $100 million or more in large global banks but it has generally been much lower for smaller Asia Pacifi c banks. In Asia, the cost of software and services has been in the range of $5 million to $10 million for small banks and $20 million to $25 million for mid-sized banks, while for large banks it can go much higher. The investment is substantial and it is normally amortised over a period of 5-7 years.

•

•

Replacing core banking system has high risks and huge costs and thus requires strong business and fi nancial justifi cation



Recent big deals have shown signifi cant variation in the expenditure incurred for software and services. For example, it was reported to be $20 million-$25 million in the deal for HSBC, around $35 million for State Bank of India, $33 million for Central Bank of India and $4 million for Union Bank of Philippines.

For many vendors, the pricing may be different when they venture into new or more competitive markets. Involvement of a local partner generally helps to lower the costs of the project. Our research shows that many large banks prefer to hire consultants to guide this complex process and they often have a team of vendors and system integrators. All these add to the total cost of the project.

Maintenance cost is generally considered part of operating expenses. Some banks that undertake in-house implementation may need additional IT manpower, on top of what is required for the basic core banking system. But most banks take this into consideration and justify it when planning for core banking replacement.

However these may not be the only costs involved. In many cases, there are also hidden costs in the process. These unplanned costs may come from service disruptions, system downtimes or other system problems during the course of implementation or from unexpected delays in project implementation.

Cost overrun could also be caused by incremental changes, which often increase the scope of the project and are sometimes due to the allure of technical advancement. While such changes may be a necessity in some cases and improve the effi cacy of the project in others, the banks have to evaluate these against the corresponding cost and schedule overruns. It is common for the bank to realise that there is a mismatch between deliverables and expectations when it has reached the implementation and deployment stage. Usually resulting from improper project realisation, delta analysis or communication, this has been one of the primary causes for incremental changes in the project leading to unexpected overruns.

While the banks strive to keep these costs in check, there is another type of cost that gives critical business justifi cation for such a steep investment. For most banks, the replacement decision is taken only when the “opportunity cost” of not changing a system (such as loss of market share, reduced competitiveness and lower growth) becomes too high and, in many cases, when their survival is at stake. Some other banks fi nd it easier to justify the replacement citing regulatory requirements such as those under BASEL II. Nonetheless, the substantial cost savings (post replacement) – both tangible and intangible – coupled with revenue

•

•

•

•

•

•



growth in the long term are defi nite motivations. We discuss these further in the following section.

Financial Justifi cation of New System

Increasedefficiency, competitivenessand time saving

Improvedmargins and return on investment

Shorter break even period, lower manpower cost and higher ROI.

Improvedcompetitivenessand growth. Customerrelationshipimproved

Improvedmarketpresence,capture of new market,increased fee, revenue

Improvedrevenuegeneration, business growth

Direct benefits

Indirect benefits

Legend

Project Stages

Integrated,flexible system

Loweropportunity

costs

Loweroperational,maintenance

cost

Customercentric, STP

Innovativeproducts,bundling

Newinitiatives,services

Expected deliverables of the new system

Direct and indirect financial impact for the bank


While there is clear business justifi cation in the form of intangible benefi ts such as market growth, retaining of competitiveness and long-term success, many bankers mull over cost effectiveness and return on investment (ROI) in order to fi nd fi nancial justifi cation for the project.

Though varying with individual projects, cost savings primarily come from lower maintenance costs, lower operating costs and time savings. Many legacy systems demand a large pool of IT-trained manpower, which is becoming increasingly scarce and expensive. Reduced manpower requirements after replacement would therefore lower the maintenance costs. In addition, systems that provide front-end and back-offi ce integration improve effi ciency in data collection, enhance operational processes and allow the keeping of consolidated customer information, thereby helping the banks to meet customer requirements more quickly, which in turn lowers the operating costs.

As the banks go for STP, the rollout time for products declines. This, coupled with faster response times, provides considerable time savings for the banks. For many banks, these cost savings have led to a shorter payback period and an improved ROI. Industrial Bank of Korea claims that with its legacy system, it used to take almost a month to roll out a product. But since implementing a new core banking solution (by Temenos), the rollout time has reduced to 2-3 days and the time for batch end-of-day settlement has reduced by 30%.

•

•

•

Financial justifi cation through cost savings and revenue growth

While investment is substantial, benefi ts from cost savings, ROI and business growth could be more



Vendors often claim that replacement brings about a sharp increase in productivity. However, attributing the improvement to only the new system would not be appropriate as in many cases replacement is accompanied by process restructuring.

The most critical impact on a bank’s fi nancials is in its revenue growth. A fl exible system can facilitate the development of innovative products to cater to ever changing market demand. Designing and creating new products and customising are easier with the right system, which leads to more product innovation and shorter rollout times.

The bank would achieve faster growth (and in many cases greater market share) with its ability to make quick decisions and its agility in rolling out new products. Banks like ICICI and HDFC in India have managed to capture a large share of the Indian market (which was earlier monopolised by state-owned banks) through improved service quality and innovative products due to their advanced core banking systems.

Customer-centric systems (compared to account-centric systems of the past) provide a single view of the customer to multiple functional segments of the bank. This facilitates customising of products to customer segment, cross selling and bundling of products and services, leading to improved fee collection and revenue growth. Additionally, the bank can enhance customer satisfaction and improve business through features like virtual 24/7 banking.

The cost savings and revenue growth will vary between banks depending on the unique features of individual projects. Some big banks claim that they have benefi ted through a distinct improvement in effi ciencies and the retention of a substantial number of customers that they would have certainly lost otherwise. Most banks also agree that there has been drastic reduction in end-of-day processing time and product development time (e.g. some banks can set parameters of products within a couple of days). Most banks have extended their hours of operation to nights and weekends as well. These tangible and intangible benefi ts often provide substantial fi nancial justifi cation for the banks to take the plunge.

•

•

•

•

•

Intangible boost to growth highly possible if bank has the right system



5Core Banking Replacement Building Blocks

We have identifi ed the critical building blocks of the core banking replacement project. These comprise the technical issues that arise as the bank shifts from one system to another. The issues covered herein are coexistence, interfaces, data cleaning and conversion, and product and process rationalisation. The objective is to highlight the issues and success factors in the transition process. Our target audience for this section are the key technical decision-makers in the bank.

Core Banking Replacement Building Blocks

5.1 Application architecture and core banking5.1.1 Key issues5.1.2 Deployment strategy

5.2 Service oriented architecture5.3 Interface considerations 5.4 Coexistence

5.4.1 Branches5.4.2 Call centres5.4.3 ATM transactions5.4.4 Other online interfaces5.4.5 Batch interfaces – inward clearing5.4.6 Batch interfaces – outward clearing5.4.7 Other transaction implications

5.5 Data conversion and data cleansing5.6 Product rationalisation 5.7 Process rationalisation

5.1 Application Architecture and Core Banking

Our research into core banking architecture and deployment practices reveals that the process of replacement consists of several critical building blocks which need to be taken into consideration during planning:

Core Banking Building Blocks

DeploymentStrategy

InterfacesProcessRationalisation

CoexistenceProductRationalisation

Service Oriented Core Banking Architecture

DataConversion

ChangeManagement

ProjectOrganisation &

ProgrammeManagement

Building Blocks


5.1.1 Key issuesIn our analysis, we found a number of key questions which always arise concerning these building blocks. For example:

Big bang or phased deployment strategy – Is coexistence of the old and new worlds required? If yes, what type/scope of coexistence is needed? How long can we tolerate coexistence?

Service Oriented Architecture (SOA) – What is the impact of the new core banking system on the bank’s overall systems architecture? What changes are required? What impact will it have?

Interface considerations – How many interfaces will we need to build? Who is going to build it? How can we minimise the risk of slippage in the interfaces?

•

•

•

•

•

Critical building blocks of core banking transformation


Core Banking Replacement Bui ld ing Blocks


Coexistence – How will the old and new worlds coexist during the deployment period?

Data cleansing and data conversion – What is our approach to data conversion? What inter-dependencies exist? How do we address data cleansing?

Process rationalisation – Which processes will be impacted by the core banking replacement? Shall we change the processes or shall we change the core banking system? How much legacy do we want to take over to the new “post core banking replacement world”? How can we best manage the rationalisation process?

Product rationalisation – Which products can be converted without modifying the core banking system? Which products and services will be impacted by the core banking replacement? Shall we change our products or shall we modify the core banking system? How many legacy products do we want to take over to the new “post core banking replacement world”? Are there opportunities for new products and services as part of the core banking replacement? How can we best manage the product rationalisation process?

Project organisation and programme management – How do we organise the project? Do we need senior management involvement? If yes, how much involvement? Do we need external consultants or a systems integrator to help, or can we do it in-house? If we need external help, how can we best manage the external resources?

Change management – What is change management? Do we really need it? If yes, how much change management do we need? Do we focus purely on internal change management or do we also need external change management?

Banks need to answer these and other questions for a successful core banking replacement project. This chapter will examine some of these core banking building blocks in more detail and explain their purpose in the overall programme of core banking enabled transformation.

5.1.2 Deployment strategyA critical decision for any core banking replacement is the choice of deployment strategy. There are primarily two options: big bang implementation or a phased rollout by cluster. For each approach, there are a number of variations. But for the purpose of this document, we will focus on the two broad options:

•

•

•

•

•

•

•

•Identify the deployment approach most suitable for the bank’s needs


Big Bang is a deployment strategy which assumes that all systems will be deployed at the same time in one big bang. As a result, banks do not need to worry about coexistence or the more complex rollout logistics of a phased approach. The disadvantage of the big bang is that there is little or no margin for error. If a large bank is considering big bang deployment, it should conduct massive training and repeated conversion rehearsals over some period of time. The transition planning also has to ensure that all conversion logistics are in place, i.e. hardware, systems software, network, etc. Analysing best practices, we have found that conversion rehearsals should always include a month end. We see the big bang option as the most risky approach, only worth considering for small banks.

Phased Approach is the deployment of the new core banking solution by branch or regional cluster. It is recommended that the phased deployment is conducted as a “big bang” for each deployment cluster. This means that, as in the big bang approach, the entire solution is deployed in one go – but only for a manageable cluster and not for the entire enterprise. The advantage of this approach is that banks receive the benefi ts of the big bang for all deployment clusters while keeping risks within a manageable level. For instance, if deployment problems occur, they can be confi ned to the cluster and will not affect the entire enterprise. On the down side, a phased rollout will take longer and will require massive logistical planning for each deployment cluster. Nevertheless, we believe that the benefi ts of this approach, especially risk mitigation, more than compensates for its higher cost and longer deployment period.

•

•Phased approach has manageable risk

Big bang is quick but has no margin for error



5.2 Service Oriented Architecture We believe it is essential that the bank has the right architecture to suit its core banking needs. The architecture is important because it will set the foundation for the future. Choosing an ageing and infl exible architecture will lock the bank in the past before it even starts with the deployment of its core banking solution. Service Oriented Architecture (SOA) is a relatively new concept that has been gaining popularity lately. While vendors often talk about it, many banks consider it just as a new buzzword. The fact remains that this is a new technology which still needs to mature and develop the capability to successfully manage high transaction volumes. Nonetheless, it can provide the necessary fl exibility and is being actively considered by some banks. We have described the essential elements of SOA below.

SOA is essentially a business-driven framework for the deployment of reusable business components embedded in computer code. This defi nition highlights some of the essential elements of this architecture.

Herein the services are “loosely coupled”, i.e. not tightly integrated as that would limit its fl exibility. Specifi cally, each “service” has a corresponding “contract” which defi nes what the service does and how it can be used. We understand that there should ideally be no restriction on how a service operates internally in order to deliver on its contracted capabilities. This can enable each service to be altered internally without necessitating changes to the client applications (which can include other services) so long as the changes do not alter the contracted defi nition of the service and how to use it. If this is achieved, the advantage is clear – one can modify the internal operations or even replace a given service without having to modify every programme that uses the same service so long as the contract is not changed.

Those who advocate SOA believe that it is not about the internal workings of the application but about how the application exposes its “services” to the outside world. Thus, although the selected core banking system may not have been constructed with SOA environments in mind (many were not), it can fi t into an SOA environment by exposing its services through well-defi ned interface contracts (e.g. for withdrawals, transfers, clearing, and the like). This would enable the bank to loosely couple their existing applications with the new core banking system and avoid the disadvantages of tight coupling.

According to the defi nition of Dirk Krafzig, Karl Banke and Dirk Slama in their book Enterprise SOA (Prentice Hall ISBN 0-13-146575-9), an

•

•

•

•

•

Build the system around SOA which would provide the bank with business fl exibility



Enterprise Service Oriented Architecture can be defi ned as follows:

Defi nition of Service Oriented Architecture (SOA)

Business Logic Data

ApplicationFront-end

BusinessService

ServiceRepository

ServiceBus

Contract Implementation Interface

ServiceOriented

Architecture(SOA)

A Service Oriented Architecture (SOA) is a software architecture that is based on the key concepts of application front-end, business service, service repository, and service bus. A service consists of a contract, one or more interfaces and an implementation.

Services and application model are the major attractions of SOA

In addition there is a service repository and a

service bus

The application front-end is the owner of the business processes

A service consists of...

a) a service contract that specifies the functionality, usage, and constraints for a client of the serviceb) an implementation that provides business logic and datac) a service interface that physically exposes the functionality

A client can be either an application front-end or another service

1 2 3 4

a b c

b2b1

1

Services provide business functionality that the application front-end and other services can use

2

The service repository stores the service contracts of the individual services of an SOA

3

The service bus intercon-nects the application front-end and the services

4

Source Synthesised from Enterprise SOA by Krafzig, Banke and Slama

A core banking architecture consists of deposit and loan product processing engines, as well as a product factory for rapid deployment of new products and services. The customer information repository sits outside the core banking architecture and is loosely coupled to it through an enterprise service bus. This is necessary as the customer information repository must be able to support multiple core banking systems, as is required in many banks around the world.

A more detailed view is included in chapter 3 (core banking defi nition)

•



Illustrative Core Banking Architecture

Multi-Channel Bank System

ExternalInterfaces

General Ledger

CreditCards

ClearingHouse

BahtNet

Branch

Call Centre

ATM

Internet

etc.

etc.

etc.

Core Banking System

Customer Information

Collateral Information

Common Services


Deposits Loans

Chan

nel In

tegratio

n

Applicatio

n In

tegratio

n

Rep

ortin

g / S

tatemen

t Interface




5.3 Interface Considerations Our research shows that interfaces are a key concern for any core banking replacement project. Every major application in the bank is interconnected, or interfaced with the core banking system, as illustrated in the chart below. According to some experts, an enterprise service bus (ESB) and an SOA together can help to reduce the number and complexity of interfaces, enabling the bank to focus on its core business rather than the maintenance of an IT infrastructure.

Old Core Banking System

Online Online Online Batch Online/Batch

Batch

Batch Online OnlineOnline/

Batch OnlineBatch

Online

Batch

Batch

Batch

Online

Online

Batch

Online

Batch

Batch

Branch Application

Core Banking System

Trade Finance

HumanResources

Financial Planning

Agent Service

Audit and Control

Authorised Signature

Data Warehouse

Cash ManagementCall Centre Cheque CIS

E-Channel

EAI

Donation

Custodian

Credit Card

BONDSWIFTPaymentLoan

OldCore Banking

System


Transition from the old core banking system to the new core banking system can be conducted in three steps:

•

•

SOA and ESB together can reduce the complexity of interfaces



Transtition Phase

Step 1: Implement switching

layer

Step 3: All accounts

converted to new Core Banking System

Step 2: Phased migration to new Core Banking

System and coexisting with

Legacy


The end result is a smooth transition from old to new core banking system, as illustrated below:

New Core Banking System

Online Online Online Batch Online/Batch

Batch

Batch Online OnlineOnline/

Batch OnlineBatch

Online

Batch

Batch

Batch

Online

Online

Batch

Online

Batch

Batch

Branch Application

Core Banking System

Trade Finance

HumanResources

Financial Planning

Agent Service

Audit and Control

Authorised Signature

Data Warehouse

Cash ManagementCall Centre Cheque CIS

E-Channel

EAI

Donation

Custodian

Credit Card

BONDSWIFTPaymentLoan

SWITCHING MECHANISM

NewCore Banking

System


•



5.4 Coexistence Our research indicates that as the bank replaces the system using phased implementation, it often faces the critical issue of coexistence. Coexistence is the strategy and process taken to operate two core banking systems concurrently for a limited period of time. Coexistence describes in detail which methods, such as switches, merges and manual processes, are used to process transactions between the old and new worlds.

A critical question in core banking replacement is how the bank should deal with coexistence issues, assuming that it chooses this deployment option. Coexistence planning is a very complex activity. But contrary to the common myths, it is clearly doable and it works.

Coexistence Environment Overview

Old World / Legacy Core Banking System

Coexistence Switches /

Merge

New World / Next Core Banking System

Coexistence Infrastructure

OldCore Banking

System

NewCore Banking

System

Other Online

InterfacesATM

Call Centre

Systems

Clearing House

Other Batch Interfaces

Unconverted Branches Converted Branches


We have come across different methods of managing coexistence and interfaces. Described below are types of interfaces that we believe are the better ways of dealing with coexistence.

•

•

•

Coexistence poses considerable challenges demanding complex and strategic planning



Coexistence Implications


how does the bank operate while accounts are progressively converted to the new core banking system?

how will inter-branch transactions be handled during coexistence?

how will the call centre service requests during coexistence?

how will ATM transactions be processed during coexistence?

how will other online interfaces be processed during coexistence?

how will incoming batch interfaces be processed during coexistence?

how will outgoing batch interfaces be processedduring coexistence?

how will sweeping and other features be processed during coexistence?

Branches Call Centres

Batch Interfaces (Outward Clearing) Other Implications

ATM TransactionsOther Online

InterfacesBatch Interfaces (Inward Clearing)

What is Coexistence




5.4.1 BranchesIn most banks, the branches account for the bulk of customer-facing transactions. A key question to be answered here is how the bank wants to treat the different types of possible intra-branch transactions. As most affect the customer and the bank’s relationship with him, we believe that it is important to have business involved in all of these discussions and let business make the fi nal decision on how to proceed. After all, business will know its customer better than IT does. There are a number of options:

Branches During Coexistence

Old branches can access new accounts Yes No No

New branches can access old accounts Yes Yes No

ATMs can access all accounts Yes Yes Yes

Development effort / risk High Low None

Feature Option 12-way Support

Option 21-way Support

Option 3No Support

Coexistence Options

Old Branch New Branch

Customer has account in a new branch and wants to transact at an old branch

Customer has account in an old branch and wants to transact at a new branch


At fi rst glance, the two-way option may look like the best choice. However we understand that it comes with a high cost for building the coexistence interfaces. After analysing transaction volumes, banks may fi nd it worthwhile to consider option 3, “No Support”, as a feasible alternative. In our review, we learnt that business usually understands and supports this approach for standard branch services (e.g. deposits, withdrawals and transfers). The business rationale is that the potential inconvenience is only for a limited time and can be managed through good customer communication, especially where there is low to moderate transaction volume. Our research indicates that if the bank is replacing its front-end system and core banking system at the same time, option 3 is preferable because it reduces the need for temporary integration between the old front end and the new core banking system and between the new front end and the old core banking system.

•

•

For intra-branch transactions, business should make the decision on coexistence approach



5.4.2 Call centres We believe that the second-most important customer contact point is the call centre. During coexistence, the call centre transactions can be handled through an online transaction switch without posing any problem for the operation.

Call Centre Transactions During Coexistence

OldCore Banking

System

NewCore Banking

System


Call Centre System


Online Transaction Switch


•



5.4.3 ATM transactions Our analysis shows that managing coexistence of ATM transactions is usually not of any major concern. Due to the nature of ATM transactions, the infrastructure is already in place to deal with multiple back-end systems.

ATM Transactions During Coexistence

OldCore Banking

System

NewCore Banking

System



Tandem ATM SwitchATM


•



5.4.4 Other online interfacesThese are treated with the same strategy, i.e. the use of online switches.

Online Transactions During Coexistence

OldCore Banking

System

NewCore Banking

System



External System

Online Transaction Switch


•



5.4.5 Batch interfaces – inward clearingWe have discovered that one of the best ways in which inward clearing transactions are addressed is through a batch splitter. The batch splitter will divide (split) incoming clearing transactions into “old world” and “new world” transactions and then proceed with the approval and posting process for the respective core banking systems. This approach usually does not pose any major technical challenge.

Inward Clearing Transactions During Coexistence

OldCore Banking

System

NewCore Banking

System



External System

Switch

During rollout, the files need to be split to send the data to the appropriate system…

Batch Splitter

Batch


•



5.4.6 Batch interfaces – outward clearingSimilarly we have found that outward clearing transactions can be addressed through a batch combiner. The batch combiner, as the name implies, will combine the outgoing clearing transactions into one or more batches, in accordance with the clearing house regulations. Again, technically, this approach does not pose any challenge and has been successfully used by leading banks around the world.

Outward Clearing Transactions During Coexistence



OldCore Banking

System

NewCore Banking

System

External System

Batch Combiner

During rollout, the new system will also generate this data for converted accounts …

A ‘Combiner’ will therefore be needed

Batch


•



5.4.7 Other transaction implicationsOther types of transactions need to be analysed on a case-by-case basis. Typically these transactions centre on inter-branch sweeping and standing orders, as illustrated in the chart below:

Other Coexistence Implications


Inter-BranchSweeping

Amend the systems to pass the transactions out

Create an external system for inter-branch sweeps

Manual processes

Standing Orders

Amend the systems to pass the transactions out

Create an external system for inter-branch standing orders

Manual processes

Others

Each situation will have to be judged on

Criticality Volume Complexity

A decision is then made on the best solution available


•



5.5 Data Cleansing and Data Conversion

Our research shows that data cleansing and data conversion are of the utmost concern for most banks around the world. We believe that data cleansing should not be conducted as part of a core banking project. In our opinion, data cleansing is an entirely separate project with its own organisation structure and milestones. It should be an ongoing operation (rather than a one-off project) at the bank and great care should be taken to avoid creating dependencies between data cleansing and the core banking project. Placing data cleansing objectives with the data conversion team is tantamount to asking for unclean data to be converted.

Data should be cleaned either before or after it is converted, but not during the conversion exercise, and not by the data conversion team. This is important as cleansing of customer data cannot be resolved with technology alone, but requires the hands-on involvement of the bank’s customer-facing personnel. Note, however, that other types of data transformation are required during the core banking data conversion to accommodate differences in data format between the old and new systems or to auto-set default values for new fi elds in the new system. But these should not be confused with data cleansing, which changes the meaning of existing data rather than its format or structure.

Data conversion, on the other hand, is an important part of the core banking replacement project. It can be executed in three stages, as illustrated in the chart below:

•

•

•

Data cleansing should be a separate project distinct from the core banking project

Data conversion can be executed in three stages



Data Cleansing and Data Conversion

CustomersAccountsStanding InstructionsTransaction HistoryEtc…

Data


Data

... what it takes :

Step 1: Data Mapping

Step 2: Data ConversionExtracts

Step 3: Data ConversionLoads

Data Cleansing

Data ConversionOldCore Banking

System

NewCore Banking

System


Data mapping – Our research shows that banks start the data conversion process with data mapping. This essentially entails mapping the old-world data elements to the new-world data elements and can be used to identify areas for product and process rationalisation. There are a number of considerations for data mapping, as illustrated in the chart below:

Data Mapping

Step 1 : Data Mapping

Current AccountIs there a corresponding product for each of our existing products?

Can we rationalise our products to fit the supported products in the new CBS?

Current AccountProduct

Current Account

Account No.

Current AccountAcc Branch Code

Acc Product Code

Acc Sequence No.

Acc Check Digit

Does the new system’s account number structure match our existing structure?

Should our account number structure continue to have meaning?

When will we run out of account numbers?What should be the length of the account number? What are the implications for the new system, cheques, passbooks, ATM transaction records, etc. ?

Account No.Attributes

Data Mapping Considerations

“New World” Core Banking System

“Old World” Core Banking System

Domicile Branch Code

Account Open Date

Interest Rate Method

Limit

Is there a one-to-one mapping of fields for this product (i.e. Current Accounts)?

Is there a one-to-one mapping of field values (e.g. are our interest rate methods supported by corresponding methods in the new CBS)?

How do we handle custom fields (e.g. Special Field1)? Should we customise the new CBS or rationalise the requirement?

Is the source data “clean” and acceptable?

Domicile Branch Code

Account Open Date

Interest Rate Method

Limit

Special Field1


•



Data conversion extracts – During this second stage of the process, customer and account information is extracted from the existing system and put into the conversion staging area in preparation for loading into the new world system.

Data Conversion

"Old" World

Conversion Staging Area

DATA


Extracted data ready for loading

Conversion data file layout as required by new core banking system

ConversionData

ConversionReports

Data

Extr

act M

odul

es

Step 2 : Data Conversion Extracts

OldCore Banking

System


Data conversion loads – This is the fi nal stage where customer and account information is loaded into the new core banking system and reconciliation reports are automatically generated.

•

•



Data Conversion Loads

"Old" World

Conversion Staging Area

DATA


Extracted data ready for loading

Conversion data file layout as required by new core banking system

ConversionData

ConversionReports

Data

Extr

act M

odul

es

Step 3 : Data Conversion Loads

"New" World

DATA


Conversion reconciliation and verification.

Report Generator

Reports

Load

Mod

ules

OldCore Banking

System

NewCore Banking

System




5.6 Product Rationalisation We have discovered that product rationalisation is also an important element of successful replacement projects. Product rationalisation is essentially the process of assessing the value of the bank’s current product and service offerings, i.e. whether a product or service is still competitive and profi table or should be deemed “sunset”. This is the time to ask not only where the bank is with its current offerings but also where it wants to be in the future. Banks often also check if an existing product or service can be migrated to the new platform in a cost effective manner, e.g. without too much customisation. Also to be considered is how the bank can make full use of the new core banking solution and launch competitive new/enhanced products and services. Ultimately, the bank needs to defi ne the future market offerings in terms of:

a. products/services to be discontinued,

b. products/services to be redesigned and renewed, and

c. new products/services to be introduced with the launch of the new core banking system.

Hence, product rationalisation has a number of benefi ts for the core banking replacement programme. It enables the bank to take full advantage of the capabilities of the new core banking solution. It simplifi es the sales process through consolidation of “like offerings” into core banking “confi gurable” products.

It also provides an opportunity to discontinue products/services that are not, or not adequately, contributing to the bottom line. In addition, it mitigates the risk of project delay and failure as the bank avoids unnecessary customisation to support redundant old-world products.

•

•

•

Data conversion can be executed in three stages



5.7 Process RationalisationCore banking replacements will impact most of the front- and back-end users. Hence, process rationalisation provides the bank with a chance to overhaul its fragmented and perhaps outdated business processes as an explicit outcome of the core banking enabled transformation. It allows discontinuation of legacy processes and elimination of paper-based or semi-automated processes. It also provides an opportunity for process re-engineering to utilise the new core banking solution to its fullest.

•Process rationalisation can overhaul outdated processes



6Critical Success Factors and Best Practices

Organisation of the project and management of the change are critical issues for projects of such a scale. We have identifi ed the key factors and best practices for banks to accomplish success in selection and implementation. We have also detailed the essential ingredients for service providers to achieve successful implementation. This section is targeted at all decision makers, within banks as well as vendors.

Critical Success Factors and Best Practices

6.1 Project organisation and programme management6.1.1 Stage 1 project organisation6.1.2 Stage 2 project organisation6.1.3 Stage 3 project organisation

6.2 Critical success factors and best practices in system selection6.3 Critical success factors and best practices in vendor selection6.4 Best practices for vendors (for successful implementation)

6.1 Project Organization and Programme Management

We believe that a project of the magnitude and scale of a core banking replacement requires strong project organisation and programme management. In addition, the project organisation should be adjusted depending on the phase of the project.

Business Transformation Team Structure

OthersTeller

Core Banking

Common Activities Deployment

Project Organisation

Steering Committee

Programme Director

QA PMO Support Team

Core Banking Enabled

Transformation Technology

Core Banking Enabled

BusinessProcess

Architecture & Integration

DataMigration

Testing

Organisation& Change

Functional Technical

BenefitRealisation

Business Transformation Team Process

Coordination & Decision

New WorldClusterPilot

Source: Immacon SOBIT Research

Our research has led us to a few best practices in programme organisation which we discuss below. The overall responsibility for the project should lie with the project steering committee. This committee should be chaired by the CEO and it is important that he demonstrates commitment to the project. Other members of the steering committee should include the bank’s full-time programme director, heads of all the business units, the CIO, and key risk-management and fi nance personnel.

We believe that the bank’s full-time programme director should have complete authority over the project. The programme director should be empowered to make decisions after consultation with business and IT. He needs the authority to make the fi nal decision if consensus cannot be reached with a business division or with IT. An overriding decision should be immediately reported to the steering committee, which can veto the decision if necessary.

•

•

•

Programme organisation should delineate the responsibilities and accountabilities of project decisions


Crit ical Success Factors and Best Pract ices


The programme director should be supported in his day-to-day activities by the project managers for the business and technology transformation. The fi rst stage of the project deals primarily with issues of business and technology transformation: delta analysis, interface analysis and design, conversion and coexistence. An important aspect of this phase is the delta resolution for product/process realignment. These activities will require substantial full-time involvement and empowerment of the business specialist and the IT specialist, both of whom must have a good understanding of the bank’s legacy systems.The project organisation will change depending on the stage of the project. The charts below illustrate the different stages of the project and the corresponding organisation required to execute the project effectively. Banks should ensure that the core programme leadership team is always full-time and leads the project for the entire duration of the exercise. We believe that the programme organisation can be divided into three broad stages.

6.1.1 Stage 1 project organisationThere are various ways in which banks plan and organise their project. One practice that we have discovered is delta analysis. In this approach, the fi rst stage of the project is focused on diagnosing the current business and IT environment in the bank and defi ning how the bank should operate in future. Based on the current environment and the target environment, the bank defi nes the “delta”, followed by the delta resolution. We need to stress here that the delta is not a “Gap”. A “Gap” analysis looks backwards, whereas a delta analysis looks forward.

Stage 1 Project Organisation, Delta Analysis & Design

Significant Third Party Resource

Involvement

Core Banking System Project

Manager

Core Banking System Business

Team

Interface Analysis and Design Team

Conversion & Coexistence Design

TeamDelta Analysis Team

Product Realignment

Process Realignment

Project OfficeTechnical Support

Stage 1

Stage 1Delta Analysis & Design


•

•

•


6.1.2 Stage 2 project organisationThe second stage of the project is the move from delta analysis and resolution to the build-and-test stage. The focus at this point is on the rapid technical implementation of the solution.

Stage 2 Project Organisation, Build & Test


Manager

SystemImplementation

TeamInterfaces Team Testing Team

Training & Procedures

Team

CustomerApplication

Team

DepositsApplication

Team

LoansApplication

Team

OnlineInterfaces

BatchInterfaces

Legacy Systems Teams

3rd Party Interface

Systems Teams

Pilot Site Selection Prep.

Go /No Go Assessment (ext.

Accountants)

BusinessTesting Team

IntegrationTesting Team

CoexistenceDevelopment

Team

OperationsTesting Team

ConversionsData Extracts

Teams

Train-the- Trainers

Training Team

UserProcedures

Team

OnlineApplication

Team

Accounting & Other Apps

Team

DataConversionLoad Team


Stage 2

Stage 2Build & Test


Involvement


•



6.1.3 Stage 3 project organisationThe third stage of the project sees a move from the technical build-and-test stage to the pilot implementation stage. The focus here is the deployment of a live pilot, to test and fi ne-tune the new core banking solution and its processes and procedures.

Stage 3 Project Organisation, Pilot


Involvement


Manager

Pilot Team

Core Banking System Pilot User Support

Team

Core Banking System Applications Fix

Teams

Interfaces Support Team

Data Conversion & Coexistence Support

Team

Pilot User Training Team

Legacy System Fix Team

3rd Party Interface System Fix Team

Conversion Data Extracts Support

Teams


Stage 3

Stage 3Pilot


•



6.2 Critical Success Factors and Best Practices in System Selection

Key Success Factors in Selection

Business decision to change

Long term impact on the organisation,growth,processes and culture

Flexibility, adaptability, compatibilityand financial impact

Softwareplatform, type of solution and hardware

Goals Managerial and financialcommitment

Existingsystem, size of bank, business goals

Required systemarchitectureand platform

Selection Process

Set Business Direction

Take Strategic Decision

EstablishFunctional

Requirement

EstablishTechnical

Requirement

SystemSelection


The impact of core banking system transformation would be visible over the long term in the performance of the organisation. A bank replaces its system once every 10-15 years (sometimes even longer), and thus it is essential that the bank develops clear objectives and its expectations are detailed to ensure suitability of the system and to avoid a mismatch between deliverables and expectations. The bank should be clear whether it needs to replace the core banking system, the front end, or both. It must not be enamoured with “bells” and “whistles” as these only represent the front end and not the real core banking system.

The rapid pace of change in the banking business makes it extremely diffi cult to picture the banking landscape in the years to come. For this reason, the right selection would be one with a forward-looking fl exible architecture that has the ability to respond to the business dynamics and adapt to newer products and services as well as the scalability to meet future growth. This calls for a delta analysis.

The bank must ensure that the project involves business and management executives with leadership skills along with the IT people. Involvement of the CEO and second-order decision makers will ensure long-term

•

•

•

Selection of a system requires managerial and business support from all sections and a clear focus on business goals

Ensure involvement of business representatives and develop a matrix for evaluation



commitment to successful implementation. The selection process should involve key representatives from functional divisions as they would be the ultimate users. But users see only the front end, while IT people may be more aware of the technical requirements in terms of processing power. Thus it is necessary to involve both the teams and ensure coordination while avoiding/resolving confl icts.

A detailed matrix of selection criteria should be developed. Each solution and vendor needs to be evaluated on this matrix, and the system that can provide the highest value to the organisation should be selected. Having a consultant (who has experience with similar projects and awareness of unique local requirements) to guide the bank would further strengthen the selection process.

We recommend that banks leave the old world behind and move to the new system in entirety. While this poses signifi cant transformation challenges, it would ensure optimum returns as there would be no “legacy baggage”. But the bank must ensure that the system functionality, platform and technology are right for its needs and it would not be wise to just choose the “best” in the market. The architectural components of the system and its raw processing ability are critical. The technology should easily integrate with existing systems within the bank, facilitate differentiation, assist in quick decision-making, improve competitiveness through faster product development and, at the same time, improve returns through lower operational and maintenance costs.

Further, the architecture of the selected system should facilitate growth plans. There may be cases where the functional and technical capabilities of a system make it scalable but not fl exible, or vice versa. In such a scenario, banks may just be shifting their systems from a smaller box to a bigger box where growth may be constrained again within a few years. This should be avoided at all costs. The architecture should be component-based as this would allow for the possibility of making future additions to the system. We highly recommend an SOA-based system that can provide fl exibility for future changes. Banks can select a packaged system that has the ready processing capacity and customise the front end to suit the user needs.

Finally, it is important that bankers do not lose sight of business objectives and get wrapped up in architectural discussions and process redesign issues that are too broad or diffused to add value to the business. They should aim for quick decision-making and system selection in order to prevent opportunity costs from rising further.

•

•

•

•

Functional capabilities and architecture should facilitate growth plans



6.3 Critical Success Factors and Best Practices in Vendor Selection

Success Factors in Vendor Selection

Track record and technical ability of the product to meet the functionalrequirement

Ability to tide overdowntrends and sustaintechnicaladvancements

Ability to meet the unique local requirementsand yet provide the requisite quality standards

Financial ability andcommitmenttowards long term technical advancementand services

Reputation and long term commitment to provide ongoing support and futureintegrations

Project Stages

Identifyvendors with track record

and reputation

Evaluatefinancial

strength and viability

Evaluateexperiencewith similar

projects

Evaluatecommitment

to business & technical

enhancement

Evaluate post- implementation

support and services

Evaluating service providers


System selection and vendor selection go hand in hand. Vendors and service providers can no longer be viewed as just IT suppliers. Instead, they are partners in the long-term success of a bank. The selection, in many cases, is based primarily on cost savings, which ironically may prove to be a costly mistake in future. The basis of decisions should be the vendor’s capabilities and not pricing.

It is imperative that banks ensure the vendor provides the right mix of product and services required to meet the objectives and ambitions of the business and the unique requirements of the project. The relationship between system provider and system integrator should also be evaluated and their track record in managing projects as a team needs to be analysed.

Equally important is that the bank has to evaluate its own comfort level with regard to the vendor’s reliability and suitability for the particular project. If the bank has an existing system from the vendor, there could be a distinct benefi t from having fewer integration issues. Using the same vendor for both the front end and the core banking system can also reduce integration and interface issues considerably.

•

•

•

Suitability of IT partner for unique requirements of the project and its commitment to provide long-term technical support are crucial

Select the right mix of product and services



We have seen projects of even leading international vendors fail despite excellent track record and strong technical capability. The main cause was lack of local knowledge and ability to cater to the unique conditions of the banking environment in that country. Cost aside, the bank should select those vendors that involve local people in the process of customisation and localisation, and ensure that they provide international quality while meeting the local standards. Vendors that have already customised a product for a particular country are likely to be more suitable to undertake future projects in that country.

Finally, the bank should select a vendor that has the commitment and ability to continually enhance the product so that future upgrading of the system would be easier. The IT partner should be one with whom the bank can maintain a long-term relationship, both through ongoing post-implementation technical services and through future products.

•

•

Select vendors that involve local people in customisation



6.4 Best Practices for Vendors (for Successful Implementation)

Key Success Factors for Implementation

Banks should develop strong team to guide the vendor

Developempathy with business environment

Excellentcommunicationskills to motivate and meet resistance to change

Develop pilot projects to ensureexpectation and deliverables match. User acceptancetests at all levels

Timely data cleaning, migration and integration with existing system with zero error

Post-implementation support through ongoing services and future upgrades

Project Stages

Understandunique

requirements, expectation of

the bank

Involve local people to meet

unique local requirements

User training to adopt new processes in work culture

Thoroughtesting at

each stage. Develop pilot

project

Ensureseamless

integration and timely

implementation

Provide long term

partnership to the bank

Successful Implementation


What can vendors do (besides providing a good product) to successfully implement a project of this scale? Successful implementation involves not only timely completion but also seamless integration, zero error and smooth transition.

We believe the basic ingredient for success is the ability of the vendor to understand the business requirements. Clarity of banks and vendors on both the requirements from the new system and the requisite deliverables would lessen the risk of expectation/deliverable mismatch and help the vendors to customise and localise the system as per the unique requirements of individual projects.

Vendors should ensure that within the bank, there is strong business ownership, management involvement and a business environment conducive for implementing the project. There must be a common ground for decision making, where the banks and service providers can interact to fi nd solutions for inevitable hiccups. The aim is to meet the objectives and achieve timely completion coupled with high quality, but balanced with the costs involved. It is important that the right mix of people within the bank is involved in the process.

•

•

•

Understand the business needs

Ensure strong business ownership for project within the bank

Develop empathy with working environment

Begin user training even before deployment of system



Vendors need to ensure optimum utilisation of communication channels. Besides having domain knowledge, the service provider has to develop empathy with the working environment and culture to meet the unique local requirements. Allocation of the right expertise is crucial. Equally essential is that the vendor selects its partner carefully and chooses one that has the requisite expertise. In addition, when there are multiple vendors in a team, the accountabilities, responsibilities and decision-making process must be clear and a ”prime vendor” must be identifi ed.

Technical skills to integrate the existing systems and migrate data from old to new system are indispensable, but equally important are communication skills for user training and change management. User training should begin much before implementation to ensure smooth transition. The vendor should conduct seminars and training sessions for users in phases, with the involvement of a strong internal team from the bank.

Internal processes within the bank need to be redesigned and aligned with the capabilities of the new core banking system. Application- and process-specifi c initiatives can bring about cost savings as well as improve effi ciencies by redeploying resources and enhancing the quality of products and services.

Testing of new core banking systems on a smaller scale prior to across-the-board implementation is one way of minimising risk and evaluating the effectiveness of the system. We believe that implementation of large projects should be done in phases with repeated parallel testing at each step. A good strategy could be to implement in pilot branches and conduct business acceptance tests before rolling out on a larger scale. While the testing should be thorough, it should not be overly long or else it could delay the process and increase the costs. A right balance needs to be struck. At any stage of the project, if changes become necessary, then the vendor and bank should re-evaluate the project. Sign-offs at each stage can facilitate this process.

Finally, IT vendors should take a long-term perspective while implementing the project. Continual upgrading and ongoing support services are critical requirements for a long-term relationship with the bank.

•

•

•

•

•

Redesign processes within the bank for optimum returns

Conduct testing and user acceptance tests at all levels



7Unique Core Banking Replacement Considerations

This section covers the unique business considerations, functional requirements and key challenges faced by different types of banks. Going further, we have also analysed the problems and system demands from unique situations like mergers and acquisitions.

Unique Core Banking Replacement Considerations 7.1 A large multinational bank7.2 A small commercial bank7.3 An Islamic bank7.4 “Internet only” banks7.5 Mergers and acquisitions of banks

7.1 A Large Multinational Bank

Unique Requirements

• Complex transactions across geographic locations and multiple functions

• Requires scalable system with proven technology and reliability

• Integration with the existing system and seamless connectivity across functions

• Multinational, multilingual capability

• Architecture that provides agility and flexibility but also robustness and reliability to handle large volumes

• Maintaining smooth operations during transition


Key Challenges

• Business process restructuring and change management are difficult propositions in old organisations with deeply-ingrained work culture and processes

• Data migration tends to be more difficult due to geographic dispersion and high volume of business

• User training is generally more time consuming

• Coexistence of two systems during transformation process

• Multiple application systems and software across the organisation need to be integrated

• Single product may not suit complex requirements and may demand significant customisation


For most top-tier large banks, the key consideration for replacement has been to overcome the limitations of their antiquated legacy system and disparate systems with spaghetti structures caused by extensive middleware and multi-application connectivity. Thus the banks essentially

•Replacing core banking system in large multinational bank is highly complex


Unique Considerat ions


need to eliminate duplicated systems, integrate systems across multiple functions, add functionality in the core system, and improve the database and its connectivity.

For a bank with branches across countries, millions of customer accounts and large transaction volumes, core banking system replacement is a massive project which requires a very strong business justifi cation. Most large banks take years to reach a decision on core banking replacement. It is a multi-year project where clarity on system requirements is vital. The banks need to determine whether a front-end replacement would suffi ce or they require core banking replacement as well.

Most off-the-shelf systems are not suitable for the volume and unique requirements of a large multinational bank, and hence substantial customisation of the packaged solution is necessary during implementation. However, a better approach would be to customise the front end rather than the core processing system. This would make it imperative for the bank to either utilise the services of an experienced system integrator (e.g. SBI) or undertake further development on existing systems to meet its complex needs (as in the case of HSBC).

The platform of choice for large banks should be mainframe, which has proven its ability to meet scalability needs and handle large transaction volumes. As most large banks have legacy systems that are based on mainframes, this would make transition more feasible and lower the switching costs.

The requirements from a system should refl ect long-term strategic goals of the bank. The banks essentially need systems that are integrated across functions and locations to facilitate the implementation of competitive strategies with a customer-centric view. This may demand customisation on the front end and transition to a component-based banking system architecture such as SOA.

The functionality across multiple operations has to be complemented with stability, reliability, scalability, robustness and fl exibility to enable the bank to introduce new products and services with ease and speed. Compatibility and integration of multiple applications throughout the organisation is essential for large retail banks.

We believe that past experience with similar large projects and reliability would be critical considerations in vendor selection. Long-term support would be essential, whereas pricing is not likely to be a key issue.

Many large banks have systems that were developed in-house. But often, the people who developed these systems (or know the software codes)

•

•

•

•

•

•

•

Banks need a scalable and robust system to handle high volumes

Vital requirement is seamless connectivity across functions and locations


are no longer with the organisation. This makes the tasks of deployment, data conversion and data migration extremely diffi cult for the vendor.

Implementation will probably be a drawn-out process lasting several years. A gradual or phased approach would be the most suitable, with step-by-step implementation and testing at each phase. We recommend that banks conduct pilot projects before deployment. Cost and schedule overruns are likely due to the complexity of the process. Each stage of implementation should have a sign-off to ensure timely completion as per requirements. Maintaining smooth operations during implementation and coexistence would be a big challenge.

User training and change management are likely to be diffi cult due to the extensive scale of the project, users being spread across geographic locations and functions, and deeply-ingrained work culture. Most banks would thus prefer a system that can be seamlessly integrated within the organisation so that the change process is smooth. Integrating and improving processes and transforming the work culture would be essential for optimum returns from the new system. We advise banks to undertake process and product rationalisation exercises along with the replacement in order to achieve the best outcome.

Having strong management support to see the project through and strong internal teams to coordinate with vendors and communicate within the organisation would be essential for a project of this scale.

•

•

•



7.2 A Small Commercial Bank

Unique features

• Less complexity and smaller scale of operations

• Lack of trained IT manpower

• Investment size and cost savings are critical considerations

• Smaller geographic spread and fewer number of branches – faster implementation

• Outsourcing a feasible option

System requirements

• Need agility and flexibility from system

• Capability to innovate and differentiate products and services

• Compete on basis of cost effectiveness

• Need integrated and centralised system

• Likely to need services for customisation and localisation

A small commercial bank


A small bank with a modest asset base and localised operations has its own unique business considerations for selecting a system vendor and service provider. Most small banks see cost as a critical business consideration and essentially require systems that have a low cost of ownership, particularly in terms of operational and maintenance costs.

To retain competitiveness, most banks need fl exibility and agility from their systems to be able to provide differentiated products and to roll out products with speed. A customer-centric system that can help the banks to focus on fee-based transactions and product innovations to tap consumer demand is important. This can be achieved through architectural integration and SOA. Market penetration through cross selling, product bundling and product innovation is likely to be an immediate consideration of these banks. In addition, they need scalability so that the system can cater to growing volumes.

While mainframes are proven technology across the globe, UNIX may also be feasible for small banks as their scalability and volume requirements are low. Due to manpower constraints, most banks do not have the ability to develop the software internally and thus prefer packaged solutions. There has been an increasing trend among smaller banks to acquire integrated solutions to take advantage of end-to-end

•

•

•

Competitiveness through fl exibility and cost effectiveness are considered essential for growth

Small banks can take aggressive approach by adopting new-generation technology and big bang deployment



integration through a single product and vendor (which may be diffi cult for the scale of operations of a large tier 1 bank). Outsourcing is another viable and practical alternative for many, if they can overcome the security constraints.

We recommend that banks look for packaged solutions that have the capability to meet their future needs. The customisation requirements for small banks are generally less complex and hence customisation of the front end may suffi ce. The focus of these banks is likely to be the completion of the replacement project not only in minimum time but also at a low cost.

Implementation is less challenging than for a large retail bank. While we recommend the phased approach due to lower risk, the big bang approach may also be feasible in the case of a small bank. This is largely because the level of complexity in its processes and the scale of its operations permit the bank to adopt new technology aggressively. However rationalisation of processes and products is necessary for optimum returns from the project.

•

•



7.3 An Islamic BankUnique requirements

• Adaptability to conduct financial transactions in accordance with Islamic law yet compete with conventional banking

• Flexibility to develop and support interest-free Islamic products

• Compatibility with other Islamic applications

• Cost effective and suitable for relatively small banks but scalable to cater to rising volumes

• Multi-channel delivery, innovative products and product differentiation capability

• Coexistence and integration with conventional banking systems


Over the last two decades, hundreds of Islamic banks have mushroomed across the world to cater to the unique requirements of Islamic fi nance. Islamic banks are common in the Middle East but have sprung up as far away as London and the Philippines. Within the Asia Pacifi c region, Malaysia and Indonesia are two countries that have shown rapid growth in Islamic banking.

The bedrock of Islamic banking is the principle of shared risk. Interest payment is regarded as exploitation in Islam because depositors and lenders make money without providing labour or sharing risks. Shariah law requires profi ts to be shared and bans investment in certain industries such as those related to alcohol and gambling. It also prohibits interest payments and the handling of money as a commodity. Hence Islamic banks pool deposits to invest in construction, commodities trading and other businesses that do not profi t from interest payments. Commercial borrowers pay the bank and its depositors a share of their profi ts instead of interest.

This requires the system to have the ability to integrate basic core banking features with strong Islamic banking functionality. A system that can offer sophisticated and innovative Islamic products and services coupled with operational effi ciency and cost effectiveness would allow the banks to maintain an edge in a highly competitive industry. It is a niche segment where banks need core banking systems which can facilitate the set-up of new Islamic banks and the conversion of conventional banks to Islamic

•

•

•

Recent spurt in number of Islamic banks has forced the banking sector to look for systems that provide compliance with Islamic law

System should have the ability to integrate core banking features with Islamic principles



banking, and help already established Islamic banks to stay competitive in the market. The growing demands require that the new system is not only fl exible but also scalable.

Challenges are plenty as there are no standard rules and there are unique market requirements which need to be considered while offering products in different markets. Additionally, pooling of assets and liabilities and calculation of profi ts can be diffi cult. Thus the system should have fl exible accounting structure and banking processes peculiar to Islamic banking.

The banks need to offer consumers multiple innovative products that comply with Islamic banking rules and yet be able to compete and extend their market reach. The resources of most Islamic banks are more limited, which makes the task even more onerous. Further, they have to exist alongside and in many cases compete with conventional banks. Thus multi-channel delivery, high quality of services, a centralised system and 24/7 capability are some of the requirements of Islamic banks as well.

•

•



7.4 ‘Internet Only’ BanksKey Requirements

• Compete with brick-and-mortar banks on basis of “new technology”

• Capability to provide product and service differentiation and innovation to meet consumer requirements

• Cost effectiveness

• Speed to market the products and straight-through processes

• Architecture that provides flexibility and growth

• Maintain competitive edge through agility and creativitySource: Asian Banker Research

“Internet only” banks, a relatively new concept, are specialised banks that compete with brick-and-mortar banks (conventional banks) on the basis of convenience, lack of locational constraint and lower costs. These banks offer innovative products and services online round the clock and seek to do it cost effectively. As they have lower fi xed, operational and maintenance costs and the cost benefi ts are passed on to customers, the fees are generally lower and the interest rates competitive.

Most of these banks are small and do not have adequate manpower to customise and implement the core banking systems. For this reason, they prefer packaged solutions, with cost being a major consideration in selection. The transaction volumes are not as high as those of conventional banks and multi-channel delivery capability is not necessary. The front end, however, may need customisation to suit the unique user needs for this type of bank.

These banks maintain their competitive edge through innovative products and services offered online to the customers. Speed is essential and hence system fl exibility and agility are key requirements. Quick decision-making and reduced product-rollout time are equally important. Scalability is not critical, so a UNIX-based system may suffi ce.

Competition from new entrants in the market and from existing conventional banks has forced most of these banks to provide innovative services at low cost and with low fee-based income. Capability to meet this requirement is likely to be a critical consideration in system selection.

•

•

•

•

Cost effectiveness with fl exibility for innovative products is essential for “internet only” banks



Many of these banks are probably acquiring a core banking system for the fi rst time. Implementation is likely to be less complex and faster to roll out than in conventional banks. Most internet banks are new and small, making integration and data migration easier.

•



7.5 Mergers and Acquisitions of Banks

Core Banking Considerations in Mergers and Acquisitions

Problems

• Duplicate systems impede growth

• Difficult for banks to deliver integrated, customer-centric services

• Maintenance and operational costs increase

• Difficult for two systems to coexist unless restructured

Integration

• Linking the core banking systems so that they effectively function as one platform

• Difficult for two systems to coexist

• Time consuming and costs can be high

• May be followed by core banking replacement after a few years

Migration

• Systems of pre-merger entities are migrated onto one platform

• Data migration has high risks

• Time consuming

• May be followed by core banking replacement after a few years


Mergers and acquisitions can be nightmares for IT professionals of the banks involved as they are invariably followed by restructuring of the core banking systems. This is largely because the duplicate systems impede growth due to their high maintenance and operational costs. Further, running two separate systems makes it diffi cult for the banks to have an integrated view of the customer. Thus banks have to ultimately consolidate the two systems, resulting in integrated databases and core banking.

Restructuring can be done by two means – migration or integration. Both the options are high risk, involve huge costs and normally take several years to accomplish. Implementation problems may lead to errors that can easily shake the customer’s confi dence in the bank.

In migration, the systems of pre-merger entities are migrated onto one platform. Take the example of Bank of Tokyo, whose business was migrated onto Mitsubishi Bank’s core platform. However, data migration can be almost as risky as a core banking replacement project.

•

•

•

M&A requires system migration or integration, either of which is risky and challenging



Integration entails linking the two systems so that they effectively function as one platform. This project can be equally challenging and may require anywhere from six months to several years to implement. In Japan, three banks merged to form Mizuho Bank using the integration approach. But even as two banks are able to integrate their core banking systems through robust middleware and other technical advancement, customisation of the front end is likely to be essential.

Other than technical challenges in the process, it can be diffi cult to get two banks to reach an agreement on platform, system and system integrator. In some cases, a third approach may also be feasible, where a fi nancially strong purchaser installs a new core banking system within the bank in order to meet aggressive business objectives. As we have discussed, this would involve high costs and risks but may also result in long-term growth for the bank if done properly.

At the end of it all, the banks must have a system that is suitable for the transaction volumes and processing needs of the combined bank and meets the objectives of the merger.

•

•

•



8Country Trend Analyses

This section analyses the trends in core banking system re-placement in a few leading countries within Asia. The market trends, demand characteristics and unique requirements of each country are explored.

Country Trend Analyses

8.1 India8.2 China8.3 Japan, Korea and Taiwan8.4 South East Asia – Indonesia, Malaysia, Thailand and Singapore

8.1 India

• Most tier 1 and tier 2 banks have already made decisions; some small banks likely to replace their systems

• Has been quite an active market for core banking in last 2-3 years

• Many banks have gone for centralised and end-to-end solutions

• Leading vendors are Infosys, I-flex and FNS(TCS)

• Banks have preferred local vendors due to familiarity with local system, sophistication of technology and cost effectiveness

•Fewer opportunities in future as market is reaching saturation soon

• Data centralisation of public sector banks and stiff competition have led to demand for better customer service and product enhancement

• More banks prefer open system and new technology

• Most Indian banks prefer changing their infrastructure from bottom up rather than adding applications due to archaic structure

• Preference for local vendors

• Cost is not a major consideration

• Partial replacement in some banks likely to be followed by purchase of application software for remaining functions

Market Trends Demand characteristics

Source: Asian Bank Research

India is a unique country from the core banking perspective. Till fi ve years back, most banks in the country were working on mere branch automation and most state-owned banks did not even have a core banking system owing to lack of infrastructure and network readiness to provide a centralised system. New private-sector banks then came into the market with a distinct technical advantage which led to substantial customer attrition in state-owned banks.

Competition within the banking sector of this country is rising as foreign banks are becoming more aggressive, growing through both acquisitions and expansion of operations. Aggressiveness of the private banks has thus forced most state-owned banks to replace their core banking systems with advanced, centralised systems that are not only competitive but also cost effective. In the last two years, almost 30% of the country’s banks (most of these being state-owned) have taken the decision to replace their core systems. Because of this, almost 50% of deals in Asia during this period have come from India.

Prominent deals in the last few years include State Bank of India with TCS, Canara Bank with I-fl ex (for a $49 million project), Central Bank of India with TCS (for a project costing 150 crore rupees or about $33

•

•

•

After active spell in last 3-4 years, Indian core banking market may be reaching saturation soon




million) and Bank of Baroda with HP. As the trend indicates, most of the major banks in the country have already entered into core banking deals. Most of them would be completing their rollout in 2007. We understand that those who have not yet entered into deals are actively evaluating vendors. For this reason, we believe that the Indian market is nearing saturation.

Some banks have preferred integrated, packaged solutions. This is a feasible option for banks which are undertaking greenfi eld projects – and hence do not have to face the complex issue of integration with old systems – and whose transaction volumes are low. The preference has been for local vendors, who understand local business requirements and are considered more reliable in terms of domain knowledge. Moreover, many Indian vendors now rank among the top global vendors. The leading core banking providers within the country are Infosys, TCS (with FNS), I-fl ex and Nucleus Software.

A critical challenge that many banks have faced in the transformation process is the wide spread of branches across the country and in areas where networking and infrastructure capabilities are still being developed. As a result, many banks have found it diffi cult to integrate all their branches through a centralised system. Another tricky problem has been change management, as most banks are shifting from branch automation to a centralised system. In branch systems, branch employees maintained ownership of the data. However with centralised systems, some banks have observed that their employees felt a ”lack of ownership of data”, on top of the typical employee dissatisfaction with change in processes.

UNIX-based systems have clearly been the preferred choice as India has traditionally favoured UNIX. Most of its local vendors also provide systems in UNIX.

•

•

•


8.2 China

BranchComputerisation

BranchNetworking

DataCentralisation

Integrated Core Banking Systems

IT Infrastructure development of Chinese banks

• Increasing number of core banking deals; leading vendors include FNS, Misys, Temenos and System Access

• Banks treading cautiously in selection of systems and vendors following deal failures

• Tier1 and Tier 2 banks looking for international standards in new systems but need systems to provide for local practices

• Many Tier 1 banks using in-house systems and increasingly considering new technology

• Many smaller banks still prefer local vendors

• Increasing foreign competition as foreign banks gain full access in 2007

• Need to keep pace with rapid growth and market demand

• Traditional accounting system being chal-lenged by new business and foreign banks

• Need product that meets the unique local requirements, e.g. language, business environment

• Higher costs and implementation risk due to unique requirements; needs involvement of local people

• Lack of prominent local vendors

Market Trends Demand Characteristics

Source: Asian Bank Research

Regulatory and market-driven competitive pressures are forcing banks in China to consider replacing their core banking systems. Market pressure comes from the arrival of foreign stake-holding in banks and customers becoming more demanding on quality of services and products. The robust growth of the Chinese economy has attracted fi nancial institutions from across the globe.

On the regulatory front, under China’s WTO commitments, foreign banks will gain full access to its banking sector in 2007. In addition, the country is gearing up to host the 2008 Olympics. With this background, most banks in the country are awakening to the need for technically advanced and competitive systems.

We believe all Chinese banks are now somewhere between branch computerisation and integrated core banking in terms of IT infrastructure. Only a few leading banks like Bank of Shanghai, ICBC, China Minsheng

•

•

•

Market-driven and regulatory pressures are forcing many banks to consider replacing their systems



Bank, China Development Bank and CITIC Bank have upgraded to an integrated core banking system.

There is increasing interest in core banking system replacement among banks, with many medium and small banks mulling over the decision and some evaluating vendors. We have seen a gradual growth in number of deals in the last couple of years and expect the trend to continue and probably accelerate as competition intensifi es. The platform of choice continues to be mainframe, which is more appropriate considering the large branch network and high transaction volumes.

We have discovered that the uptake of core banking systems has been slow in the country as a whole because the banks have been very cautious. Additionally, we have observed that tier 1 banks (and now increasingly tier 2 banks) prefer international vendors for the quality of their solutions and services, whereas many smaller banks continue to prefer local vendors due to the lower cost and higher level of trust and reliability. There continues to be a certain level of doubt in the market about the ability of foreign vendors to meet the local requirements of Chinese banks. Deal implementation problems have also been reported in cases like CITIC Bank, whose replacement project was done by Fiserv.

Many banks in China are looking at point solutions in, for example, trade fi nance and treasury rather than at core banking system replacement. We believe this refl ects their short-term objective of attracting foreign funds.

Most banks in China have unique requirements such as ability to deliver in Mandarin and capability to customise and localise the solution to suit their business conditions. For this reason, most vendors that are providing solutions to Chinese banks are setting up centres in China and employing local people.

Recent prominent deals include China Minsheng Bank by SAP, which also marks the entry of the global vendor into this region, Hua Xia Bank by TCS, and ICBC Beijing and Bank of Shanghai by Temenos.

•

•

•

•

•

Only a few banks have upgraded to an integrated core banking system

Smaller banks continue to prefer local vendors

China presents a good opportunity for those who have technical capability and domain knowledge to meet the unique requirements of banks



8.3 Japan, Korea and TaiwanTrend Analysis in Japan, Korea & Taiwan

• Predominantly mainframe; Cobol-trained generation will start retiring in 2007

• Most large banks have proprietary systems developed in-house

• Mergers and acquisitions have delayed core banking replacement

• Demand likely to increase due to foreign shareholding in the banking sector

• Predominantly proprietary systems; many banks have in the past preferred in-house development but manpower is becoming scarce for such systems

• Banks now shifting towards new technology for cost effectiveness and reduced human-resource requirement

• Banks regard the application of new technology crucial for competition

• Banks are looking for rapid product-to-market delivery and cost effectiveness to face increasing competition

• Integration and data migration from proprietary system can be challenging

Issues and Trends in Japan

• Lack of confidence to change from legacy system among many banks

• Market opening up with several deals in 2005; many of these were for open systems

• Require usage of traditional Chinese characters in software

• Need system to suit the unique requirements of language and business culture

Issues and Trends in Taiwan

Issues and Trends in Korea


The level of technical sophistication among Japanese banks is one of the highest in Asia with most banks having basic integrated CRM. Japan has traditionally had largely mainframe-based systems, most of which are proprietary systems developed in-house. Reliance on these stable and robust systems has been widely accepted in the country and thus the banks have been relatively slow in patronising the UNIX technology.

However the banks are increasingly acknowledging the need to reduce the high maintenance cost of these systems as the manpower for managing them is dwindling. In Japan, this is known as the “2007 problem” as that is the year when Cobol-trained manpower starts retiring. Another factor that is likely to move the market is the increasing foreign share in the Japanese banking sector.

Various mergers in the Japanese banking sector have also led to complex

•

•

•

Japan

Banks in Japan are struggling with rising maintenance cost and scarcity of trained manpower



systems that typically would need upgrading or replacement to reduce complexity and improve effi ciency. Ageing systems and competitive pressures are likely to bring about increased activity on the core banking front over the next few years. Interestingly, a notable trend has been the formation of smaller new-generation banks in Japan which tend to look at new-generation technology.

Indications are there but a substantial shift towards undertaking this risky venture is yet to be seen in this country. According to one leading vendor in the region, “Japan market will move in 2-3 years. They have not reformed their fi nancial services sector yet. It is coming very slowly. Once it is done, then we will see a change in reforms, change in attitude in both public and semi-public sectors. Nothing in Japan happens quickly.”

We believe that technical advancement among banks in Korea has reached integrated core banking and robust middleware. Till a few years back, most banks in Korea used mainframe-based legacy systems. But in the last few years, there has been an increasing shift towards UNIX-based systems. The new regulatory environment requires banks to have stringent capital coverage and risk management policies. These new rules, high cost of maintenance and ageing technology are believed to be the critical factors driving the shift.

Competition in the market is intense and banks need to be effi cient and cost effective in order to gain an edge. For this reason, most banks are looking for architecture that not only meets their current business requirements but is also scalable to cater to future growth. Nonetheless, the complexity of tasks involved in replacement and integration is a key deterrent for most banks. Historically banks have preferred to build their systems in-house, but we are seeing an increasing shift in favour of IT companies.

Taiwan is one of the few countries where there was a sudden surge of activity in 2005, with four banks going for core banking deals as compared with 2004 when there were none. We believe that most banks still lack the confi dence to change from legacy systems, but competitive pressures are forcing them to look for newer-generation technology.

Our research shows that technical advancement in the banking sector of this country is currently at data centralisation and integrated core banking. Now the banks are poised to take the leap towards integrated CRM in order to achieve total customer centricity. As there is already a level of technological sophistication among these banks, they do not feel the urgency to take a replacement decision, but competition and

•

•

•

•

•

Korea

There is increasing shift towards new-generation technology among Korean banks

Taiwan

Taiwan offers a good opportunity to IT companies with its increasing shift towards open-end technology



consumer demand have been driving the shift.

Recent core banking replacement decisions have been in favour of the UNIX platform. However, in most cases, a critical consideration has been the ability to suit the unique requirements of language and business culture in Taiwan. The latest prominent deals include Cathay United Bank by TCS-FNS and Ta-Chong Bank by I-fl ex.

•



8.4 South East Asia – Indonesia, Malaysia, Thailand and Singapore

Trend Analyses of South East Asia Countries

• Many smaller banks continue to operate on legacy systems

• Existing systems are costlier and more difficult to maintain; manpower to maintain them dwindling

• Not many core banking deals done recently; market yet to open up substantially

• Compatibility with Islamic banking an important requirement for some banks

• Largely cyclical market with banks coming to market to replace ageing systems

• Banks aiming for integrated core banking; more top-tier banks likely to take decision

Issues and Trends in Indonesia

• Largely cyclical market; banks come to market to replace or upgrade ageing system

• Most banks have centralised data systems and are aiming for integrated core system

• Has been active lately with many core banking deals; mixed demand for open and proprietary systems

Issues and Trends in Thailand

• Considered a relatively mature and saturated market

• Many banks technically advanced with integrated CRM; banks replace to upgrade and improve competitiveness

Issues and Trends in Singapore

Issues and Trends in Malaysia


Banks in developing South East Asian countries like Thailand, Malaysia and the Philippines have an existing base of fi rst-generation infrastructure. However this was purchased 15-20 years back. Hence, not only is it outdated but it has also reached a stage where managing and upgrading it are extremely complex tasks. The key requirement for these banks is thus to have a suitable architecture that is technically advanced to give them a competitive boost as well as scalability.

The motivation for change varies. But change is happening. According to one leading vendor, “South East Asian countries such as Malaysia and Indonesia are cyclical markets. People go out and replace system

•

•

South East Asia is predominantly a cyclical market where banks replace ageing systems to maintain competitiveness



about every 15 years. They are [returning] to that; it is time to look and replace again. There is no economic pressure; it is just retirement and renewal strategy.”

In Malaysia, in the last three years, we have seen many small and medium banks coming to the market to replace their systems. Many of them have chosen vendors that can provide them with Islamic banking capability. For this reason, local vendors such as Microlink and Silverlake are popular in the country. We understand that the leading bank of Malaysia, Maybank, is also in the process of evaluating vendors for changing its core banking system. Given the small size of the country’s banking sector, the change is noticeable. The aim of the banks is to have integrated core banking systems.

Many experts consider Singapore a rather mature and saturated market. Banks in the country have already achieved technical sophistication in their banking systems. Since there is no urgency to change, the banks take considerable time in making a decision.

We have seen very few deals from this country lately. The only prominent one in recent times is DBS Bank – in 2005, the bank appointed Infosys to provide an integrated system for its domestic retail operations.

Technical advancement among smaller banks in Indonesia leaves much to be desired, with some of them still working on branch computerisation. Some technically advanced banks have set up a centralised data system. We believe that many smaller banks in Indonesia continue to operate on ineffi cient legacy systems and are spending a lot of money and time to maintain them. The skills to operate these systems are disappearing as most young graduates prefer to work on an open system while the older people are retiring. Hence maintaining these systems is becoming more problematic. The platform of choice has mostly been mainframe, but there are indications now that banks are considering UNIX systems as well.

However change has not been easy to come by. We have not seen many prominent deals from Indonesia in recent years. But we expect the market to open up in the next 2-3 years owing to increasing ineffi ciency and competitive pressures.

•

•

•

•

•

Many Malaysian banks look for capability to adapt to Islamic banking

Singapore is a saturated market

Many banks in Indonesia continue to operate on high-cost legacy systems



9Vendor Assessment

This section examines the current standing of vendors in the Asian markets and ranks them. A survey across banks in Asia coupled with our in-depth analysis of the products and the deals implemented by the vendors in Asia have assisted us in rating them, both on their abilities and on their product’s capabilities. Besides this, we have analysed their market positioning based on their success and architecture.

Vendor Assessment

9.1 Vendor and product assessment 9.2 Market positioning

9.1 Vendor and Product Assessment

Our Assessment of Vendor and Their Product

The key vendors in the region and their core banking products have been analysed based on a survey done across banks in Asia. This has been complemented with our research into their products, track record and fi nancial strength and a quantitative analysis of the recent decisions.

We have divided our assessment into two parts. First is vendor assessment based on four parameters and second is product assessment based on fi ve parameters. The analysis has been done for only core banking systems and not other solutions.

Vendor assessment – methodology

Reliability – Reliability of the vendors in the region has been judged through a survey done across banks in which they rated the vendors based on their level of trust in each vendor’s capability to meet project deadlines and commitment to the project. We have complemented this with our research into the vendors’ track record, number of projects in the last two years and number of years in business as well as the parent support of these organisations.

Financial strength – We have assessed the fi nancial strength of vendors on the basis of their fi nancial standing in absolute numbers and

•

•


Vendor Assessment

Vendor Assessment

their growth over the last three years. The analysis has included key indicators such as revenue, operating profi t, net income and net worth, among others.

Current presence in Asia – The vendors’ presence in Asia has been judged on the number of core banking deals that they acquired in 2004 and 2005. The spread of these deals across Asian countries has given us a background on the number of countries where the vendor has managed to make its presence felt. This has been complemented with research into local presence through offi ces.

Implementation capabilities – The assessment of implementation capabilities has been based on our analysis of the number of successfully implemented projects in Asia in the last two years and our research into the reputation of the vendors on their implementation track record.

Product assessment – methodology

Ability to meet unique needs – The assessment of this quality has been based on a market survey where banks were asked to rate the product on its ability to meet their unique and specifi c requirements while providing international quality. We have further analysed the local presence of the product in individual countries and the success of customisation.

Product support – This has been analysed through a survey where bankers were asked to assess the product on post-implementation support services.

Presence among big banks – The presence of vendors among large banks in Asia has been determined based on the number of deals that the vendors have won in recent years from large Asian banks. The suitability of the product architecture to meet the requirements of large multinational banks has also been analysed.

Deals with small banks – The presence of vendors among small banks has been assessed on the number of deals won by the vendors for small and mid-size banks in Asia.

Market perception of product – A survey done recently among Asian banks has enabled us to assess the market perception of the product based on its functionality and architecture.

•

•

•

•

•

•

•


9.2 Market PositioningProduct Positioning – As we see it

High

ArchitecturalAdvancement

Market Penetration

SOA/RDB

Low

Traditional/Flat-file DB

Unproven Emerging Leaders

Niche Players Ageing Architecture

X = Fidelity Core Bank X = Temenos Core Bank

U = I-flex

U = InfosysU = TCS Bancs

U = Temenos Globus

A = Fiserv

U = Fidelity Sanchez

A = Silverlake

X = Fidelity Systematics

Legend

X = Mainframe

U = UNIX

A = AS4000


The product and vendor positioning is based on our assessment of architectural advancement (progression towards relational database and SOA) and market penetration of the products across banks in Asia.

Unproven – This segment consists of those products that have no signifi cant history of implementation in Asia and hence market penetration is rather low. However the prospects look good, as the architecture is relatively new and more fl exible. There seems to be only one product in this category and that is Fidelity Corebank, a mainframe-based core banking system.

Emerging leaders – This segment comprises those products that are technically advanced and have higher market penetration following implementation across banks in Asia. We believe that the architectural development of Temenos Corebank and Fidelity Corebank is somewhat similar, but Temenos has made more progress in the region in the last few years. We thus see it as an emerging leader in mainframe-based systems.

Ageing architecture – The products that have high market penetration among Asian banks but also architecture that is relatively old belong to this segment. Our classifi cation of new architecture implies products that have relational database and are more suitable for Service Oriented Architecture. In contrast, old architecture is used for those systems that were built long ago and have a traditional fl at-fi le database system. Since

•

•

•


Vendor Assessment

their inception, some of these products have undergone architectural changes and a certain level of technical advancement. As these products have been in the market for a long time, their market penetration is considerably high. Many UNIX systems such as Infosys Finacle, TCS Bancs and I-fl ex Flexcube are in this segment. Among mainframes, Fidelity Systematics is also positioned here. Fidelity Systematics had high penetration in the market a few years back, but in recent years it has not had any major implementation in Asia.

Niche players – The products in this category specifi cally cater to niche segments such as wholesale banks and small retail banks. Understandably, their market penetration is lower. For example, we believe Globus of Temenos is more of a wholesale banking package, while Fiserv ICBS and Fidelity Sanchez are more suitable for smaller banks.

•


Vendor Assessment

10Conclusions

Our research leads us to certain conclusions on success in core banking which we discuss here in two sections. The fi rst is for banks where we identify the critical requirements to achieve success with the core banking systems project. The second is for IT service providers and delineates essential factors to achieve long-term success in the core banking systems market.

Conclusion

10.1 Conclusion 1 – For bankers10.2 Conclusion 2 – For vendors

10.1 Conclusion 1 – For BankersSummarising Success Factors for Banks

People and workculture adaptation

Embrace change management

Strong leadership & decision making

Management and business commitment

Clear business direction, goals and business intelligence


We believe that the following elements are essential for a successful core banking project.

The bank must have clear business direction and goals, which would be the guiding principles for all stages of the project from selection to implementation. This would also ensure that the project has adequate justifi cation and support from the business perspective and the implementation does not stray from requirements because of enamouredness with technical enhancements.

To ensure that the project has management commitment at all times, there should be adequate business ownership and decision making should involve people from business functions. We believe that strong project sponsorship from top management is critical for its success. Viewing the project as just an IT project would be a recipe for failure. The bank should also develop strong internal teams to communicate and coordinate with the service providers to ensure deliverables match the business objectives.

There is bound to be resistance to change and employee dissatisfaction, which can only be countered through effective communication and

•

•

•

•

Lack of business commitment and willingness to adopt changes within bank can lead to failure of even well-implemented projects

Have clear business goals

Ensure total business commitment at all times

Effective communication is essential for change management


Conclusion

developing the right business environment. Internal teams should be developed to conduct training and overcome employee resistance.

For the change to yield optimum returns, it should be adopted at all levels within the organisation. The bank should shift from old world to new world in entirety. Product rationalisation and process restructuring would facilitate optimal utilisation of the new system and thus should accompany this transition. Failure to do so would lead to old processes being tied to the new system and eventually a mismatch between expectations and deliverables.

•

Conclusion

Process restructuring and product rationalisation should accompany the process


10.2 Conclusion – For VendorsSummarising Success Factors for Vendors

Reputation, track record

Partners in projects, not just vendors

International quality standards meeting local needs

Technical enhancements

Long term commitment to business


For long-term success, it is essential that service providers see each project as a long-term relationship. Besides maintaining high technical standards, they need a track record of successful implementation. Every project has its unique characteristics and requirements which need to be addressed with utmost diligence. Having the right people with domain and business knowledge to suit the local requirements of individual projects is essential for successful implementation. An army of men cannot replace a few critical people. Needless to say, the technical ability and track record of the vendor are most critical in the selection process. Service providers must invest continually in technical advancements. Equally important is catering to the local conditions while providing international quality in the product and services. Ensuring that deliverables are in line with the expectations of the bank requires clear communication at all levels. This would involve user training and the challenging task of managing process and work-culture change within the bank. There should be fool-proof testing at each step in addition to other strategies for risk minimisation. Successful implementation of each project is a step in building the market presence and reputation of the service provider.

•

•

•

•

Long-term commitment to enhance product quality and “partnership” role in project are crucial for success of IT service providers

View project as long-term relationship

Employ right people with domain knowledge

Ensure deliverables and expectations match through effective communication


Conclusion

A1Appendix ICase Studies

Case Studies

A1.1 State Bank of IndiaA1.2 Union Bank of Philippines

A1.1 State Bank of IndiaSWOT Analysis

Strengths

Threats

Weaknesses

Opportunities

In-house IT capability to implement the project. Strong internal teams

Almost non-existent previous core banking system, easing integration issues

Vendor has previous experience in country and strong alliance with system integrator

System Integrator is familiar with unique business requirements in India

Highly complex task with almost 8,000 branches

Implementation time-consuming due to wide reach

Large human resource requirement for in-house implementation

Existing independent branch system

Core banking replacement project extended to 4 associated banks

Increased competitiveness and improved efficiency

Centralised system that gives single view of customer and frees resources for better service

Difficult to change processes and work culture in a 200-year-old organisation with branches extending to remote areas

Lack of ownership of data at the user level

10 million transactions per day. Scale of data migration huge with zero margin for error


State Bank of India (SBI) is the largest commercial bank of India with 8,000 branches across India and a global presence in 20 countries. This two-century-old organisation has not only a wide spread but also a deep reach into the interiors of the country. Till a few years back, it was working on basic branch automation and a rudimentary legacy system. However, competitive pressures from private sector banks and the opening up of the economy made it necessary for the bank to purchase technically-advanced and cost-effi cient systems that could meet its functional and technical requirements.

Under the old system, the bank had computerised 2,050 branches on a standalone basis. Thus each branch had its own independent system, which it maintained and managed. The system was Bankmaster (now under Misys) and it was used in 75% of the bank’s branches. However, as each branch was independent, consistency and integration of systems within the bank was not possible and customers could not freely approach other branches of the bank.

Inherent problems with the existing system and the competitive climate in the industry thus forced the bank to undertake the massive project of

•

•

•

Largest commercial bank of India found it necessary to purchase new system to face competition and reduce attrition rate

The old system


Case Studies

Case Studies

revamping its core banking system. It initiated the plan with transformation in 3,300 branches in year 2000. But thereafter, the change process was extended to include 5,000 branches of four associate banks as well.

The key motivation for the bank to purchase a new system was the desire to have a local framework in which IT could serve as an “enabling force” and relieve the local branches of back-offi ce operations thereby allowing them to focus on delivery and marketing. And this was possible only if the bank had a centralised core banking system and made its branches a service and delivery channel. Multi-channel delivery without core banking was not practical.

The Timeline of the Transformation Project

April2007

August2006

April2006

2004200320022000

Implementation completed

85% of Business migrated to new

system

3,000 branches(50% bank's

business)migrated

200 branches migrated

Implementation process begins

at pilot branches

Selection process.

Preparing RFP took 6 months

Project Conceptualised with KPMG as

consultant


However, when the bank started to consider replacing its system, there were very few examples. It wanted proven technology for its system but there was none. Not even Bank of America and other big global banks had undertaken such a change. Its size was the key issue and it needed a system that could cater to its growing needs. (Together with its associate banks, SBI now has 15,000 branches and 140 million accounts in total.)

The whopping project for transformation of the domestic business was conceptualised in 2000 with KPMG as the consultant. The actual process of selection began in 2002 as the bank developed a matrix of criteria (10,000-odd points) for system and vendor selection which had to be approved by the government (SBI being a state-owned bank). It took almost six months for it to prepare the request for proposal. The selection after the RFP was issued took another two months. As it was a public bank, the selection process was bureaucratic with approvals needed from regulators. Technical bids were sought through the request for proposal followed by fi nancial bids. Suitable vendors were selected based on the technical bids and their pricing was one of the fi nal decisive criteria.

•

•

•

The selection process


FNS Bancs was considered the most suitable to meet the bank’s requirements. TCS was chosen as system integrator as it had the distinct advantage of being aware of local business practices, work culture and regulations and thus was well-placed to understand the requirements of the bank. Strong alliance between FNS and TCS was another factor that contributed to the selection of FNS as the vendor. This, however, meant moving to the UNIX platform which was relatively less proven than mainframe for a bank of this size.

Owing to the size of the organisation, the customisation of software and the user training and training for implementation were, in that order, the two most diffi cult tasks faced by the bank and the service providers. Unique requirements of the bank such as having to maintain branch individuality while centralising the systems posed signifi cant challenges in customisation. Its validation and process-adaptation requirements forced further customisation.

The original product from FNS which had about one million software codes was customised into a more complex hybrid product with almost two million codes. This extensive addition to the software code of the product was done by TCS and the system now covers 4,000 transaction types.

Because of the complexity, pilot projects were implemented. The task of migrating data from the old system to the new system had to achieve total migration and reconciliation with no loss of data. A bank with ten million transactions a day has no room for error or else customer attrition and loss of reputation can be extensive.

The deployment, which is still in progress, is being done gradually over all domestic branches and the branches of four associate banks. This involves a total of 8,000 branches, a scale seen by very few banks in the world. The bank implements the new system over 40 branches in a day.

SBI is a typical example where the time-consuming work of training staff and educating users is conducted in-house, a process which will take years to complete and require a huge amount of resources. SBI has formed a strong in-house team to work with the vendors on deployment and implementation.

Change management within the bank has been a whopping task. The ingrained culture of the organisation is undergoing a total transformation as the bank moves from an independent branch system to a central system. This has led to users feeling a ”lack of ownership of data”, unlike

•

•

•

•

•

•

•

Customisation and implementation process

The deployment was phased

The change management


Case Studies

previously where there was an entrepreneurial feeling as they managed the system and customised it to meet unique local requirements. This demanded a strong acceptance of change management within the bank, with staff roles changing and business processes being restructured across all users. SBI met this challenge through strong internal teams and effective communication. The change process is likely to continue even after the new system has been fully implemented.

By mid-2006, 85% of the bank’s business would have been transferred to the new system. By March 2007, SBI expects to have rolled out its core banking system to almost all of its domestic branches and those of the four associate banks.

Despite the substantial cost, time and resources employed in the process, we believe that it was imperative for the bank to shift to a newer system. Before the change, its attrition rate was high with private banks garnering huge market shares thanks to their technical advancement. The cost-to-income ratio of the bank is already showing signifi cant improvement. We expect this new system to give a strong boost to the bank’s future growth. However the effectiveness of the system for such a large bank can only be seen after it has been implemented across all branches.

For its international operations, the bank recently chose Infosys to provide a single integrated solution across all branches as it felt that TCS’s resources were already tied up with its domestic project. It is also believed to be implementing a new trade solution. In addition, the bank is undertaking a business process restructuring exercise in order to improve its effi ciency. With all these initiatives, SBI should remain a formidable player and retain its stronghold in the Indian market.

•

•

•

The outlook


Case Studies

A1.2 Union Bank of PhilippinesSWOT Analysis

Strengths

Threats

Weaknesses

Opportunities

Relatively small bank with 111 branches, making replacement less complex

Willingness and adaptability to change from mainframe legacy to new technology

Willingness to take risks to improve competitiveness

Data migration from multiple existing systems and integration was complex

Data cleanup was difficult as Finacle required some parameters which old system did not have

Lack of in-house IT manpower. Cost also an issue

Centralised the back-office operations with the new system

Growing economy. Acquisition of new customers and markets possible through differentiation of products and services

Availability of multiple vendors for open technology made choice easier

Lower TCO in new technology

Shifting from legacy to open system required change in processes and business culture

New system required extensive user training and acceptance at all levels

Big bang approach has higher risks. Tried for first time in the country


Union Bank of Philippines (UBP) is a relatively small bank with an asset base of $1.98 billion and 111 branches in the country. However it is among the top ten banks in the Philippines, with a history of fast growth thanks to its tech-savvy approach. True to its reputation, UBP has become the fi rst bank in the country to shift from mainframe to open platform.

The bank had an existing legacy system (from Systematics, running on refurbished mainframes) which was ten years old. The key problems faced by the bank included high operational costs and diffi culty in building interfaces. The bank then realised the need for a simpler system where interfaces are not an issue and total cost of ownership is lower.

The change was also prompted by the need to acquire business agility coupled with improved effi ciency and to have the ability to differentiate its products and services. Being in a competitive environment, the bank worked on a tight margin hence cost was an essential consideration. With these issues in mind, the bank started exploring the possibility of shifting to a newer technology platform in 2002.

•

•

•

The old system

Cost a critical consideration


Case Studies

The Timeline of the Transformation Project

April2005

April2004

4 Qtr2003

1 Qtr2003

2002

Implementation is completed

Implementationbegins with user

training

Selection process

completed. Finalises Infosys

Requests forproposal

from vendors

Explores possibility of shifting from mainframe to open platform


In 2003, the bank invited proposals from leading vendors that could meet its technical requirements. The process of selection took six months, during which the bank analysed all the proposals and bids and visited two Infosys project sites in India. The bank viewed the venture as the beginning of a long-term partnership and made the selection accordingly.

The selection criteria included the functional features of the system, the quality of the team and the track record of the vendor company. While technical capability of the system to meet the objectives was essential, cost was also considered to be a critical factor. Infosys presented a strong business case following a Gap analysis.

The bank fi nally selected Infosys to provide the system Finacle for its retail operations (CASA, loans, deposits and GL). Local fi rm Total Information Management Corporation (with whom the bank has a long-term relationship) was also hired to provide consultation and assistance in implementation. The project involved replacing its mainframe-based legacy system with a new-generation open-ended system which runs on Sun infrastructure. For Infosys, this was its fi rst big project in the Philippines. For this reason, involvement of a local partner was an asset for the bank as well as the vendor.

The project cost was about $4 million. One of the key considerations for the bank while selecting a system was the fi nancial impact. It wanted a system whose cost could be met through the operating profi ts of the bank over a period of fi ve years. In addition, the new system should have lower operational costs, thus leading to better returns for the bank.

Implementation took approximately one year and the system went live in April 2005. The implementation posed many challenges such as localisation and customisation to unique business conditions of the Philippines. In addition, data stored in multiple mainframe-based systems had to be cleaned, migrated and consolidated. Some of the items that Finacle needed were not found in the old system, making the task more diffi cult.

•

•

•

•

•

The selection process

The new system

The implementation and deployment process


Case Studies

The project was signifi cant for the Philippine banking sector because it was the fi rst time a local bank shifted from a mainframe-based system to open technology. For this reason – coupled with the fact that it used ”big bang” implementation – it was keenly watched by many in the industry.

The bank took an aggressive approach by adopting big bang, which was less time-consuming but came with high risk. Most banks, especially larger ones, prefer a traditional step-by-step rollout due to lower risks. However owing to the relatively small size of the bank, big bang was considered achievable and more feasible. The advantage in this approach is the avoidance of integration issues that arise from having two separate systems co-existing within the bank during rollout. The implementation is fast and would not slow the bank’s transformation process. The bank felt confi dent that it could implement the project according to schedule and it succeeded.

One of the strengths of Union Bank of Philippines has been its adaptability towards new-generation technology. It is considered a tech-savvy bank and has proven so by being among the initial few in the country to step out to replace their entire system. The bank developed an in-house core team which worked with the Infosys team to fulfi l the implementation plan and to train users for the change in processes.

The success of Union Bank of Philippines in its core banking transformation has some lessons for other banks undertaking similar projects. The management should be committed from conception to fi nal implementation. This is required of both the bank and the vendor and was one of the critical success factors for the bank. The bank developed strong teams with good banking knowledge and got them trained for the new system to ensure optimum utilisation. The bank faced a certain amount of resistance and “getting everybody on board” was a challenge. Most banks in the Philippines continue to operate on legacy mainframes. For these banks, UBP has been an example to look up to.

With the new system, the bank aims to reduce its cost by 15% over fi ve years. If achieved, this would give it substantial competitive advantage. Moving from account centricity to customer centricity should help it provide better customer service and improve its market presence. The bank has discovered that with the parameterisation of the system, it can launch new products much faster and with ease. The cost of interfacing is also lower. In addition, the bank did away with the branch IT network following core banking replacement. With the new centralised system, the bank freed up resources previously engaged in branch IT infrastructure. Additionally, the centralisation of back-offi ce functions should give a boost to its competitiveness

•

•

•

•

•

Lessons learnt

The outlook


Case Studies

A2Appendix IIAn Average Request for Proposal

An average RFP runs into 70-80 pages, with the bank requiring vendors to submit a whole range of information which would assist the bank in evaluating the suitability of the system for its requirements. While some in-depth information is essential to analyse the product and the vendor, we believe that unnecessary information simply increases the complexity of the process. Banks often forget that somebody with the right breath and depth of knowledge needs to read and analyse all the responses to an RFI or RFP. For a vendor providing this extent of information, it usually becomes an unwarranted exercise. For this reason, we believe that banks should ask for only relevant detailed information. In-depth critical information gained through a few questions may be more useful than a “laundry list” of non-essential information.

What follows is a sample of the table of contents of an average RFP. Often, the RFP is accompanied by a worksheet that requires vendors to provide information on 800-900 parameters which include vendor profi le, technology, product, customer information system, general information, security, and loan and deposit system information. However, as this worksheet is very extensive and specifi c to each bank’s requirements, we are not providing a sample of it in our report.

Table of contents A. Introduction

1 Bank profi le1.1 Vision1.2 Mission1.3 History and background

2 Bank products and services3 Purpose4 Eligibility requirements

4.1 Eligible vendors4.2 Eligible products and services4.3 Cost of this request for proposal

5 Defi nition of terms

B. Request for Proposal (RFP) Process

1 RFP contact details2 Overview of the RFPprocess and schedule

2.1 RFP process2.2 RFP schedule

3 RFP documents3.1 Clarifi cation of RFP documents3.2 Pre-submission conference

4 Vendor proposal preparation4.1 Language4.2 Statement of compliance4.3 Vendor proposal conditions4.4 Vendor proposal validity4.5 Format, signing and packaging of vendor proposal4.6 Pricing4.7 Payment terms and conditions

5 Submission of the vendor proposal5.1 Sealing of the vendor proposals5.2 Reserved rights

6 Vendor proposal Evaluation6.1 Confi dentiality of the evaluation process6.2 Clarifi cation of vendor proposal6.3 Examination of vendor proposal and determination of

responsiveness


Average Request for Proposal


6.4 Evaluation methodology6.5 Bank’s right to accept or refuse any vendor proposal

7 Award of contract7.1 Post-qualifi cation7.2 Award criteria7.3 Reserved rights7.4 Notifi cation of award7.5 Signing of the contract7.6 Performance security7.7 Corrupt or fraudulent practices

C. Commercial Terms and Conditions

1 Standard terms and conditions2 Other terms and conditions

2.1 Responsibility2.2 Delivery2.3 Storage2.4 Transportation, marking, labeling, packing and shipment2.5 Transfer of risk and title

D Background and Vendor Proposal Requirements

1 Background and vendor proposal requirement1.1 Background1.2 Overview and scope1.3 Architecture1.4 System demonstration requirements1.5 Reference site visit requirements1.6 Pilot testing requirements

2 Implementation plan3 Maintenance and support4 Vendor’s expectations from bank

E. Financial Vendor Proposal Requirements

1 Overview2 Price3 Payment terms and conditions

3.1 Payment milestones


3.2 Payment due dates3.3 Payment conditions

F. Statement of Compliance (Requirements Matrix)

1 Answering the requirements matrix2 Requirements matrix3 Executive summary

3.1 Instructions3.2 Summary of technical proposal

4 Organization and support5 Application and support6 General features7 Business requirement

7.1 Customer information system7.2 Savings and time deposits system7.3 Checking deposits system7.4 Loans system7.5 General ledger system7.6 Branch automation system

8 System demonstration requirements9 Reference site visit requirements10 Pilot testing requirements11 Implementation plan

11.1 Implementation approach and methodology11.2 Scope of work11.3 Implementation schedule11.4 Implementation personnel

12 Maintenance and support13 Vendor’s expectations from bank14 Appendices

G. Attachments

1 Glossary of terms2 RFP forms

2.1 Performance security3 Standard terms and conditions

