Asian Banker - Core Banking Replacement

8/10/2019 Asian Banker - Core Banking Replacement

http://slidepdf.com/reader/full/asian-banker-core-banking-replacement 1/173

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

Management Report:

Roadmap to SuccessfulCore Banking System Replacement

Critical Success Factor s and Best Practices



Neeti Aggarwal, CFA

Published September 2006©2006 The Asian Banker

Management Report:

Roadmap to Successful

Core Banking System ReplacementCritical Success Factors and Best Practices



IMPORTANT NOTICE Although 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.

PORTANT NOTICE



ABOUT THE ASIAN BANKER Asia’s financial service landscape is undergoing tremendous change and evolution.Liberalisation, consolidation and rapid technological advances have opened uptremendous opportunities for financial institutions and, it is vital for banks to benchmarkthemselves against their competitors and to keep abreast of global developments.

Decision-makers need accurate, incisive, timely and continuous information to bring theirorganisation to the next level, meet competitive challenges successfully and managetheir own future. The Asian Banker has long recognised the importance of information asa 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:

As ian Banker Research: current , cont inuous and in-depth research on bestpractices and market developments and trends

Proprietary & generic research services

Subscription-based research support services for different programs

As ian Banker Publicat ions: incisive news and in formation on transformationalissues

The Asian Banker Journal

Asian Banker E-newsletters on different segments in the financial services industrysuch as operations & technology, wealth management, CRM, retail distribution and

payment systems amongst others Annual Publication: The CEO Collection; The Asian Banker 300 Banks Ranking

Special Reports on M&A; Internet Banking; Payments Systems; Retail Banking;CRM; Risk Management; Wealth Management and Operations & Technology

As ian Banker Forums: exc lusive gather ing of industry leaders and sen ior dec is ionmakers to network and exchange information

Annual Major Conferences

The Asian Banker Summit

The Future of Banking in China

Asia Pacific Heads of Retail Banking Annual Meeting

China International Risk Convention (CIRC)

Roundtable Series / Consultative Forums

Wealth Management Advisory Forum

Consumer Credit Advisory Forum

Risk Advisory Forum

Industry Briefings

Contact:

THE ASIAN BANKER

10 Hoe Chiang Road#14-06 Keppel Tower Singapore 0899315Tel: (65) 6236 6500Fax: (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 financial 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 financial services consulting. His

consulting assignments constitute a highly diversified portfolio that includes some of

the largest commercial banks in Asia.

CKNOWLEDGEMENT



Core BankingTransformationCritical Success Factors and Best Practices

Table of Contents

1. Core Banking Trends in Asia Pacific

Market Trends

1.1 Prominent recent deals in the region

1.2 Geographic dispersion of deals in recent years and 2006

estimates

1.3 Activity within countries and their vendor preferences

1.4 Estimates of system and software spending in Asia

Pacific

Technical Trends

1.5 Evolution and convergence of core banking systems

1.6 Technology integration in Asian countries

1.7 Trends in platform usage among Asian countries

1.8 Trends in deployment approach

2. 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 selection

2.3 UNIX versus mainframe – survey results on

considerations in system selection

3. Core Banking System – An Overview

3.1 Core banking system – an introduction and definition

3.1.1 Definition of core banking system

3.1.2 What to expect in core banking replacement



3.1.3 Rationale for front-end systems replacement

3.2 Overview of the core banking system replacement

project

3.3 Approaches to replacement

4. Phases of Core Banking Replacement and Critical

Considerations

4.1 Phases of core banking replacement – an overview

4.2 Timeline of replacement project stages

4.3 Phase 1 – Business justification and blueprint

4.3.1 Developing business objectives

4.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 selection

4.4.4 The right architecture and platform

4.4.5 Selection process

4.5 Phase 3 – Implementation

4.5.1 Key challenges and critical success factors

4.5.2 Implementation process

4.6 Phase 4 – Deployment

4.6.1 Deployment process

4.6.2 Deployment approaches

4.7 Risk mitigation

4.8 Financial implications

5. Core Banking Replacement Building Blocks

5.1 Application architecture and core banking

5.1.1 Key issues

5.1.2 Deployment strategy

5.2 Service oriented architecture

5.3 Interface considerations

5.4 Coexistence

ble of Con tents

2 Asian Banker Research Report



Table of Con tents

5.4.1 Branches

5.4.2 Call centres

5.4.3 ATM transactions

5.4.4 Other online interfaces

5.4.5 Batch interfaces – inward clearing

5.4.6 Batch interfaces – outward clearing

5.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 Practices

6.1 Project organisation and programme management

6.1.1 Stage 1 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 Considerations

7.1 A large multinational bank

7.2 A small commercial bank

7.3 An Islamic bank

7.4 “Internet only” banks

7.5 Mergers and acquisitions of banks

8. Country Trend Analyses

8.1 India

8.2 China

8.3 Japan, Korea and Taiwan

Asian Banker Research Report 3



8.4 South East Asia – Indonesia, Malaysia, Thailand and

Singapore

9. Vendor Assessment

9.1 Vendor and product assessment

9.2 Market positioning

10. Conclusions10.1 Conclusion 1 – for bankers

10.2 Conclusion 2 – for vendors

A1. Appendix I – Case Studies

A1.1. State bank of India

A1.2 Union bank of Philippines

A1. Appendix II – An Average Request for Proposal


ble of Con tents



Executive Summary

Increasing consumer demands, high costs and widespread dissatisfaction

with ageing systems are making it increasingly dif ficult 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 finding 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 financial institutions are shackled

by a series of heavily siloed non-integrated back-of fice 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 financial 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 first time) new core banking

systems and upgrade themselves technically to improve product innovation,

agility in decision making and cost effectiveness. We expect the Asia-widetrend 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 first-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 ef ficiencies. 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 definition of the core banking system. We define it as a

highly ef ficient “customer accounting” and transaction processing engine, for

high volumes of back-of fice transactions and customer-level accounting and

reporting of the deposit and loan products processed in the bank. Howeverit does not include the front of fice. Thus we believe that the bank has to

first determine whether it really needs to replace its core system or it can

manage with just front-of fice 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 first phase is business justification and identification of business

requirements through delta analysis. We believe that the bank should, first

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 deficiencies

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 financial justification for the project at this


ecut 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 andfinancials

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 flexibility 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 userfriendly 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

flexible architecture that has the ability to support the business ambitions of

the bank and allows for future modifications 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 flexible and easily upgradeable infrastructure. We advise banks to look

for a system that has the flexibility 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 financial 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 flexible 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 first time and whose transaction volumes are not very high), a UNIX-

based system could meet their requirements. As more than 50% of the dealsin 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 configuration 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 essentialas 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

ef ficacy 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 final phase of the project is deployment. This is probably the

most critical and challenging stage, where the bank undertakes the actual


ecut 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 fit 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 significant 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 predefine the milestones at each stage of the

replacement process and ensure they are adhered to. At any stage, if the

bank finds 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.


ecut 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 issuesranging from pattern in deals, replacement approach, platformselection, implementation and key architectural trends. The aimis to learn from recent decisions and understand the marketdynamics 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 Pacific

Technical 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



1.1 Prominent Recent Deals in theRegion

Major Asian Core Banking Deals in Last two Years

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

Analysing the recent decisions, we noticed three significant trends.Firstly, more than 50% of banks that decided to replace their corebanking 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 increasinglyfavouring the UNIX platform. Part of the reason for this observation isthat most of the recent deals came from small banks, for which the UNIXplatform is more feasible. Thirdly, no vendor dominates the region, but Asian service providers have been given preference by banks whilevendors with strongholds in Europe and the United States find it dif ficultto develop a solid position here.

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

•

•

•

Market Trends


re banking Trends in Asia Pacif ic



No vendor dominates the country but Infosys and TCS have taken a fairshare of the pie. There has been a distinct preference for local vendorsas they offer international-quality products and yet understand the uniqueIndian requirements.

Leading Vendors in Asian Countries in Last two Years

In China, SAP clinched the core banking systems deal awarded by ChinaMinsheng Bank, marking the entry of this global vendor in the region.Chinese banks are increasingly considering replacement; howeverfollowing implementation problems in a few Chinese banks, they arenow more cautious about taking the plunge. Taiwan banks did not enterinto a single deal in 2004 but showed sudden activity in 2005. I-flex hasemerged as the top vendor in this country.

The Philippines was rather subdued with just two deals in 2005 (ascompared with five deals in 2004) – both came from smaller banks andwere won by Nucleus Software. The last major deal in the Philippineswas that of Union Bank of Philippines which replaced its system withFinacle of Infosys. Malaysia, on the other hand, continued to witness aflurry of activity with many small banks upgrading their ageing systemsprimarily through local vendors.

Internationally, one of the biggest deals in the past year was for HSBC’sglobal operations, which was won by Temenos. The bank is understoodto 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 marketcontinued to be active in 2005

No vendor emerges as aclear leader in Asian region,but some vendors havehigher market share in certain

countries


Core banking Trends in Asia Pacif ic



private banks in the country has forced most state-owned banks tosubstitute (and in most cases acquire for the first time) a centralised corebanking system to improve their competitiveness and retain their marketshare. However we expect the trend to slow down in the next couple ofyears as most leading banks have already entered into core bankingdeals. A few banks that have not yet upgraded their systems are findingit increasingly dif ficult to compete and are currently evaluating availableproducts and vendors.

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

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

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

•

•

•





1.3 Activity Within Countries andTheir Vendor Preferences

Activi ty in Banking Sectors for Core Bank ing Replacement in Last two Years

05 10 15 20 25 30

Vendor

Preference

InternationalVendors

Local

Vendors

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

South

Korea

Taiwan

Vietnam

Philippines

Thailand

India

Malaysia

Indonesia

China Legend

Source: Asian Banker Research

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

We believe that almost 25% of the Indian banking sector has enteredinto core banking replacement deals in the last two years. In absoluteterms, the number is far higher than that of any other country – though

as a percentage of the whole sector, it may not be as significant. Mostbanks in this country have preferred local vendors owing to not just the

international level of expertise and reputation of the vendors but alsotheir higher level of trust in them. Contributing to this is also the fact thatmany Indian vendors have advanced in these last few years to becomesome of the leading vendors in the world.

Interestingly, the banking sectors of Thailand and Korea saw no newdeals in 2005 despite being active in 2004. However there was increasedactivity in Taiwan and China. Increasing competition from foreign banksin these countries is forcing banks to evaluate their core bankingreplacement needs. We believe the core banking transformation in these

countries is set to accelerate over the next few years.

•

•

Market Trends

Indian banks have favouredtechnical advancement throughlocal vendors

Other Asian countries expectedto continue to show demand forcore banking transformation





Most Chinese banks have shown a strong preference for systemsthat are designed to suit their specific and unique requirements. Forthis reason, smaller Chinese banks have preferred domestic vendorswhile larger banks have preferred international vendors that can meettheir local needs. Similarly, many Malaysian banks have preferred localvendors that can meet their Islamic banking requirements.

Banks from developed markets like Singapore and Hong Kong havefirst-generation technical sophistication and are undertaking a cyclicalreplacement of their ageing systems. In contrast, banks in countries likeIndia, Pakistan and Vietnam are purchasing core banking systems forthe first time now. For obvious reasons, activity among the banks thatlack technical sophistication will increase.

We believe that most Asian banks prefer to select vendors that eitherinvolve local people through a setup in their country or partner localvendors. This is because there is a perception among the bankers thata local is more likely to understand and adapt to the unique local needsof a particular country. However in many countries, the availability ofinternational-quality products from local vendors is a limiting factor whichhas forced banks to look for alternatives.

•

•

•

China banks have preferencefor systems that cater to theirunique needs





1.4 Estimates of System andSoftware Spending in AsiaPacifi c

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

800

600

1,000

400

200

0.14

2004 2005 2006f 2007f 0

(%)($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 suchas licence fees and the service cost. It includes only core banking systemsreplacement by banks and excludes other system applications such astreasury and trade processing.

We have discovered that the cost structure of core banking deals variesconsiderably due to multiple factors such as the scale and complexity of

the replacement process. However, generally, we believe that the totalinvestment required to purchase core banking systems is made up ofsoftware and service cost which constitutes 30%, system integrationcost of 20-25% and hardware and infrastructure cost of 45-50%.

Based on our analysis of recent deals, the system and service cost fora small bank (with a size of $1 billion or less) comes to $5 million-10million. 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 sizeis likely to be higher depending on the extent of transformation beingundertaken.

•

•

Market Trends

Steady increase in spendinglikely to continue; no significant jump expected in near future

Deal sizes have varied fromabout $5 million for small banksto more than $50 million forlarge wholesale banks





A critical cost item is system software cost; this includes the cost ofsoftware licences, which varies depending on project. For example, forFNS 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, asa percentage of total revenue, we believe the investments are likely toshow a declining trend as the banks have witnessed even higher growthin revenue. We also believe that there is stiff price competition amongvendors and that this will keep the costs in core banking replacementunder control.

•

•





1.5 Evolution and Convergence ofCore Banking Systems

Evolution of Core Banking Systems

Business PlatformJ2EE, .NET

EAI, BPM, WS

Parameterisation

Legacy

systems

1970 1990 2004 2005

Web XML Web services Serv ice-oriented architecture?

China Bank:

Kirchman

ICICI: Finacle

HDFC: I-flex for

retail

KDB: FNS

Banco de Oro:

ICBS

Chinatrust:

FNS

HDFC: I-flex for

corporate

OCBC: Silverlake

StanChart:

testing open

sys

Kasikorn: 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

Mainframe

systems

UNIX

systems

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

Towards

core banking

systems today


The first generation of banking technology was represented by the IBMmainframe, which had immense data processing capabilities but was not

as ef ficient in back-of fice accounting functions. Nonetheless its reliability

•

Technical Trends

Evolution of core bankingindustry in Asia showsincreasing convergence of

technologies and focus onarchitecture of systems





and scalability remain unbeaten today. In the next stage of evolution cameparameterisation of processing rules and enhancement in automationfrom back- to front-of fices. Here, the UNIX platform solutions haveshown high functionality, with some of them using relational databasetechnology to maintain accounting and administrative data.

UNIX systems have borrowed ideas freely from mainframes suchas logical partitioning, the ability for isolation, the ability to shareacross partitions, and common interfaces. Integration tools and othertechnological advancements have brought about a certain level ofstandardisation and convergence of technologies today at the platform,application and architectural layers.

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

Trends in Requ irements

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

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

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

• Convergence of old and new technology with increased scalabilityand flexibility


Service Oriented Architecture (SOA) is a relatively new concept thathas gained popularity quickly. Herein, business applications areconstructed from independent reusable interoperable services that canbe reconfigured without a vast amount of technical labour. The conceptis based on web services and components that are brought together toperform specific business tasks. It essentially means reducing barriers inantiquated infrastructure and creating a real-time integration of disparatesystems and a sharing of databases on a flexible and easily upgradeableinfrastructure. 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 flexible

•

•

•

•

Banks need to adopt ServiceOriented Architecture





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

The key attributes that banks require from their architecture are flexibility,scalability and agility. With customer expectations increasing, banks havemoved towards centralised systems with customer-centric architecture,where they drive the business through a single view of the customer andthe 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 serviceproviders leading to increased product offerings and pricecompetition.


The growth in demand for core banking systems in Asia Pacific hasprompted many international vendors such as SAP, Temenos, Fidelity

and Misys to focus increasingly on the region. At the same time, vendorsthat began their operations in Asian countries have grown to becomerecognised names across the world; these include companies likeInfosys, I-flex and TCS.

Desire to become the leading player in the market has led to mergersand acquisitions among IT service providers. At the global level, Fidelity’sacquisition of Sanchez broadened its reach to a larger collection ofbanks. Among leading vendors in Asia, TCS acquired FNS in a leap fromtheir previous alliance. Another example of consolidation in the industry

is Oracle’s acquisition of a stake in I-flex. These players are developingan increasingly strong foothold in the core banking systems market.

Greater convergence makes it dif ficult for bankers to differentiatebetween vendors’ value propositions. However standard protocols andfierce competition have led to more product offerings and price wars – aboon for the industry as a whole.

•

•

•

•

Asian vendors are increasingtheir global reach

Desire to become leadingplayer has led to consolidationin the industry





1.6 Technology Integration in Asian Countries

Technology Integration in As ian Countries

‘ A c c o u n t c e n t r i c i t y ’

‘ C u s t o m e r c e n t r i c i t y ’

Thailand

India (State Banks)

Philippines

China

Malaysia

Indonesia

Hong Kong

Taiwan

Singapore

Aus tral ia

India (Private Banks)

Japan

Korea

B r a n

c h

c o m p u

t e r i s

a t i o n

B r a n

c h

n e t w

o r k i n

g

C e n t r a l i s

e d

d a t a

c e n t r e

C o r e

b a n k

i n g s y s t e m s

a d v a n c

e m e n t

R o b u

s t m i d d l e w

a r e

a n d b

a s i c C R

M

W e b s

e r v i c

e s a n d

c u s t o

m e r

c e n t r i c

i t y


We tracked the technical advancement of banking sectors andarchitectures in several Asian countries. We discovered that theintegration of technology and the movement from account centricity tocustomer centricity have varied significantly among Asian countries.Developed countries such as Japan, Singapore, Hong Kong and Australiahave shown distinct technical advancement not only on the core bankingfront but also in their banking systems architecture, achieving customercentricity through integration.

On the other hand, developing countries like China, Thailand, Philippines,Indonesia and Malaysia are far behind. These countries are now movingtowards 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 toexpedite this process.

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

•

•

•

Technical Trends

Developed countries haveshown distinct technicaladvancement





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, stabilityand scalability of these systems have been proven over the years andcontinue to attract these banks. But in the last five years, market dynamicshave changed considerably and banks are increasingly considering theUNIX-based systems.

The shift in preference has been brought about by competitive pressuresin the market which have forced banks to look for systems that can meettheir functional requirements with flexibility and agility. Acceleratingthe trend is the fact that most Asian banks are smaller compared withmany European and multinational banks and hence UNIX systems areconsidered adequate for their scalability requirements. Another majorfactor that draws many bankers to UNIX is the cost savings. Changes inregulatory requirements (under Basel II) have also forced banks to lookfor an integrated and flexible system.

For these reasons, we have seen an increasing shift among Koreanand 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 beprimarily mainframe users butthere is a strong shift in favourof UNIX systems

Competitive pressures and costeffectiveness of UNIX-basedsystems are driving the shift





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

In the Indian subcontinent, most commercial banks are adoptingcore banking systems for the first time. Thus most banks have takenadvantage of this new-generation technology. As there is no problemof integrating with the existing system, implementation is cheaper andless complex. Moreover, the traditional preference of Indian banks (andIndian vendors) is for a UNIX environment.

While smaller Asian banks have favoured UNIX-based systems owingto their cost effectiveness, we believe that mainframe has proved to bemore reliable and scalable for a larger size of operations. As transactionvolumes 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

Long

Duration

Existing

Implementation

Time

Short

Duration

Gradual Implementation Big Bang Implementation

Implementation

App roac h

Singapore

HSBCBank

ChinaMinsheng

Bank

CentralBank of

India

AllahabadBank

MuslimCommercial

Bank

Bank ofPanshin

UnionBank of

Philippines

Bank of East Asia

Hua XiaBank

IndustrialBank ofKorea

CathayUnitedBank

StateBank of India

DBSBank

ChinaDevelopment-

Bank

Bank Asset Size

More than$100 billion

$20-100 billion

Less than$20 billion


The banks have two options in deployment. “Big Bang” implementationlargely involves a new system which goes live at the same time thatall the processes are shifted onto it. This is believed to be the quickestbut probably also the riskiest way to deploy the project. While therisks are high, the integration problems are minimised as old and newsystems do not coexist. A phased approach, on the other hand, involvesgradual deployment across branches/functions generally through “bigbang” in small clusters. Here, the banks have to face the sticky issue ofcoexistence of two systems.

Our research shows that in Asia Pacific, the traditional phased deploymentapproach is distinctly preferred for its reduced risks and gradual changein processes. Though the choice of approach varies with banks’ uniquerequirements, top-tier banks in general have preferred the gradualapproach. This is because their scale of operation makes “big bang” notonly extremely dif ficult but in some cases also unfeasible.

Most banks with an asset size greater than $100 billion have preferredphased deployment and the time required has stretched over manyyears. For example, it is expected to take about five 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 prefergradual deployment while somesmaller banks choose “bigbang” approach





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

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

•





2Bankers’ PerceptionSurvey on CoreBanking SystemSelectionWe have conducted a series of surveys in the Asian banking

sector to strengthen our research on various aspects of corebanking 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 SystemSelection

2.1 Survey results on key reasons for replacement

2.2 Survey results on factors considered in system selection

2.3 UNIX versus mainframe – survey results on considerations in

system selection



2.1 Survey Results on KeyReasons 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 Pacific countries last year found that inflexibility,

high cost and dif ficulty of integration were the three main problems that

banks faced in legacy systems.

•


nker ’s Perception Survey



2.3 UNIX Versus Mainframe – Survey Results onConsiderations in SystemSelection

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

Old

Archit ecture More Vendorsvs Monopoly

Scalability App lication

Avai labi lit yInstability

42

32

21

37

47

37

115

MAINFRAME SYSTEMS UNIX SYSTEMS

Avai labi lit y of

Internal Skills

Many banks in Korea and Japan

use internal programmers to

customise their systems.

Total Cost of

Ownership

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 sawas the strengths and weaknesses of UNIX and mainframe systems. Wefound that while there are an increasing number of banks favouring UNIXsystems due to low cost of ownership, scalability and recent technicaladvancements, stability is still perceived to be the biggest strength ofmainframe 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, “Whenwe purchase a UNIX system, we enter a buyers market as there aremany products available and we can choose. But when we purchasemainframe, we enter a sellers market and may have to wait.” Anotherbanker feels that while UNIX technology is improving, it may not matchthe scalability of mainframes yet.

Banks that have invested in their system are aware that a considerableamount of time, money and effort is involved in customising and adaptingthese systems. Replacing these systems is a painful and risky exercise.However the fact remains that many of these legacy systems are unlikelyto 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 isin banking and not IT development.

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

While the debate over preferred technology continues, it goes withoutsaying that what may be considered suitable by one bank may not beappropriate for another bank. For example, big banks with an extensivescale of operation may find it risky to switch from mainframe systems toUNIX technology primarily because of complexities, high risks and hugecosts involved in the process. However a small bank which is building itscore 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 ofoperation 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 themarket

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


•

•


Banker ’s Perception Survey



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


Banker ’s Perception Survey



This page has been left intentionallly blank



3.1 Core Banking System – AnIntroduction 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 dif ficult 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 inflexibility demands lengthy

development cycles

No/Limited Basel II Support – New and more complex Basel II-drivenrisk 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 justification 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


ore Banking System Overview



Core Banking System Overview

“Our system will transform your organisation and make your bank more

competitive.”

“With our system, you will be able to significantly 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 reflect what their

clients can expect from a core banking replacement project?

To answer these questions, it is necessary to clearly define what a core

banking replacement really is

3.1.1 Definition of a core banking system

We have discovered that there are multiple definitions of core banking

systems today. However based on our discussions with industry experts,

we can define core banking, in simple terms, as a highly ef ficient “customer

accounting” and transaction processing engine for high volumes of back-

of fice transactions. The purpose of a core banking system is thus to

give banks the ability to process large transaction volumes in a fast and

ef ficient way; clearing, transfers and interest/fee calculation are all the

fortes of core banking. But let us explore this in more detail and look atsome 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

CoreBanki ng System

C h a n n e l I n t e g r a t i o n

A p p l i c a t i o n

I n t e g r a t i o n

R e p o r t i n 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-end

System

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 bankingreplacement 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 thenecessary 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 & Service

Delivery

Business

IntelligenceCore Systems

Delivery Channels

Application supporting the

bank’s delivery channels.

Integrates into the customer

relationship management

and core systems

Data Warehouse & Data Marts

Enterprise data warehouse

with relevant data marts

Relationship & Risk

Management Infrastructure

Common customer view and

central customer liability. “The

customer belongs to the bank”

and not a booking unit

Data Mining

Utilise existing information in

the data warehouse e.g. to find

customer behaviour pattern

Imaging and Workflow

Imaging and workflow

capabilities e.g. for the

commercial lending process

Middleware Infrastructure

Integration infrastructure to

link the bank’s systems. A

modern architecture is built

around an enterprise service

bus utilising an SOA

New Age Channels

Internet-based virtual

delivery channels, including

Web and WAP services

Customer Information

Repository

D a t a W a r e h o u s e

C h a n n e l I n t e g r a t i o n

P h y s i c a l

C h a n n e l s

V i r t u a l C h a n n e l s

Other Support Systems

Workflow ManagementDocument Imaging Capability

Core Banking

Dep osi ts L oan s

A p p l i c a t i o n I n t e g r a t i o n

C h a n n e l I n t e g r a t i o

n

R e p o r t i n g

Common Services


Source: Immacon Research

3.1.2 What to expect in core banking replacement

To start an effective core banking replacement programme, the bankmust 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 andfeatures. 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 replacement

To make matters more complicated, it is often important to also change

the front-end applications, to better reap the benefits 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 fasterimplementation 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 find it dif ficult 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 define 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, thisapproach requires experienced business process designers capable of

defining the future operating model of the bank.

Custom built solution: This approach requires technical and business

process designers capable of defining 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

benefits from core bankingreplacement





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-of fice 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 benefits 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 fit 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 BankingSystem Replacement Project

Core Banking System Replacement Project – an Overview

Reasons for

replacement

Gap analysis of

existing

infrastructure

Select right

platform

Select right

architecture

Evaluate

financial

impact

Risk-return

analysis

Select software

vendor and

integrator

Identify right

approach to

implementation

Project Stages

Development

of business

objectives

Selection of

approach

Development

of selection

criteria

Bidding

process

System

selection

Selection

of service

provider

Implementation

and launch

Ongoing

technical

support &

enhancement


Replacing or even upgrading the core banking system is a complexand 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 financial and business

justification 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 isalmost like a heart transplant

involving high cost, high risk,

and substantial effort and time





Core Banking Replacement Stages

Replacement Stages Through the Project

E f f i c i e n c y / P e r f o r m a n c e

Projectstart

Euphoric

"We will changethe world"

Disillusioned

"This is hard but we

have passed the

point 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"

Continuous

Improvements


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 Replacement Approaches to Core Bank ing System Replacement

In-house

development and

implementation

Purchase of system

software and

services

Complete

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 flexibility 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 financial

and human resources

Buy vs. Build





4Phases of Core BankingReplacement andCritical 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 corebanking system replacement project. Going further, we discussthe factors that we believe are essential ingredients for success.This section is targeted at both business decision-makers as wellas 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 justification and blueprint

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

4.4 Phase 2 – selection4.4.1 Reasons for replacement4.4.2 Considerations in determining selection criteria4.4.3 Key considerations in vendor selection4.4.4 The right architecture and platform4.4.5 Selection process

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

4.5.2 Implementation process4.6 Phase 4 – deployment

4.6.1 Deployment process4.6.2 Deployment approaches

4.7 Risk mitigation4.8 Financial implications



4.1 Phases of Core BankingReplacement – An Overview

In our analysis of best practices for core banking replacement, wehave identified four key phases required for a successful core bankingreplacement project, namely:

Core Banking Replacement Project Phases

Understand Business Imperatives

Achieve Consensus on BusinessDriver & Approach for Core

Banking Replacement

Define Core Banking

Transformation Strategy eg.

Replacement or Transformation

Develop “Delta” TransformationBlueprint

- 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

Business

Justification &Blueprint

Selection“Delta Driven”

ImplementationDeployment

4 - 6 Months 4 - 6 Months 18 - 24 MonthsDependent on Chosen

Deployment Approach

Source: Immacon SOBIT Methodology

The Business Justifi cation and Blueprint Phase sets the stage for thecore banking replacement project. During this phase, a bank takes stockof 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 andintegrators and decides on the vendor management approach. As aproject 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 hiredwill be the prime vendor.

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

•

•

•

•

We divide core banking

replacement into four phases


e Phases Of Core Banking Replacement



The Phases Of Core Banking Replacement

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

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

•




4.2 Timeline of ReplacementProject Stages

Core Banking Replacement Project Phases

Project Phases

Business

Justification &

BlueprintSelection

“Delta Driven”


4 - 6 Months 4 - 6 Months 18 - 24 MonthsDependent on Chosen

Deployment ApproachSource: Immacon SOBIT Methodology

As time management guru Alan Lakein has taught us, “failing to plan isplanning to fail”. Thus the first phase of the core banking replacementproject provides an overall plan for the initiative. It is important for businessdecision-markers to agree on the business objectives and justificationfor the replacement, followed by detailed planning of what should beachieved with the new core banking solution. At this stage, we believethat it is also important to decide if the core banking replacement projectshould 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 24months from the time the bank acquires a solution to the commencementof deployment. Smaller banks using a proven solution with little or nocustomisation can of course expedite their schedule. The chart below showsan 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

Asses s Curr ent Oper ation s

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

Phase

4 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 changemanagement and business transformation efforts.

The selection timeframe is dependent on the number of vendors involvedand 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 – BusinessJustifi cation and Blueprint

4.3.1 Developing business objectives

Objective: Develop business objectives and establish the vision and justification for the target future state.

Core Banking Replacement Justifi cation & Blueprint Development

Sign Off

Understand

Business

Imperatives

Assess

Current

Operations

Blueprint &

Visualise the

Future

Operations

Prepare

Implementation

Blueprint

Develop

Business

Justification

Business




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 andreal-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 flexiblesystems to meet the requirements of banking industry today, we believethat each bank needs to initiate the process by developing clear businessgoals and objectives of core banking replacement to meet its own uniquerequirements. These objectives would facilitate involvement of businessinto the project (which would otherwise have the risk of being seen as anIT project) and also would give clear directions to the selection process.

Assessing business demand, future business directions and anticipatingfuture requirements would ensure that the bank can suitably select the

system that can meet its expectations. The ability of ageing IT systemshas become limiting factor for ambitions of future growth. In many banksnumerous back processes are as a consequence of maturity of a 10-15year old system. New systems are now required to provide considerablesynergies and ef ficiencies towards meeting long term targets.

While the broad requirements from the system functionality would besimilar for most banks, unique requirements would vary. Improvingcompetitiveness and garnering market share is one common objectivecited 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. SimilarlyBanks in India and Pakistan may believe that product differentiationand service oriented features are more important to meet the needs ofgrowing middle class and maintaining competitiveness. For example ingrowing economies banks would rather grab a larger chunk of marketshare than just riding on growth. These unique needs should guide thebank in developing its long term strategic objectives.

These Business objectives should in turn act as key guiding factor inestablishing selection criteria. These should be forward looking to ensure

suitability of the new system in long term as a bank replaces its systemonce in 10-15 years. Nonetheless in today’s fast paced environment it isextremely dif ficult for one to judge what the face of market would be afterfew years and hence the bank has to ensure flexibility in the system.

4.3.2 Delta methodology – assessing future requirements

Our research into replacement case studies shows that it is imperativefor banks to take stock of their current operations in the “old world”environment, and comprehend the technology infrastructure andshortcomings. Thereafter, the banks should understand their currentbusiness 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 unexpecteddelays in implementation and incremental changes in the project.

For this reason, we believe that banks should form a clear understanding ofthe target “new world” and use this to develop a Transformation Blueprintsupported by an Implementation Roadmap. One methodology that thebanks can use is delta analysis. Herein the blueprint and implementationroadmap should define the new world and how to get there, e.g. businessand technical architecture, technology platform, process transformation

and organisation alignment. The Delta Transformation Blueprint shouldbe complemented by a business case and/or a business justification, afinancial impact analysis and a visualisation of the new world.

The biggest challenge a bank is likely to face in the Delta approach isthe scarcity of experienced resources. This approach requires seasonedbanking practitioners with the ability to deal with a clean-slate approach,a good business appreciation of technology and the ability to switchcomfortably 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

Source: Imma con SOBIT Methodology

•

•

•





Delta Analysis

Old World

Old Core Banking

Systems

AS 400

UNIX

Mainframe

New World

New Core Banking

Systems

New

Core Banking

System

The Delta not “ A Gap” w ill driv e the development of the Delta Definiti on Documents

SOBIT Core Banking Implementation Methodology

Reporting

Local Practices

Policies & Procedures

Products

Processes

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

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

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

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

Delta

Analysis

Key Concept 2:

Delta Analysis

Moving Towards A “Legacy

Free” New World


Go / No Go Milestones

DesignGo /NoGo

DesignSign-Off

PilotGo /NoGo

DeploymentGo /NoGo

Milestone:Next phase will be kicked

off once previous phase’ssign-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 Implementation

Pilot

Phase 4: Deployment

Training

Logistics

Phase

Project will stop untilmilestone is signed off

Go / No Go Decision

Milestones

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 seenare driven by clear business objectives, a strong business justification,





a blueprint for the future and a roadmap on how to reach the target – all developed in the first phase of the project. This is followed by aninitial delta analysis in the selection and implementation phases of theproject and the conscious sign-off of project-embedded milestones ineach phase. If one of these milestones is not signed off, the projectstops. This disciplined approach can save the bank a lot of money andagony.

• Key activities to consider for the business justification stage of the project

are:Define the business objectives and desired outcome of the project

Assess the current operations and existing IT infrastructure against thebusiness objectives

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

Define the implementation approach and timeline to achieve the futurestate

Formalise the business justification for the future state

-

-

-

-

-

Delta methodology would

facilitate business justification





4.4 Phase 2 – SelectionCritical Considerations in the Selection Process

Considerlong-term strategic

goals of the bank

Develop arating system

detailed toprovide

objective &

subjectiveassessment

Invite bids fromvendors that

have strongexperience in

similar projects,

reputation andtrack record

Eliminate theproducts and

vendors that donot meet the

essential

criteria

Final selectionshould

comprisedetailed

analysis of

vendor and itspartners in the

project

Financialassessment is

important butdecision should

be based on

product andvendor

capability

Project Stages

Identify key

deliverables to

meet long-term

needs

Develop

selection

matrix. Identify

‘Go’ / ‘No Go’

criteria

Develop

Request for

Proposal and

invite bids

Initial filter to

eliminate

unsuitable

vendors

Invite

presentation

from

short-listed

vendors

Financial

assessment

and final

selection


4.4.1 Reasons for replacement

Key Demands from New Systems

Problems with legacy system Demands for new system

Flexible, scalable

Component-based architecture

Competitive edge

Customer-centric with single

view of customer

Easy information access

Higher efficiency

STP ability

Product differentiation easy

Lower operational and

maintenance 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 lacking

information accessibility



Identifying the critical currentand future needs to be met by

new system




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

Widespread dissatisfaction with ageing, expensive and inflexibletechnology is one of the prime reasons for change. In countries like Indiawhere private sector banks boast technically advanced systems, it hasbecome imperative for public sector banks to replace their systems as wellto 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. Theoperational and maintenance costs are steep and available manpowerfor maintaining them is dwindling. According to one vendor, ”Just keepingthese systems running can often consume more than 70% of the ITbudget, leaving little money to gain advantage over competitors.”

While these systems have been stable, they are highly inflexible andhence largely unsuitable in today’s competitive environment. Many ofthese systems were implemented at a time when banks did not engagein fee-based transactions. Rather than being customer centric, they arelargely account centric.

Branches need excess staff to maintain systems and back-of fice 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 havealso forced banks to look for alternatives to legacy systems.

Information in many of the legacy systems is stored in independentsilos. This makes gaining insight into customer needs and integratingcustomer information across functions extremely dif ficult, as these involvethe collation of a large amount of data from disparate systems held indifferent formats. For example, in legacy systems, a credit card divisionmay not know about the customer’s savings account. The banks that stillhave no centralised customer-centric system are realising it is essentialto acquire one as this would provide them with a single customer viewand easily accessible and deployable real-time information, therebyimproving the banks’ ef ficiency across functions.

The aim is now to eliminate duplicate systems, integrate legacy andsub- systems with middleware, install and integrate databases and addapplications. The banks need to adopt scalable and flexible systemswhich can meet multi-channel delivery requirements, can integrateinformation and processes across the organisation, are easy to upgradeand can adapt to changes. This is essential to meet consumer demandsand 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 criteria

Focus of Banks with Regard to Selection Criteria

54

3

21

Business Direction/Goals

Scale and Complexity of

Operations

Product Features

Cost/Financial ImpactBusiness 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 financials of the organisation but even its viabilityand competitiveness. Therefore it is essential that banks select thesystem that provides the right components and architecture to meet theirobjectives.

The architectural components that can meet the functional requirementsof the bank, given its business goals, must first be mapped out. Thiswould also determine whether the bank should replace the core bankingsystem in a few functional segments (or geographic locations) or go fora complete replacement, and whether it needs to replace just the corebanking system or the front end and GL as well.

We believe existing system and technical capabilities would be a decisivefactor in evaluating whether to upgrade the existing system or replace.Gap analysis for features such as scalability, flexibility, availability ofhuman resource, costs and processes of the existing system woulddetermine the technical capabilities and type of architecture requiredof a new system. Integration of the new and existing systems withinthe bank and the problems therein would also determine the systemarchitecture required and the risks involved in the change process.

The complexity and scale of the bank’s operations would shape itsscalability and flexibility 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 developselection criteria based on

its unique requirements and

business objectives





and scalability. Multi-channel delivery, high transaction volume and usercompatibility with lower downtime would be critical considerations. Asmall bank, on the other hand, may prefer a UNIX solution because ofavailability, flexibility and agility.

Finally, the right technology should come at the right price. Cost andfinancial impact are critical inputs in system selection. Most systemsrequire heavy investments but these ideally should translate into costssavings and revenue growth in the long term. For a smaller bank withlimited 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

54

3

21

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. Mostbanks see a core banking project as a highly risky proposition, so theywould invariably like to partner a vendor whom they can trust and believeto have the ability to handle a project of that size and nature. The vendorsare generally solution providers and, in most cases, service providerswho implement the solution within the banks. The two often join handswith a hardware supplier to form a consortium to bid for the project.Where there are multiple vendors, banks need to decide who would bethe prime vendor.

The evaluation of vendors involves multiple assessment criteria, foremostbeing delivery track record, financial viability, technical capability, product

features and cost.

•

•

•

Critical considerations in

assessing IT service providers

Evaluating vendor track recordand financial 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 themwith the right product and service mix. There are relatively few vendorsthat have successfully completed core banking projects of the size andcomplexity of tier 1 banks. But for tier 2 and tier 3 markets, there ismore competition. The IT partners’ track record and reputation should beevaluated 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 financial strength (to ensure long-term

viability), ability to continually upgrade products and track record in post-implementation services are critical factors for lasting success. Investinga huge amount of resources on a product is useless if the vendor whoprovided it is no longer around to service it a few years later.

The alliances and relationships between the IT partners are otherfactors that need to be considered. For example, State Bank of Indiaand Central Bank of India who both hired TCS as their system integratorwere provided with a system from FNS, now owned by TCS, andhardware from another vendor. The standing relationship between thesetwo companies was a definite plus in their favour.

4.4.4 The right architecture and platform

Critical Requirements from System Architecture

Flexible,

Scalable,

Stable

Modular,

Integration

Customer-

centric,

Single Viewof Customer

Straight

Through

Processing

Service

Oriented

Arc hit ectu re

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 specifically to suit their unique

•

•

•

•

Vital to assess vendor’s

financial 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 moreflexibility and scalability, similar to moving out of the confines of a smallbox. What they need to ensure is that the new system is not like a biggerbox which quickly becomes a constraint again in a few years’ time.

Flexibility – With a convergence of financial services and a highlycompetitive environment, banks need to display a high degree offlexibility, agility and ef ficiency in its processes and product andservice development. Whatever the platform and solution that a bankselects, it has to be flexible to meet the constantly changing bankingrequirements.

Scalability – Scalability is a particularly important factor for retailcommercial banking. A bank can expect healthy growth rates in thissegment of the market and must plan for an increase in transactionvolume. Another factor to consider is the bank’s strategy in terms ofproduct offerings and delivery channels.

Functional requirements – It is essential to have a comprehensive MIS(management information system) to cover all products, all customergroupings and all geographical locations. In addition are customised

requirements such as multi-channel, multi-time-zone and multilingualprocessing ability to meet the specific needs of a bank. However thebank has to determine which of these needs require changes in the frontend 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 affectingother parts, thereby enabling banks to easily change and enter intoparticular segments of operations. For long-term ef ficiency, banksneed to transcend relationships and dependencies across systems andbusiness units through integrated technology.

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

The architecture of the banking system should integrate the corebanking system such that there is customer centricity with a single viewof 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 technologyto organisation structure.

Business Process Modelling (BPM) is mainly a mechanism for theorchestration of processes, with its ability to precisely model andpossibly 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 onloosely coupled components which support generic services and arebased on web technology. In a core banking context, it means reducingbarriers in antiquated infrastructure and creating real-time integration ofdisparate systems and sharing of databases within a flexible and easilyupgradeable infrastructure.

Those components should be flexible so they can be reused or combinedto create new business functions both within and across enterprises.They should embody best practices and should enhance the bank’sability to outsource and extend processes to business partners. The

generic nature of the components means they are intended to traversesilos and departments, thereby facilitating the breakdown of barrierswhich only exist for historical, technical and antiquated organisationalreasons. We discuss SOA in more detail in section 5.

Selecting the Architecture

Most mainframe-based core banking solutions are designed for rawhorse power. The idea here is to support high transaction volumes.Core banking solutions built on other platforms are typically focusedon 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 beentouted to larger banks with some success.

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

were initially designed.

•

•

•

•

•

SOA critical for future flexibility





Selecting the Platform

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

The platform decision is critical as it can automatically exclude certainplatform-specific core banking systems. To the business user, this mayseem counterintuitive; after all, it is the core banking system we want toselect. However, as explained earlier, the functions and features of thecore banking system are not the sole determinants of the appropriatesolution. First, the solution must be able to handle the bank’s requirementsfor volume, availability, reliability, scalability, security, response timeand other non-functional qualities. For these, the choice of platform isparamount.

There are many aspects which should be considered in platform selection

for mission critical systems:

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

High availability – Using parallel sysplex or geographically dispersed

parallel sysplex, the mainframe is able to achieve availability of upto 99.999%. Alternative platforms should be measured against thisbenchmark. This will facilitate clear decision-making and buy-in of allstakeholders 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 froma single point instead of multiple systems and thus helps reduce thesecurity risk exposure. However, as the security infrastructure fornon-mainframe environments is constantly advancing, banks shouldconsider the available security components as part of the overall costof either platform option.

•

•

•

-

-

-





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

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

On the other hand, for small wholesale banks and banks that do nothave large transaction volumes, the UNIX platform could prove to beeffective. Given the technical advancement in UNIX systems in recentyears and the increased availability of UNIX hardware, software andtechnical 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 andtolerance for unplanned system downtimes once or twice a month, theprice-performance equation here makes the non-mainframe solutions aviable option.

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

4.4.5 The selection process

Objective: Select and acquire the enabling technology and serviceprovider.

-

•

•

•

Cost should not be driving

factor; identify what is mostsuitable 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

Conduct

Negotiation &

Contracting

Business




Project Stages

Source: Immacon SOBIT Methdology

Selection of the right core banking solution is critical for the success of aproject. We have seen retail banks selecting a wholesale core bankingsolution and wholesale banks selecting a core banking solution meantfor retail banks. We are also seeing more and more bankers attemptingto 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 atechnology solution. However we believe that business should have thefinal say on the solution, and the choice should be based on businessneeds and not technology considerations. It is also important during theselection process that IT first picks out proven core banking systemsand then considers their underlying technology platform, programminglanguage and tools, not in the reverse order. We believe that a failure todo 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 keptsimple, concise and open-ended. As the name implies, the objective ofthe RFI is to obtain information for deciding on the final shortlist to kickoff the Request for Proposal (RFP) process. If the RFI contains too muchdetail, it can render the RFP process obsolete and make the preliminaryanalysis in the RFI stage very laborious. As the bank has to analyseand weigh the RFI responses, it is important to keep the workload of thereviewer to a manageable level.

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

•

•

•

•





the future. The RFI process should focus on the essential requirementsfor the future, bearing in mind that quantity never replaces quality. At theend of the process, 2-3 finalists 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 thisstage, the choice of platform should already have been made. The RFPshould concentrate on the requirements for the new world, and shoulddemand full compliance with the bank’s visualisation or at least a briefdescription of what requirements cannot be met by the core banking

solution and for what reason. The RFP should not be sent to more thanthree vendors for a major component such as trade services, multi-channel delivery and core banking. By now, the bank should also havean understanding of how the selection would be conducted and know ifit is necessary to obtain a proof of concept. Ultimately, the key drivershere are cost and timing. Where a bank can afford the money and time,a pilot of the new solution is recommended. To achieve an objectiveassessment, many banks are using a scoring method to document andtabulate 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 facesis that they have to not only select the vendor but also justify why thisvendor was chosen over others. Hence, it is important to have a solidand transparent selection process in place. In addition, it is crucialthat the selection is conducted for “new world operation” and does notdegenerate into a selection of “the emperor’s new clothes”, e.g. wherelegacy operations are deployed with new technology. Our analysisshows that successful organisations avoid taking legacy baggage intothe new world.

Conduct negotiation and contracting – This stage is completed withan agreement on final pricing and contractual arrangement with the

vendor and service provider.

To summarise, the selection phase starts with gathering of informationand shortlisting of solutions for the subsequent RFP process. This allowsthe bank to refine its assumptions about the future-state vision based onfindings during the RFI process, and sets the stage for developing acomprehensive RFP for the shortlisted vendors. Upon receipt, the RFPresponses are evaluated as inputs for the selection of the final vendor.This whole process is completed with the conclusion of negotiations onpricing and contractual arrangement.

•

•

•

•





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

Key Challenges During Implementatio n

• 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 overruns


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 andknowledge of local business

• Select strong partners in implementing project


Core system replacement or even upgrading is a major challenge thatcan create disruption of service, customer dissatisfaction and employeedisappointment. Transition from one system involves not just technicalcomplexities but a plethora of unforeseen problems in areas such asmatching 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 thenew system. This includes the dif ficult task of data cleaning, as somedata may be very old and irrelevant. Mass migration requires largecapital investment and an implementation schedule stretching overseveral years. It also poses a significant risk of service interruption thatcan cause a dip in customer satisfaction.

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

For some projects, the coding of ageing systems may be unknown,making data migration and integration a rather dif ficult proposition.For example, when Korea Development Bank switched from an IBMsystem to an FNS system, it involved shifting to a totally new systemarchitecture. In other cases, the bank may be shifting to a new platformwhich 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 ofindividual banks is another critical area where things could easily gowrong and lead to an expectation/deliverable mismatch. While rollingout a time-consuming project, there may be developments in the marketor a realisation of the need for increased functionality which demandfurther customisation in the product. As the implementation period getsextended with these incremental changes, the project becomes morelikely to have cost overruns. This is where the sign-off at each stagewould 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 andcost overruns is essential. Motivation will decline while resistance willincrease day by day. Managing these emotions and ensuring that theproject is not viewed as just an IT project would be a big challenge.

The most critical success factor in implementation is thus to test atevery stage. Banks should develop pilot projects, divide large projectsinto phases, and conduct user acceptance tests or, rather, businessacceptance tests to ensure a match between deliverables andexpectations. 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 tosuccessful completion.

In addition, it is important to provide user training and manage resistanceto the change in processes that accompanies such a project. Thereshould be helpdesks ready to handle enquiries and complaints fromusers – which are likely to be plenty. Along with processes, the workculture would also have to be changed to ensure optimal returns fromthe project.

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

In many such projects, trained manpower for new systems may not bereadily available within the bank. It is for this reason that some bankshave resorted to outsourcing their manpower. But the banks need to

remember that a few experts with the right experience and knowledgemay prove to be more useful than an army of staff.

Finally the bank’s business environment, adaptability to changeand commitment to the project are vital for success not just duringimplementation but also during and after deployment. Vendors shouldensure that management is involved in the project from conception tillfinal deployment. We cannot stress enough the importance of strongmanagerial support and business ownership for a replacement projectwhich could go miles in motivating people in the organisation to achievesuccess.

4.5.2 Implementation process

Objective: Operationalise and pilot the transformed future state, includingtechnology, process and organisational change.

•

•

•

•





Core Banking Implementation Process

Sign Off

Delta AnalysisDetailed

Design

Build & TestPilot

Implementation

Business




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 fitthe organisation to the new System.

Identify Essential Modifications to

the new System - Every effort shouldbe made to avoid changes to the newSystem but rather to align thebusiness to the new system. Changesto the new Core Banking Systemshould be limited to those essential inorder to meet regulatoryrequirements.

Identify Integration Delta -Determine the interfaces, conversionmodules and coexistencedevelopment required to integrate thenew System into the bank’senvironment.

Business Realignment Design -Define the reengineered productsand services and businessprocesses aligned to the newSystem.

System Design - Prepare thedesign for system configuration.

Also design the unavoidablemodifications identified during theDelta Analysis.

Integration Design - Prepare thetechnical design for the Interfaces,

Data Conversion Modules andCoexistence Modules.

Business Realignment - Align thebank’s products and services to thenew System. Also align the bank’sprocesses and procedures to thenew System.

Configure & Customise -Configure the system as needed,effect the necessary changes to theorganisation, and make changes tothe system, where absolutelynecessary. In addition, the interfacesbetween the new System and the

many linked systems are created.

Testing - Perform various levels andtypes of testing to the new systemand processes etc. in preparationfor correct functioning in the liveenvironment.

Training Preparation - Preparetraining plan, materials and coursetrainers.

Pilot Preparation - Identify and

prepare the pilot site, train the pilotusers and conduct rehearsals toprepare for the actual cutover.

Pilot Go/No Go - Confirm thecompletion of Pilot Preparationactivities and readiness for cutoverof the new System to the Pilot

community.

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

Delta Analysis Report Design Specifications Applications Ready For Pilot Appli cations Ready For

Deployment


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

Delta Analysis – A delta analysis is the identification of differences (the“delta”) between the desired state and the selected package, and waysto resolve these differences. One objective of the delta analysis is toidentify the package modifications required to address country-specificregulatory requirements. The package modifications are necessary ifconfiguration through package-embedded parameters is not possible.For the remaining delta, there are a number of resolution optionsavailable, such as:

•

•Implementation process

involves delta analysis,

detailed designs and product

modification to meet the bank’s

requirements





a. No change / Out-of-the-box fits 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

Regulatory

Customisation

Core Package

Regulatory

Customisation

Core Package

Regulatory

Customisation

Core Package

Regulatory

Customisation

Core Package

Regulatory

Customisation

Core Package

Start :

Process / Appraisal

Identify Regulatory

RequirementsI de nt if y D el ta D el ta Resol ut io n

Option I:

No change /

Out of the box fits

Option II:

Rationalise

Process / Product

Option III:

Modify package

Customisation

Input on Package

Cost ImpactNo (should be included

in 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 Bank Product / Processto Match Package

Modify Package

DeltaRegulatory

Modifications

© Immacon SOBIT Methodology


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

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

Conduct a “solutioning” to determine the appropriate customisation orrefinements to suit the future state

Define and estimate interface, data conversion and coexistenceefforts

Typical deliverables of this task include: Delta Definition and Resolutions,Configuration Definition, Interface Definition, Data Conversion Definition

and Coexistence Definition

-

-

-





Detailed Design – A detailed design of the future solution is needed forthe subsequent Build & Test stage of the project. A detailed design doneright can save a bank a lot of time and money by avoiding unnecessaryrework and change requests. Many projects run into dif ficulties becausethe design is never stable. In those projects, coding starts even beforethe detailed design is approved. In our analysis, this is one of the majorcauses of project failure, i.e. the inability to complete and sign off detaileddesign documentation. The detailed design documentation shouldinclude 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 beexpanded and some of the recommended activities to consider are:

Prepare a detailed business design, including rationalised product andprocess designs.

Prepare a detailed system design for customisation and configurationof the selected solution.

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

Build & Test – The customisation and configuration of the selectedsolution begins here. At this stage, it is important to freeze the designand to apply a rigorous change management process to any unavoidablechanges. Hence, the sign-off of the detailed design documents of theprevious 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 responsiblefor “acceptance”. What the bank needs is a trained test team of, perhaps,

former users who understand and appreciate the need for thoroughtesting and know how to conduct systems testing. Generally the realend-user does not have these skills. Hence, we prefer to use the term“business acceptance testing” or “business solution testing” over “useracceptance testing” to avoid confusion.

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

Customise and configure 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 configure the interface, data conversion and coexistenceintegration components

Prepare and conduct system, operations and business solutiontesting

Pilot – A live pilot is the final “acceptance” test. No matter how hardwe try, we will never be able to fully recreate and test a system in alab environment. But during a live pilot, the system can truly be testedfor real-life usability. Of course, the pilot should be representative of

the bank’s core operations. We have seen projects with well-executedtesting run into trouble as the test and production environments weredifferent, and even in cases where the production environment itselfwas used for bank-wide testing by the actual end-users reposting realbusiness transactions prior to a big bang deployment. The lesson learnt:the final test is the live environment.

Our recommendation is to use a manageable mid-size branch for thepilot. The pilot should always include a month end, as most banks havespecial month-end processing which can cause a lot of disruption ina real-life operation if not managed appropriately. The pilot should be

used to assess the effectiveness and completeness of the end-usertraining and the new business processes and procedures, as well as thecustomers’ acceptance of the new products and new operation. It shouldalso be used to identify bugs and bottlenecks and ultimately to fine-tunethe applications before deployment on an enterprise-wide scale. Thisstage of the project will deliver a “future state new world operation” in alive environment. Recommended activities to consider for this stage ofthe project are:

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

Deploy, support and refine 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

ProductRationalisation

System Change

SystemCustomisation

SystemConfiguration

ConductGap

Analysis

Resolution

Business ChangeDelta Analysis

Configuration Analysis

Integration

Process

Rationalisation

PilotPlanning

Train Pilot Users& IT Ops

Pilot SitePreparation

Dress Rehearsal

ConvertPilot Data

Pilot End-userSupport

ApplicationSupport & Fixes

Pilot

3 PilotGo/No Go

Update ProcedureManual

Prepare User

Guides

LocalCustomisation

CoreCustomisation

SystemConfiguration

Interfaces

Data Conversion

Coexistence

Prepare Training Plan

Prepare TrainingMaterials

Train-the- Trainers

SystemIntegration

Testing

Operations Testing

BusinessSolution Testing

Business Build

System Build

Integration Build

TrainingPreparation

Testing

Product Designs

Process Designs

Local CustomisationDesigns

Core CustomisationDesigns

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: PilotImplementation

Phase 3:Build & Test

Phase 2:Design






4.6 Phase 4 – Deployment4.6.1 Deployment process

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

Core Banking Deployment

Sign Off

Business

Justification &Blueprint Selection

“Delta Driven”


Project Stages

TrainingChange

Mgmt &

Comm

Go Live Fine TuneLogistics


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

Logistics – Managing logistics is critical for the rollout of a new corebanking solution to the branch network. The logistics include rolloutsequence (where, when, how many), possible changes to branchlayout and bank image, and update and/or replacement of hardwareand infrastructure software. It also includes the planning and executionof training logistics for the enterprise-wide deployment. The bank may

need the hardware to rapidly build and dismantle mobile training branchenvironments for hands-on systems training.

Training – We have discovered that once the new core banking system isready for rollout, training is one of the most important activities requiredto successfully deploy the new world on an enterprise-wide scale. Todo this, the bank’s project team must fine-tune and update the trainingplans and materials taking into account the lessons learnt from the pilotdeployment.

Change management & communication – We have found in ourassessment 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 touchingevery level of the organisation, from the CEO to the end-user in thebranch. Successful change management for a project as complex,high risk and high profile as a core banking enabled transformation canultimately only be led by one person: the CEO. The chief executive issupported 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 leadsby example.

Communication of the change is divided into two parts: internal andexternal. Our analysis shows that the effectiveness of the communicationcan be significantly enhanced through the use of multimedia technology.Usage of these tools ensures consistency in the message and rapiddeployment to the enterprise and public alike. The bank will needdifferent communication programmes depending on the audience theywant to address.

Go live – We have seen that successful deployment is normally conductedthrough a carefully prepared rollout plan which clearly identifies the timing

and sequence of each task. The rollout is undertaken by specially trainedrollout teams which, among other things, conduct a “train the trainer”programme in their respective rollout clusters. A best practice analysis hasshown that it is more effective to train “key branch employees” as trainersfor their respective units, than make “external” trainers responsible forthe training deployment. This approach is an integral part of the changemanagement programme and fosters ownership and accountability.The employees are likely to pay more attention to the tasks if they knowthat they will have to train their peers and be accountable for all of thepredefined deployment activities.

The implementation teams are usually supported by a 24/7 central

command centre, which coordinates and directs all implementationactivities and has one or two rapid deployment teams available to bedispatched to support trouble spots. The drawback of this approach isthat banks will be required to do a lot of methodical planning, conductmassive training of key and branch employees and be held accountablefor the results.

Fine tune – The final activity in the deployment stage is the fine-tuningof the operation based on feedback received during deployment.Successful organisations have gradually turned this fine-tuning activityinto a continuous improvement programme managed and led by former

members of the rollout team.

•

•





4.6.2 Deployment approaches

Comprehensive 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 duringthe project planning stage, but we discuss it here as it has a directbearing on the mode of deployment. The question foremost in the mindof bankers as they decide to replace their banking system is: shouldsystems be upgraded piecemeal or through an integrated end-to-endsolution? Banks vary in their choices. Some want to replace the corebanking system of all geographic locations along with other operationssuch as treasury through a universal or end-to-end integrated solution.Others adopt the best-of-breed approach by selecting separate softwaresystems 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 onlyone vendor or else there would be immense integration issues. Forthe front end and back of fice, there should also be a single vendor ifpossible, though the project may be divided into smaller parts. Howeverwhen it comes to replacing banking systems across geographic locationsor across operations (retail, wholesale, treasury, etc), we suggest thefocused approach for bigger (tier 1) banks primarily because of thecomplexity of the process. The banks would be able to reduce thecomplexity 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 forsmaller banks mainly due to the lower scale of the project. End-to-endreplacement has its pluses as integration would be less of an issue, itavoids successive disruption of services and it provides a standardisedtechnical capability across functions.

While deciding on the replacement approach is easy, deploymentis probably the most dif ficult and challenging part of a core bankingproject and can be accomplished through multiple approaches. The twoextremes are “big bang approach” where the entire system goes liveat the specified time and “gradual/phased implementation” where theprocess is divided across various functions, locations or branches.

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

The justification for big bang comes from the fact that it is dif

ficult fortwo 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 seriousproblem occur, the bank has only one option: to fall back on the old corebanking solution. If such a problem occurs more than a week into thecutover, the bank will have serious trouble as the fallback option mostlikely does not exist anymore.

For smaller banks, this approach is possible and even feasible. But forbigger banks, particularly for banks spread across countries, we believethat a total big bang approach is not only high risk but also rather dif ficult

to implement. Examples of recent big bang deals include Union Bank ofPhilippines and Industrial Bank of Korea.

We believe the gradual approach, which is essentially step-by-stepreplacement, should be the preferred mode of implementation amonglarge banks as the complexity and risks in the process are lower. Aphased implementation also deploys the entire core banking solution inone 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 isdeployed at once and can be tested and fine-tuned in a tightly controlledenvironment. Should there be any problem, it can be confined to thecluster. We also recommend that the first cluster is deployed as a pilot,to test not only the new core banking solution but also the conversionand coexistence strategy. The disadvantage of the phased approachis that it takes longer than the enterprise-wide big bang and it requirescareful planning for coexistence and logistics.

We believe that the advantages of phased implementation far outweighthe disadvantages. If risk mitigation is important for the bank, thenthe phased approach is worth a serious look. Gradual implementationleads to a phased change in the processes and working environmentof the organisation, making the change slower and less likely to meetresistance.

In conclusion, the big bang approach is the most risky option a bank canchoose. Big Bang is only recommended for small banks, or for caseswhere the bank is implementing a solution which has already beencustomised for its country and implemented here many times. Solutionswhich have not been customised for a specific country or which are

implemented as part of a core banking enabled transformation are, inour 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 functionalrequirements of the bank

• Ensuring adequatefinancial, business and

management support forthe change

• Financial viability to

provide long termrelationship and

technical support

• Experience in

successfullyimplementing similar

project

• Evaluation of

technical capabilitiesof solution to meet the

business goals

• Flexibility and

adaptability to newdevelopments

• Ensuring smooth,

timely and cost effectiveimplementation of new

system

• Ensuring adaptation in

the work culture andpost-implementation

smooth operations

• Commitment of vendor

to provide long termsupport

• Technical advancementsand their compatibility

with the new system

Project Stages

Evaluation risk

& management

commitment

Selection of

vendor, service

providers

Solution risk Implementation

risk

Long term

technical

support risk


Risks and potential losses in replacing a core banking system are veryhigh, making it imperative that banks tread with caution at each step.

We have identified

five broad stages in the replacement process andinherent risk characteristics of each.

Lack of management commitment is one of the primary causes forproject failure. We believe that a core banking replacement project needsbusiness and management support in totality and the project should notbe perceived as an IT project. Management commitment should not belimited to simply business and managerial involvement at all stages ofthe project but extend to strong leadership support that sees the projectthrough.

The evaluation of business needs and objectives must be comprehensive,

as inadequate assessment of technical and functional requirements willlead to improper selection and possibly expectation/deliverable mismatchat a later stage. It is critical for the bank to understand the type and depthof functionality provided by the core banking solution in the context of itsown requirements and replacement objectives.

Availability of multiple solutions with varying technology and comparablefunctionalities has made this task more dif ficult. We believe that while animproper selection of solution could lead to short-term benefits, it mayact 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 isthe worst-case scenario. As a general guideline, a vendor is not just an ITsupplier for the bank; instead it should be viewed as a partner that wouldprovide not only the solution and integration services but also long-termrelationship and technical support to the organisation. We believe thatbanks should not just evaluate the financial viability and track record ofthese vendors, but also ensure adequate fit with the project and thatthey are able to trust the service provider. This is especially true for theselection 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 propositionin any organisation. It is more so in the case of banks due to the highrisk of potential losses and errors in a scenario where they cannot allowa margin of error.

Risks are present at all corners, whether it is system customisation,data migration, consolidation of multiple systems, integration of multipleprocesses or user adaptation to new processes. Another risk is thepossible lack of long-term support from vendors, which could translateinto 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 wouldhelp ensure the adequacy of selection criteria and lower the likelihood ofexpectation/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

System

Integration

Unexpected

Cost

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 requiresstrong commitment and business justification in most cases. It is for thisreason that most banks take considerable time in coming to a decision

to replace or even upgrade their system. The cost components of thetotal capital expenditure are software and service cost which constitutes30%, system integration cost of 20-25% and hardware and infrastructurecost of 45-50%.

The software and service cost is highly dependent on the scale andcomplexity of the project. For example, it could be $100 million or morein large global banks but it has generally been much lower for smaller Asia Pacific banks. In Asia, the cost of software and services has beenin the range of $5 million to $10 million for small banks and $20 millionto $25 million for mid-sized banks, while for large banks it can go muchhigher. 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 financial

justification





Recent big deals have shown significant variation in the expenditureincurred for software and services. For example, it was reported to be$20 million-$25 million in the deal for HSBC, around $35 million for StateBank of India, $33 million for Central Bank of India and $4 million forUnion Bank of Philippines.

For many vendors, the pricing may be different when they ventureinto new or more competitive markets. Involvement of a local partnergenerally helps to lower the costs of the project. Our research showsthat 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 needadditional IT manpower, on top of what is required for the basic corebanking system. But most banks take this into consideration and justifyit when planning for core banking replacement.

However these may not be the only costs involved. In many cases, thereare also hidden costs in the process. These unplanned costs may comefrom service disruptions, system downtimes or other system problemsduring the course of implementation or from unexpected delays in projectimplementation.

Cost overrun could also be caused by incremental changes, which oftenincrease the scope of the project and are sometimes due to the allureof technical advancement. While such changes may be a necessity insome cases and improve the ef ficacy of the project in others, the bankshave to evaluate these against the corresponding cost and scheduleoverruns. It is common for the bank to realise that there is a mismatchbetween deliverables and expectations when it has reached theimplementation and deployment stage. Usually resulting from improper

project realisation, delta analysis or communication, this has been oneof the primary causes for incremental changes in the project leading tounexpected overruns.

While the banks strive to keep these costs in check, there is anothertype of cost that gives critical business justification for such a steepinvestment. For most banks, the replacement decision is taken only whenthe “opportunity cost” of not changing a system (such as loss of marketshare, reduced competitiveness and lower growth) becomes too highand, in many cases, when their survival is at stake. Some other banksfind it easier to justify the replacement citing regulatory requirementssuch 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 definite motivations. We discuss these furtherin the following section.

Financial Justifi cation of New System

Increasedefficiency,

competitivenessand time saving

Improvedmargins and

return oninvestment

Shorter breakeven period,

lowermanpower cost

and higher ROI.

Improvedcompetitiveness

and growth.Customer

relationship

improved

Improvedmarket

presence,capture of new

market,

increased fee,revenue

Improvedrevenue

generation,business

growth

Direct benefits

Indirect benefits

Legend

Project Stages

Integrated,

flexible system

Lower

opportunity

costs

Lower

operational,

maintenance

cost

Customer

centric, STP

Innovative

products,

bundling

New

initiatives,

services

Expected deliverables of the new system

Direct and indirect financial impact for the bank


While there is clear business justification in the form of intangiblebenefits such as market growth, retaining of competitiveness and long-term success, many bankers mull over cost effectiveness and return oninvestment (ROI) in order to find financial justification for the project.

Though varying with individual projects, cost savings primarily come fromlower maintenance costs, lower operating costs and time savings. Manylegacy systems demand a large pool of IT-trained manpower, whichis becoming increasingly scarce and expensive. Reduced manpowerrequirements after replacement would therefore lower the maintenancecosts. In addition, systems that provide front-end and back-of ficeintegration improve ef ficiency 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 savingsfor the banks. For many banks, these cost savings have led to a shorterpayback period and an improved ROI. Industrial Bank of Korea claimsthat with its legacy system, it used to take almost a month to roll outa product. But since implementing a new core banking solution (byTemenos), the rollout time has reduced to 2-3 days and the time forbatch end-of-day settlement has reduced by 30%.

•

•

•

Financial justification through

cost savings and revenue

growth

While investment is substantial,

benefits from cost savings, ROIand business growth could be

more





Vendors often claim that replacement brings about a sharp increase inproductivity. However, attributing the improvement to only the new systemwould not be appropriate as in many cases replacement is accompaniedby process restructuring.

The most critical impact on a bank’s financials is in its revenue growth. A flexible system can facilitate the development of innovative productsto cater to ever changing market demand. Designing and creating newproducts and customising are easier with the right system, which leadsto more product innovation and shorter rollout times.

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

Customer-centric systems (compared to account-centric systems ofthe past) provide a single view of the customer to multiple functionalsegments of the bank. This facilitates customising of products to customer

segment, cross selling and bundling of products and services, leading toimproved fee collection and revenue growth. Additionally, the bank canenhance customer satisfaction and improve business through featureslike virtual 24/7 banking.

The cost savings and revenue growth will vary between banks dependingon the unique features of individual projects. Some big banks claim thatthey have benefited through a distinct improvement in ef ficiencies andthe retention of a substantial number of customers that they would havecertainly lost otherwise. Most banks also agree that there has beendrastic reduction in end-of-day processing time and product developmenttime (e.g. some banks can set parameters of products within a couple of

days). Most banks have extended their hours of operation to nights andweekends as well. These tangible and intangible benefits often providesubstantial financial justification for the banks to take the plunge.

•

•

•

•

•

Intangible boost to growth

highly possible if bank has the

right system





5Core BankingReplacement BuildingBlocks

We have identified the critical building blocks of the core banking

replacement project. These comprise the technical issuesthat 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 Bui lding Blocks

5.1 Application architecture and core banking5.1.1 Key issues


5.2 Service oriented architecture

5.3 Interface considerations

5.4 Coexistence

5.4.1 Branches

5.4.2 Call centres



5.4.5 Batch interfaces – inward clearing



5.5 Data conversion and data cleansing5.6 Product rationalisation

5.7 Process rationalisation



5.1 Application Architecture andCore Banking

Our research into core banking architecture and deployment practicesreveals that the process of replacement consists of several critical building

blocks which need to be taken into consideration during planning:

Core Banking Building Blocks

Deployment

Strategy

InterfacesProcess

Rationalisation

CoexistenceProduct

Rationalisation

Service Oriented

Core Banking

Architecture

Data

Conversion

Change

Management

Project

Organisation &

Programme

Management

Building Blocks


5.1.1 Key issues

In our analysis, we found a number of key questions which always ariseconcerning these building blocks. For example:

Big bang or phased deployment strategy – Is coexistence of the oldand 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? Whatchanges 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


ore Banking Replacement Bui lding 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 webest 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 corebanking 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.


A 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 thebig 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 benefits of

the big bang for all deployment clusters while keeping risks within a

manageable level. For instance, if deployment problems occur, they can

be confined to the cluster and will not affect the entire enterprise. Onthe down side, a phased rollout will take longer and will require massive

logistical planning for each deployment cluster. Nevertheless, we believe

that the benefits 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 inflexible

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 stillneeds to mature and develop the capability to successfully manage high

transaction volumes. Nonetheless, it can provide the necessary flexibility

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

definition 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 flexibility. Specifically, each “service” has a corresponding

“contract” which defines 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 definition 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 workingsof 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 fit into an SOA environment by exposing its services

through well-defined 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 definition 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 flexibility





Enterprise Service Oriented Architecture can be defined as follows:

Defi nition of Service Oriented Architecture (SOA)

Business Logic Data

Application

Front-end

Business

Service

Service

Repository

Service

Bus

Contract Implementation Interface

Service

Oriented Arc hit ectu re

(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-endis 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 service

b) 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 theapplication front-end and

other services can use

2

The service repository

stores the servicecontracts 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 deploymentof new products and services. The customer information repository sits

outside the core banking architecture and is loosely coupled to it throughan enterprise service bus. This is necessary as the customer information

repository must be able to support multiple core banking systems, as isrequired in many banks around the world.

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

•





Illustrative Core Banking Architecture

Multi-Channel Bank System

ExternalInterfaces

GeneralLedger

CreditCards

ClearingHouse

BahtNet

Branch

Call Centre

ATM

Internet

etc.

etc.

etc.

Core Banking System

Customer Information

Collateral Information

Common Services


Deposits Loans

C h ann

el I n t e gr a t i on

A p pl i c a t

i onI n t e gr a t i on

R e p or t i n g / S

t a t em en t I n t er f a c e






5.3 Interface Considerations Our research shows that interfaces are a key concern for any corebanking replacement project. Every major application in the bank is

interconnected, or interfaced with the core banking system, as illustratedin the chart below. According to some experts, an enterprise service

bus (ESB) and an SOA together can help to reduce the number andcomplexity 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 Online

Online/

Batch OnlineBatch

Online

Batch

Batch

Batch

Online

Online

Batch

Online

Batch

Batch

BranchApplication

Core BankingSystem

Trade Finance

HumanResources

FinancialPlanning

Agent Service

Audit andControl

AuthorisedSignature

DataWarehouse

CashManagementCall Centre Cheque CIS

E-Channel

EAI

Donation

Custodian

Credit Card

BONDSWIFTPaymentLoan

Old

Core 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 withLegacy


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 Online

Online/

Batch OnlineBatch

Online

Batch

Batch

Batch

Online

Online

Batch

Online

Batch

Batch

BranchApplication

Core BankingSystem

Trade Finance

HumanResources

FinancialPlanning

Agent Service

Audit andControl

AuthorisedSignature

DataWarehouse

CashManagementCall Centre Cheque CIS

E-Channel

EAI

Donation

Custodian

Credit Card

BONDSWIFTPaymentLoan

S W I T C H I N G M E C H

A N I S M

New

Core 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

Old

Core Banking

System

New

Core Banking

System

Other

Online

InterfacesATM

Call

Centre

Systems

Clearing

House

Other

Batch

InterfacesUnconverted Branches Converted Branches

Source:Immacon Research

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 operatewhile accounts areprogressively converted to thenew core banking system?

how will inter-branchtransactions be handledduring coexistence?

how will the call centreservice requests duringcoexistence?

how will ATM transactionsbe processed duringcoexistence?

how will other onlineinterfaces be processedduring coexistence?

how will incoming batch interfaces be processedduring coexistence?

how will outgoing batchinterfaces be processedduring coexistence?

how will sweeping andother features beprocessed duringcoexistence?

Branches Call Centres

Batch Interfaces

(Outward Clearing)Other Implications

ATM Transact ion sOther Online

Interfaces Batch Interfaces(Inward Clearing)

What is Coexistence






5.4.1 Branches

In 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 final 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

FeatureOption 1

2-way SupportOption 2

1-way SupportOption 3

No Support

Coexistence Options

Old Branch New Branch

Customer has account in anew branch and wants totransact at an old branch

Customer has account in anold branch and wants totransact at a new branch


At first 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 find 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

Old

Core Banking

System

New

Core Banking

System


Call CentreSystem


Online Transaction

Switch


•






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

Old

Core Banking

System

New

Core Banking

System



Tandem ATM SwitchATM


•






These are treated with the same strategy, i.e. the use of online

switches.

Online Transactions During Coexistence

Old

Core Banking

System

New

Core Banking

System



ExternalSystem

Online TransactionSwitch


•






Similarly 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



Old

Core Banking

System

New

Core Banking

System

ExternalSystem

BatchCombiner

During rollout, thenew system will alsogenerate this datafor convertedaccounts …

A ‘Combiner’ will

therefore be needed

B a t c h


•






Other 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-Branch

Sweeping

Amend the systems topass the transactions out

Create an external systemfor inter-branch sweeps

Manual processes

Standing Orders

Amend the systems topass the transactions out

Create an external systemfor inter-branch standing orders

Manual processes

Others

Each situation will have tobe judged on

Criticality Volume

Complexity

A decision is then made onthe best solution available


•





5.5 Data Cleansing and DataConversion

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 careshould 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 conversionto accommodate differences in data format between the old and new

systems or to auto-set default values for new fields 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 Instructions Transaction HistoryEtc…

Data

CustomersAccountsStanding Instructions Transaction HistoryEtc…

Data

... what it takes :

Step 1: Data Mapping

Step 2: Data Conversion

Extracts

Step 3: Data ConversionLoads

Data Cleansing

Data ConversionOld

Core Banking

System

New

Core Banking

System

Source:Immacon SOBIT Methodology

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 Account

Is there a corresponding product for each ofour existing products?

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

Current Account

Product

Current Account

Account No.

Current AccountAcc Branch Code

Acc Product Code

Acc Sequence No.

Acc Check Digit

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

Should our account number structurecontinue to have meaning?

When will we run out of account numbers?What should be the length of the accountnumber? What are the implications for thenew system, cheques, passbooks, ATMtransaction 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 forthis product (i.e. Current Accounts)?

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

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

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

Customers

Accounts

Standing Instructions

Transaction History

Etc…

Extracted data ready for loading

Conversion data file layout as

required by new core banking

system

Conversion

Data

Conversion

Reports

Data

E x t r a c t M o d u l e s

Step 2 : DataConversion Extracts

Old

Core Banking

System


Data conversion loads – This is the final 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

Customers

Accounts


Transaction History

Etc…

Extracted data ready for loading

Conversion data file layout asrequired by new core banking

system

Conversion

Data

Conversion

Reports

Data

E x t r a c t M o d u l e s

Step 3 : DataConversion Loads

"New" World

DATA

Customers

Accounts


Transaction History

Etc…

Conversion

reconciliation

and verification.

Report Generator

Reports

L o a d M o d u l e s

Old

Core Banking

System

New

Core 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 profitable 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 effectivemanner, 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 define 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 benefits for the core

banking replacement programme. It enables the bank to take full

advantage of the capabilities of the new core banking solution. It

simplifies the sales process through consolidation of “like offerings” into

core banking “configurable” 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 Factorsand Best Practices

Organisation of the project and management of the change are

critical issues for projects of such a scale. We have identified thekey 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 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)



6.1 Project Organization andProgramme Management

We believe that a project of the magnitude and scale of a core bankingreplacement requires strong project organisation and programme

management. In addition, the project organisation should be adjusteddepending on the phase of the project.

Business Transformation Team Structure

Others

Teller

Core Banking

Common Activities Deployment

Project Organisation

Steering Committee

Programme Director

QA PMO Support Team

Core Banking Enabled

Transformation Technology

Core Banking Enabled

Business

Process

Architecture &

Integration

Data

MigrationTesting

Organisation

& Change

Functional Technical

Benefit

Realisation

Business Transformation

Team Process

Coordination & Decision

New WorldCluster Pilot

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 chairedby the CEO and it is important that he demonstrates commitment to theproject. Other members of the steering committee should include the

bank’s full-time programme director, heads of all the business units, theCIO, and key risk-management and finance personnel.

We believe that the bank’s full-time programme director should have

complete authority over the project. The programme director should beempowered to make decisions after consultation with business and IT.

He needs the authority to make the final decision if consensus cannotbe 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


i t ical Success Factors and Best Pract ices




The 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, Bui ld & Test

Core Banking

System Project

Manager

System

Implementation

Team

Int erf ac es Team Test ing TeamTraining &

Procedures

Team

Customer

ApplicationTeam

Deposits

Application

Team

Loans Application

Team

Online

Interfaces

Batch

Interfaces

Legacy Systems

Teams

3rd Party

Interface

Systems Teams

Pilot Site

Selection Prep.

Go /No Go

Assessment (ext.

Accountants)

Business

Testing Team

Integration

Testing Team

CoexistenceDevelopment

Team

Operations

Testing Team

Conversions

Data ExtractsTeams

Train-the-

TrainersTraining Team

User

Procedures

Team

Online

Application

Team

Accounting &

Other Apps

Team

Data

Conversion

Load Team

Project OfficeTechnical Support

Stage 2

Stage 2

Build & Test

Significant Third

Party ResourceInvolvement


•






The 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 fine-tune the new core banking

solution and its processes and procedures.

Stage 3 Project Organisation, Pilot

Significant ThirdParty Resource

Involvement

Core Banking

System ProjectManager

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

Project OfficeTechnical Support

Stage 3

Stage 3

Pilot


•


Crit ical Success Factors and Best Pract ices



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 conflicts.

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 significant 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 flexible, 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 flexibility 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 andBest Practices in VendorSelection

Success Factors in Vendor Selection

Track record and

technical ability of

the product to

meet the

functional

requirement

Ability to tide

over

downtrends and

sustain

technical

advancements

Ability to meet

the unique local

requirements

and yet provide

the requisite

quality

standards

Financial ability

and

commitment

towards long

term technical

advancement

and services

Reputation and

long term

commitment to

provide ongoing

support and

future

integrations

Project Stages

Identify

vendors with

track record

and reputation

Evaluate

financial

strength and

viability

Evaluate

experience

with similar

projects

Evaluate

commitment

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 mayprove 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 ofproduct and services required to meet the objectives and ambitions of

the business and the unique requirements of the project. The relationshipbetween system provider and system integrator should also be evaluated

and their track record in managing projects as a team needs to beanalysed.

Equally important is that the bank has to evaluate its own comfort level

with regard to the vendor’s reliability and suitability for the particularproject. If the bank has an existing system from the vendor, there could

be a distinct benefit from having fewer integration issues. Using thesame 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 waslack of local knowledge and ability to cater to the unique conditions of the

banking environment in that country. Cost aside, the bank should selectthose vendors that involve local people in the process of customisation

and localisation, and ensure that they provide international quality whilemeeting the local standards. Vendors that have already customised a

product for a particular country are likely to be more suitable to undertakefuture projects in that country.

Finally, the bank should select a vendor that has the commitment andability to continually enhance the product so that future upgrading of thesystem 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 (forSuccessful Implementation)

Key Success Factors fo r Implementation

Banks should

develop strong

team to guide the

vendor

Develop

empathy with

business

environment

Excellent

communication

skills to

motivate and

meet resistance

to change

Develop pilot

projects to

ensure

expectation and

deliverables

match. User

acceptance

tests 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

Understand

unique

requirements,

expectation ofthe bank

Involve local

people to meet

unique localrequirements

User training

to adopt new

processes inwork culture

Thorough

testing at

each stage.

Develop pilot

project

Ensure

seamless

integration and

timely

implementation

Provide long

term

partnership tothe 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 find 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 identified.

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-specific initiatives can bring about cost savings as well as

improve ef ficiencies 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 BankingReplacementConsiderations

This section covers the unique business considerations, functional

requirements and key challenges faced by different typesof 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 bank

7.3 An Islamic bank

7.4 “Internet only” banks

7.5 Mergers and acquisitions of banks



7.1 A Large Multinational Bank

Unique Requi rements

• 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


nique Considerations



Unique Considerations

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 justification. 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

suf fice 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 hasproven 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 reflect 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 flexibility 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 dif ficult 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 dif ficult 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 f eatures

• 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 anddifferentiate 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 flexibility 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 througharchitectural 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

flexibility 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 dif ficult

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 suf fice. 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 Bank

Unique requi rements

• 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 finance.

Islamic banks are common in the Middle East but have sprung up as

far away as London and the Philippines. Within the Asia Pacific 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 profits 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 andother businesses that do not profit from interest payments. Commercial

borrowers pay the bank and its depositors a share of their profits 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 ef ficiency 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 lookfor systems that provide

compliance with Islamic law

System should have the ability

to integrate core banking

features with Islamic principles





7.4 ‘Internet Only’ Banks

Key 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 fixed, operational andmaintenance costs and the cost benefits 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 innovativeproducts and services offered online to the customers. Speed is essential

and hence system flexibility 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 suf fice.

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

flexibility for innovative products

is essential for “internet only”

banks





Many of these banks are probably acquiring a core banking system for

the first 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 ofBanks

Core Banking Considerations in Mergers and Acquis itions

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 bankingreplacement 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 dif ficult 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 corebanking.

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 confidence 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 dif ficult 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 financially 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 markettrends, demand characteristics and unique requirements ofeach 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 newtechnology

• 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 fiveyears back, most banks in the country were working on mere branchautomation and most state-owned banks did not even have a corebanking system owing to lack of infrastructure and network readiness toprovide a centralised system. New private-sector banks then came intothe market with a distinct technical advantage which led to substantialcustomer attrition in state-owned banks.

Competition within the banking sector of this country is rising as

foreign banks are becoming more aggressive, growing through bothacquisitions and expansion of operations. Aggressiveness of the privatebanks has thus forced most state-owned banks to replace their corebanking systems with advanced, centralised systems that are not onlycompetitive but also cost effective. In the last two years, almost 30% ofthe country’s banks (most of these being state-owned) have taken thedecision to replace their core systems. Because of this, almost 50% ofdeals in Asia during this period have come from India.

Prominent deals in the last few years include State Bank of India withTCS, Canara Bank with I-flex (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


untry Trend Analyses




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

Some banks have preferred integrated, packaged solutions. This is afeasible option for banks which are undertaking greenfield projects –and hence do not have to face the complex issue of integration with oldsystems – and whose transaction volumes are low. The preference hasbeen for local vendors, who understand local business requirements andare considered more reliable in terms of domain knowledge. Moreover,many Indian vendors now rank among the top global vendors. Theleading core banking providers within the country are Infosys, TCS (withFNS), I-flex and Nucleus Software.

A critical challenge that many banks have faced in the transformationprocess is the wide spread of branches across the country and in areaswhere networking and infrastructure capabilities are still being developed. As a result, many banks have found it dif ficult to integrate all their branches

through a centralised system. Another tricky problem has been changemanagement, as most banks are shifting from branch automation to acentralised system. In branch systems, branch employees maintainedownership of the data. However with centralised systems, some bankshave observed that their employees felt a ”lack of ownership of data”, ontop of the typical employee dissatisfaction with change in processes.

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

•

•

•




8.2 China

Branch

Computerisation

Branch

Networking

Data

CentralisationIntegrated 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, businessenvironment

• 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 inChina to consider replacing their core banking systems. Market pressurecomes from the arrival of foreign stake-holding in banks and customers

becoming more demanding on quality of services and products. Therobust growth of the Chinese economy has attracted financial institutionsfrom across the globe.

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

We believe all Chinese banks are now somewhere between branchcomputerisation 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 anintegrated core banking system.

There is increasing interest in core banking system replacement amongbanks, with many medium and small banks mulling over the decision andsome evaluating vendors. We have seen a gradual growth in number ofdeals in the last couple of years and expect the trend to continue andprobably accelerate as competition intensifies. The platform of choicecontinues to be mainframe, which is more appropriate considering thelarge branch network and high transaction volumes.

We have discovered that the uptake of core banking systems has beenslow in the country as a whole because the banks have been verycautious. Additionally, we have observed that tier 1 banks (and nowincreasingly tier 2 banks) prefer international vendors for the quality oftheir solutions and services, whereas many smaller banks continue toprefer local vendors due to the lower cost and higher level of trust andreliability. There continues to be a certain level of doubt in the marketabout the ability of foreign vendors to meet the local requirements ofChinese banks. Deal implementation problems have also been reportedin cases like CITIC Bank, whose replacement project was done by

Fiserv.

Many banks in China are looking at point solutions in, for example, tradefinance and treasury rather than at core banking system replacement.We believe this reflects their short-term objective of attracting foreignfunds.

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

Recent prominent deals include China Minsheng Bank by SAP, whichalso marks the entry of the global vendor into this region, Hua Xia Bankby 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 Analys is 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 ofthe highest in Asia with most banks having basic integrated CRM. Japan

has traditionally had largely mainframe-based systems, most of whichare proprietary systems developed in-house. Reliance on these stableand robust systems has been widely accepted in the country and thus thebanks have been relatively slow in patronising the UNIX technology.

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

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

•

•

•

Japan

Banks in Japan are struggling

with rising maintenancecost and scarcity of trained

manpower





systems that typically would need upgrading or replacement to reducecomplexity and improve ef ficiency. Ageing systems and competitivepressures are likely to bring about increased activity on the core bankingfront over the next few years. Interestingly, a notable trend has been theformation of smaller new-generation banks in Japan which tend to lookat new-generation technology.

Indications are there but a substantial shift towards undertaking thisrisky venture is yet to be seen in this country. According to one leadingvendor in the region, “Japan market will move in 2-3 years. They havenot reformed their financial services sector yet. It is coming very slowly.Once it is done, then we will see a change in reforms, change in attitudein both public and semi-public sectors. Nothing in Japan happensquickly.”

We believe that technical advancement among banks in Korea hasreached integrated core banking and robust middleware. Till a few yearsback, most banks in Korea used mainframe-based legacy systems. Butin the last few years, there has been an increasing shift towards UNIX-based systems. The new regulatory environment requires banks to havestringent capital coverage and risk management policies. These new

rules, high cost of maintenance and ageing technology are believed tobe the critical factors driving the shift.

Competition in the market is intense and banks need to be ef ficient andcost effective in order to gain an edge. For this reason, most banksare looking for architecture that not only meets their current businessrequirements but is also scalable to cater to future growth. Nonetheless,the complexity of tasks involved in replacement and integration is a keydeterrent for most banks. Historically banks have preferred to build theirsystems in-house, but we are seeing an increasing shift in favour of ITcompanies.

Taiwan is one of the few countries where there was a sudden surgeof activity in 2005, with four banks going for core banking deals ascompared with 2004 when there were none. We believe that most banksstill lack the confidence to change from legacy systems, but competitivepressures are forcing them to look for newer-generation technology.

Our research shows that technical advancement in the banking sectorof this country is currently at data centralisation and integrated corebanking. Now the banks are poised to take the leap towards integratedCRM in order to achieve total customer centricity. As there is alreadya 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 theUNIX platform. However, in most cases, a critical consideration has beenthe ability to suit the unique requirements of language and businessculture in Taiwan. The latest prominent deals include Cathay UnitedBank by TCS-FNS and Ta-Chong Bank by I-flex.

•





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

In Malaysia, in the last three years, we have seen many small andmedium banks coming to the market to replace their systems. Many ofthem have chosen vendors that can provide them with Islamic bankingcapability. For this reason, local vendors such as Microlink and Silverlakeare popular in the country. We understand that the leading bank ofMalaysia, Maybank, is also in the process of evaluating vendors forchanging its core banking system. Given the small size of the country’sbanking sector, the change is noticeable. The aim of the banks is to haveintegrated core banking systems.

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

We have seen very few deals from this country lately. The only prominentone 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 muchto 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 oninef ficient legacy systems and are spending a lot of money and time tomaintain them. The skills to operate these systems are disappearingas most young graduates prefer to work on an open system while theolder people are retiring. Hence maintaining these systems is becomingmore 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 seenmany prominent deals from Indonesia in recent years. But we expect themarket to open up in the next 2-3 years owing to increasing inef ficiencyand 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





9 Vendor Assessment

This section examines the current standing of vendors in the

Asian markets and ranks them. A survey across banks in Asiacoupled 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 assessment9.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

financial 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 five 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 financial strength of

vendors on the basis of theirfinancial standing in absolute numbers and

•

•


ndor Assessment



Vendor Assessment

their growth over the last three years. The analysis has included key

indicators such as revenue, operating profit, 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 of fices.

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

Abil ity to meet un ique 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 specific 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

Architectural

Advancement

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 andSOA) and market penetration of the products across banks in Asia.

Unproven – This segment consists of those products that have no

significant 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 flexible. 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 architecturaldevelopment 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 classification 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 traditionalflat-

file database system. Since

•

•

•


ndor 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-flex 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 specifically 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 first is forbanks 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 d irection, 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 justification 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


onclusion



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, trackrecord

Partners in proj ects, 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 eachproject as a long-term relationship. Besides maintaining high technicalstandards, they need a track record of successful implementation. Everyproject has its unique characteristics and requirements which need to beaddressed with utmost diligence.

Having the right people with domain and business knowledge to suitthe local requirements of individual projects is essential for successfulimplementation. 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 investcontinually in technical advancements. Equally important is catering tothe local conditions while providing international quality in the productand services.

Ensuring that deliverables are in line with the expectations of the bankrequires clear communication at all levels. This would involve usertraining and the challenging task of managing process and work-culturechange within the bank.

There should be fool-proof testing at each step in addition to otherstrategies for risk minimisation. Successful implementation of eachproject 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


onclusion



A1 Appendix ICase Studies

Case Studies

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



Case Studies

revamping its core banking system. It initiated the plan with transformationin 3,300 branches in year 2000. But thereafter, the change process wasextended to include 5,000 branches of four associate banks as well.

The key motivation for the bank to purchase a new system was thedesire to have a local framework in which IT could serve as an “enablingforce” and relieve the local branches of back-of fice operations therebyallowing them to focus on delivery and marketing. And this was possibleonly if the bank had a centralised core banking system and made itsbranches a service and delivery channel. Multi-channel delivery withoutcore banking was not practical.

The Timeline of the Transformation Project

Apri l

2007

Augu st

2006

Apri l

2006

2004200320022000

Implementation

completed

85% of Business

migrated to new

system

3,000 branches

(50% bank's

business)

migrated200 branches

migrated

Implementation

process begins

at pilotbranches

Selection

process.

Preparing RFPtook 6 months

Project

Conceptualised

with KPMG as

consultant

Source: Asia n Banker Research

However, when the bank started to consider replacing its system, therewere very few examples. It wanted proven technology for its systembut there was none. Not even Bank of America and other big globalbanks had undertaken such a change. Its size was the key issue andit needed a system that could cater to its growing needs. (Togetherwith its associate banks, SBI now has 15,000 branches and 140 millionaccounts in total.)

The whopping project for transformation of the domestic business

was conceptualised in 2000 with KPMG as the consultant. The actualprocess of selection began in 2002 as the bank developed a matrix ofcriteria (10,000-odd points) for system and vendor selection which hadto be approved by the government (SBI being a state-owned bank). Ittook almost six months for it to prepare the request for proposal. Theselection after the RFP was issued took another two months. As it wasa public bank, the selection process was bureaucratic with approvalsneeded from regulators. Technical bids were sought through the requestfor proposal followed by financial bids. Suitable vendors were selectedbased on the technical bids and their pricing was one of the final decisivecriteria.

•

•

•

The selection process




FNS Bancs was considered the most suitable to meet the bank’srequirements. TCS was chosen as system integrator as it had the distinctadvantage of being aware of local business practices, work culture andregulations and thus was well-placed to understand the requirementsof the bank. Strong alliance between FNS and TCS was another factorthat contributed to the selection of FNS as the vendor. This, however,meant moving to the UNIX platform which was relatively less proventhan mainframe for a bank of this size.

Owing to the size of the organisation, the customisation of software andthe user training and training for implementation were, in that order, thetwo most dif ficult tasks faced by the bank and the service providers.Unique requirements of the bank such as having to maintain branchindividuality while centralising the systems posed significant challengesin customisation. Its validation and process-adaptation requirementsforced further customisation.

The original product from FNS which had about one million softwarecodes was customised into a more complex hybrid product with almosttwo million codes. This extensive addition to the software code of theproduct was done by TCS and the system now covers 4,000 transaction

types.

Because of the complexity, pilot projects were implemented. The taskof migrating data from the old system to the new system had to achievetotal migration and reconciliation with no loss of data. A bank with tenmillion transactions a day has no room for error or else customer attritionand loss of reputation can be extensive.

The deployment, which is still in progress, is being done gradually overall domestic branches and the branches of four associate banks. Thisinvolves a total of 8,000 branches, a scale seen by very few banks inthe 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 staffand educating users is conducted in-house, a process which will takeyears to complete and require a huge amount of resources. SBI hasformed a strong in-house team to work with the vendors on deploymentand implementation.

Change management within the bank has been a whopping task. Theingrained culture of the organisation is undergoing a total transformationas the bank moves from an independent branch system to a centralsystem. This has led to users feeling a ”lack of ownership of data”, unlike

•

•

•

•

•

•

•

Customisation and

implementation process

The deployment was phased

The change management


se Studies



previously where there was an entrepreneurial feeling as they managedthe system and customised it to meet unique local requirements. Thisdemanded a strong acceptance of change management within the bank,with staff roles changing and business processes being restructuredacross all users. SBI met this challenge through strong internal teamsand effective communication. The change process is likely to continueeven after the new system has been fully implemented.

By mid-2006, 85% of the bank’s business would have been transferredto the new system. By March 2007, SBI expects to have rolled out itscore banking system to almost all of its domestic branches and those ofthe 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 garneringhuge market shares thanks to their technical advancement. The cost-to-income ratio of the bank is already showing significant improvement.We expect this new system to give a strong boost to the bank’s futuregrowth. However the effectiveness of the system for such a large bankcan only be seen after it has been implemented across all branches.

For its international operations, the bank recently chose Infosys toprovide a single integrated solution across all branches as it felt thatTCS’s resources were already tied up with its domestic project. It isalso believed to be implementing a new trade solution. In addition, thebank is undertaking a business process restructuring exercise in orderto improve its ef ficiency. With all these initiatives, SBI should remain aformidable 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 improvecompetitiveness

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 assetbase of $1.98 billion and 111 branches in the country. However it is amongthe top ten banks in the Philippines, with a history of fast growth thanksto its tech-savvy approach. True to its reputation, UBP has become thefirst bank in the country to shift from mainframe to open platform.

The bank had an existing legacy system (from Systematics, running onrefurbished mainframes) which was ten years old. The key problems

faced by the bank included high operational costs and dif ficulty in buildinginterfaces. The bank then realised the need for a simpler system whereinterfaces are not an issue and total cost of ownership is lower.

The change was also prompted by the need to acquire business agilitycoupled with improved ef ficiency and to have the ability to differentiateits products and services. Being in a competitive environment, the bankworked on a tight margin hence cost was an essential consideration.With these issues in mind, the bank started exploring the possibility ofshifting to a newer technology platform in 2002.

•

•

•

The old system

Cost a critical consideration


se Studies



The Timeline of the Transformation Project

Apri l

2005

Apri l

2004

4 Qtr

20031 Qtr

2003

2002

Implementation

is completed

Implementation

begins with user

training

Selection

process

completed.

Finalises Infosys

Requests for

proposalfrom vendors

Explores

possibility of

shifting from

mainframe to

open platform

Source: Asia n Banker Research

In 2003, the bank invited proposals from leading vendors that couldmeet its technical requirements. The process of selection took sixmonths, during which the bank analysed all the proposals and bids andvisited two Infosys project sites in India. The bank viewed the ventureas the beginning of a long-term partnership and made the selectionaccordingly.

The selection criteria included the functional features of the system, thequality of the team and the track record of the vendor company. Whiletechnical capability of the system to meet the objectives was essential,

cost was also considered to be a critical factor. Infosys presented astrong business case following a Gap analysis.

The bank finally selected Infosys to provide the system Finacle forits retail operations (CASA, loans, deposits and GL). Local firm TotalInformation Management Corporation (with whom the bank has a long-term relationship) was also hired to provide consultation and assistancein implementation. The project involved replacing its mainframe-basedlegacy system with a new-generation open-ended system which runson Sun infrastructure. For Infosys, this was its first big project in thePhilippines. For this reason, involvement of a local partner was an assetfor the bank as well as the vendor.

The project cost was about $4 million. One of the key considerations forthe bank while selecting a system was the financial impact. It wanteda system whose cost could be met through the operating profits of thebank over a period of five years. In addition, the new system should havelower operational costs, thus leading to better returns for the bank.

Implementation took approximately one year and the system wentlive in April 2005. The implementation posed many challenges suchas localisation and customisation to unique business conditions of thePhilippines. In addition, data stored in multiple mainframe-based systemshad to be cleaned, migrated and consolidated. Some of the items that

Finacle needed were not found in the old system, making the task moredif ficult.

•

•

•

•

•

The selection process

The new system

The implementation and

deployment process


Case Studies



The project was significant for the Philippine banking sector because itwas the first time a local bank shifted from a mainframe-based system toopen technology. For this reason – coupled with the fact that it used ”bigbang” implementation – it was keenly watched by many in the industry.

The bank took an aggressive approach by adopting big bang, which wasless time-consuming but came with high risk. Most banks, especiallylarger ones, prefer a traditional step-by-step rollout due to lower risks.However owing to the relatively small size of the bank, big bang wasconsidered achievable and more feasible. The advantage in this approach

is the avoidance of integration issues that arise from having two separatesystems co-existing within the bank during rollout. The implementationis fast and would not slow the bank’s transformation process. The bankfelt confident that it could implement the project according to scheduleand it succeeded.

One of the strengths of Union Bank of Philippines has been its adaptabilitytowards new-generation technology. It is considered a tech-savvy bankand has proven so by being among the initial few in the country to stepout to replace their entire system. The bank developed an in-house coreteam which worked with the Infosys team to fulfil the implementation

plan and to train users for the change in processes.The success of Union Bank of Philippines in its core bankingtransformation has some lessons for other banks undertaking similarprojects. The management should be committed from conception to finalimplementation. This is required of both the bank and the vendor andwas one of the critical success factors for the bank. The bank developedstrong teams with good banking knowledge and got them trained forthe new system to ensure optimum utilisation. The bank faced a certainamount 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 fiveyears. If achieved, this would give it substantial competitive advantage.Moving from account centricity to customer centricity should help itprovide better customer service and improve its market presence. Thebank has discovered that with the parameterisation of the system, it canlaunch new products much faster and with ease. The cost of interfacingis also lower. In addition, the bank did away with the branch IT networkfollowing core banking replacement. With the new centralised system, thebank freed up resources previously engaged in branch IT infrastructure. Additionally, the centralisation of back-of fice functions should give aboost to its competitiveness

•

•

•

•

•

Lessons learnt

The outlook


se Studies



A2 Appendix II An Average Request forProposal

An average RFP runs into 70-80 pages, with the bank requiring

vendors to submit a whole range of information which wouldassist 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 profile, technology, product, customer

information system, general information, security, and loan and

deposit system information. However, as this worksheet is very

extensive and specific to each bank’s requirements, we are not

providing a sample of it in our report.



Table of contents A. Introduction

1 Bank profile

1.1 Vision

1.2 Mission

1.3 History and background

2 Bank products and services

3 Purpose

4 Eligibility requirements

4.1 Eligible vendors

4.2 Eligible products and services

4.3 Cost of this request for proposal

5 Definition of terms

B. Request for Proposal (RFP) Process

1 RFP contact details

2 Overview of the RFPprocess and schedule

2.1 RFP process

2.2 RFP schedule

3 RFP documents

3.1 Clarification of RFP documents

3.2 Pre-submission conference

4 Vendor proposal preparation

4.1 Language

4.2 Statement of compliance

4.3 Vendor proposal conditions

4.4 Vendor proposal validity4.5 Format, signing and packaging of vendor proposal

4.6 Pricing

4.7 Payment terms and conditions

5 Submission of the vendor proposal

5.1 Sealing of the vendor proposals

5.2 Reserved rights

6 Vendor proposal Evaluation

6.1 Confidentiality of the evaluation process

6.2 Clarification of vendor proposal

6.3 Examination of vendor proposal and determination of

responsiveness


erage Request for Proposal



Average Request for Proposal

6.4 Evaluation methodology

6.5 Bank’s right to accept or refuse any vendor proposal

7 Award of contract

7.1 Post-qualification

7.2 Award criteria

7.3 Reserved rights

7.4 Notification of award

7.5 Signing of the contract

7.6 Performance security

7.7 Corrupt or fraudulent practices

C. Commercial Terms and Conditions

1 Standard terms and conditions

2 Other terms and conditions

2.1 Responsibility

2.2 Delivery

2.3 Storage

2.4 Transportation, marking, labeling, packing and shipment

2.5 Transfer of risk and title

D Background and Vendor Proposal Requirements

1 Background and vendor proposal requirement

1.1 Background

1.2 Overview and scope

1.3 Architecture

1.4 System demonstration requirements

1.5 Reference site visit requirements

1.6 Pilot testing requirements

2 Implementation plan

3 Maintenance and support

4 Vendor’s expectations from bank

E. Financial Vendor Proposal Requirements

1 Overview

2 Price

3 Payment terms and conditions

3.1 Payment milestones




3.2 Payment due dates

3.3 Payment conditions

F. Statement of Compliance (Requirements Matrix)

1 Answering the requirements matrix

2 Requirements matrix

3 Executive summary

3.1 Instructions3.2 Summary of technical proposal

4 Organization and support

5 Application and support

6 General features

7 Business requirement

7.1 Customer information system

erage Request for Proposal

Asian Banker - Core Banking Replacement

Documents

Transcript of Asian Banker - Core Banking Replacement