Asian Banker - Core Banking Replacement

w w w . t h e a s i a n b a n k e r .
c o m
Management Report:
Roadmap to Successful
Core Banking System Replacement
Critical Success Factors and Best Practices
Neeti Aggarwal, CFA
Published September 2006
2006 The Asian Banker
Management Report:
Roadmap to Successful
Core Banking System Replacement

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.
I MPORTANT NOTI CE
ABOUT THE ASIAN BANKER
Asias nancial service landscape is undergoing tremendous change and evolution.
Liberalisation, consolidation and rapid technological advances have opened up
tremendous opportunities for nancial institutions and, it is vital for banks to benchmark
themselves against their competitors and to keep abreast of global developments.
Decision-makers need accurate, incisive, timely and continuous information to bring their
organisation to the next level, meet competitive challenges successfully and manage
their own future. The Asian Banker has long recognised the importance of information as
a strategic management and decision-making tool and is positioned to provide banks and
partner organisations useful, crucial and timely business intelligence.
The Asian Banker achieves this through three synergistic services:
Asian Banker Research: current, continuous and in-depth research on best
practices and market developments and trends
Proprietary & generic research services
Subscription-based research support services for different programs
Asian Banker Publications: incisive news and information on transformational
issues
The Asian Banker J ournal
Asian Banker E-newsletters on different segments in the nancial services industry
such 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
Asian Banker Forums: exclusive gathering of industry leaders and senior decision
makers to network and exchange information
Annual Major Conferences
The Asian Banker Summit
The Future of Banking in China
Asia Pacic 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 Briengs
Contact:
THE ASIAN BANKER
10 Hoe Chiang Road
#14-06 Keppel Tower
Singapore 0899315
Tel: (65) 6236 6500
Fax: (65) 6236 6530
http://www.theasianbanker.com
ABOUT THE ASI AN BANKER

ACKNOWLEDGEMENT
We 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 nancial services industry. He specialises
in core banking enabled change, business transformation, credit risk management
and strategy development. His career in banking and consulting covers assignments
in Germany, United Kingdom, Switzerland, Turkey, Nepal, Sri Lanka, ASEAN and
many other parts of the world.
He has managed retail and wholesale banking operations for major global banks
in Europe and Asia. After his stint as Deputy General Manager of a joint-venture
merchant bank in Indonesia, his interest turned to nancial services consulting. His
consulting assignments constitute a highly diversied portfolio that includes some of
the largest commercial banks in Asia.
ACKNOWLEDGEMENT
Core Banking
Transformation
Table of Contents
1. Core Banking Trends in Asia Pacic
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
Pacic
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 denition
3.1.1 Denition 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 justication 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
Table of Contents
2 Asian Banker Research Report
Table of Contents
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 cleansing
5.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 J apan, 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. Conclusions
10.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
Table of Contents
Executive Summary
Increasing consumer demands, high costs and widespread dissatisfaction
with ageing systems are making it increasingly difcult 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 nding it imperative to expand
their channels and services while managing operational and technical costs
even as margins are shrinking due to stiff competition. But this is hampered
by technical limitations as many traditional nancial institutions are shackled
by a series of heavily siloed non-integrated back-ofce 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 nancial perspectives. But competitive pressures are forcing banks
to take speedy actions, as can be seen in our analysis of trends in Asian
markets.
Analysing the Asian markets and the recent core banking replacement
decisions, we found that there has been a gradual rise in the number of core
banking deals in the last two years. Interestingly, almost half of the deals
during this period have come from state-owned Indian banks. These banks
had faltered due to competitive pressure from private banks and have found
it imperative to purchase (in most cases for the rst time) new core banking
systems and upgrade themselves technically to improve product innovation,
agility in decision making and cost effectiveness. We expect the Asia-wide
trend to continue in the year 2006; but as the Indian market nears saturation,
there are likely to be fewer deals from this country in the following years.
Looking at the trend in countries that have rst-generation technical
sophistication, we have discovered that core banking replacement is
considered a cyclical industry as banks come to the market about every 15
years to replace an ageing system and improve their efciencies. 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 Chinas hosting of the
Executive Summary
Olympics in 2008. On the other hand, we have found that banks in countries
like J apan 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 denition of the core banking system. We dene it as a
highly efcient customer accounting and transaction processing engine, for
high volumes of back-ofce transactions and customer-level accounting and
reporting of the deposit and loan products processed in the bank. However
it does not include the front ofce. Thus we believe that the bank has to
rst determine whether it really needs to replace its core system or it can
manage with just front-ofce 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 rst phase is business justication and identication of business
requirements through delta analysis. We believe that the bank should, rst
and foremost, determine its long-term strategic goals as these would guide
the bank towards the critical requirements for its system. With the business
objectives in mind, banks need to analyse the capabilities and deciencies
of their existing core banking system to determine the new systems
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 nancial justication for the project at this
Executive Summary
early stage of the process.
The second phase of the project is selection of the system and the vendor.
Selection of a core banking system will affect not only the growth and nancials
of the organisation but also its viability and competitiveness. Hence banks
need to critically evaluate all available options and select the system that
provides the right DNA (the architecture) to meet its business and strategic
requirements. We believe that the selection process should involve business
representatives from all functional divisions owing to the pervasive nature
of these systems within the organisation. Viewing the project as just an IT
project would be a recipe for failure.
The selection process begins with the issuance of a Request for Proposal
to various vendors. Each of the bids is assessed on both qualitative and
quantitative terms across a matrix of selection criteria. The critical requirements
from a new system are exibility and scalability to cater to future growth. We
advise banks to ensure that with the new system, they are not simply shifting
to a bigger box which may become a constraint again in a few years time,
as this would defeat the whole purpose of replacing the system. Equally
important is that banks should not be enamoured with bells and whistles
(which are more often than not the front-end features) and should look for
a system that has the requisite processing power rather than just a user
friendly front-end screen.
We have discovered that one of the challenges is picturing the banking
landscape in years to come due to the rapid pace of change in the banking
business. Thus the right selection would be one with a forward-looking
exible architecture that has the ability to support the business ambitions of
the bank and allows for future modications 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 exible and easily upgradeable infrastructure. We advise banks to look
for a system that has the exibility of SOA and to integrate their systems and
components in an SOA-based framework within the bank.
Banks need to select not the best system available but the one that is most
appropriate for their particular requirements. Different banks and their unique
requirements are discussed in section 8.
Equally critical is selecting the right vendor. We believe that it is imperative
for banks to consider vendors as long-term partners in growth in todays
fast-paced environment. The critical vendor assessment criteria include trust
Executive Summary
in the vendors ability to meet the business objectives (through optimum
customisation and localisation of the product) as well as the vendors
reliability, implementation capabilities and nancial strength. Vendors that
have a track record of providing international-quality products while meeting
the local needs of banks are more likely to achieve long-term success. The
mix of product and services coupled with pricing are critical considerations.
We have rated leading vendors in Asian markets based on our assessment
and a survey done among bankers this is discussed in our section on
vendor assessment.
Platform choice is one other critical factor in selection. While mainframe
remains unbeaten in its robustness and stability, UNIX-based systems are
becoming more popular. We have discovered that banks in Asian countries
are increasingly shifting towards the more agile and exible UNIX systems,
which are perceived to have lower operational and maintenance costs. While
this is true for banks that have lower transaction volumes, it may not be so
for large retail banks. We believe that mainframes continue to have a distinct
advantage in terms of stability and scalability. Hence for mission critical
projects, mainframes would still be preferred for their reliability. However for
small banks (and those banks that are acquiring a core banking system for
the rst time and whose transaction volumes are not very high), a UNIX-
based system could meet their requirements. As more than 50% of the deals
in Asia have come from small banks, UNIX-based systems have become
more common.
The third phase of the project is implementation. The key objective is to
operationalise and pilot the transformed future state, including technology,
process and organisational change. This involves developing detailed
designs, including system designs for conguration and customisation and
designs for interfaces and data conversion. The other critical elements of this
phase are building and testing the system, implementing pilot projects and
conducting business acceptance tests at each stage. We recommend that
banks limit customisation of the core banking system to what is essential
as it may affect the core processing ability of the system. Rather, the banks
should customise the front end which interacts with the users.
At each stage, the bank should undertake delta analysis to determine the
efcacy 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 nal phase of the project is deployment. This is probably the
most critical and challenging stage, where the bank undertakes the actual
Executive 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 t with
the business).
Data conversion and data mapping are two crucial elements that the bank has
to deal with during deployment. The data migration and conversion process
is often hampered by lack of available information on the old system. Mass
migration requires a large capital investment, takes a few years to implement
and poses a signicant 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 predene the milestones at each stage of the
replacement process and ensure they are adhered to. At any stage, if the
bank nds that it cannot achieve these milestones, it may review its project
and decide whether and how it wants to continue the project.
Our research into change management during replacement shows that the
majority of banks upgrade their system or implement a new one to meet
existing users process and work culture requirements. Instead, however,
we recommend that banks align their products, processes and work culture
with the new system. In other words, the replacement should be undertaken
together with product and process rationalisation coupled with work culture
transformation in order to optimise the returns from the new system.
This embracing of new technology requires tremendous effort in change
management, which demands extensive user training and re-engineering
of processes across the organisation. There is often resistance to change
and employee dissatisfaction during the transition. We believe this can be
countered only through effective communication and developing the right
business environment.
We have discovered that just 30% of recent replacement projects had active
CEO involvement. However our research shows that successful projects
require the backing of a strong leader from top management with a strategic
Executive Summary
mindset and the duty to see the project through. Strong leadership support
and a capable steering team (which can harness the banks 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.
Executive Summary
1
Core Banking Trends in
Asia Pacic
This section examines the trends in core banking transformation
among Asian countries and covers a wide spectrum of issues
ranging from pattern in deals, replacement approach, platform
selection, implementation and key architectural trends. The aim
is to learn from recent decisions and understand the market
dynamics of this region.
Core Banking Trends in Asia Pacic
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 Pacic
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
1.1 Prominent Recent Deals in the
Region
Major Asian Core Banking Deals in Last two Years

In keeping with the worldwide trend, Asian banks have been active
in replacing and upgrading their core banking systems in the last few
years. We believe high demand and competitive pressures are forcing
many banks in the region to improve their technical base.
Analysing the recent decisions, we noticed three signicant trends.
Firstly, more than 50% of banks that decided to replace their core
banking systems were small banks with an asset base of less than
$1 billion. Medium to large Asian banks are taking considerably long
to mull over the wisdom of replacing. Secondly, banks are increasingly
favouring the UNIX platform. Part of the reason for this observation is
that most of the recent deals came from small banks, for which the UNIX
platform is more feasible. Thirdly, no vendor dominates the region, but
Asian service providers have been given preference by banks while
vendors with strongholds in Europe and the United States nd it difcult
to develop a solid position here.
Looking at the geographic dispersion of recent decisions, we discovered
that the concentration of replacements has varied in the last two years.
However the Indian banking industry has taken a clear lead in core
banking transformation. Most of the deals came from state-owned
banks like Bank of Baroda, Allahabad Bank and Central Bank of India.
Market Trends
Core banking Trends in Asia Pacific
No vendor dominates the country but Infosys and TCS have taken a fair
share of the pie. There has been a distinct preference for local vendors
as they offer international-quality products and yet understand the unique
Indian requirements.
Leading Vendors in Asian Countries in Last two Years
In China, SAP clinched the core banking systems deal awarded by China
Minsheng Bank, marking the entry of this global vendor in the region.
Chinese banks are increasingly considering replacement; however
following implementation problems in a few Chinese banks, they are
now more cautious about taking the plunge. Taiwan banks did not enter
into a single deal in 2004 but showed sudden activity in 2005. I-ex has
emerged as the top vendor in this country.
The Philippines was rather subdued with just two deals in 2005 (as
compared with ve deals in 2004) both came from smaller banks and
were won by Nucleus Software. The last major deal in the Philippines
was that of Union Bank of Philippines which replaced its system with
Finacle of Infosys. Malaysia, on the other hand, continued to witness a
urry of activity with many small banks upgrading their ageing systems
primarily through local vendors.
Internationally, one of the biggest deals in the past year was for HSBCs
global operations, which was won by Temenos. The bank is understood
to be improving further on the present solution. Within the region, DBS
Banks core banking deal was another feather in the cap of Infosys, a
Core banking systems market

continued to be active in 2005
No vendor emerges as a
clear leader in Asian region,
but some vendors have
higher market share in certain
countries
leading player in the region, particularly in India.
Analysing vendor dominance in the region, we discovered that I-ex,
Infosys, TCS-FNS, Nucleus Software and System Access have been
popular among second-tier banks in Asia. For large banks, the preferred
vendors include Temenos, TCS, SAP and Infosys. Leading international
vendors such as Fiserv and Fidelity have shown little activity in the region
in the last two years.
TCS-FNS and Infosys are strong in this region, particularly in India.
Temenos, however, has had no signicant deal in Asia in the recent two
years though it continues to be a erce contender for deals from top-tier
banks across the world. Its last big project in the region was for Industrial
Bank of Korea.
Globally, Islamic banking is a fast growing sector with banks demanding
a system specically catering to this segment. Within Asia, Islamic
banking has been popular largely in Malaysia and Indonesia. The leading
vendors for Islamic banking in the region are Silverlake, Infopro and
Microlink who have done a fair number of deals in Malaysia.
In summary, we believe that international vendors have found it
difcult to establish a stronghold in Asian markets as there is distinct
preference for vendors who are perceived to have knowledge of the
unique local market conditions in addition to a solid track record.
Please see our section on vendor analysis for more details.

1.2 Geographic Dispersion of
Deals in Recent Years and
2006 Estimates
Number of Deals in Last two Years and Our Estimates for 2006
20
15
10
5
0
I
n
d
i
a
M
a
l
a
y
s
i
a
O
t
h
e
r
s
T
a
i
w
a
n
C
h
i
n
a
I
n
d
o
n
e
s
i
a
P
h
i
l
i
p
p
i
n
e
s
V
i
e
t
n
a
m
S
i
n
g
a
p
o
r
e
S
o
u
t
h

K
o
r
e
a
T
h
a
i
l
a
n
d
Number of deals in 2006(e)
Number of deals in 2005
Number of deals in 2004
Legend
Source: Asian Banker Research
Regional Breakdown of Deals Within Asia for 2005
India
50%
Malaysia
11%
Greater China
16%
Indonesia
5%
Philippines
5%
Others
13%
The deals include only core banking deals in the region. It does not include
other applications and systems such as treasury and trade processing.
We believe that activity for core banking systems will increase steadily in
the next 2-3 years in Asia Pacic. The trend in individual countries will,
however, vary based on local market conditions.
Clearly, India continues to dominate Asias core banking systems market
with its 50% share of the total core banking deals by commercial banks
in the region. This is because the emergence of technically advanced
Market Trends
Indian market is fast reaching
saturation; China and Taiwan
are opening up
private banks in the country has forced most state-owned banks to
substitute (and in most cases acquire for the rst time) a centralised core
banking system to improve their competitiveness and retain their market
share. However we expect the trend to slow down in the next couple of
years as most leading banks have already entered into core banking
deals. A few banks that have not yet upgraded their systems are nding
it increasingly difcult to compete and are currently evaluating available
products and vendors.
Taiwan witnessed a recent surge in core banking deals, though mostly
from smaller banks. In China, the number of deals has been rising slowly
but steadily as more and more banks evaluate the need for replacement;
however most of these deals have been from smaller banks. We expect
the current trend in both Taiwan and China to continue this year.
Malaysia has also been active with four deals in 2005, though most of
these were again from smaller banks. However we believe some big
banks like Maybank are actively considering core banking replacement.
We expect to see more core banking deals in Malaysia with Islamic banks
favouring local vendors who can meet Islamic banking requirements.
Most other countries saw just a few small deals with the exception of
Singapore, where DBS has entered into a core banking deal for its retail
business. Thailand and Korea were noticeably absent from the scene in
2005, but we expect activity in both countries to pick up over the next
couple of years.

1.3 Activity Within Countries and
Their Vendor Preferences
Activity in Banking Sectors for Core Banking Replacement in Last two Years
05 10 15 20 25 30
Vendor
Preference
International
Vendors
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
The level of activity is represented by the percentage of commercial banks
in each country that have awarded core banking system deals in the last
two years. It is based on number of deals and gives the same rating to big
and small banks.
We believe that almost 25% of the Indian banking sector has entered
into core banking replacement deals in the last two years. In absolute
terms, the number is far higher than that of any other country though
as a percentage of the whole sector, it may not be as signicant. Most
banks in this country have preferred local vendors owing to not just the
international level of expertise and reputation of the vendors but also
their higher level of trust in them. Contributing to this is also the fact that
many Indian vendors have advanced in these last few years to become
some of the leading vendors in the world.
Interestingly, the banking sectors of Thailand and Korea saw no new
deals in 2005 despite being active in 2004. However there was increased
activity in Taiwan and China. Increasing competition from foreign banks
in these countries is forcing banks to evaluate their core banking
replacement needs. We believe the core banking transformation in these
countries is set to accelerate over the next few years.
Market Trends
Indian banks have favoured
technical advancement through
local vendors
Other Asian countries expected
to continue to show demand for
core banking transformation
Most Chinese banks have shown a strong preference for systems
that are designed to suit their specic and unique requirements. For
this reason, smaller Chinese banks have preferred domestic vendors
while larger banks have preferred international vendors that can meet
their local needs. Similarly, many Malaysian banks have preferred local
vendors that can meet their Islamic banking requirements.
Banks from developed markets like Singapore and Hong Kong have
rst-generation technical sophistication and are undertaking a cyclical
replacement of their ageing systems. In contrast, banks in countries like
India, Pakistan and Vietnam are purchasing core banking systems for
the rst time now. For obvious reasons, activity among the banks that
lack technical sophistication will increase.
We believe that most Asian banks prefer to select vendors that either
involve local people through a setup in their country or partner local
vendors. This is because there is a perception among the bankers that
a local is more likely to understand and adapt to the unique local needs
of a particular country. However in many countries, the availability of
international-quality products from local vendors is a limiting factor which
has forced banks to look for alternatives.
China banks have preference

for systems that cater to their
unique needs
1.4 Estimates of System and
Software Spending in Asia
Pacic
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
(%)
($mi l l i on)
0.10
0.13
0.12
0.11
Estimated spending by Asian banks on purchase of CB systemsoftware and services
Legend
Spending as % of total revenue of Asian banks
The estimates of investments only cover the cost of system software such
as licence fees and the service cost. It includes only core banking systems
replacement by banks and excludes other system applications such as
treasury and trade processing.
We have discovered that the cost structure of core banking deals varies
considerably due to multiple factors such as the scale and complexity of
the replacement process. However, generally, we believe that the total
investment required to purchase core banking systems is made up of
software and service cost which constitutes 30%, system integration
cost of 20-25% and hardware and infrastructure cost of 45-50%.
Based on our analysis of recent deals, the system and service cost for
a small bank (with a size of $1 billion or less) comes to $5 million-10
million. For a medium-sized bank ($1 billion-50 billion), it is $25 million-
30 million. For large global banks (more than $50 billion), the deal size
is likely to be higher depending on the extent of transformation being
undertaken.
Market Trends
Steady increase in spending
likely to continue; no signicant
jump expected in near future
Deal sizes have varied from
about $5 million for small banks
to more than $50 million for
large wholesale banks
A critical cost item is system software cost; this includes the cost of
software licences, which varies depending on project. For example, for
FNS customers, software licence cost has varied from $1 million to over
$7 million, with an average of $1.8 million in 2005.
Overall, we have seen a steady rise in investment made by banks in
Asia over recent years. We expect the trend to continue. However, as
a percentage of total revenue, we believe the investments are likely to
show a declining trend as the banks have witnessed even higher growth
in revenue. We also believe that there is stiff price competition among
vendors and that this will keep the costs in core banking replacement
under control.

1.5 Evolution and Convergence of
Core Banking Systems
Evolution of Core Banking Systems
Business Platform J2EE, .NET
EAI, BPM, WS
Parameterisation
Legacy
systems
1970 1990 2004 2005
Web XML Web services Service-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 rst generation of banking technology was represented by the IBM
mainframe, which had immense data processing capabilities but was not
as efcient in back-ofce accounting functions. Nonetheless its reliability
Technical Trends
Evolution of core banking
industry in Asia shows
increasing convergence of
technologies and focus on
architecture of systems
and scalability remain unbeaten today. In the next stage of evolution came
parameterisation of processing rules and enhancement in automation
from back- to front-ofces. Here, the UNIX platform solutions have
shown high functionality, with some of them using relational database
technology to maintain accounting and administrative data.
UNIX systems have borrowed ideas freely from mainframes such
as logical partitioning, the ability for isolation, the ability to share
across partitions, and common interfaces. Integration tools and other
technological advancements have brought about a certain level of
standardisation and convergence of technologies today at the platform,
application and architectural layers.
Banks are increasingly looking for solutions that have the technical
capability to meet their unique functional requirements while improving
their competitiveness. There is also increasing demand for component-
based modular systems that do not have integration issues.
Trends in Requirements
Architecture that supports flexibility, growth and services such as
Service Oriented Architecture (SOA)
Systems capable of global deployment multi-channel, multilingual
with high connectivity
Customer centric focus with increased connectivity across
processes and functions. Integrated solution increasingly available
Convergence of old and new technology with increased scalability
and flexibility
Service Oriented Architecture (SOA) is a relatively new concept that
has gained popularity quickly. Herein, business applications are
constructed from independent reusable interoperable services that can
be recongured without a vast amount of technical labour. The concept
is based on web services and components that are brought together to
perform specic business tasks. It essentially means reducing barriers in
antiquated infrastructure and creating a real-time integration of disparate
systems and a sharing of databases on a exible and easily upgradeable
infrastructure. We discuss this in more detail in section 5.
On the architectural front, J 2EE and .NET are two architectural frameworks
that have evolved in the last few years. These are new-generation exible
Banks need to adopt Service

Oriented Architecture
and interoperable architectures that facilitate the complete meshing of
core banking solutions with the complex technology fabric of the bank.
The key attributes that banks require from their architecture are exibility,
scalability and agility. With customer expectations increasing, banks have
moved towards centralised systems with customer-centric architecture,
where they drive the business through a single view of the customer and
the paramount consideration in all decisions is the consumer.
IT Service Providers in the Region
Vendor consolidation through mergers and acquisitions.
Partnership among vendors to mix and match solutions.
Standard protocols and fierce competition among IT service
providers leading to increased product offerings and price
competition.
The growth in demand for core banking systems in Asia Pacic has
prompted many international vendors such as SAP, Temenos, Fidelity
and Misys to focus increasingly on the region. At the same time, vendors
that began their operations in Asian countries have grown to become
recognised names across the world; these include companies like
Infosys, I-ex and TCS.
Desire to become the leading player in the market has led to mergers
and acquisitions among IT service providers. At the global level, Fidelitys
acquisition of Sanchez broadened its reach to a larger collection of
banks. Among leading vendors in Asia, TCS acquired FNS in a leap from
their previous alliance. Another example of consolidation in the industry
is Oracles acquisition of a stake in I-ex. These players are developing
an increasingly strong foothold in the core banking systems market.
Greater convergence makes it difcult for bankers to differentiate
between vendors value propositions. However standard protocols and
erce competition have led to more product offerings and price wars a
boon for the industry as a whole.
Asian vendors are increasing

their global reach
Desire to become leading
player has led to consolidation
in the industry
1.6 Technology Integration in
Asian Countries
Technology Integration in Asian Countries
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
Australia
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 and
architectures in several Asian countries. We discovered that the
integration of technology and the movement from account centricity to
customer centricity have varied signicantly among Asian countries.
Developed countries such as J apan, Singapore, Hong Kong and Australia
have shown distinct technical advancement not only on the core banking
front but also in their banking systems architecture, achieving customer
centricity through integration.
On the other hand, developing countries like China, Thailand, Philippines,
Indonesia and Malaysia are far behind. These countries are now moving
towards data centralisation (having advanced from branch automation),
but many of the banks have yet to achieve core banking sophistication.
Architectural integration is still at the initiation stage in these countries.
However we believe that competitive pressures are forcing banks to
expedite this process.
In India, relatively new private banks have given a new direction and a
signicant boost to core banking integration in the banking sector of this
country. State-owned banks are already beginning to arm themselves
with more integrated systems to face this competition.
Technical Trends
Developed countries have
shown distinct technical
advancement
1.7 Trends in Platform Usage
Among Asian Countries
Recent Core Banking Acquisition Trends Among Asian Banks
South Korea
China
Pakistan
Taiwan
India
Vietnam
Singapore
Primarily UNIX-based
System Users
Japan
Hong Kong
Philippines
Thailand
Malaysia
Indonesia
Primarily Mainframe-
based System Users
Likely to shift to UNIX
Traditionally, Asian banks particularly those in Korea, J apan and China
use mainframe-based proprietary systems. The robustness, stability
and scalability of these systems have been proven over the years and
continue to attract these banks. But in the last ve years, market dynamics
have changed considerably and banks are increasingly considering the
UNIX-based systems.
The shift in preference has been brought about by competitive pressures
in the market which have forced banks to look for systems that can meet
their functional requirements with exibility and agility. Accelerating
the trend is the fact that most Asian banks are smaller compared with
many European and multinational banks and hence UNIX systems are
considered adequate for their scalability requirements. Another major
factor that draws many bankers to UNIX is the cost savings. Changes in
regulatory requirements (under Basel II) have also forced banks to look
for an integrated and exible system.
For these reasons, we have seen an increasing shift among Korean
and Chinese banks towards UNIX-based systems. However J apan and
many South East Asian countries still seem to be adopting a wait and
Technical Trends
Many countries continue to be
primarily mainframe users but
there is a strong shift in favour
of UNIX systems
Competitive pressures and cost
effectiveness of UNIX-based
systems are driving the shift
see approach. In mature countries like Singapore, there are very few
deals as well; but in the countrys most recent deal, DBS opted in favour
of a UNIX platform.
In the Indian subcontinent, most commercial banks are adopting
core banking systems for the rst time. Thus most banks have taken
advantage of this new-generation technology. As there is no problem
of integrating with the existing system, implementation is cheaper and
less complex. Moreover, the traditional preference of Indian banks (and
Indian vendors) is for a UNIX environment.
While smaller Asian banks have favoured UNIX-based systems owing
to their cost effectiveness, we believe that mainframe has proved to be
more reliable and scalable for a larger size of operations. As transaction
volumes increase, the total cost per user in mainframe decreases,
making it more competitive.

1.8 Trends in Deployment
Approach
Deployment Approaches in Recent Core Banking Decision
Long
Duration
Existing
Implementation
Time
Short
Duration
Gradual Implementation Big Bang Implementation
Implementation
Approach
Singapore
HSBC
Bank
China
Minsheng
Bank
Central
Bank of
India
Allahabad
Bank
Muslim
Commercial
Bank
Bank of
Panshin
Union
Bank of
Philippines
Bank of
East Asia
Hua Xia
Bank
Industrial
Bank of
Korea
Cathay
United
Bank
State
Bank of India
DBS
Bank
China
Development-
Bank
Bank Asset Size
More than
$100 billion
$20-100 billion
Less than
$20 billion
The banks have two options in deployment. Big Bang implementation
largely involves a new system which goes live at the same time that
all the processes are shifted onto it. This is believed to be the quickest
but probably also the riskiest way to deploy the project. While the
risks are high, the integration problems are minimised as old and new
systems do not coexist. A phased approach, on the other hand, involves
gradual deployment across branches/functions generally through big
bang in small clusters. Here, the banks have to face the sticky issue of
coexistence of two systems.
Our research shows that in Asia Pacic, the traditional phased deployment
approach is distinctly preferred for its reduced risks and gradual change
in processes. Though the choice of approach varies with banks unique
requirements, top-tier banks in general have preferred the gradual
approach. This is because their scale of operation makes big bang not
only extremely difcult but in some cases also unfeasible.
Most banks with an asset size greater than $100 billion have preferred
phased deployment and the time required has stretched over many
years. For example, it is expected to take about ve years for HSBC.
Similarly, ABN AMRO plans to gradually implement its system in the
Greater China region and some other Asian countries over a period of
Technical Trends
Bigger banks continue to prefer
gradual deployment while some
smaller banks choose big
bang approach
ve years. For State Bank of India and Central Bank of India, it is likely to
be around four years. We believe that it is critical to keep the rollout time
and the period that two systems coexist as short as possible.
On the other hand, a few smaller banks have taken the quicker approach
of big bang. These include: Union Bank of Philippines whose system
by Infosys was implemented in just one year; Industrial Bank of Korea by
Temenos; and Cathay United Bank, Taiwan by TCS-FNS.

2
Bankers Perception
Survey on Core
Banking System
Selection
We have conducted a series of surveys in the Asian banking
sector to strengthen our research on various aspects of core
banking transformation. Our surveys have given us an insight
into how bankers assess various vendors in the region, key
considerations in the selection of a new system, and platform
preference among Asian banks. We have discovered that some
of the common perceptions lack sound foundation.
Bankers Perception Survey on Core Banking System
Selection
2.1 Survey results on key reasons for replacement
2.2 Survey results on factors considered in system selection
2.3 UNIX versus mainframe survey results on considerations in
system selection
2.1 Survey Results on Key
Reasons for Replacement
Perception Survey on Key Reasons for Replacement
% of executives citing area as a problem
10 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 Pacic countries last year found that inexibility,
high cost and difculty of integration were the three main problems that
banks faced in legacy systems.

Bankers Perception Survey
2.2 Survey Results on Factors
Considered in System
Selection
Perception Survey on Factors Considered
R
a
n
k
i
n
g
Importance
Cost
Short product time-to-market
Availability of third party applications
Ease of integration
Vendor reputation and track record
Straight through processing/ real-time capability
Truly modular and integrated, single sign-on
Functionality
Scalability
Reliability/ stability
With increasing standardisation and convergence, banks believe that it
is now easier for them to switch from one vendor to another for multiple
systems. To assess the importance that banks give to various parameters
of selection, we conducted a survey a few months back.
The survey highlighted the importance of cost in the selection of a core
banking system in Asia. Most banks considered cost savings through
lowering of maintenance cost or operational cost as one of the key
benets that was motivating them to change their core banking systems.
Another key reason cited by many bankers was their desire to improve
competitiveness through faster rollout of products, product innovation
and differentiation. Availability of third-party applications and ease of
integration were other critical factors that the bankers looked for in system
selection. Vendor reputation and track record also came high in the list.
Trust in the vendors ability as well as the vendors reliability and t with
the project are often cited as considerations in the selection process.
Interestingly, architectural features such as STP, exibility and scalability
were much lower in the list. However, we believe that these are essentially
the features that will determine the functionality of the system in future.
The survey results indicate that many bankers tend to give undue
importance to cost and other considerations in their selection process,
which often leads to awkward consequences
Cost remains the key

consideration when choosing
a core banking system,
regardless of platform
2.3 UNIX Versus Mainframe
Survey Results on
Considerations in System
Selection
Perception of Strengths of Each System

Interestingly, mainframe systems
are perceived as old, while UNIX
systems are perceived as new,
which is not always true.
Stability
Old
Architecture
More Vendors
vs Monopoly
Scalability Application
Availability
Instability
42
32
21
37
47
37
11
5
MAINFRAME SYSTEMS UNIX SYSTEMS
Availability of
Internal Skills
Many banks in Korea and J apan
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 saw
as the strengths and weaknesses of UNIX and mainframe systems. We
found that while there are an increasing number of banks favouring UNIX
systems due to low cost of ownership, scalability and recent technical
advancements, stability is still perceived to be the biggest strength of
mainframe systems.
According to one banker, keeping legacy systems running consumes 60-
70% of IT budgets, leaving little resources for technical enhancements
to gain competitive advantage. According to one bank in Korea, When
we purchase a UNIX system, we enter a buyers market as there are
many products available and we can choose. But when we purchase
mainframe, we enter a sellers market and may have to wait. Another
banker feels that while UNIX technology is improving, it may not match
the scalability of mainframes yet.
Banks that have invested in their system are aware that a considerable
amount of time, money and effort is involved in customising and adapting
these systems. Replacing these systems is a painful and risky exercise.
However the fact remains that many of these legacy systems are unlikely
to give banks the innovation and technical advancement that can be
provided by solution providers who have been constantly upgrading
Stability is the biggest

perceived strength for
mainframe systems, while lower
TCO is the biggest perceived
strength for UNIX systems
their technology. Banks are increasingly realising that their expertise is
in banking and not IT development.
According to a leading global vendor, Asian banks have always been
very interested in UNIX solutions and so, proportionately speaking, we
have more UNIX centres in Asia than in the United States. We believe
this is because the core banking market today is dominated by Indian
banks, which have traditionally preferred UNIX-based systems.
While the debate over preferred technology continues, it goes without
saying that what may be considered suitable by one bank may not be
appropriate for another bank. For example, big banks with an extensive
scale of operation may nd it risky to switch from mainframe systems to
UNIX technology primarily because of complexities, high risks and huge
costs involved in the process. However a small bank which is building its
core banking system from scratch (or replacing it) may prefer lower-cost
open systems.
Open Versus Proprietary Perception of Features
Strengths
Weaknesses
Strengths
Weaknesses
Reliability - Highly reliable
Scalability - Highly scalable, essential for larger banks
Robustness - Robust applications with good track record
Security - Substantially higher levels of system security
Cost - Cost to acquire and maintain
Agility - Perceived slower development and adaptations
to trends in technology
Hardware/Software - Fewer hardware and software
suppliers can lead to challenges in negotiating a
reasonable pricing if the bank does not posses sufficient
bargaining power
Skills - Smaller and hence more expensive pool of
skilled resources available in the market
Cost - Perceived lower total cost of ownership (TCO).
However, in real life operations, the TCO in complexity of
operation increases with the numbers of users and
transactions volume
Architecture - Considered more flexible architecture. Our
analysis however shows that some of the mainframe
solutions have a more contemporary architecture
"Add on's" - Perceived higher availability of third party
applications. However, our analysis shows that such
applications can also be integrated into mainframe
architectures
Hardware/Software - More choice of hardware systems,
and application software provider
Functionality - Integrated universal Banking solution
often provide higher level of functionality (at the cost of
scalability)
Skills - Larger pool of skilled resources available in the
market
Reliability - Less stable than mainframe systems (but this
could be acceptable for smaller banks)
Scalability - Lower level of scalability. Scalability comes at
the cost of overly complex operating environments
Security - Lower level of security than mainframe
systems. Viruses have been found in Unix based
environments
Deployment -Not yet proven on large scale though
becoming increasingly popular among smaller banks
UNIX SYSTEM Mainframe SYSTEM

Open systems have proved their ability to perform from the security and
technology points of view. According to one banker, 5-10 years ago a
large bank would go for mainframe, no questions asked. But in the last
5-10 years things have changed. Any bank today, no matter how big,
may consider switching to open system.
On the other hand, most big banks still favour the reliability and stability
of mainframes. Some bankers are inclined towards proprietary systems
as they are used to working on them. Switching to a new technology
would not only involve a huge amount of cost and high risks but also
require effort to get used to the new processes.
According to one vendor, Open systems are most appropriate for Asian
banks due to their smaller size compared to many international banks.
They dont need the scalability of mainframes and the scalability of open
systems has really increased in recent years. One leading bank in Korea
states that the trend in Korea today is to shift towards UNIX systems
from IBM due to the availability of small packages that can be easily
integrated in our system [whereas] when we use mainframe we need to
code them which would be a time consuming proposition.
The right choice varies with banks requirements
As can be seen from the survey, platform choice is a dilemma that all
bankers face when they consider replacement. Our in-depth analysis
shows that for smaller Asian banks, a UNIX platform could be more
feasible as they may not need the scalability of the mainframe and UNIX
can be cost effective for a small number of transactions. However our
research shows that for large retail banks, mainframe is likely to still be
the preferred choice because:
It is more reliable and keeps the system running through most upgrades.
Hence the downtime is low.
It has the capability to support a large number of users, supports
multiple applications and allows better resource management. This is
especially important where transaction volumes are high.
It requires less server capacity than UNIX for the same amount of work
and has higher continuous availability (due to less downtime).
On the cost issue, UNIX-based systems are generally believed to have
a lower total cost of ownership (TCO). However the benchmark, we
believe, should not be total cost of ownership but total cost per user. Our
research indicates that when the bank has large volumes of transactions
and users, the operational cost of mainframe could be lower on a per-user
-
-
-
Strengths and weaknesses of

proprietary and open systems,
as perceived by respondent
banks
Our research and analysis of
the platform features reveal a
different picture
basis. Also, while making the cost comparison, banks must consider the
switching costs (shifting from existing mainframe to UNIX) and the cost
of the coexistence of two systems during the replacement process.
Please see our section on platform choices in section 4 for more details
This page has been left intentionallly blank
3
Core Banking System An
Overview
There are various denitions of core banking system circulating
in the market. We have dened the core banking system (as we
see it) and researched on aspects that are (and also those that are
falsely believed to be) included in the replacement. This section
provides an overview of the replacement and transformation
process. We believe there should be clarity on the components
of core banking system replacement even before the process is
initiated.
Core Banking System An Overview
3.1 Core banking system an introduction and denition
3.1.1 Denition of core banking system
3.2 Overview of the core banking system replacement project
3.3 Approaches to replacement
3.1 Core Banking System An
Introduction and Denition
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 difcult 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 inexibility demands lengthy
development cycles
No/Limited Basel II Support New and more complex Basel II-driven
risk frameworks are not supported
Due to such perceptions, the business users demand an immediate
replacement of the core banking systems. Here are some examples of
the justication given for this investment to address all of these issues:
We are losing market share. We need to replace our core banking
system now to increase our competitiveness and regain lost markets.
We need to replace our core banking system to have a better
understanding of our customer.
We need to replace our core banking system to be able to bring new
products to the market faster.
We need a core banking-enabled product factory.
These and similar statements are what we hear when talking to leading
bankers throughout the region.
The software vendors of course are responding to these needs, by
claiming:
-
-
-
-
-
-
-
-
-
Perceived needs justifying

replacement of core banking
system
Core Banking System Overview
Our system will transform your organisation and make your bank more
competitive.
With our system, you will be able to signicantly 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 reect what their
clients can expect from a core banking replacement project?
To answer these questions, it is necessary to clearly dene what a core
banking replacement really is
3.1.1 Denition of a core banking system
We have discovered that there are multiple denitions of core banking
systems today. However based on our discussions with industry experts,
we can dene core banking, in simple terms, as a highly efcient customer
accounting and transaction processing engine for high volumes of back-
ofce transactions. The purpose of a core banking system is thus to
give banks the ability to process large transaction volumes in a fast and
efcient way; clearing, transfers and interest/fee calculation are all the
fortes of core banking. But let us explore this in more detail and look at
some of the myths regarding core banking replacement projects.
What Core Banking Systems Do
A core banking system is a transaction processing engine with customer-
level accounting and reporting of the deposit and loan products processed
in the bank.
Core banking also deals with transactions such as interest and fee
calculation, pre-processing for statement printing, end-of-day processing,
and consolidation of daily individual transactions as
-
-
-
-
-
-
Core banking system is simply

the core processing power of
the bank
Core Banking System is Transaction Processing Engine
Deposits Loans
Common Services
Product Definition & Management
Core Banking System
C
h
a
n
n
e
l In
te
g
ra
tio
n
A
p
p
lic
a
tio
n
In
te
g
ra
tio
n
R
e
p
o
rtin
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 systemand a separate
project
Replacing the General Ledger is a
separate systemand 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 banks GL system
according to its chart of accounts structure for the daily trial balance
sheet preparation. The chart below illustrates the scope of a core banking
replacement project.
What Core Banking Systems Do Not Do
Core banking systems do not deal with the customer-facing front end
of the bank. Core banking systems also do not deal with the analytics
embedded in an industrial-strength data warehouse design.
Core banking systems do not include a comprehensive CIR (Customer
Information Repository) though they do include a CIF (Customer
Information File) or CIS (Customer Information System) focused on their
own processing and reporting needs. These components have only the
necessary customer information or capabilities embedded.
In a Service Oriented Architecture solution, the CIR will sit on top of
the core banking systems, as it is assumed that a bank will always
have multiple core systems which need to interact and share customer
information. The chart below illustrates a typical banking architecture
and shows where the key components reside.

Conceptual Application Architecture Framework
Sales & Service
Delivery
Business
Intelligence
Core Systems
Delivery Channels
Application supporting the
banks 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 banks 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 Management
Document Imaging Capability
Core Banking
Deposits Loans
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
To start an effective core banking replacement programme, the bank
must manage the expectations of all parties involved. Therefore we
believe that it is very important to clearly understand what a core banking
replacement really is. In some cases, a bank might not even need to
change the core banking system but just refresh an ageing front-end
system. In other cases, a bank might need to do both, i.e. replace the
core banking system and simultaneously replace the front-end systems
of the bank. This of course is a project of much greater magnitude and is
analogous to changing the wheels in a fast moving car.
What you see is not what you get
Many banks evaluate core banking systems based on functions and
features. The objective is to get as many bells and whistles as possible.
As the initial selection is very much driven by the business user, the
vendor would score highly with a pretty front end and usability.
The irony here is that the user will not get what he sees. We have
discovered that it is a common and understandable misconception of
business users that front-end screens relate to core banking. This more
often than not leads to sub-optimal results for the core banking project.
It is crucial to recognise that what the user sees is the front end of a
banking application architecture (a teller system, an advisor workstation,
a kiosk or an internet front-end) but not the core banking system. Core
Critical for banks to understand

what they would get in core
banking replacement
banking is about raw processing power: transaction throughput, interest
and fee calculation, parameterised product setup, clearing, interfacing
with existing systems and transaction sources, etc. The good-looking
screens have little to do with critical aspects of core banking and are no
indicator for the quality of the core banking system.
To make matters more complicated, it is often important to also change
the front-end applications, to better reap the benets of the core banking
replacement. For the front-end replacement, it is critical to make sure
that the front-end applications can be integrated with the back-end
systems with minimal effort. For a contemporary core banking and front-
end replacement project, it is advisable to deploy SOA and an enterprise
service bus.
To deploy a front-end solution for a new core banking project, there are
three options:
Package solution with minimal customisation: This is typically
the going-in position of banks that are accustomed to best of breed
package implementations. The potential advantages are faster
implementation and lower customisation costs. However, the bank
that takes this approach must be determined to follow through and
use the package capabilities as provided. Many banks nd it difcult to
sustain this approach as the project progresses and the limitations of
the package become clearer.
Package solution customised to the banks desired processes:
This approach requires the bank to dene its multi-channel front-end
operating model, processes and performance metrics prior to selecting
the front-end package. The advantage of this approach is that the
upfront design can help establish a realistic business case and give
clear requirements for vendor selection and contracting. However, this
approach requires experienced business process designers capable of
dening the future operating model of the bank.
Custom built solution: This approach requires technical and business
process designers capable of dening 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
benets from core banking
replacement
Same vendor for front end and core banking: Here, front-end and
core banking replacement solutions, though separate systems, come
from the same vendor and the vendor is responsible for integrating the
front- and back-ofce 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 benets 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 t with the
solution chosen. Moreover, who decides what is best of breed?
-
-
We recommend that banks
choose the same vendor for
core banking and front end
3.2 Overview of the Core Banking
System Replacement Project
Core Banking System Replacement Project an Overview
Reasons 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 complex
and high-risk proposition requiring substantial resources and time. Most
banks prefer to defer the decision till the change becomes imperative.
The decision making process includes providing nancial and business
justication to the management and evaluating the risks and returns; it
is a time consuming process that requires the involvement of not just the
IT people but also decision makers across functions. We believe that
opportunity costs are high and hence a successful bank is one which
can take fast decisions and has adequate management support to carry
them through.
Risk-return analysis has to be coupled with development of business
objectives, gap analysis of the existing infrastructure and delta analysis
of future needs. We believe that it is critical at all stages of selection
and implementation that banks keep business objectives in mind as the
primary consideration.
Core banking replacement is

almost like a heart transplant
involving high cost, high risk,
and substantial effort and time
Core Banking Replacement Stages
Replacement Stages Through the Project
E
f
f
i
c
i
e
n
c
y
/

P
e
r
f
o
r
m
a
n
c
e
Project
start
Euphoric
"We will change
the world"
Disillusioned
"This is hard but we
have passed the
point of no return"
Reality Strike
"The honeymoon
is over"
Scapegoating
"Its somebody else's mistake"
"How can we get out of this"
The Emperors 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 Banking 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 J apan and Korea
Ownership of hardware
System integrator hired for
software
Vendor customises, integrates
and implements solution
according to the banks
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 J apan, Korea and China). This is primarily due to the complexity
of their operations and their desire for exibility in developing a system to
meet the unique requirements. However this requires extensive capital
investment and channels substantial resources away from the banks
core business.
The debate on Build versus Buy continues among a few top-tier banks
that have the ability to build their own systems. But increasingly, banks
are awakening to their shortcomings as an IT developer and becoming
more inclined to focus on their core business instead.
Banks select a replacement approach based on their individual
requirements. For example, HSBC has chosen a middle path by taking
Temenos as its partner in co-developing an international core banking
system. The bank and the IT company would thus pool their resources
and technologies to develop the best solution.
Banks approach to core

banking replacement depends
on the availability of nancial
and human resources
Buy vs. Build
The substantial cost, resources and expertise involved in building a
new system has forced many banks (particularly medium- and smaller-
sized banks) to turn to purchasing packaged systems from vendors and
thereafter customising to suit their requirements (either by themselves
or asking a system integrator to customise). For example, State Bank
of India hired TCS as its system integrator; TCS purchased the system
from FNS and customised it to meet the banks needs, and then the
bank itself implemented the nal system.
We have discovered that many medium-sized banks want a vendor
that provides (or purchases) the system software and implements it.
Cost issues aside, this approach is more feasible for banks that lack IT
resources or prefer to have the technical expertise of the vendor due
to the complexity of the task. It has been used by various banks in the
region such as Union Bank of Philippines, Industrial Bank of Korea,
Central Bank of India and Ta-Chong Bank. However the customisation
should be more on the front end while the main package should provide
the requisite core processing power.
Some banks may prefer a third alternative: complete outsourcing
to an application service provider (ASP). This frees up resources for
banks as they need not own the hardware or the software for their core
banking activities. Management of the data centre and branches may be
outsourced to a vendor that is adequately equipped and has a proven
track record in providing these services. In return, the banks could pay
the ASP on a per-transaction or per-branch basis.
While a few second-tier banks in Australia and J apan have turned to
outsourcing, this approach is gaining more attention in other Asian
countries only now. In line with this trend, HP recently signed a ten-
year outsourcing contract with Bank of Baroda, wherein it will implement
and manage an enterprise-wide SOA including a core banking solution
(provided by Infosys) across the banks domestic and international
operations. Several small cooperative banks in India that do not have
adequate resources but nd it essential to enhance system quality (to
face the competition in the market) are also understood to be taking this
approach.
Essentially in outsourcing, the costs are lower compared to in-house
development and, more importantly, the complex technological projects
are left to experts who offer economies of scale. This frees up the
banks capital and other resources and takes security concerns away
from the bank. However some reasons often cited against outsourcing
are: security risk, difculty in maintaining competitive advantage as the
ASPs services are the same for other banks, and country risk involved
when outsourcing overseas.
Increasing shift towards

packaged solutions among
smaller- and medium-sized
banks
Outsourcing an option
considered due to low cost and
vendor expertise
4
Phases of Core Banking
Replacement and
Critical Considerations
Replacing a core banking system is a complex and high-risk
proposition. This section analyses in detail the key requirements,
critical considerations and challenges in each stage of the core
banking system replacement project. Going further, we discuss
the factors that we believe are essential ingredients for success.
This section is targeted at both business decision-makers as well
as IT people involved in the transition process.
Phases of Core Banking Replacement and Critical Considerations
4.1 Phases of core banking replacement an overview
4.2 Timeline of replacement project stages
4.3 Phase 1 business justication and blueprint
4.4 Phase 2 selection
4.4.5 Selection process
4.5 Phase 3 implementation
4.6 Phase 4 deployment
4.7 Risk mitigation
4.8 Financial implications
4.1 Phases of Core Banking
Replacement An Overview
In our analysis of best practices for core banking replacement, we
have identied four key phases required for a successful core banking
replacement project, namely:
Core Banking Replacement Project Phases
Understand Business Imperatives
Achieve Consensus on Business
Driver &Approach for Core
Banking Replacement
Define Core Banking
Transformation Strategy eg.
Replacement or Transformation
Develop DeltaTransformation
Blueprint
- Business Scope &Objective
- Reference Technical &Business
..Architecture
- PlatformPreference
- 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
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
4 - 6 Months 4 - 6 Months 18 - 24 Months
Dependent on Chosen
Deployment Approach
Source: Immacon SOBIT Methodology
The Business Justication and Blueprint Phase sets the stage for the
core banking replacement project. During this phase, a bank takes stock
of its current environment, revisits its business strategy and establishes
business drivers for its future technology and process infrastructure.
The Selection Phase is when a bank shortlists suitable vendors and
integrators and decides on the vendor management approach. As a
project of this magnitude cannot, in most cases, be done by one vendor/
integrator, it is important at this stage to decide on which of those hired
will be the prime vendor.
Delta Driven Implementation is recommended over the traditional
Gap driven approach. The disadvantage of the Gap driven approach is
that the specications for the new system, more often than not, resemble
a detailed description of the existing Old World legacy system. In
We divide core banking

replacement into four phases
The Phases Of Core Banking Replacement
contrast, the delta driven approach focuses on requirements beyond the
existing legacy systems. This approach looks at the future operation, the
New World, and how a bank can optimise the selected core banking
solution. The objective is to develop a legacy free environment as soon
as possible.
The Deployment Phase is the nal stage of any core banking project.
In this phase, the enterprise-wide deployment of the new core banking
system is conducted. To be successful, it is important that both bank and
vendor have agreed at the outset on one deployment approach. The
most debated options are the big bang and the phased deployment. In
addition, there are a number of variations to these two popular options.

4.2 Timeline of Replacement
Project Stages
Core Banking Replacement Project Phases
Project Phases
Business
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
4 - 6 Months 4 - 6 Months 18 - 24 Months
Dependent on Chosen
DeploymentApproach
As time management guru Alan Lakein has taught us, failing to plan is
planning to fail. Thus the rst phase of the core banking replacement
project provides an overall plan for the initiative. It is important for business
decision-markers to agree on the business objectives and justication
for the replacement, followed by detailed planning of what should be
achieved with the new core banking solution. At this stage, we believe
that it is also important to decide if the core banking replacement project
should be approached as a transformation or as a replacement project.
Wavering in the objective of the project would be a costly mistake.
Our research shows that a typical core banking project takes 18 to 24
months from the time the bank acquires a solution to the commencement
of deployment. Smaller banks using a proven solution with little or no
customisation can of course expedite their schedule. The chart below shows
an illustrative implementation schedule of a typical core banking project.
Illustrative Core Banking Implementation Project Schedule
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Phase 1: Business J ustification &Blueprint
Assess Current Operations
Understand Business Imperatives
Blueprint & Visualise Future Operations
Prepare Implementation Roadmap
Develop Business Justification
Phase 2: Selection
Issue RFP & Receive Responses
Issue RFI / Refine Vision
Select Systems & Service Provider
Conduct Negotiation & Contracting
Phase 3: "Delta" Driven Implementation
Detailed Design
Delta Analysis
Build & Test
Pilot
Phase 4: Deployment
Training
Logistics
Change Management & Communication
Go Live
Fine Tune
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 change
management and business transformation efforts.
The selection timeframe is dependent on the number of vendors involved
and the level of detail required by the RFI and RFP documents.
A typical core banking

replacement project takes 18-
24 months though the duration
varies with the extent of change
and size of bank
4.3 Phase 1 Business
J ustication and Blueprint
Objective: Develop business objectives and establish the vision and
justication for the target future state.
Core Banking Replacement Justication & Blueprint Development
Sign Off
Understand
Business
Imperatives
Assess
Current
Operations
Blueprint &
Visualise the
Future
Operations
Prepare
Implementation
Blueprint
Develop
Business
J ustification
Business
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
Project Stages
Key Requirements From Core Banking System Replacement
Integration - Seamless integration of system and operations for
time saving and cost effectiveness
Single Customer View - Ability to have easy access to a single and
precise view of customer relationship
Product Factory - Customer-centric system that facilitates develop-
ment and deployment of new products and services with ease and
real-time information
Straight Through Processing - Improved, faster and comprehensive
banking functionality
Multi Channel Sales & Service - Ability to implement cross channel
sales effectively and efficiently
Data Warehouse - Large volume of data made easily accessible to
facilitate quick decision making
Flexibility - Ability to adapt to constantly changing requirements of
business in future
Developing business objectives
of core banking system
replacement
While banks are awakening to the need of advanced and more exible
systems to meet the requirements of banking industry today, we believe
that each bank needs to initiate the process by developing clear business
goals and objectives of core banking replacement to meet its own unique
requirements. These objectives would facilitate involvement of business
into the project (which would otherwise have the risk of being seen as an
IT project) and also would give clear directions to the selection process.
Assessing business demand, future business directions and anticipating
future requirements would ensure that the bank can suitably select the
system that can meet its expectations. The ability of ageing IT systems
has become limiting factor for ambitions of future growth. In many banks
numerous back processes are as a consequence of maturity of a 10-15
year old system. New systems are now required to provide considerable
synergies and efciencies towards meeting long term targets.
While the broad requirements from the system functionality would be
similar for most banks, unique requirements would vary. Improving
competitiveness and garnering market share is one common objective
cited for replacement. In some banks it may actually be a case of survival
rather than choice that forces the management towards replacement.
A global bank is likely to require more scalable system with multi-
channel, multilingual capability across geographic locations. Similarly
Banks in India and Pakistan may believe that product differentiation
and service oriented features are more important to meet the needs of
growing middle class and maintaining competitiveness. For example in
growing economies banks would rather grab a larger chunk of market
share than just riding on growth. These unique needs should guide the
bank in developing its long term strategic objectives.
These Business objectives should in turn act as key guiding factor in
establishing selection criteria. These should be forward looking to ensure
suitability of the new system in long term as a bank replaces its system
once in 10-15 years. Nonetheless in todays fast paced environment it is
extremely difcult for one to judge what the face of market would be after
few years and hence the bank has to ensure exibility in the system.
Our research into replacement case studies shows that it is imperative
for banks to take stock of their current operations in the old world
environment, and comprehend the technology infrastructure and
shortcomings. Thereafter, the banks should understand their current
business imperatives and anticipate future needs. These should be the
key drivers for the core banking replacement strategy. Yet, we have
Banks need to initiate the

process by developing clear
business goals
Requirements for core banking
system varies between banks
Business objectives should be
the guiding factor throughout
the replacement project
Delta methodology requires
banks to anticipate future needs
and plan accordingly
discovered that often banks fail to do so, which results in an expectation/
deliverable mismatch at a later stage. This can also lead to unexpected
delays in implementation and incremental changes in the project.
For this reason, we believe that banks should form a clear understanding of
the target new world and use this to develop a Transformation Blueprint
supported by an Implementation Roadmap. One methodology that the
banks can use is delta analysis. Herein the blueprint and implementation
roadmap should dene the new world and how to get there, e.g. business
and technical architecture, technology platform, process transformation
and organisation alignment. The Delta Transformation Blueprint should
be complemented by a business case and/or a business justication, a
nancial impact analysis and a visualisation of the new world.
The biggest challenge a bank is likely to face in the Delta approach is
the scarcity of experienced resources. This approach requires seasoned
banking practitioners with the ability to deal with a clean-slate approach,
a good business appreciation of technology and the ability to switch
comfortably between the big picture and the nitty-gritty operational details.
Delta analysis is forward looking and it is driven by three key concepts:
Delta Methodology
Key Concept 1:
New World / Old World
Leaving the legacy behind
Key Concept 2:
Delta Analysis
Moving towards a legacy free new world
Key Concept 3:
Go / No Go Milestones
Put a stake in the ground before proceeding

These key concepts, we believe, need to be addressed in each phase
of the project: the new world / old world transformation blueprint is
developed during phase 1 (Core Banking Business J ustication); the
delta analysis is addressed during the selection and implementation
phases; the go / no go milestones are applied throughout each phase of
the project.
We believe it is crucial that the project stops after the completion of each
milestone until the milestone is signed off. This may sound draconian but
the temptation to start the next phase while sign-offs are debated must
be avoided at all costs for a project of this magnitude. Ultimately, this
approach can save the bank a lot of time and money. It will also ensure
that milestones are taken very seriously.
Because each milestone forms the basis upon which the following phase
will be built, this approach ensures that the next layer is not built on an
incomplete foundation. This can result in fewer changes and reworking in
subsequent phases and a more adaptable system as it is easier to make
changes to a solution built up consistently. The remainder of this chapter
will explore the best practices in this methodology in more detail.
Old World
New World
Bank Transformation Stage 1
s t c u d o r P
y c a g e L
g n i k a M
s s o L
e d o C
y c a g e L
Old World
n o i t a m o t u A
s s e c o r P
y c a g e L
Do Not
Cross
Key Concept 1:
Leaving the Legacy Behind

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 will drive the development of the Delta Definition 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
FreeNew World
Design
Go / No Go
Design
Sign-Off
Pilot
Go / No Go
Deployment
Go / No Go
Milestone:
Next phase will be kicked
off once previous phases
sign-off is completed
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Phase 1: Business J ustification &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 until
milestone is signed off
Go / No Go Decision
Milestones
Project Flow
Project will continue to the next phase
Stop
Go
Key Concept 3:
PutA Stake in the Ground
Before Proceeding
In summary, successful core banking replacement projects we have seen
are driven by clear business objectives, a strong business justication,
a blueprint for the future and a roadmap on how to reach the target
all developed in the rst phase of the project. This is followed by an
initial delta analysis in the selection and implementation phases of the
project and the conscious sign-off of project-embedded milestones in
each phase. If one of these milestones is not signed off, the project
stops. This disciplined approach can save the bank a lot of money and
agony.
Key activities to consider for the business justication stage of the project
are:
Dene the business objectives and desired outcome of the project
Assess the current operations and existing IT infrastructure against the
business objectives
Develop and visualise the blueprint of the future state of operations
and the enabling technology
Dene the implementation approach and timeline to achieve the future
state
Formalise the business justication for the future state
-
-
-
-
-
Delta methodology would
facilitate business justication
4.4 Phase 2 Selection
Critical Considerations in the Selection Process
Consider
long-term strategic
goals of the bank
Develop a
rating system
detailed to
provide
objective &
subjective
assessment
Invite bids from
vendors that
have strong
experience in
similar projects,
reputation and
track record
Eliminate the
products and
vendors that do
not meet the
essential
criteria
Final selection
should
comprise
detailed
analysis of
vendor and its
partners in the
project
Financial
assessment is
important but
decision should
be based on
product and
vendor
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
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 eciency
STP ability
Product dierentiation easy
Lower operational and
maintenance cost
Lower TCO
Outdated architecture
Lack of exibility
Lack of scalability
Long product rollout time
Slow response time
Product innovation dicult
High operating cost
High maintenance cost
Scarce trained manpower
Product-centric
Disparate systems lacking
information accessibility
Identifying the critical current
and future needs to be met by
new system
The bank needs to consider its objectives and conduct a delta analysis
to guide its development of selection criteria for the new system.
Widespread dissatisfaction with ageing, expensive and inexible
technology is one of the prime reasons for change. In countries like India
where private sector banks boast technically advanced systems, it has
become imperative for public sector banks to replace their systems as well
to lower the attrition rate and survive in this competitive environment.
Many banks have decades-old legacy systems that either fail to support
the latest products or do so with complex and time-consuming effort. The
operational and maintenance costs are steep and available manpower
for maintaining them is dwindling. According to one vendor, J ust keeping
these systems running can often consume more than 70% of the IT
budget, leaving little money to gain advantage over competitors.
While these systems have been stable, they are highly inexible and
hence largely unsuitable in todays competitive environment. Many of
these systems were implemented at a time when banks did not engage
in fee-based transactions. Rather than being customer centric, they are
largely account centric.
Branches need excess staff to maintain systems and back-ofce functions,
thus adding to cost. The time required to bring a product to the market,
the speed of transactions and end-of-day processing requirements have
also forced banks to look for alternatives to legacy systems.
Information in many of the legacy systems is stored in independent
silos. This makes gaining insight into customer needs and integrating
customer information across functions extremely difcult, as these involve
the collation of a large amount of data from disparate systems held in
different formats. For example, in legacy systems, a credit card division
may not know about the customers savings account. The banks that still
have no centralised customer-centric system are realising it is essential
to acquire one as this would provide them with a single customer view
and easily accessible and deployable real-time information, thereby
improving the banks efciency across functions.
The aim is now to eliminate duplicate systems, integrate legacy and
sub- systems with middleware, install and integrate databases and add
applications. The banks need to adopt scalable and exible systems
which can meet multi-channel delivery requirements, can integrate
information and processes across the organisation, are easy to upgrade
and can adapt to changes. This is essential to meet consumer demands
and maintain competitiveness in the sector. Absence of an adequate
system could even hamper the viability of an organisation.

Focus of Banks with Regard to Selection Criteria
5
4
3
2
1
Business Direction/Goals
Scale and Complexity of
Operations
Product Features
Cost/Financial Impact
Business Culture Process
Human Resources
Existing System/
Technical Capacities
Ideal Bank
Average Bank
Legend
Scale of 0 to 5 measures level of importance
(0 = Not important at all, 5 = Very important)
Selection of the system is a strategic decision which can impact not
just the growth and nancials of the organisation but even its viability
and competitiveness. Therefore it is essential that banks select the
system that provides the right components and architecture to meet their
objectives.
The architectural components that can meet the functional requirements
of the bank, given its business goals, must rst be mapped out. This
would also determine whether the bank should replace the core banking
system in a few functional segments (or geographic locations) or go for
a complete replacement, and whether it needs to replace just the core
banking system or the front end and GL as well.
We believe existing system and technical capabilities would be a decisive
factor in evaluating whether to upgrade the existing system or replace.
Gap analysis for features such as scalability, exibility, availability of
human resource, costs and processes of the existing system would
determine the technical capabilities and type of architecture required
of a new system. Integration of the new and existing systems within
the bank and the problems therein would also determine the system
architecture required and the risks involved in the change process.
The complexity and scale of the banks operations would shape its
scalability and exibility requirements for the architecture and platform.
For example, a large retail bank may prefer mainframes due to reliability
Critical factors that determine

the selection criteria
The bank needs to develop
selection criteria based on
its unique requirements and
business objectives
and scalability. Multi-channel delivery, high transaction volume and user
compatibility with lower downtime would be critical considerations. A
small bank, on the other hand, may prefer a UNIX solution because of
availability, exibility and agility.
Finally, the right technology should come at the right price. Cost and
nancial impact are critical inputs in system selection. Most systems
require heavy investments but these ideally should translate into costs
savings and revenue growth in the long term. For a smaller bank with
limited resources, cost may be a more decisive factor than in a bigger
bank.
Focus of Banks in Assessing Core Banking System Vendors
5
4
3
2
1
Track Record
Product Functionality
Cost / Financial Impact
Reliability
Commitment to Business
Financial Viability
Ongoing Support
Ideal Bank
Average Bank
Legend
Scale of 0 to 5 measures level of importance
(0 = Not important at all, 5 = Very important)
Banks cannot bring about transformation in their systems alone. Most
banks see a core banking project as a highly risky proposition, so they
would invariably like to partner a vendor whom they can trust and believe
to have the ability to handle a project of that size and nature. The vendors
are generally solution providers and, in most cases, service providers
who implement the solution within the banks. The two often join hands
with a hardware supplier to form a consortium to bid for the project.
Where there are multiple vendors, banks need to decide who would be
the prime vendor.
The evaluation of vendors involves multiple assessment criteria, foremost
being delivery track record, nancial viability, technical capability, product
features and cost.
Critical considerations in
assessing IT service providers
Evaluating vendor track record
and nancial viability is a must,
but equally important is for the
bank to assess its comfort level
with the vendors ability
Banks need partners that have the proven track record to provide them
with the right product and service mix. There are relatively few vendors
that have successfully completed core banking projects of the size and
complexity of tier 1 banks. But for tier 2 and tier 3 markets, there is
more competition. The IT partners track record and reputation should be
evaluated in the context of the banks unique requirements. For example,
banks in China look for customisation and localisation capability. Similarly,
Indian banks have shown a preference for local vendors.
In addition, the IT partners nancial strength (to ensure long-term
viability), ability to continually upgrade products and track record in post-
implementation services are critical factors for lasting success. Investing
a huge amount of resources on a product is useless if the vendor who
provided it is no longer around to service it a few years later.
The alliances and relationships between the IT partners are other
factors that need to be considered. For example, State Bank of India
and Central Bank of India who both hired TCS as their system integrator
were provided with a system from FNS, now owned by TCS, and
hardware from another vendor. The standing relationship between these
two companies was a denite plus in their favour.
Critical Requirements from System Architecture
Flexible,
Scalable,
Stable
Modular,
Integration
Customer-
centric,
Single View
of Customer
Straight
Through
Processing
Service
Oriented
Architecture
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 specically to suit their unique
Vital to assess vendors

nancial strength for long-
term viability and technical
enhancement
Understanding the need for the
right architecture
requirements. Most banks today are shifting their systems to attain more
exibility and scalability, similar to moving out of the connes of a small
box. What they need to ensure is that the new system is not like a bigger
box which quickly becomes a constraint again in a few years time.
Flexibility With a convergence of nancial services and a highly
competitive environment, banks need to display a high degree of
exibility, agility and efciency in its processes and product and
service development. Whatever the platform and solution that a bank
selects, it has to be exible to meet the constantly changing banking
requirements.
Scalability Scalability is a particularly important factor for retail
commercial banking. A bank can expect healthy growth rates in this
segment of the market and must plan for an increase in transaction
volume. Another factor to consider is the banks strategy in terms of
product offerings and delivery channels.
Functional requirements It is essential to have a comprehensive MIS
(management information system) to cover all products, all customer
groupings and all geographical locations. In addition are customised
requirements such as multi-channel, multi-time-zone and multilingual
processing ability to meet the specic needs of a bank. However the
bank has to determine which of these needs require changes in the front
end and which demand core banking replacement.
Modularity We believe that the system architecture has to be modular.
This means that one part of the system can be changed without affecting
other parts, thereby enabling banks to easily change and enter into
particular segments of operations. For long-term efciency, banks
need to transcend relationships and dependencies across systems and
business units through integrated technology.
Straight Through Processing (STP) One key feature which has led
to the success of core banking systems today is front- to back-ofce
straight through processing. While this is essentially the ability to have
a series of underlying business events generate multiple accounting
events without having to physically transfer the data from point to point,
this translates into a substantial decline in cost of ownership and control
because of the need for less reconciliation. Further, it allows banks to
reduce manual intervention and redeploy their existing resources.
The architecture of the banking system should integrate the core
banking system such that there is customer centricity with a single view
of customers across functions. In a customer-centric environment, the
The functionality and

architecture of the system
along with its suitability to meet
business goals would be the
key concerns
Imperative for banks to have
modular architecture with STP
and single view of customer
Integration of core banking
system within the banking
system architecture equally
important
consumer is paramount and drives all business decisions from technology
to organisation structure.
Business Process Modelling (BPM) is mainly a mechanism for the
orchestration of processes, with its ability to precisely model and
possibly change the context in which enterprise components are used.
Convergence of SOA and BPM is vital to the implementation of SOA-
based core banking solutions.
Service Oriented Architecture (SOA) is a relatively recent addition to the
architecture of banking systems. SOA in its purest sense is centred on
loosely coupled components which support generic services and are
based on web technology. In a core banking context, it means reducing
barriers in antiquated infrastructure and creating real-time integration of
disparate systems and sharing of databases within a exible and easily
upgradeable infrastructure.
Those components should be exible so they can be reused or combined
to create new business functions both within and across enterprises.
They should embody best practices and should enhance the banks
ability to outsource and extend processes to business partners. The
generic nature of the components means they are intended to traverse
silos and departments, thereby facilitating the breakdown of barriers
which only exist for historical, technical and antiquated organisational
reasons. We discuss SOA in more detail in section 5.
Selecting the Architecture
Most mainframe-based core banking solutions are designed for raw
horse power. The idea here is to support high transaction volumes.
Core banking solutions built on other platforms are typically focused
on functions and features and do not offer the same level of stability,
availability and end-user response time. While these types of solutions
usually cater to small- and medium-sized banks, they have recently been
touted to larger banks with some success.
Other mid-range solutions were initially built for the wholesale market
and then repackaged as Integrated Universal Banking Solutions for
the broader banking market. Some of those integrated solutions are
impressive in terms of functions and features, extending beyond deposits
and loans to include treasury and trade nance products and providing
a common customer information system across the package. However,
these solutions need to be carefully assessed with regard to their support
for the banks branch network, which differentiates a universal bank from
the traditional wholesale banking operations for which these systems
were initially designed.
SOA critical for future exibility

Selecting the Platform
An important consideration for the replacement of a core banking
system is the platform upon which the solution will operate. Typically,
banks choose between mainframe and UNIX platforms for their core
banking environment. This decision should be made after the conclusion
of the RFI (Request for Information) process at the latest, so that the
RFP (Request for Proposal) is issued only to vendors with solutions for
the selected platform.
The platform decision is critical as it can automatically exclude certain
platform-specic core banking systems. To the business user, this may
seem counterintuitive; after all, it is the core banking system we want to
select. However, as explained earlier, the functions and features of the
core banking system are not the sole determinants of the appropriate
solution. First, the solution must be able to handle the banks requirements
for volume, availability, reliability, scalability, security, response time
and other non-functional qualities. For these, the choice of platform is
paramount.
There are many aspects which should be considered in platform selection
for mission critical systems:
Virtualisation of the resources of computer operations Resources in
the platform of choice should be virtualised and centralised, enabling
better management of the operations. A key consideration should be
the level of distribution of these resources across various systems.
Distribution of resources over a large number of servers can lead to an
unacceptably high level of complexity, especially in an open system
environment, due to the ever increasing number of servers required to
maintain the scalability of such systems.
High availability Using parallel sysplex or geographically dispersed
parallel sysplex, the mainframe is able to achieve availability of up
to 99.999%. Alternative platforms should be measured against this
benchmark. This will facilitate clear decision-making and buy-in of all
stakeholders when faced with lower availability guarantees.
Security Security has always been a concern for banking systems.
The mainframe platform enables the bank to manage security from
a single point instead of multiple systems and thus helps reduce the
security risk exposure. However, as the security infrastructure for
non-mainframe environments is constantly advancing, banks should
consider the available security components as part of the overall cost
of either platform option.
-
-
-
Platform cost Typically, platform cost is calculated as either total cost
of ownership or total cost per user. However, measuring total cost is not
straightforward and often results in an underestimation of UNIX costs
due to lower overall availability and the greater number of unplanned
outages. We have, for example, found that the average expected
revenue loss per hour of system downtime could amount to well over
$1 million. Considering that unplanned outages can occur as often as
once or twice a month, the costs can climb quickly.
In summary, we believe that the total cost should not be the driving
factor in platform selection for a retail bank. For a mission critical system,
considerations such as availability, scalability, reliability and security are
of far higher priority. Cost should only be a barrier for banks that cannot
afford the most suitable platform and are willing to compromise on the
service level of a mission critical system.
On the other hand, for small wholesale banks and banks that do not
have large transaction volumes, the UNIX platform could prove to be
effective. Given the technical advancement in UNIX systems in recent
years and the increased availability of UNIX hardware, software and
technical skills, UNIX is rapidly becoming a preferred choice for smaller
banks and new banks. As these banks have only a handful of branches,
limited multi-channel requirements, lower security requirements and
tolerance for unplanned system downtimes once or twice a month, the
price-performance equation here makes the non-mainframe solutions a
viable option.
However, for those banks that intend to shift from mainframe to UNIX, or
vice versa, the switching cost and the cost of coexistence of two systems
need to be added to the total replacement cost.
4.4.5 The selection process
Objective: Select and acquire the enabling technology and service
provider.
-
Cost should not be driving

factor; identify what is most
suitable based on needs
For smaller banks, UNIX could
prove to be effective but banks
need to consider switching cost
Core Banking Selection Process
Sign Off
Issue RFI /
Refine Vision
Issue RFP
Select System
& Service
Provider
Conduct
Negotiation &
Contracting
Business
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
Project Stages
Source: Immacon SOBIT Methdology
Selection of the right core banking solution is critical for the success of a
project. We have seen retail banks selecting a wholesale core banking
solution and wholesale banks selecting a core banking solution meant
for retail banks. We are also seeing more and more bankers attempting
to make technology decisions, deliberating about J ava versus Cobol,
UNIX versus mainframe, SOA, etc. Needless to say, the outcome of
such decisions is often sub-optimal.
It is important that bankers focus on business solutions and not on a
technology solution. However we believe that business should have the
nal say on the solution, and the choice should be based on business
needs and not technology considerations. It is also important during the
selection process that IT rst picks out proven core banking systems
and then considers their underlying technology platform, programming
language and tools, not in the reverse order. We believe that a failure to
do all this can lead to very costly errors.
Issue RFI / rene vision If time allows, the selection process should
start with a Request for Information (RFI). The RFI should be kept
simple, concise and open-ended. As the name implies, the objective of
the RFI is to obtain information for deciding on the nal shortlist to kick
off the Request for Proposal (RFP) process. If the RFI contains too much
detail, it can render the RFP process obsolete and make the preliminary
analysis in the RFI stage very laborious. As the bank has to analyse
and weigh the RFI responses, it is important to keep the workload of the
reviewer to a manageable level.
A brief, well-written RFI (and RFP) addressing the critical points the
bank is interested in would be more worthwhile for the banks reviewers
and management, than a long laundry list of functions and features
which describes more or less the existing system of the bank and not

the future. The RFI process should focus on the essential requirements
for the future, bearing in mind that quantity never replaces quality. At the
end of the process, 2-3 nalists should have been shortlisted for an in-
depth review during the RFP stage.
Issue RFP An RFP is issued after a shortlist has been prepared. At this
stage, the choice of platform should already have been made. The RFP
should concentrate on the requirements for the new world, and should
demand full compliance with the banks visualisation or at least a brief
description of what requirements cannot be met by the core banking
solution and for what reason. The RFP should not be sent to more than
three vendors for a major component such as trade services, multi-
channel delivery and core banking. By now, the bank should also have
an understanding of how the selection would be conducted and know if
it is necessary to obtain a proof of concept. Ultimately, the key drivers
here are cost and timing. Where a bank can afford the money and time,
a pilot of the new solution is recommended. To achieve an objective
assessment, many banks are using a scoring method to document and
tabulate the results. See Appendix 2 for more on RFP.
Select system and service provider A sub-optimal selection will
have dire results for all. One of the challenges the selection team faces
is that they have to not only select the vendor but also justify why this
vendor was chosen over others. Hence, it is important to have a solid
and transparent selection process in place. In addition, it is crucial
that the selection is conducted for new world operation and does not
degenerate into a selection of the emperors new clothes, e.g. where
legacy operations are deployed with new technology. Our analysis
shows that successful organisations avoid taking legacy baggage into
the new world.
Conduct negotiation and contracting This stage is completed with
an agreement on nal pricing and contractual arrangement with the
vendor and service provider.
To summarise, the selection phase starts with gathering of information
and shortlisting of solutions for the subsequent RFP process. This allows
the bank to rene its assumptions about the future-state vision based on
ndings during the RFI process, and sets the stage for developing a
comprehensive RFP for the shortlisted vendors. Upon receipt, the RFP
responses are evaluated as inputs for the selection of the nal vendor.
This whole process is completed with the conclusion of negotiations on
pricing and contractual arrangement.

4.5 Phase 3 Implementation
Key Challenges During Implementation
Integrating with an ageing existing system with limited information
on software code
Data migration and seamless and smooth transition with zero error
User training and coping with resistance to change in processes
and work culture
Localisation and customisation of solution to suit the unique
requirements
Matching expectations and deliverables
Incremental changes leading to cost and schedule 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 and
knowledge of local business
Select strong partners in implementing project
Core system replacement or even upgrading is a major challenge that
can create disruption of service, customer dissatisfaction and employee
disappointment. Transition from one system involves not just technical
complexities but a plethora of unforeseen problems in areas such as
matching of expectations and deliverables, adaptability of system within
the organisation and change management.
Seamless and smooth

transition to new technology
and processes with zero error is
the key challenge
The foremost challenge is data migration and seamless transition to the
new system. This includes the difcult task of data cleaning, as some
data may be very old and irrelevant. Mass migration requires large
capital investment and an implementation schedule stretching over
several years. It also poses a signicant risk of service interruption that
can cause a dip in customer satisfaction.
There can be various problems in the process. For example, the old
system may have been account-based and not customer-based,
requiring information to be collected from multiple systems and migrated
to a centralised location. Some banks put in their system more than 15
years ago and the people who implemented it are no longer with the
banks such systems are undocumented and hence make the project
more challenging.
For some projects, the coding of ageing systems may be unknown,
making data migration and integration a rather difcult proposition.
For example, when Korea Development Bank switched from an IBM
system to an FNS system, it involved shifting to a totally new system
architecture. In other cases, the bank may be shifting to a new platform
which demands coexistence of two platforms for a certain period of time
and a huge data conversion exercise.
Customisation of the system to meet the unique requirements of
individual banks is another critical area where things could easily go
wrong and lead to an expectation/deliverable mismatch. While rolling
out a time-consuming project, there may be developments in the market
or a realisation of the need for increased functionality which demand
further customisation in the product. As the implementation period gets
extended with these incremental changes, the project becomes more
likely to have cost overruns. This is where the sign-off at each stage
would be of immense help.
The project at some stages may just seem too big in scope and magnitude.
But ensuring that any changes do not lead to unnecessary delays and
cost overruns is essential. Motivation will decline while resistance will
increase day by day. Managing these emotions and ensuring that the
project is not viewed as just an IT project would be a big challenge.
The most critical success factor in implementation is thus to test at
every stage. Banks should develop pilot projects, divide large projects
into phases, and conduct user acceptance tests or, rather, business
acceptance tests to ensure a match between deliverables and
expectations. Also critical is having strong internal teams with good
communication skills and decision-making capability. There should be
Testing at all levels is the most

critical means of risk reduction
a strong steering committee with a clear objective to guide the project to
successful completion.
In addition, it is important to provide user training and manage resistance
to the change in processes that accompanies such a project. There
should be helpdesks ready to handle enquiries and complaints from
users which are likely to be plenty. Along with processes, the work
culture would also have to be changed to ensure optimal returns from
the project.
Banks need to develop a detailed schedule of implementation and
ensure its strict adherence at all levels. For a large bank with hundreds
of branches, the project will be a multi-year initiative. Take the example
of State Bank of India which is implementing its system across 8,000
branches. Despite taking on 40-50 branches per day, the bank expects
to nish the implementation only by April 2007, four years after its
commencement in 2003.
In many such projects, trained manpower for new systems may not be
readily available within the bank. It is for this reason that some banks
have resorted to outsourcing their manpower. But the banks need to
remember that a few experts with the right experience and knowledge
may prove to be more useful than an army of staff.
Finally the banks business environment, adaptability to change
and commitment to the project are vital for success not just during
implementation but also during and after deployment. Vendors should
ensure that management is involved in the project from conception till
nal deployment. We cannot stress enough the importance of strong
managerial support and business ownership for a replacement project
which could go miles in motivating people in the organisation to achieve
success.
Objective: Operationalise and pilot the transformed future state, including
technology, process and organisational change.

Core Banking Implementation Process
Sign Off
Delta Analysis
Detailed
Design
Build & Test
Pilot
Implementation
Business
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
Project Stages
Transformation Approach and Methdology
Phase 1:
Delta Definition
Programme Management & Project Control
Phase 2:
Design
Phase 3:
Build & Test
Phase 4:
Pilot
Identify Organisational Change -
Determine the changes needed to fit
the organisation to the new System.
Identify Essential Modifications to
the new System - Every effort should
be made to avoid changes to the new
Systembut rather to align the
business to the new system. Changes
to the new Core Banking System
should be limited to those essential in
order to meet regulatory
requirements.
Identify Integration Delta -
Determine the interfaces, conversion
modules and coexistence
development required to integrate the
new Systeminto the banks
environment.
Business Realignment Design -
Define the reengineered products
and services and business
processes aligned to the new
System.
System Design - Prepare the
design for systemconfiguration.
Also design the unavoidable
modifications identified during the
Delta Analysis.
Integration Design - Prepare the
technical design for the Interfaces,
Data Conversion Modules and
Coexistence Modules.
Business Realignment - Align the
banks products and services to the
new System. Also align the banks
processes and procedures to the
new System.
Configure & Customise -
Configure the systemas needed,
effect the necessary changes to the
organisation, and make changes to
the system, where absolutely
necessary. In addition, the interfaces
between the new Systemand the
many linked systems are created.
Testing - Performvarious levels and
types of testing to the new system
and processes etc. in preparation
for correct functioning in the live
environment.
Training Preparation - Prepare
training plan, materials and course
trainers.
Pilot Preparation - Identify and
prepare the pilot site, train the pilot
users and conduct rehearsals to
prepare for the actual cutover.
Pilot Go/No Go - Confirmthe
completion of Pilot Preparation
activities and readiness for cutover
of the new Systemto the Pilot
community.
Pilot & Fine-tune - Cutover the Pilot
site and users to the new System.
Identify and fix problems that did not
arise in the testing environments.
Delta Analysis Report Design Specifications Applications Ready For Pilot
Applications Ready For
Deployment
The core banking implementation phase can be divided into four distinct
stages. We came across an interesting concept of delta analysis.
Delta Analysis A delta analysis is the identication of differences (the
delta) between the desired state and the selected package, and ways
to resolve these differences. One objective of the delta analysis is to
identify the package modications required to address country-specic
regulatory requirements. The package modications are necessary if
conguration through package-embedded parameters is not possible.
For the remaining delta, there are a number of resolution options
available, such as:
Implementation process
involves delta analysis,
detailed designs and product
modication to meet the banks
requirements
a. No change / Out-of-the-box ts your needs
b. Rationalise process
c. Rationalise product
d. Customise and modify package
The chart below illustrates this approach in more detail:
Requirements Analysis Chart
Delta Analysis & Resolution
Core Package
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
Requirements
Identify Delta Delta Resolution
Option I:
No change /
Out of the box ts
Option II:
Rationalise
Process / Product
Option III:
Modify package
Customisation
Input on Package
Cost Impact
No (should be included
in base price)
No No
Yes (Time & Material
Cost for Modication)
New Core Banking
Solution Procured
Regulatory
Modication
New Core Bank
Capabilities
New World
Operations
Delta
+
Delta
Resolution
Accept Package
Change Bank
Product / Process
to Match Package
Modify Package
Delta
Regulatory
Modications
Immacon SOBIT Methodology
Some of the recommended activities to consider for this stage of the
project are:
Conduct a delta analysis to identify the differences (the delta) between
the required future state and the selected solution
Conduct a solutioning to determine the appropriate customisation or
renements to suit the future state
Dene and estimate interface, data conversion and coexistence
efforts
Typical deliverables of this task include: Delta Denition and Resolutions,
Conguration Denition, Interface Denition, Data Conversion Denition
and Coexistence Denition
-
-
-
Detailed Design A detailed design of the future solution is needed for
the subsequent Build & Test stage of the project. A detailed design done
right can save a bank a lot of time and money by avoiding unnecessary
rework and change requests. Many projects run into difculties because
the design is never stable. In those projects, coding starts even before
the detailed design is approved. In our analysis, this is one of the major
causes of project failure, i.e. the inability to complete and sign off detailed
design documentation. The detailed design documentation should
include the following, among other things: business design, systems
design, interface design, data conversion design and coexistence design
(assuming no big bang deployment).
For this stage of the project, the initial project blueprint needs to be
expanded and some of the recommended activities to consider are:
Prepare a detailed business design, including rationalised product and
process designs.
Prepare a detailed system design for customisation and conguration
of the selected solution.
Prepare a detailed integration design for the interfaces, data conversion
and coexistence components.
Build & Test The customisation and conguration of the selected
solution begins here. At this stage, it is important to freeze the design
and to apply a rigorous change management process to any unavoidable
changes. Hence, the sign-off of the detailed design documents of the
previous stage is compulsory before this stage begins.
At this point, we would like to caution that the term user acceptance test
should not be taken literally. The real end-user should not be responsible
for acceptance. What the bank needs is a trained test team of, perhaps,
former users who understand and appreciate the need for thorough
testing and know how to conduct systems testing. Generally the real
end-user does not have these skills. Hence, we prefer to use the term
business acceptance testing or business solution testing over user
acceptance testing to avoid confusion.
Some of the recommended activities to consider for this stage of the
project are:
Customise and congure 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 congure the interface, data conversion and coexistence
integration components
Prepare and conduct system, operations and business solution
testing
Pilot A live pilot is the nal acceptance test. No matter how hard
we try, we will never be able to fully recreate and test a system in a
lab environment. But during a live pilot, the system can truly be tested
for real-life usability. Of course, the pilot should be representative of
the banks core operations. We have seen projects with well-executed
testing run into trouble as the test and production environments were
different, and even in cases where the production environment itself
was used for bank-wide testing by the actual end-users reposting real
business transactions prior to a big bang deployment. The lesson learnt:
the nal test is the live environment.
Our recommendation is to use a manageable mid-size branch for the
pilot. The pilot should always include a month end, as most banks have
special month-end processing which can cause a lot of disruption in
a real-life operation if not managed appropriately. The pilot should be
used to assess the effectiveness and completeness of the end-user
training and the new business processes and procedures, as well as the
customers acceptance of the new products and new operation. It should
also be used to identify bugs and bottlenecks and ultimately to ne-tune
the applications before deployment on an enterprise-wide scale. This
stage of the project will deliver a future state new world operation in a
live environment. Recommended activities to consider for this stage of
the project are:
Plan and prepare for the pilot deployment, including training of the pilot
users and dress rehearsals of the pilot cutover and operations
Deploy, support and rene the pilot operation
-
-
-
-
Reference Implementation Methodology
A comprehensive implementation method may be the one that follows:
Comprehensive Implementation Chart
Conguration Denition
Interfaces
Data Conversion
Coexistence
Product
Rationalisation
System Change
System
Customisation
System
Conguration
Conduct
Gap
Analysis
Resolution
Business Change
Delta Analysis
Conguration Analysis
Integration
Process
Rationalisation
Pilot
Planning
Train Pilot Users
& IT Ops
Pilot Site
Preparation
Dress Rehearsal
Convert
Pilot Data
Pilot End-user
Support
Application
Support & Fixes
Pilot
3
Pilot
Go/No Go
Update Procedure
Manual
Prepare User
Guides
Local
Customisation
Core
Customisation
System
Conguration
Interfaces
Data Conversion
Coexistence
Prepare
Training Plan
Prepare
Training
Materials
Train-the-
Trainers
System
Integration
Testing
Operations
Testing
Business
Solution
Testing
Business Build
System Build
Integration Build
Training
Preparation
Testing
Product Designs
Process Designs
Local Customisation
Designs
Core Customisation
Designs
Conguration Designs
Interfaces Designs
Data Conversion Designs
Coexistence Designs
Business Design
System Design
Integration Design
2 Sign O Design 1 Sign O Delta
Phase 1:
Delta Denition
Phase 4: Pilot
Implementation
Phase 3:
Build & Test
Phase 2:
Design
4.6 Phase 4 Deployment
Objective: Enterprise-wide rollout of the rened future state operation.
Core Banking Deployment
Sign Off
Business
J ustification &
Blueprint
Selection
Delta Driven
Implementation
Deployment
Project Stages
Training
Change
Mgmt &
Comm
Go Live Fine Tune Logistics
After the successful completion of the pilot, the bank is ready to execute
the roadmap for deployment of the pilot operation to the whole enterprise.
To do this, a number of important planning tasks need to be updated and
nalised:
Logistics Managing logistics is critical for the rollout of a new core
banking solution to the branch network. The logistics include rollout
sequence (where, when, how many), possible changes to branch
layout and bank image, and update and/or replacement of hardware
and infrastructure software. It also includes the planning and execution
of training logistics for the enterprise-wide deployment. The bank may
need the hardware to rapidly build and dismantle mobile training branch
environments for hands-on systems training.
Training We have discovered that once the new core banking system is
ready for rollout, training is one of the most important activities required
to successfully deploy the new world on an enterprise-wide scale. To
do this, the banks project team must ne-tune and update the training
plans and materials taking into account the lessons learnt from the pilot
deployment.
Change management & communication We have found in our
assessment of successful re-engineering and transformation projects
that effective change management is essential to obtain buy-in and
Enterprise-wide rollout of
the system poses critical
challenges, demanding careful
planning and caution at each
stage
acceptance of the new operation throughout the enterprise.
Change management done right is a very involved programme touching
every level of the organisation, from the CEO to the end-user in the
branch. Successful change management for a project as complex,
high risk and high prole as a core banking enabled transformation can
ultimately only be led by one person: the CEO. The chief executive is
supported in this task by the entire senior management team of the bank.
It is critical here that management not only walks the talk but also leads
by example.
Communication of the change is divided into two parts: internal and
external. Our analysis shows that the effectiveness of the communication
can be signicantly enhanced through the use of multimedia technology.
Usage of these tools ensures consistency in the message and rapid
deployment to the enterprise and public alike. The bank will need
different communication programmes depending on the audience they
want to address.
Go live We have seen that successful deployment is normally conducted
through a carefully prepared rollout plan which clearly identies the timing
and sequence of each task. The rollout is undertaken by specially trained
rollout teams which, among other things, conduct a train the trainer
programme in their respective rollout clusters. A best practice analysis has
shown that it is more effective to train key branch employees as trainers
for their respective units, than make external trainers responsible for
the training deployment. This approach is an integral part of the change
management programme and fosters ownership and accountability.
The employees are likely to pay more attention to the tasks if they know
that they will have to train their peers and be accountable for all of the
predened deployment activities.
The implementation teams are usually supported by a 24/7 central
command centre, which coordinates and directs all implementation
activities and has one or two rapid deployment teams available to be
dispatched to support trouble spots. The drawback of this approach is
that banks will be required to do a lot of methodical planning, conduct
massive training of key and branch employees and be held accountable
for the results.
Fine tune The nal activity in the deployment stage is the ne-tuning
of the operation based on feedback received during deployment.
Successful organisations have gradually turned this ne-tuning activity
into a continuous improvement programme managed and led by former
members of the rollout team.

Comprehensive Implementation Chart
Complete End to End
Partial Replacement
Big Bang Approach Gradual Implementation
Integrated solution suitable more for small
and medium banks
Easier to integrate solution from single
supplier
Phasing of implementation process
reduces risks
Suitable more for smaller banks
Risks and complexity higher
Implementation more challenging
Sudden change in processes and culture
within organisation
Preferred approach by large banks due to
complexity and scale
Lower risk, phased shift in processes
Challenging to have two systems coexist
during implementation
Difficult to integrate multiple systems
This approach can be used for smaller as
well as bigger banks
Partial replacement less complex as it is
for specific functions / locations
Big bang approach can be challenging,
particularly for big banks, but is quicker
The replacement approach is actually dealt with by the bank during
the project planning stage, but we discuss it here as it has a direct
bearing on the mode of deployment. The question foremost in the mind
of bankers as they decide to replace their banking system is: should
systems be upgraded piecemeal or through an integrated end-to-end
solution? Banks vary in their choices. Some want to replace the core
banking system of all geographic locations along with other operations
such as treasury through a universal or end-to-end integrated solution.
Others adopt the best-of-breed approach by selecting separate software
systems and vendors for different operations or geographic locations.
The selected replacement approach then determines the choice of
vendor and systems and thereafter the deployment approach.
We strongly believe that for core banking systems, there should be only
one vendor or else there would be immense integration issues. For
the front end and back ofce, there should also be a single vendor if
possible, though the project may be divided into smaller parts. However
when it comes to replacing banking systems across geographic locations
or across operations (retail, wholesale, treasury, etc), we suggest the
focused approach for bigger (tier 1) banks primarily because of the
complexity of the process. The banks would be able to reduce the
complexity and mitigate the risk by breaking down the process into
smaller projects, provided integration issues can be resolved.
The replacement approach

We believe focused, rather than
integrated, projects are more
suitable for bigger banks
On the other hand, universal solutions may be more feasible for
smaller banks mainly due to the lower scale of the project. End-to-end
replacement has its pluses as integration would be less of an issue, it
avoids successive disruption of services and it provides a standardised
technical capability across functions.
While deciding on the replacement approach is easy, deployment
is probably the most difcult and challenging part of a core banking
project and can be accomplished through multiple approaches. The two
extremes are big bang approach where the entire system goes live
at the specied time and gradual/phased implementation where the
process is divided across various functions, locations or branches.
The choice of approach may vary depending on the complexity and scale
of the project. Big bang is the quickest but also riskiest due to its low
error-tolerance level. If the bank favours this option, then it has chosen
to go live with its new core banking system and auxiliary solutions (if
any, e.g. multi-channel delivery) at the same time. The advantage of
this approach is that it is fast and does not require any coexistence
planning.
The justication for big bang comes from the fact that it is difcult for
two separate systems to coexist and from it being a faster approach.
The disadvantage is that it requires extensive training and plenty of full-
scale dress rehearsals for the entire organisation. Should any serious
problem occur, the bank has only one option: to fall back on the old core
banking solution. If such a problem occurs more than a week into the
cutover, the bank will have serious trouble as the fallback option most
likely does not exist anymore.
For smaller banks, this approach is possible and even feasible. But for
bigger banks, particularly for banks spread across countries, we believe
that a total big bang approach is not only high risk but also rather difcult
to implement. Examples of recent big bang deals include Union Bank of
Philippines and Industrial Bank of Korea.
We believe the gradual approach, which is essentially step-by-step
replacement, should be the preferred mode of implementation among
large banks as the complexity and risks in the process are lower. A
phased implementation also deploys the entire core banking solution in
one big bang similar to the enterprise-wide big bang.
The key difference between a phased implementation and an enterprise-
wide big bang is that the phased implementation is conducted in stages,
in successive deployment clusters which are closely controlled and
The deployment approaches

Big bang is the quickest but
also the riskiest
Gradual implementation should
be the preferred mode among
bigger banks
monitored. The advantage of this approach is that the entire solution is
deployed at once and can be tested and ne-tuned in a tightly controlled
environment. Should there be any problem, it can be conned to the
cluster. We also recommend that the rst cluster is deployed as a pilot,
to test not only the new core banking solution but also the conversion
and coexistence strategy. The disadvantage of the phased approach
is that it takes longer than the enterprise-wide big bang and it requires
careful planning for coexistence and logistics.
We believe that the advantages of phased implementation far outweigh
the disadvantages. If risk mitigation is important for the bank, then
the phased approach is worth a serious look. Gradual implementation
leads to a phased change in the processes and working environment
of the organisation, making the change slower and less likely to meet
resistance.
In conclusion, the big bang approach is the most risky option a bank can
choose. Big Bang is only recommended for small banks, or for cases
where the bank is implementing a solution which has already been
customised for its country and implemented here many times. Solutions
which have not been customised for a specic country or which are
implemented as part of a core banking enabled transformation are, in
our opinion, not a good choice for a big bang implementation.

4.7 Risk Mitigation
Inherent Risks in Each Stage of the Project
Assessing the technical
and functional
requirements of the bank
Ensuring adequate
financial, business and
management support for
the change
Financial viability to
provide long term
relationship and
technical support
Experience in
successfully
implementing similar
project
Evaluation of
technical capabilities
of solution to meet the
business goals
Flexibility and
adaptability to new
developments
Ensuring smooth,
timely and cost effective
implementation of new
system
Ensuring adaptation in
the work culture and
post-implementation
smooth operations
Commitment of vendor
to provide long term
support
Technical advancements
and their compatibility
with the new system
Project Stages
Evaluation risk
& management
commitment
Selection of
vendor, service
providers
Solution risk
Implementation
risk
Long term
technical
support risk
Risks and potential losses in replacing a core banking system are very
high, making it imperative that banks tread with caution at each step.
We have identied ve broad stages in the replacement process and
inherent risk characteristics of each.
Lack of management commitment is one of the primary causes for
project failure. We believe that a core banking replacement project needs
business and management support in totality and the project should not
be perceived as an IT project. Management commitment should not be
limited to simply business and managerial involvement at all stages of
the project but extend to strong leadership support that sees the project
through.
The evaluation of business needs and objectives must be comprehensive,
as inadequate assessment of technical and functional requirements will
lead to improper selection and possibly expectation/deliverable mismatch
at a later stage. It is critical for the bank to understand the type and depth
of functionality provided by the core banking solution in the context of its
own requirements and replacement objectives.
Availability of multiple solutions with varying technology and comparable
functionalities has made this task more difcult. We believe that while an
improper selection of solution could lead to short-term benets, it may
act as a constraint in the longer term.
In our opinion, the foremost issue in selecting a core banking system is
the solution. If the solution is right, then a bank can always opt to bring in
Inherent risks in replacement

project
Banks need to tread carefully
as there are hurdles at each
step of the change process
Project needs business support
in totality
Evaluation at each stage has to
be comprehensive
Improper selection of vendor
and system can lead to project
failure
a third-party service provider should things not go as planned. But that is
the worst-case scenario. As a general guideline, a vendor is not just an IT
supplier for the bank; instead it should be viewed as a partner that would
provide not only the solution and integration services but also long-term
relationship and technical support to the organisation. We believe that
banks should not just evaluate the nancial viability and track record of
these vendors, but also ensure adequate t with the project and that
they are able to trust the service provider. This is especially true for the
selection of the systems integrator, which can make or break a project
by its decisions on the resources assigned to the project.
Transition from an old system to a new technology is a risky proposition
in any organisation. It is more so in the case of banks due to the high
risk of potential losses and errors in a scenario where they cannot allow
a margin of error.
Risks are present at all corners, whether it is system customisation,
data migration, consolidation of multiple systems, integration of multiple
processes or user adaptation to new processes. Another risk is the
possible lack of long-term support from vendors, which could translate
into faster obsolescence of the system and inability to meet expectations
amid the constantly changing dynamics of the banking sector.
Analysing various risk elements in the planning stage of the project would
help ensure the adequacy of selection criteria and lower the likelihood of
expectation/deliverable mismatch at a later stage.
Banks cannot afford any margin

of error in the implementation
4.8 Financial Implications
Investments and Costs Implications
Cost Analysis
Recurring Cost
One Time Cost
Planned Unplanned
Core Banking
Hardware
System
Integration
Unexpected
Cost
Loss of
Business
Customers
Core Banking software acquisition and
maintenance cost
Hardware acquisition and maintenance
cost
System integration and consulting cost
Planned Costs
Unexpected delays
Incremental changes during implementa-
tion
Scope of project becoming too big
Resistance to change
Unplanned Costs
Ownership of the core banking system is very costly and requires
strong commitment and business justication in most cases. It is for this
reason that most banks take considerable time in coming to a decision
to replace or even upgrade their system. The cost components of the
total capital expenditure are software and service cost which constitutes
30%, system integration cost of 20-25% and hardware and infrastructure
cost of 45-50%.
The software and service cost is highly dependent on the scale and
complexity of the project. For example, it could be $100 million or more
in large global banks but it has generally been much lower for smaller
Asia Pacic banks. In Asia, the cost of software and services has been
in the range of $5 million to $10 million for small banks and $20 million
to $25 million for mid-sized banks, while for large banks it can go much
higher. The investment is substantial and it is normally amortised over a
period of 5-7 years.
Replacing core banking

system has high risks and
huge costs and thus requires
strong business and nancial
justication
Recent big deals have shown signicant variation in the expenditure
incurred for software and services. For example, it was reported to be
$20 million-$25 million in the deal for HSBC, around $35 million for State
Bank of India, $33 million for Central Bank of India and $4 million for
Union Bank of Philippines.
For many vendors, the pricing may be different when they venture
into new or more competitive markets. Involvement of a local partner
generally helps to lower the costs of the project. Our research shows
that many large banks prefer to hire consultants to guide this complex
process and they often have a team of vendors and system integrators.
All these add to the total cost of the project.
Maintenance cost is generally considered part of operating expenses.
Some banks that undertake in-house implementation may need
additional IT manpower, on top of what is required for the basic core
banking system. But most banks take this into consideration and justify
it when planning for core banking replacement.
However these may not be the only costs involved. In many cases, there
are also hidden costs in the process. These unplanned costs may come
from service disruptions, system downtimes or other system problems
during the course of implementation or from unexpected delays in project
implementation.
Cost overrun could also be caused by incremental changes, which often
increase the scope of the project and are sometimes due to the allure
of technical advancement. While such changes may be a necessity in
some cases and improve the efcacy of the project in others, the banks
have to evaluate these against the corresponding cost and schedule
overruns. It is common for the bank to realise that there is a mismatch
between deliverables and expectations when it has reached the
implementation and deployment stage. Usually resulting from improper
project realisation, delta analysis or communication, this has been one
of the primary causes for incremental changes in the project leading to
unexpected overruns.
While the banks strive to keep these costs in check, there is another
type of cost that gives critical business justication for such a steep
investment. For most banks, the replacement decision is taken only when
the opportunity cost of not changing a system (such as loss of market
share, reduced competitiveness and lower growth) becomes too high
and, in many cases, when their survival is at stake. Some other banks
nd it easier to justify the replacement citing regulatory requirements
such as those under BASEL II. Nonetheless, the substantial cost savings
(post replacement) both tangible and intangible coupled with revenue

growth in the long term are denite motivations. We discuss these further
in the following section.
Financial Justication of New System
Increased
efficiency,
competitiveness
and time saving
Improved
margins and
return on
investment
Shorter break
even period,
lower
manpower cost
and higher ROI.
Improved
competitiveness
and growth.
Customer
relationship
improved
Improved
market
presence,
capture of new
market,
increased fee,
revenue
Improved
revenue
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 justication in the form of intangible
benets such as market growth, retaining of competitiveness and long-
term success, many bankers mull over cost effectiveness and return on
investment (ROI) in order to nd nancial justication for the project.
Though varying with individual projects, cost savings primarily come from
lower maintenance costs, lower operating costs and time savings. Many
legacy systems demand a large pool of IT-trained manpower, which
is becoming increasingly scarce and expensive. Reduced manpower
requirements after replacement would therefore lower the maintenance
costs. In addition, systems that provide front-end and back-ofce
integration improve efciency in data collection, enhance operational
processes and allow the keeping of consolidated customer information,
thereby helping the banks to meet customer requirements more quickly,
which in turn lowers the operating costs.
As the banks go for STP, the rollout time for products declines. This,
coupled with faster response times, provides considerable time savings
for the banks. For many banks, these cost savings have led to a shorter
payback period and an improved ROI. Industrial Bank of Korea claims
that with its legacy system, it used to take almost a month to roll out
a product. But since implementing a new core banking solution (by
Temenos), the rollout time has reduced to 2-3 days and the time for
batch end-of-day settlement has reduced by 30%.
Financial justication through

cost savings and revenue
growth
While investment is substantial,
benets from cost savings, ROI
and business growth could be
more
Vendors often claim that replacement brings about a sharp increase in
productivity. However, attributing the improvement to only the new system
would not be appropriate as in many cases replacement is accompanied
by process restructuring.
The most critical impact on a banks nancials is in its revenue growth.
A exible system can facilitate the development of innovative products
to cater to ever changing market demand. Designing and creating new
products and customising are easier with the right system, which leads
to more product innovation and shorter rollout times.
The bank would achieve faster growth (and in many cases greater market
share) with its ability to make quick decisions and its agility in rolling out
new products. Banks like ICICI and HDFC in India have managed to
capture a large share of the Indian market (which was earlier monopolised
by state-owned banks) through improved service quality and innovative
products due to their advanced core banking systems.
Customer-centric systems (compared to account-centric systems of
the past) provide a single view of the customer to multiple functional
segments of the bank. This facilitates customising of products to customer
segment, cross selling and bundling of products and services, leading to
improved fee collection and revenue growth. Additionally, the bank can
enhance customer satisfaction and improve business through features
like virtual 24/7 banking.
The cost savings and revenue growth will vary between banks depending
on the unique features of individual projects. Some big banks claim that
they have beneted through a distinct improvement in efciencies and
the retention of a substantial number of customers that they would have
certainly lost otherwise. Most banks also agree that there has been
drastic reduction in end-of-day processing time and product development
time (e.g. some banks can set parameters of products within a couple of
days). Most banks have extended their hours of operation to nights and
weekends as well. These tangible and intangible benets often provide
substantial nancial justication for the banks to take the plunge.
Intangible boost to growth

highly possible if bank has the
right system
5
Core Banking
Replacement Building
Blocks
We have identied the critical building blocks of the core banking
replacement project. These comprise the technical issues
that arise as the bank shifts from one system to another. The
issues covered herein are coexistence, interfaces, data cleaning
and conversion, and product and process rationalisation. The
objective is to highlight the issues and success factors in the
transition process. Our target audience for this section are the
key technical decision-makers in the bank.
Core Banking Replacement Building Blocks
5.1 Application architecture and core banking
5.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.5 Data conversion and data cleansing
5.6 Product rationalisation
5.7 Process rationalisation
5.1 Application Architecture and
Core Banking
Our research into core banking architecture and deployment practices
reveals that the process of replacement consists of several critical building
blocks which need to be taken into consideration during planning:
Core Banking Building Blocks
Deployment
Strategy
Interfaces Process
Rationalisation
Coexistence Product
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 arise
concerning these building blocks. For example:
Big bang or phased deployment strategy Is coexistence of the old
and new worlds required? If yes, what type/scope of coexistence is
needed? How long can we tolerate coexistence?
Service Oriented Architecture (SOA) What is the impact of the new
core banking system on the banks overall systems architecture? What
changes are required? What impact will it have?
Interface considerations How many interfaces will we need to build?
Who is going to build it? How can we minimise the risk of slippage in the
interfaces?
Critical building blocks of core

banking transformation
Coexistence How will the old and new worlds coexist during the
deployment period?
Data cleansing and data conversion What is our approach to data
conversion? What inter-dependencies exist? How do we address data
cleansing?
Process rationalisation Which processes will be impacted by the
core banking replacement? Shall we change the processes or shall we
change the core banking system? How much legacy do we want to take
over to the new post core banking replacement world? How can we
best manage the rationalisation process?
Product rationalisation Which products can be converted without
modifying the core banking system? Which products and services will be
impacted by the core banking replacement? Shall we change our products
or shall we modify the core banking system? How many legacy products
do we want to take over to the new post core banking replacement
world? Are there opportunities for new products and services as part of
the core banking replacement? How can we best manage the product
rationalisation process?
Project organisation and programme management How do we
organise the project? Do we need senior management involvement?
If yes, how much involvement? Do we need external consultants or a
systems integrator to help, or can we do it in-house? If we need external
help, how can we best manage the external resources?
Change management What is change management? Do we really
need it? If yes, how much change management do we need? Do we
focus purely on internal change management or do we also need external
change management?
Banks need to answer these and other questions for a successful core
banking replacement project. This chapter will examine some of these
core banking building blocks in more detail and explain their purpose in
the overall programme of core banking enabled transformation.
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
banks needs
Big Bang is a deployment strategy which assumes that all systems will
be deployed at the same time in one big bang. As a result, banks do not
need to worry about coexistence or the more complex rollout logistics
of a phased approach. The disadvantage of the big bang is that there
is little or no margin for error. If a large bank is considering big bang
deployment, it should conduct massive training and repeated conversion
rehearsals over some period of time. The transition planning also has to
ensure that all conversion logistics are in place, i.e. hardware, systems
software, network, etc. Analysing best practices, we have found that
conversion rehearsals should always include a month end. We see the
big bang option as the most risky approach, only worth considering for
small banks.
Phased Approach is the deployment of the new core banking solution by
branch or regional cluster. It is recommended that the phased deployment
is conducted as a big bang for each deployment cluster. This means
that, as in the big bang approach, the entire solution is deployed in one
go but only for a manageable cluster and not for the entire enterprise.
The advantage of this approach is that banks receive the benets of
the big bang for all deployment clusters while keeping risks within a
manageable level. For instance, if deployment problems occur, they can
be conned to the cluster and will not affect the entire enterprise. On
the down side, a phased rollout will take longer and will require massive
logistical planning for each deployment cluster. Nevertheless, we believe
that the benets 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 inexible
architecture will lock the bank in the past before it even starts with the
deployment of its core banking solution. Service Oriented Architecture
(SOA) is a relatively new concept that has been gaining popularity lately.
While vendors often talk about it, many banks consider it just as a new
buzzword. The fact remains that this is a new technology which still
needs to mature and develop the capability to successfully manage high
transaction volumes. Nonetheless, it can provide the necessary exibility
and is being actively considered by some banks. We have described the
essential elements of SOA below.
SOA is essentially a business-driven framework for the deployment
of reusable business components embedded in computer code. This
denition 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 exibility. Specically, each service has a corresponding
contract which denes 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 denition of the service
and how to use it. If this is achieved, the advantage is clear one can
modify the internal operations or even replace a given service without
having to modify every programme that uses the same service so long
as the contract is not changed.
Those who advocate SOA believe that it is not about the internal workings
of the application but about how the application exposes its services
to the outside world. Thus, although the selected core banking system
may not have been constructed with SOA environments in mind (many
were not), it can t into an SOA environment by exposing its services
through well-dened 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 denition 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 exibility
Enterprise Service Oriented Architecture can be dened as follows:
Denition of Service Oriented Architecture (SOA)
Business Logic Data
Application
Front-end
Business
Service
Service
Repository
Service
Bus
Contract Implementation Interface
Service
Oriented
Architecture
(SOA)
A Service Oriented Architecture (SOA) is a software architecture that
is based on the key concepts of application front-end, business
service, service repository, and service bus. A service consists of a
contract, one or more interfaces and an implementation.
Services and application
model are the major
attractions of SOA
In addition there is a
service repository and a
service bus
The application front-end
is the owner of the
business processes
A service consists of...
a) a service contract that specifies the functionality, usage, and constraints for a client of the service
b) an implementation that provides business logic and data
c) 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
b2 b1
1
Services provide business
functionality that the
application front-end and
other services can use
2
The service repository
stores the service
contracts of the individual
services of an SOA
3
The service bus intercon-
nects the application
front-end and the
services
4
Source Synthesised from Enterprise SOA by Krafzig, Banke and Slama
A core banking architecture consists of deposit and loan product
processing engines, as well as a product factory for rapid deployment
of new products and services. The customer information repository sits
outside the core banking architecture and is loosely coupled to it through
an enterprise service bus. This is necessary as the customer information
repository must be able to support multiple core banking systems, as is
required in many banks around the world.
A more detailed view is included in chapter 3 (core banking denition)

Illustrative Core Banking Architecture
Multi-Channel Bank System
External
Interfaces
General
Ledger
Credit
Cards
Clearing
House
BahtNet
Branch
Call Centre
ATM
Internet
etc.
etc.
etc.
Core Banking System
Customer Information
Collateral Information
Common Services
Deposits Loans
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

/

S
t
a
t
e
m
e
n
t

I
n
t
e
r
f
a
c
e
5.3 Interface Considerations
Our research shows that interfaces are a key concern for any core
banking replacement project. Every major application in the bank is
interconnected, or interfaced with the core banking system, as illustrated
in the chart below. According to some experts, an enterprise service
bus (ESB) and an SOA together can help to reduce the number and
complexity of interfaces, enabling the bank to focus on its core business
rather than the maintenance of an IT infrastructure.
Old Core Banking System
Online Online Online Batch Online/
Batch
Batch
Batch Online Online
Online/
Batch Online Batch
Online
Batch
Batch
Batch
Online
Online
Batch
Online
Batch
Batch
Branch
Application
Core Banking
System
Trade Finance
Human
Resources
Financial
Planning
Agent Service
Audit and
Control
Authorised
Signature
Data
Warehouse
Cash
Management
Call Centre Cheque CIS
E-Channel
EAI
Donation
Custodian
Credit Card
BOND SWIFT Payment Loan
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 with
Legacy
The end result is a smooth transition from old to new core banking
system, as illustrated below:
New Core Banking System
Online Online Online Batch Online/
Batch
Batch
Batch Online Online
Online/
Batch Online Batch
Online
Batch
Batch
Batch
Online
Online
Batch
Online
Batch
Batch
Branch
Application
Core Banking
System
Trade Finance
Human
Resources
Financial
Planning
Agent Service
Audit and
Control
Authorised
Signature
Data
Warehouse
Cash
Management
Call Centre Cheque CIS
E-Channel
EAI
Donation
Custodian
Credit Card
BOND SWIFT Payment Loan
S
W
I
T
C
H
IN
G MEC
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
Interfaces
ATM
Call
Centre
Systems
Clearing
House
Other
Batch
Interfaces
Unconverted Branches Converted Branches
We have come across different methods of managing coexistence and
interfaces. Described below are types of interfaces that we believe are
the better ways of dealing with coexistence.
Coexistence poses
considerable challenges
demanding complex and
strategic planning
Coexistence Implications
how does the bank operate
while accounts are
progressively converted to the
new core banking system?
how will inter-branch
transactions be handled
during coexistence?
how will the call centre
service requests during
coexistence?
how will ATM transactions
be processed during
coexistence?
how will other online
interfaces be processed
during coexistence?
how will incoming batch
during coexistence?
how will outgoing batch
during coexistence?
how will sweeping and
other features be
processed during
coexistence?
Branches Call Centres
Batch Interfaces
(Outward Clearing)
Other Implications
ATM Transactions
Other 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 banks relationship with him, we believe
that it is important to have business involved in all of these discussions
and let business make the nal decision on how to proceed. After all,
business will know its customer better than IT does. There are a number
of options:
Branches During Coexistence
Old branches can access new accounts Yes No No
New branches can access old accounts Yes Yes No
ATMs can access all accounts Yes Yes Yes
Development eort / risk High Low None
Feature
Option 1
2-way Support
Option 2
1-way Support
Option 3
No Support
Coexistence Options
Old Branch New Branch
Customer has account in a
new branch and wants to
transact at an old branch
Customer has account in an
old branch and wants to
transact at a new branch
At rst glance, the two-way option may look like the best choice. However
we understand that it comes with a high cost for building the coexistence
interfaces. After analysing transaction volumes, banks may nd it
worthwhile to consider option 3, No Support, as a feasible alternative.
In our review, we learnt that business usually understands and supports
this approach for standard branch services (e.g. deposits, withdrawals
and transfers). The business rationale is that the potential inconvenience
is only for a limited time and can be managed through good customer
communication, especially where there is low to moderate transaction
volume. Our research indicates that if the bank is replacing its front-end
system and core banking system at the same time, option 3 is preferable
because it reduces the need for temporary integration between the old
front end and the new core banking system and between the new front
end and the old core banking system.
For intra-branch transactions,

business should make the
decision on coexistence
approach
5.4.2 Call centres
We believe that the second-most important customer contact point is
the call centre. During coexistence, the call centre transactions can be
handled through an online transaction switch without posing any problem
for the operation.
Call Centre Transactions During Coexistence
Old
Core Banking
System
New
Core Banking
System
Call Centre
System
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 Switch ATM

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
External
System
Online Transaction
Switch

We have discovered that one of the best ways in which inward clearing
transactions are addressed is through a batch splitter. The batch splitter
will divide (split) incoming clearing transactions into old world and new
world transactions and then proceed with the approval and posting
process for the respective core banking systems. This approach usually
does not pose any major technical challenge.
Inward Clearing Transactions During Coexistence
Old
Core Banking
System
New
Core Banking
System
External
System
Switch
During rollout, the
les need to be split
to send the data to
the appropriate
system
Batch
Splitter
B
a
t
c
h

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
External
System
Batch
Combiner
During rollout, the
new system will also
generate this data
for converted
accounts
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 to
pass the transactions out
Create an external system
for inter-branch sweeps
Manual processes
Standing Orders
Amend the systems to
pass the transactions out
Create an external system
for inter-branch standing orders
Manual processes
Others
Each situation will have to
be judged on
Criticality
Volume
Complexity
A decision is then made on
the best solution available

5.5 Data Cleansing and Data
Conversion
Our research shows that data cleansing and data conversion are of the
utmost concern for most banks around the world. We believe that data
cleansing should not be conducted as part of a core banking project.
In our opinion, data cleansing is an entirely separate project with its
own organisation structure and milestones. It should be an ongoing
operation (rather than a one-off project) at the bank and great care
should be taken to avoid creating dependencies between data cleansing
and the core banking project. Placing data cleansing objectives with
the data conversion team is tantamount to asking for unclean data to be
converted.
Data should be cleaned either before or after it is converted, but not
during the conversion exercise, and not by the data conversion team.
This is important as cleansing of customer data cannot be resolved with
technology alone, but requires the hands-on involvement of the banks
customer-facing personnel. Note, however, that other types of data
transformation are required during the core banking data conversion
to accommodate differences in data format between the old and new
systems or to auto-set default values for new elds in the new system.
But these should not be confused with data cleansing, which changes
the meaning of existing data rather than its format or structure.
Data conversion, on the other hand, is an important part of the core
banking replacement project. It can be executed in three stages, as
illustrated in the chart below:
Data cleansing should be a

separate project distinct from
the core banking project
Data conversion can be
executed in three stages
Data Cleansing and Data Conversion
Customers
Accounts
Standing Instructions
Transaction History
Etc
Data
Customers
Accounts
Transaction History
Etc
Data
... what it takes :
Step 1: Data Mapping
Step 2: Data Conversion
Extracts
Step 3: Data Conversion
Loads
Data Cleansing
Data Conversion Old
Core Banking
System
New
Core Banking
System
Data mapping Our research shows that banks start the data conversion
process with data mapping. This essentially entails mapping the old-
world data elements to the new-world data elements and can be used to
identify areas for product and process rationalisation. There are a number
of considerations for data mapping, as illustrated in the chart below:
Data Mapping
Step 1 : Data Mapping
Current Account
Is there a corresponding product for each of
our existing products?
Can we rationalise our products to t the
supported products in the new CBS?
Current Account
Product
Current Account
Account No.
Current Account Acc Branch Code
Acc Product Code
Acc Sequence No.
Acc Check Digit
Does the new systems account number
structure match our existing structure?
Should our account number structure
continue to have meaning?
When will we run out of account numbers?
What should be the length of the account
number? What are the implications for the
new system, cheques, passbooks, ATM
transaction records, etc. ?
Account No.
Attributes
Data Mapping Considerations
New World
Core Banking System
Old World
Core Banking System
Domicile Branch Code
Account Open Date
Interest Rate Method
Limit
Is there a one-to-one mapping of elds for
this product (i.e. Current Accounts)?
Is there a one-to-one mapping of eld values
(e.g. are our interest rate methods supported
by corresponding methods in the new CBS)?
How do we handle custom elds (e.g.
Special Field1)? Should we
customise the new CBS or rationalise the
requirement?
Is the source data clean and acceptable?
Domicile Branch Code
Account Open Date
Interest Rate Method
Limit
Special Field1

Data conversion extracts During this second stage of the process,
customer and account information is extracted from the existing system
and put into the conversion staging area in preparation for loading into
the new world system.
Data Conversion
"Old" World
Conversion Staging Area
DATA
Customers
Accounts
Transaction History
Etc
Extracted data ready for loading
Conversion data le 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 : Data
Conversion Extracts
Old
Core Banking
System
Data conversion loads This is the nal stage where customer and
account information is loaded into the new core banking system and
reconciliation reports are automatically generated.

Data Conversion Loads
"Old" World
Conversion Staging Area
DATA
Customers
Accounts
Transaction History
Etc
Extracted data ready for loading
Conversion data le 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 3 : Data
Conversion Loads
"New" World
DATA
Customers
Accounts
Transaction History
Etc
Conversion
reconciliation
and verication.
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 banks current
product and service offerings, i.e. whether a product or service is still
competitive and protable or should be deemed sunset. This is the
time to ask not only where the bank is with its current offerings but also
where it wants to be in the future. Banks often also check if an existing
product or service can be migrated to the new platform in a cost effective
manner, e.g. without too much customisation. Also to be considered is
how the bank can make full use of the new core banking solution and
launch competitive new/enhanced products and services. Ultimately, the
bank needs to dene 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 benets for the core
banking replacement programme. It enables the bank to take full
advantage of the capabilities of the new core banking solution. It
simplies the sales process through consolidation of like offerings into
core banking congurable 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 Rationalisation
Core 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
6
Critical Success Factors
and Best Practices
Organisation of the project and management of the change are
critical issues for projects of such a scale. We have identied the
key factors and best practices for banks to accomplish success
in selection and implementation. We have also detailed the
essential ingredients for service providers to achieve successful
implementation. This section is targeted at all decision makers,
within banks as well as vendors.
6.1 Project organisation and programme management
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 and
Programme Management
We believe that a project of the magnitude and scale of a core banking
replacement requires strong project organisation and programme
management. In addition, the project organisation should be adjusted
depending on the phase of the project.
Business Transformation Team Structure
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
Migration
Testing
Organisation
& Change
Functional Technical
Benefit
Realisation
Business Transformation
Team Process
Coordination & Decision
New World
Cluster
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 chaired
by the CEO and it is important that he demonstrates commitment to the
project. Other members of the steering committee should include the
banks full-time programme director, heads of all the business units, the
CIO, and key risk-management and nance personnel.
We believe that the banks full-time programme director should have
complete authority over the project. The programme director should be
empowered to make decisions after consultation with business and IT.
He needs the authority to make the nal decision if consensus cannot
be reached with a business division or with IT. An overriding decision
should be immediately reported to the steering committee, which can
veto the decision if necessary.
Programme organisation should

delineate the responsibilities
and accountabilities of project
decisions
The programme director should be supported in his day-to-day activities
by the project managers for the business and technology transformation.
The rst stage of the project deals primarily with issues of business
and technology transformation: delta analysis, interface analysis and
design, conversion and coexistence. An important aspect of this phase
is the delta resolution for product/process realignment. These activities
will require substantial full-time involvement and empowerment of the
business specialist and the IT specialist, both of whom must have a
good understanding of the banks legacy systems.
The project organisation will change depending on the stage of the
project. The charts below illustrate the different stages of the project
and the corresponding organisation required to execute the project
effectively. Banks should ensure that the core programme leadership
team is always full-time and leads the project for the entire duration of
the exercise. We believe that the programme organisation can be divided
into three broad stages.
There are various ways in which banks plan and organise their project.
One practice that we have discovered is delta analysis. In this approach,
the rst stage of the project is focused on diagnosing the current
business and IT environment in the bank and dening how the bank
should operate in future. Based on the current environment and the
target environment, the bank denes the delta, followed by the delta
resolution. We need to stress here that the delta is not a Gap. A Gap
analysis looks backwards, whereas a delta analysis looks forward.
Stage 1 Project Organisation, Delta Analysis & Design
Significant Third
Party Resource
Involvement
Core Banking
System Project
Manager
Core Banking
System Business
Team
Interface Analysis and
Design Team
Conversion &
Coexistence Design
Team
Delta Analysis Team
Product Realignment
Process Realignment
Project Office Technical Support
Stage 1
Stage 1
Delta Analysis & Design

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, Build & Test
Core Banking
System Project
Manager
System
Implementation
Team
Interfaces Team Testing Team
Training &
Procedures
Team
Customer
Application
Team
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
Coexistence
Development
Team
Operations
Testing Team
Conversions
Data Extracts
Teams
Train-the-
Trainers
Training Team
User
Procedures
Team
Online
Application
Team
Accounting &
Other Apps
Team
Data
Conversion
Load Team
Stage 2
Stage 2
Build & Test
Significant Third
Party Resource
Involvement

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 ne-tune the new core banking
solution and its processes and procedures.
Stage 3 Project Organisation, Pilot
Significant Third
Party Resource
Involvement
Core Banking
System Project
Manager
Pilot Team
Core Banking System
Pilot User Support
Team
Core Banking System
Applications Fix
Teams
Interfaces Support
Team
Data Conversion &
Coexistence Support
Team
Pilot User Training
Team
Legacy System Fix
Team
3rd Party Interface
System Fix Team
Conversion Data
Extracts Support
Teams
Stage 3
Stage 3
Pilot

6.2 Critical Success Factors and
Best Practices in System
Selection
Key Success Factors in Selection
Business decision
to change
Long term
impact on the
organisation,
growth,
processes and
culture
Flexibility,
adaptability,
compatibility
and financial
impact
Software
platform, type of
solution and
hardware
Goals Managerial and
financial
commitment
Existing
system, size of
bank, business
goals
Required
system
architecture
and platform
Selection Process
Set Business
Direction
Take Strategic
Decision
Establish
Functional
Requirement
Establish
Technical
Requirement
System
Selection
The impact of core banking system transformation would be visible over
the long term in the performance of the organisation. A bank replaces its
system once every 10-15 years (sometimes even longer), and thus it is
essential that the bank develops clear objectives and its expectations
are detailed to ensure suitability of the system and to avoid a mismatch
between deliverables and expectations. The bank should be clear
whether it needs to replace the core banking system, the front end, or
both. It must not be enamoured with bells and whistles as these only
represent the front end and not the real core banking system.
The rapid pace of change in the banking business makes it extremely
difcult to picture the banking landscape in the years to come. For this
reason, the right selection would be one with a forward-looking exible
architecture that has the ability to respond to the business dynamics and
adapt to newer products and services as well as the scalability to meet
future growth. This calls for a delta analysis.
The bank must ensure that the project involves business and management
executives with leadership skills along with the IT people. Involvement
of the CEO and second-order decision makers will ensure long-term
Selection of a system requires

managerial and business
support from all sections and a
clear focus on business goals
Ensure involvement of business
representatives and develop a
matrix for evaluation
commitment to successful implementation. The selection process should
involve key representatives from functional divisions as they would be the
ultimate users. But users see only the front end, while IT people may be
more aware of the technical requirements in terms of processing power.
Thus it is necessary to involve both the teams and ensure coordination
while avoiding/resolving conicts.
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 signicant 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 exible, or vice versa. In
such a scenario, banks may just be shifting their systems from a smaller
box to a bigger box where growth may be constrained again within a
few years. This should be avoided at all costs. The architecture should
be component-based as this would allow for the possibility of making
future additions to the system. We highly recommend an SOA-based
system that can provide exibility for future changes. Banks can select a
packaged system that has the ready processing capacity and customise
the front end to suit the user needs.
Finally, it is important that bankers do not lose sight of business objectives
and get wrapped up in architectural discussions and process redesign
issues that are too broad or diffused to add value to the business. They
should aim for quick decision-making and system selection in order to
prevent opportunity costs from rising further.
Functional capabilities and

architecture should facilitate
growth plans
6.3 Critical Success Factors and
Best Practices in Vendor
Selection
Success Factors in Vendor Selection
Track record and
technical ability of
the product to
meet the
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 may
prove to be a costly mistake in future. The basis of decisions should be
the vendors capabilities and not pricing.
It is imperative that banks ensure the vendor provides the right mix of
product and services required to meet the objectives and ambitions of
the business and the unique requirements of the project. The relationship
between system provider and system integrator should also be evaluated
and their track record in managing projects as a team needs to be
analysed.
Equally important is that the bank has to evaluate its own comfort level
with regard to the vendors reliability and suitability for the particular
project. If the bank has an existing system from the vendor, there could
be a distinct benet from having fewer integration issues. Using the
same vendor for both the front end and the core banking system can
also reduce integration and interface issues considerably.
Suitability of IT partner for

unique requirements of the
project and its commitment to
provide long-term technical
support are crucial
Select the right mix of product
and services
We have seen projects of even leading international vendors fail despite
excellent track record and strong technical capability. The main cause was
lack of local knowledge and ability to cater to the unique conditions of the
banking environment in that country. Cost aside, the bank should select
those vendors that involve local people in the process of customisation
and localisation, and ensure that they provide international quality while
meeting the local standards. Vendors that have already customised a
product for a particular country are likely to be more suitable to undertake
future projects in that country.
Finally, the bank should select a vendor that has the commitment and
ability to continually enhance the product so that future upgrading of the
system would be easier. The IT partner should be one with whom the
bank can maintain a long-term relationship, both through ongoing post-
implementation technical services and through future products.
Select vendors that involve

local people in customisation
6.4 Best Practices for Vendors (for
Successful Implementation)
Key Success Factors for Implementation
Banks should
develop strong
team to guide the
vendor
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 of
the bank
Involve local
people to meet
unique local
requirements
User training
to adopt new
processes in
work culture
Thorough
testing at
each stage.
Develop pilot
project
Ensure
seamless
integration and
timely
implementation
Provide long
term
partnership to
the bank
Successful Implementation
What can vendors do (besides providing a good product) to successfully
implement a project of this scale? Successful implementation involves
not only timely completion but also seamless integration, zero error and
smooth transition.
We believe the basic ingredient for success is the ability of the vendor
to understand the business requirements. Clarity of banks and vendors
on both the requirements from the new system and the requisite
deliverables would lessen the risk of expectation/deliverable mismatch
and help the vendors to customise and localise the system as per the
unique requirements of individual projects.
Vendors should ensure that within the bank, there is strong business
ownership, management involvement and a business environment
conducive for implementing the project. There must be a common ground
for decision making, where the banks and service providers can interact
to nd solutions for inevitable hiccups. The aim is to meet the objectives
and achieve timely completion coupled with high quality, but balanced
with the costs involved. It is important that the right mix of people within
the bank is involved in the process.
Understand the business needs

Ensure strong business
ownership for project within the
bank
Develop empathy with working
environment
Begin user training even before
deployment of system
Vendors need to ensure optimum utilisation of communication channels.
Besides having domain knowledge, the service provider has to develop
empathy with the working environment and culture to meet the unique
local requirements. Allocation of the right expertise is crucial. Equally
essential is that the vendor selects its partner carefully and chooses
one that has the requisite expertise. In addition, when there are multiple
vendors in a team, the accountabilities, responsibilities and decision-
making process must be clear and a prime vendor must be identied.
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-specic initiatives can bring about cost savings as well as
improve efciencies 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
7
Unique Core Banking
Replacement
Considerations
This section covers the unique business considerations, functional
requirements and key challenges faced by different types
of banks. Going further, we have also analysed the problems
and system demands from unique situations like mergers and
acquisitions.
Unique Core Banking Replacement Considerations

7.1 A large multinational bank
7.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 Requirements
Complex transactions across geographic locations and multiple
functions
Requires scalable system with proven technology and reliability
Integration with the existing system and seamless connectivity
across functions
Multinational, multilingual capability
Architecture that provides agility and flexibility but also robustness
and reliability to handle large volumes
Maintaining smooth operations during transition
Key Challenges
Business process restructuring and change management are
difficult propositions in old organisations with deeply-ingrained work
culture and processes
Data migration tends to be more difficult due to geographic
dispersion and high volume of business
User training is generally more time consuming
Coexistence of two systems during transformation process
Multiple application systems and software across the organisation
need to be integrated
Single product may not suit complex requirements and may
demand significant customisation
For most top-tier large banks, the key consideration for replacement
has been to overcome the limitations of their antiquated legacy system
and disparate systems with spaghetti structures caused by extensive
middleware and multi-application connectivity. Thus the banks essentially
Replacing core banking system

in large multinational bank is
highly complex
Unique 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 justication. 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
sufce or they require core banking replacement as well.
Most off-the-shelf systems are not suitable for the volume and unique
requirements of a large multinational bank, and hence substantial
customisation of the packaged solution is necessary during
implementation. However, a better approach would be to customise the
front end rather than the core processing system. This would make it
imperative for the bank to either utilise the services of an experienced
system integrator (e.g. SBI) or undertake further development on existing
systems to meet its complex needs (as in the case of HSBC).
The platform of choice for large banks should be mainframe, which has
proven its ability to meet scalability needs and handle large transaction
volumes. As most large banks have legacy systems that are based on
mainframes, this would make transition more feasible and lower the
switching costs.
The requirements from a system should reect 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 exibility to enable
the bank to introduce new products and services with ease and speed.
Compatibility and integration of multiple applications throughout the
organisation is essential for large retail banks.
We believe that past experience with similar large projects and reliability
would be critical considerations in vendor selection. Long-term support
would be essential, whereas pricing is not likely to be a key issue.
Many large banks have systems that were developed in-house. But often,
the people who developed these systems (or know the software codes)
Banks need a scalable and

robust system to handle high
volumes
Vital requirement is seamless
connectivity across functions
and locations
are no longer with the organisation. This makes the tasks of deployment,
data conversion and data migration extremely difcult 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 difcult due to
the extensive scale of the project, users being spread across geographic
locations and functions, and deeply-ingrained work culture. Most banks
would thus prefer a system that can be seamlessly integrated within
the organisation so that the change process is smooth. Integrating
and improving processes and transforming the work culture would be
essential for optimum returns from the new system. We advise banks to
undertake process and product rationalisation exercises along with the
replacement in order to achieve the best outcome.
Having strong management support to see the project through and strong
internal teams to coordinate with vendors and communicate within the
organisation would be essential for a project of this scale.

7.2 A Small Commercial Bank
Unique features
Less complexity and smaller
scale of operations
Lack of trained IT manpower
Investment size and cost savings
are critical considerations
Smaller geographic spread and
fewer number of branches
faster implementation
Outsourcing a feasible option
System requirements
Need agility and flexibility from
system
Capability to innovate and
differentiate products and
services
Compete on basis of cost
effectiveness
Need integrated and centralised
system
Likely to need services for
customisation and localisation
A small commercial bank
A small bank with a modest asset base and localised operations has
its own unique business considerations for selecting a system vendor
and service provider. Most small banks see cost as a critical business
consideration and essentially require systems that have a low cost of
ownership, particularly in terms of operational and maintenance costs.
To retain competitiveness, most banks need exibility and agility from
their systems to be able to provide differentiated products and to roll
out products with speed. A customer-centric system that can help the
banks to focus on fee-based transactions and product innovations
to tap consumer demand is important. This can be achieved through
architectural integration and SOA. Market penetration through cross
selling, product bundling and product innovation is likely to be an
immediate consideration of these banks. In addition, they need scalability
so that the system can cater to growing volumes.
While mainframes are proven technology across the globe, UNIX
may also be feasible for small banks as their scalability and volume
requirements are low. Due to manpower constraints, most banks do
not have the ability to develop the software internally and thus prefer
packaged solutions. There has been an increasing trend among smaller
banks to acquire integrated solutions to take advantage of end-to-end
Competitiveness through
exibility and cost effectiveness
are considered essential for
growth
Small banks can take
aggressive approach by
adopting new-generation
technology and big bang
deployment
integration through a single product and vendor (which may be difcult
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 sufce. 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 requirements
Adaptability to conduct financial transactions in accordance with
Islamic law yet compete with conventional banking
Flexibility to develop and support interest-free Islamic products
Compatibility with other Islamic applications
Cost effective and suitable for relatively small banks but scalable to
cater to rising volumes
Multi-channel delivery, innovative products and product
differentiation capability
Coexistence and integration with conventional banking systems
Over the last two decades, hundreds of Islamic banks have mushroomed
across the world to cater to the unique requirements of Islamic nance.
Islamic banks are common in the Middle East but have sprung up as
far away as London and the Philippines. Within the Asia Pacic 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 prots to be shared and bans investment in certain industries
such as those related to alcohol and gambling. It also prohibits interest
payments and the handling of money as a commodity. Hence Islamic
banks pool deposits to invest in construction, commodities trading and
other businesses that do not prot from interest payments. Commercial
borrowers pay the bank and its depositors a share of their prots 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 efciency and cost effectiveness would allow the banks to
maintain an edge in a highly competitive industry. It is a niche segment
where banks need core banking systems which can facilitate the set-up
of new Islamic banks and the conversion of conventional banks to Islamic
Recent spurt in number of

Islamic banks has forced
the banking sector to look
for systems that provide
compliance with Islamic law
System should have the ability
to integrate core banking
features with Islamic principles
banking, and help already established Islamic banks to stay competitive
in the market. The growing demands require that the new system is not
only exible but also scalable.
Challenges are plenty as there are no standard rules and there are
unique market requirements which need to be considered while offering
products in different markets. Additionally, pooling of assets and liabilities
and calculation of prots can be difcult. Thus the system should have
exible accounting structure and banking processes peculiar to Islamic
banking.
The banks need to offer consumers multiple innovative products that
comply with Islamic banking rules and yet be able to compete and extend
their market reach. The resources of most Islamic banks are more limited,
which makes the task even more onerous. Further, they have to exist
alongside and in many cases compete with conventional banks. Thus
multi-channel delivery, high quality of services, a centralised system and
24/7 capability are some of the requirements of Islamic banks as well.

7.4 Internet Only 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 creativity
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 xed, operational and
maintenance costs and the cost benets are passed on to customers,
the fees are generally lower and the interest rates competitive.
Most of these banks are small and do not have adequate manpower to
customise and implement the core banking systems. For this reason,
they prefer packaged solutions, with cost being a major consideration
in selection. The transaction volumes are not as high as those of
conventional banks and multi-channel delivery capability is not necessary.
The front end, however, may need customisation to suit the unique user
needs for this type of bank.
These banks maintain their competitive edge through innovative
products and services offered online to the customers. Speed is essential
and hence system exibility and agility are key requirements. Quick
decision-making and reduced product-rollout time are equally important.
Scalability is not critical, so a UNIX-based system may sufce.
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

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

7.5 Mergers and Acquisitions of
Banks
Core Banking Considerations in Mergers and Acquisitions
Problems
Duplicate systems impede growth
Difficult for banks to deliver integrated, customer-centric services
Maintenance and operational costs increase
Difficult for two systems to coexist unless restructured
Integration
Linking the core banking systems
so that they effectively function as
one platform
Difficult for two systems to coexist
Time consuming and costs can be
high
May be followed by core banking
replacement after a few years
Migration
Systems of pre-merger entities
are migrated onto one platform
Data migration has high risks
Time consuming
May be followed by core banking
replacement after a few years
Mergers and acquisitions can be nightmares for IT professionals of the
banks involved as they are invariably followed by restructuring of the
core banking systems. This is largely because the duplicate systems
impede growth due to their high maintenance and operational costs.
Further, running two separate systems makes it difcult for the banks to
have an integrated view of the customer. Thus banks have to ultimately
consolidate the two systems, resulting in integrated databases and core
banking.
Restructuring can be done by two means migration or integration. Both
the options are high risk, involve huge costs and normally take several
years to accomplish. Implementation problems may lead to errors that
can easily shake the customers condence 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 Banks 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
J apan, 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 difcult 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 nancially strong purchaser installs a new core banking system within
the bank in order to meet aggressive business objectives. As we have
discussed, this would involve high costs and risks but may also result in
long-term growth for the bank if done properly.
At the end of it all, the banks must have a system that is suitable for the
transaction volumes and processing needs of the combined bank and
meets the objectives of the merger.

8
Country Trend Analyses
This section analyses the trends in core banking system re-
placement in a few leading countries within Asia. The market
trends, demand characteristics and unique requirements of
each country are explored.
8.1 India
8.2 China
8.4 South East Asia Indonesia, Malaysia, Thailand and Singapore
8.1 India
Most tier 1 and tier 2 banks have already
made decisions; some small banks likely to
replace their systems
Has been quite an active market for core
banking in last 2-3 years
Many banks have gone for centralised and
end-to-end solutions
Leading vendors are Infosys, I-flex and
FNS(TCS)
Banks have preferred local vendors due to
familiarity with local system, sophistication
of technology and cost effectiveness
Fewer opportunities in future as market is
reaching saturation soon
Data centralisation of public sector banks
and stiff competition have led to demand
for better customer service and product
enhancement
More banks prefer open system and new
technology
Most Indian banks prefer changing their
infrastructure from bottom up rather than
adding applications due to archaic structure
Preference for local vendors
Cost is not a major consideration
Partial replacement in some banks likely to
be followed by purchase of application
software for remaining functions
Market Trends Demand characteristics
Source: Asian Bank Research
India is a unique country from the core banking perspective. Till ve
years back, most banks in the country were working on mere branch
automation and most state-owned banks did not even have a core
banking system owing to lack of infrastructure and network readiness to
provide a centralised system. New private-sector banks then came into
the market with a distinct technical advantage which led to substantial
customer attrition in state-owned banks.
Competition within the banking sector of this country is rising as
foreign banks are becoming more aggressive, growing through both
acquisitions and expansion of operations. Aggressiveness of the private
banks has thus forced most state-owned banks to replace their core
banking systems with advanced, centralised systems that are not only
competitive but also cost effective. In the last two years, almost 30% of
the countrys banks (most of these being state-owned) have taken the
decision to replace their core systems. Because of this, almost 50% of
deals in Asia during this period have come from India.
Prominent deals in the last few years include State Bank of India with
TCS, Canara Bank with I-ex (for a $49 million project), Central Bank
of India with TCS (for a project costing 150 crore rupees or about $33
After active spell in last 3-4

years, Indian core banking
market may be reaching
saturation soon
million) and Bank of Baroda with HP. As the trend indicates, most of the
major banks in the country have already entered into core banking deals.
Most of them would be completing their rollout in 2007. We understand
that those who have not yet entered into deals are actively evaluating
vendors. For this reason, we believe that the Indian market is nearing
saturation.
Some banks have preferred integrated, packaged solutions. This is a
feasible option for banks which are undertaking greeneld projects
and hence do not have to face the complex issue of integration with old
systems and whose transaction volumes are low. The preference has
been for local vendors, who understand local business requirements and
are considered more reliable in terms of domain knowledge. Moreover,
many Indian vendors now rank among the top global vendors. The
leading core banking providers within the country are Infosys, TCS (with
FNS), I-ex and Nucleus Software.
A critical challenge that many banks have faced in the transformation
process is the wide spread of branches across the country and in areas
where networking and infrastructure capabilities are still being developed.
As a result, many banks have found it difcult to integrate all their branches
through a centralised system. Another tricky problem has been change
management, as most banks are shifting from branch automation to a
centralised system. In branch systems, branch employees maintained
ownership of the data. However with centralised systems, some banks
have observed that their employees felt a lack of ownership of data, on
top of the typical employee dissatisfaction with change in processes.
UNIX-based systems have clearly been the preferred choice as India
has traditionally favoured UNIX. Most of its local vendors also provide
systems in UNIX.

8.2 China
Branch
Computerisation
Branch
Networking
Data
Centralisation
Integrated Core
Banking Systems
IT Infrastructure development of Chinese banks
Increasing number of core banking deals;
leading vendors include FNS, Misys,
Temenos and System Access
Banks treading cautiously in selection of
systems and vendors following deal failures
Tier1 and Tier 2 banks looking for
international standards in new systems but
need systems to provide for local practices
Many Tier 1 banks using in-house systems
and increasingly considering new
technology
Many smaller banks still prefer local
vendors
Increasing foreign competition as foreign
banks gain full access in 2007
Need to keep pace with rapid growth and
market demand
Traditional accounting system being chal-
lenged by new business and foreign banks
Need product that meets the unique local
requirements, e.g. language, business
environment
Higher costs and implementation risk due
to unique requirements; needs involvement
of local people
Lack of prominent local vendors
Market Trends Demand Characteristics
Source: Asian Bank Research
Regulatory and market-driven competitive pressures are forcing banks in
China to consider replacing their core banking systems. Market pressure
comes from the arrival of foreign stake-holding in banks and customers
becoming more demanding on quality of services and products. The
robust growth of the Chinese economy has attracted nancial institutions
from across the globe.
On the regulatory front, under Chinas WTO commitments, foreign banks
will gain full access to its banking sector in 2007. In addition, the country
is gearing up to host the 2008 Olympics. With this background, most
banks in the country are awakening to the need for technically advanced
and competitive systems.
We believe all Chinese banks are now somewhere between branch
computerisation and integrated core banking in terms of IT infrastructure.
Only a few leading banks like Bank of Shanghai, ICBC, China Minsheng
Market-driven and regulatory

pressures are forcing many
banks to consider replacing
their systems
Bank, China Development Bank and CITIC Bank have upgraded to an
integrated core banking system.
There is increasing interest in core banking system replacement among
banks, with many medium and small banks mulling over the decision and
some evaluating vendors. We have seen a gradual growth in number of
deals in the last couple of years and expect the trend to continue and
probably accelerate as competition intensies. The platform of choice
continues to be mainframe, which is more appropriate considering the
large branch network and high transaction volumes.
We have discovered that the uptake of core banking systems has been
slow in the country as a whole because the banks have been very
cautious. Additionally, we have observed that tier 1 banks (and now
increasingly tier 2 banks) prefer international vendors for the quality of
their solutions and services, whereas many smaller banks continue to
prefer local vendors due to the lower cost and higher level of trust and
reliability. There continues to be a certain level of doubt in the market
about the ability of foreign vendors to meet the local requirements of
Chinese banks. Deal implementation problems have also been reported
in cases like CITIC Bank, whose replacement project was done by
Fiserv.
Many banks in China are looking at point solutions in, for example, trade
nance and treasury rather than at core banking system replacement.
We believe this reects their short-term objective of attracting foreign
funds.
Most banks in China have unique requirements such as ability to deliver
in Mandarin and capability to customise and localise the solution to
suit their business conditions. For this reason, most vendors that are
providing solutions to Chinese banks are setting up centres in China and
employing local people.
Recent prominent deals include China Minsheng Bank by SAP, which
also marks the entry of the global vendor into this region, Hua Xia Bank
by TCS, and ICBC Beijing and Bank of Shanghai by Temenos.
Only a few banks have

upgraded to an integrated core
banking system
Smaller banks continue to
prefer local vendors
China presents a good
opportunity for those who have
technical capability and domain
knowledge to meet the unique
requirements of banks
Trend Analysis in Japan, Korea & Taiwan
Predominantly mainframe; Cobol-trained generation will start retiring in 2007
Most large banks have proprietary systems developed in-house
Mergers and acquisitions have delayed core banking replacement
Demand likely to increase due to foreign shareholding in the banking sector
Predominantly proprietary systems; many banks have in the past preferred
in-house development but manpower is becoming scarce for such systems
Banks now shifting towards new technology for cost effectiveness and
reduced human-resource requirement
Banks regard the application of new technology crucial for competition
Banks are looking for rapid product-to-market delivery and cost effectiveness
to face increasing competition
Integration and data migration from proprietary system can be challenging
Issues and Trends in J apan
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 J apanese banks is one of
the highest in Asia with most banks having basic integrated CRM. J apan
has traditionally had largely mainframe-based systems, most of which
are proprietary systems developed in-house. Reliance on these stable
and robust systems has been widely accepted in the country and thus the
banks have been relatively slow in patronising the UNIX technology.
However the banks are increasingly acknowledging the need to reduce the
high maintenance cost of these systems as the manpower for managing
them is dwindling. In J apan, this is known as the 2007 problem as that
is the year when Cobol-trained manpower starts retiring. Another factor
that is likely to move the market is the increasing foreign share in the
J apanese banking sector.
Various mergers in the J apanese banking sector have also led to complex
Japan
Banks in Japan are struggling
with rising maintenance
cost and scarcity of trained
manpower
systems that typically would need upgrading or replacement to reduce
complexity and improve efciency. Ageing systems and competitive
pressures are likely to bring about increased activity on the core banking
front over the next few years. Interestingly, a notable trend has been the
formation of smaller new-generation banks in J apan which tend to look
at new-generation technology.
Indications are there but a substantial shift towards undertaking this
risky venture is yet to be seen in this country. According to one leading
vendor in the region, J apan market will move in 2-3 years. They have
not reformed their nancial services sector yet. It is coming very slowly.
Once it is done, then we will see a change in reforms, change in attitude
in both public and semi-public sectors. Nothing in J apan happens
quickly.
We believe that technical advancement among banks in Korea has
reached integrated core banking and robust middleware. Till a few years
back, most banks in Korea used mainframe-based legacy systems. But
in the last few years, there has been an increasing shift towards UNIX-
based systems. The new regulatory environment requires banks to have
stringent capital coverage and risk management policies. These new
rules, high cost of maintenance and ageing technology are believed to
be the critical factors driving the shift.
Competition in the market is intense and banks need to be efcient and
cost effective in order to gain an edge. For this reason, most banks
are looking for architecture that not only meets their current business
requirements but is also scalable to cater to future growth. Nonetheless,
the complexity of tasks involved in replacement and integration is a key
deterrent for most banks. Historically banks have preferred to build their
systems in-house, but we are seeing an increasing shift in favour of IT
companies.
Taiwan is one of the few countries where there was a sudden surge
of activity in 2005, with four banks going for core banking deals as
compared with 2004 when there were none. We believe that most banks
still lack the condence to change from legacy systems, but competitive
pressures are forcing them to look for newer-generation technology.
Our research shows that technical advancement in the banking sector
of this country is currently at data centralisation and integrated core
banking. Now the banks are poised to take the leap towards integrated
CRM in order to achieve total customer centricity. As there is already
a level of technological sophistication among these banks, they do not
feel the urgency to take a replacement decision, but competition and
Korea
There is increasing shift
towards new-generation
technology among Korean
banks
Taiwan
Taiwan offers a good
opportunity to IT companies
with its increasing shift towards
open-end technology
consumer demand have been driving the shift.
Recent core banking replacement decisions have been in favour of the
UNIX platform. However, in most cases, a critical consideration has been
the ability to suit the unique requirements of language and business
culture in Taiwan. The latest prominent deals include Cathay United
Bank by TCS-FNS and Ta-Chong Bank by I-ex.

8.4 South East Asia Indonesia,
Malaysia, Thailand and
Singapore
Trend Analyses of South East Asia Countries
Many smaller banks continue to operate on legacy systems
Existing systems are costlier and more difficult to maintain; manpower to
maintain them dwindling
Not many core banking deals done recently; market yet to open up
substantially
Compatibility with Islamic banking an important requirement for some banks
Largely cyclical market with banks coming to market to replace ageing
systems
Banks aiming for integrated core banking; more top-tier banks likely to take
decision
Issues and Trends in Indonesia
Largely cyclical market; banks come to market to replace or upgrade ageing
system
Most banks have centralised data systems and are aiming for integrated
core system
Has been active lately with many core banking deals; mixed demand for
open and proprietary systems
Issues and Trends in Thailand
Considered a relatively mature and saturated market
Many banks technically advanced with integrated CRM; banks replace to
upgrade and improve competitiveness
Issues and Trends in Singapore
Issues and Trends in Malaysia
Banks in developing South East Asian countries like Thailand, Malaysia
and the Philippines have an existing base of rst-generation infrastructure.
However this was purchased 15-20 years back. Hence, not only is it
outdated but it has also reached a stage where managing and upgrading
it are extremely complex tasks. The key requirement for these banks is
thus to have a suitable architecture that is technically advanced to give
them a competitive boost as well as scalability.
The motivation for change varies. But change is happening. According
to one leading vendor, South East Asian countries such as Malaysia
and Indonesia are cyclical markets. People go out and replace system
South East Asia is

predominantly a cyclical
market where banks replace
ageing systems to maintain
competitiveness
about every 15 years. They are [returning] to that; it is time to look and
replace again. There is no economic pressure; it is just retirement and
renewal strategy.
In Malaysia, in the last three years, we have seen many small and
medium banks coming to the market to replace their systems. Many of
them have chosen vendors that can provide them with Islamic banking
capability. For this reason, local vendors such as Microlink and Silverlake
are popular in the country. We understand that the leading bank of
Malaysia, Maybank, is also in the process of evaluating vendors for
changing its core banking system. Given the small size of the countrys
banking sector, the change is noticeable. The aim of the banks is to have
integrated core banking systems.
Many experts consider Singapore a rather mature and saturated market.
Banks in the country have already achieved technical sophistication in
their banking systems. Since there is no urgency to change, the banks
take considerable time in making a decision.
We have seen very few deals from this country lately. The only prominent
one in recent times is DBS Bank in 2005, the bank appointed Infosys
to provide an integrated system for its domestic retail operations.
Technical advancement among smaller banks in Indonesia leaves much
to be desired, with some of them still working on branch computerisation.
Some technically advanced banks have set up a centralised data system.
We believe that many smaller banks in Indonesia continue to operate on
inefcient legacy systems and are spending a lot of money and time to
maintain them. The skills to operate these systems are disappearing
as most young graduates prefer to work on an open system while the
older people are retiring. Hence maintaining these systems is becoming
more problematic. The platform of choice has mostly been mainframe,
but there are indications now that banks are considering UNIX systems
as well.
However change has not been easy to come by. We have not seen
many prominent deals from Indonesia in recent years. But we expect the
market to open up in the next 2-3 years owing to increasing inefciency
and competitive pressures.
Many Malaysian banks look for

capability to adapt to Islamic
banking
Singapore is a saturated market
Many banks in Indonesia
continue to operate on high-
cost legacy systems
9
Vendor Assessment
This section examines the current standing of vendors in the
Asian markets and ranks them. A survey across banks in Asia
coupled with our in-depth analysis of the products and the deals
implemented by the vendors in Asia have assisted us in rating
them, both on their abilities and on their products capabilities.
Besides this, we have analysed their market positioning based
on their success and architecture.
Vendor Assessment
9.1 Vendor and product assessment
9.2 Market positioning
9.1 Vendor and Product
Assessment
Our Assessment of Vendor and Their Product
The key vendors in the region and their core banking products have been
analysed based on a survey done across banks in Asia. This has been
complemented with our research into their products, track record and
nancial strength and a quantitative analysis of the recent decisions.
We have divided our assessment into two parts. First is vendor assessment
based on four parameters and second is product assessment based
on ve parameters. The analysis has been done for only core banking
systems and not other solutions.
Vendor assessment methodology
Reliability Reliability of the vendors in the region has been judged
through a survey done across banks in which they rated the vendors
based on their level of trust in each vendors 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 nancial strength of
vendors on the basis of their nancial standing in absolute numbers and

Vendor Assessment
Vendor Assessment
their growth over the last three years. The analysis has included key
indicators such as revenue, operating prot, 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 ofces.
Implementation capabilities The assessment of implementation
capabilities has been based on our analysis of the number of successfully
implemented projects in Asia in the last two years and our research into
the reputation of the vendors on their implementation track record.
Product assessment methodology
Ability to meet unique needs The assessment of this quality has been
based on a market survey where banks were asked to rate the product on
its ability to meet their unique and specic 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 Positioning
Product 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 = Infosys U = TCS Bancs
U = Temenos Globus
A = Fiserv
U = Fidelity Sanchez
A = Silverlake
X = Fidelity Systematics
Legend
X = Mainframe
U = UNIX
A = AS4000
The product and vendor positioning is based on our assessment of
architectural advancement (progression towards relational database and
SOA) and market penetration of the products across banks in Asia.
Unproven This segment consists of those products that have no
signicant 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 exible. There seems to be only one product
in this category and that is Fidelity Corebank, a mainframe-based core
banking system.
Emerging leaders This segment comprises those products that are
technically advanced and have higher market penetration following
implementation across banks in Asia. We believe that the architectural
development of Temenos Corebank and Fidelity Corebank is somewhat
similar, but Temenos has made more progress in the region in the last
few years. We thus see it as an emerging leader in mainframe-based
systems.
Ageing architecture The products that have high market penetration
among Asian banks but also architecture that is relatively old belong
to this segment. Our classication of new architecture implies products
that have relational database and are more suitable for Service Oriented
Architecture. In contrast, old architecture is used for those systems that
were built long ago and have a traditional at-le database system. Since

Vendor Assessment
their inception, some of these products have undergone architectural
changes and a certain level of technical advancement. As these products
have been in the market for a long time, their market penetration is
considerably high. Many UNIX systems such as Infosys Finacle, TCS
Bancs and I-ex Flexcube are in this segment. Among mainframes,
Fidelity Systematics is also positioned here. Fidelity Systematics had
high penetration in the market a few years back, but in recent years it
has not had any major implementation in Asia.
Niche players The products in this category specically 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
10
Conclusions
Our research leads us to certain conclusions on success in core
banking which we discuss here in two sections. The rst is for
banks where we identify the critical requirements to achieve
success with the core banking systems project. The second is for
IT service providers and delineates essential factors to achieve
long-term success in the core banking systems market.
Conclusion
10.1 Conclusion 1 For bankers
10.2 Conclusion 2 For vendors
10.1 Conclusion 1 For Bankers
Summarising Success Factors for Banks
People and work
culture adaptation
Embrace change management
Strong leadership & decision making
Management and business commitment
Clear business direction, goals and business intelligence
We believe that the following elements are essential for a successful
core banking project.
The bank must have clear business direction and goals, which would
be the guiding principles for all stages of the project from selection
to implementation. This would also ensure that the project has
adequate justication and support from the business perspective and
the implementation does not stray from requirements because of
enamouredness with technical enhancements.
To ensure that the project has management commitment at all times,
there should be adequate business ownership and decision making
should involve people from business functions. We believe that strong
project sponsorship from top management is critical for its success.
Viewing the project as just an IT project would be a recipe for failure.
The bank should also develop strong internal teams to communicate
and coordinate with the service providers to ensure deliverables match
the business objectives.
There is bound to be resistance to change and employee dissatisfaction,
which can only be countered through effective communication and
Lack of business commitment

and willingness to adopt
changes within bank can
lead to failure of even well-
implemented projects
Have clear business goals
Ensure total business
commitment at all times
Effective communication
is essential for change
management
Conclusion
developing the right business environment. Internal teams should be
developed to conduct training and overcome employee resistance.
For the change to yield optimum returns, it should be adopted at all
levels within the organisation. The bank should shift from old world to
new world in entirety. Product rationalisation and process restructuring
would facilitate optimal utilisation of the new system and thus should
accompany this transition. Failure to do so would lead to old processes
being tied to the new system and eventually a mismatch between
expectations and deliverables.
Conclusion
Process restructuring and
product rationalisation should
accompany the process
10.2 Conclusion For Vendors
Summarising Success Factors for Vendors
Reputation, track
record
Partners in projects, not just
vendors
International quality standards
meeting local needs
Technical enhancements
Long term commitment to business
For long-term success, it is essential that service providers see each
project as a long-term relationship. Besides maintaining high technical
standards, they need a track record of successful implementation. Every
project has its unique characteristics and requirements which need to be
addressed with utmost diligence.
Having the right people with domain and business knowledge to suit
the local requirements of individual projects is essential for successful
implementation. An army of men cannot replace a few critical people.
Needless to say, the technical ability and track record of the vendor
are most critical in the selection process. Service providers must invest
continually in technical advancements. Equally important is catering to
the local conditions while providing international quality in the product
and services.
Ensuring that deliverables are in line with the expectations of the bank
requires clear communication at all levels. This would involve user
training and the challenging task of managing process and work-culture
change within the bank.
There should be fool-proof testing at each step in addition to other
strategies for risk minimisation. Successful implementation of each
project is a step in building the market presence and reputation of the
service provider.
Long-term commitment to
enhance product quality and
partnership role in project are
crucial for success of IT service
providers
View project as long-term
relationship
Employ right people with
domain knowledge
Ensure deliverables and
expectations match through
effective communication
Conclusion
A1
Appendix I
Case Studies
Case Studies
A1.1 State Bank of India
A1.2 Union Bank of Philippines
A1.1 State Bank of India
SWOT Analysis
Strengths
Threats
Weaknesses
Opportunities
In-house IT capability to implement the
project. Strong internal teams
Almost non-existent previous core banking
system, easing integration issues
Vendor has previous experience in country
and strong alliance with system integrator
System Integrator is familiar with unique
business requirements in India
Highly complex task with almost 8,000
branches
Implementation time-consuming due to
wide reach
Large human resource requirement for
in-house implementation
Existing independent branch system
Core banking replacement project
extended to 4 associated banks
Increased competitiveness and improved
efficiency
Centralised system that gives single view
of customer and frees resources for better
service
Difficult to change processes and work
culture in a 200-year-old organisation with
branches extending to remote areas
Lack of ownership of data at the user level
10 million transactions per day. Scale of
data migration huge with zero margin for
error
State Bank of India (SBI) is the largest commercial bank of India with
8,000 branches across India and a global presence in 20 countries. This
two-century-old organisation has not only a wide spread but also a deep
reach into the interiors of the country. Till a few years back, it was working
on basic branch automation and a rudimentary legacy system. However,
competitive pressures from private sector banks and the opening up of
the economy made it necessary for the bank to purchase technically-
advanced and cost-efcient systems that could meet its functional and
technical requirements.
Under the old system, the bank had computerised 2,050 branches on a
standalone basis. Thus each branch had its own independent system,
which it maintained and managed. The system was Bankmaster (now
under Misys) and it was used in 75% of the banks branches. However,
as each branch was independent, consistency and integration of systems
within the bank was not possible and customers could not freely approach
other branches of the bank.
Inherent problems with the existing system and the competitive climate
in the industry thus forced the bank to undertake the massive project of
Largest commercial bank of

India found it necessary to
purchase new system to face
competition and reduce attrition
rate
The old system
Case Studies
Case Studies
revamping its core banking system. It initiated the plan with transformation
in 3,300 branches in year 2000. But thereafter, the change process was
extended to include 5,000 branches of four associate banks as well.
The key motivation for the bank to purchase a new system was the
desire to have a local framework in which IT could serve as an enabling
force and relieve the local branches of back-ofce operations thereby
allowing them to focus on delivery and marketing. And this was possible
only if the bank had a centralised core banking system and made its
branches a service and delivery channel. Multi-channel delivery without
core banking was not practical.
The Timeline of the Transformation Project
April
2007
August
2006
April
2006
2004 2003 2002 2000
Implementation
completed
85% of Business
migrated to new
system
3,000 branches
(50% bank's
business)
migrated
200 branches
migrated
Implementation
process begins
at pilot
branches
Selection
process.
Preparing RFP
took 6 months
Project
Conceptualised
with KPMG as
consultant
However, when the bank started to consider replacing its system, there
were very few examples. It wanted proven technology for its system
but there was none. Not even Bank of America and other big global
banks had undertaken such a change. Its size was the key issue and
it needed a system that could cater to its growing needs. (Together
with its associate banks, SBI now has 15,000 branches and 140 million
accounts in total.)
The whopping project for transformation of the domestic business
was conceptualised in 2000 with KPMG as the consultant. The actual
process of selection began in 2002 as the bank developed a matrix of
criteria (10,000-odd points) for system and vendor selection which had
to be approved by the government (SBI being a state-owned bank). It
took almost six months for it to prepare the request for proposal. The
selection after the RFP was issued took another two months. As it was
a public bank, the selection process was bureaucratic with approvals
needed from regulators. Technical bids were sought through the request
for proposal followed by nancial bids. Suitable vendors were selected
based on the technical bids and their pricing was one of the nal decisive
criteria.
The selection process

FNS Bancs was considered the most suitable to meet the banks
requirements. TCS was chosen as system integrator as it had the distinct
advantage of being aware of local business practices, work culture and
regulations and thus was well-placed to understand the requirements
of the bank. Strong alliance between FNS and TCS was another factor
that contributed to the selection of FNS as the vendor. This, however,
meant moving to the UNIX platform which was relatively less proven
than mainframe for a bank of this size.
Owing to the size of the organisation, the customisation of software and
the user training and training for implementation were, in that order, the
two most difcult tasks faced by the bank and the service providers.
Unique requirements of the bank such as having to maintain branch
individuality while centralising the systems posed signicant challenges
in customisation. Its validation and process-adaptation requirements
forced further customisation.
The original product from FNS which had about one million software
codes was customised into a more complex hybrid product with almost
two million codes. This extensive addition to the software code of the
product was done by TCS and the system now covers 4,000 transaction
types.
Because of the complexity, pilot projects were implemented. The task
of migrating data from the old system to the new system had to achieve
total migration and reconciliation with no loss of data. A bank with ten
million transactions a day has no room for error or else customer attrition
and loss of reputation can be extensive.
The deployment, which is still in progress, is being done gradually over
all domestic branches and the branches of four associate banks. This
involves a total of 8,000 branches, a scale seen by very few banks in
the world. The bank implements the new system over 40 branches in a
day.
SBI is a typical example where the time-consuming work of training staff
and educating users is conducted in-house, a process which will take
years to complete and require a huge amount of resources. SBI has
formed a strong in-house team to work with the vendors on deployment
and implementation.
Change management within the bank has been a whopping task. The
ingrained culture of the organisation is undergoing a total transformation
as the bank moves from an independent branch system to a central
system. This has led to users feeling a lack of ownership of data, unlike
Customisation and
implementation process
The deployment was phased
The change management
Case Studies
previously where there was an entrepreneurial feeling as they managed
the system and customised it to meet unique local requirements. This
demanded a strong acceptance of change management within the bank,
with staff roles changing and business processes being restructured
across all users. SBI met this challenge through strong internal teams
and effective communication. The change process is likely to continue
even after the new system has been fully implemented.
By mid-2006, 85% of the banks business would have been transferred
to the new system. By March 2007, SBI expects to have rolled out its
core banking system to almost all of its domestic branches and those of
the four associate banks.
Despite the substantial cost, time and resources employed in the process,
we believe that it was imperative for the bank to shift to a newer system.
Before the change, its attrition rate was high with private banks garnering
huge market shares thanks to their technical advancement. The cost-to-
income ratio of the bank is already showing signicant improvement.
We expect this new system to give a strong boost to the banks future
growth. However the effectiveness of the system for such a large bank
can only be seen after it has been implemented across all branches.
For its international operations, the bank recently chose Infosys to
provide a single integrated solution across all branches as it felt that
TCSs resources were already tied up with its domestic project. It is
also believed to be implementing a new trade solution. In addition, the
bank is undertaking a business process restructuring exercise in order
to improve its efciency. With all these initiatives, SBI should remain a
formidable player and retain its stronghold in the Indian market.
The outlook
Case Studies
A1.2 Union Bank of Philippines
SWOT Analysis
Strengths
Threats
Weaknesses
Opportunities
Relatively small bank with 111 branches,
making replacement less complex
Willingness and adaptability to change
from mainframe legacy to new technology
Willingness to take risks to improve
competitiveness
Data migration from multiple existing
systems and integration was complex
Data cleanup was difficult as Finacle
required some parameters which old
system did not have
Lack of in-house IT manpower. Cost also
an issue
Centralised the back-office operations with
the new system
Growing economy. Acquisition of new
customers and markets possible through
differentiation of products and services
Availability of multiple vendors for open
technology made choice easier
Lower TCO in new technology
Shifting from legacy to open system
required change in processes and
business culture
New system required extensive user
training and acceptance at all levels
Big bang approach has higher risks. Tried
for first time in the country
Union Bank of Philippines (UBP) is a relatively small bank with an asset
base of $1.98 billion and 111 branches in the country. However it is among
the top ten banks in the Philippines, with a history of fast growth thanks
to its tech-savvy approach. True to its reputation, UBP has become the
rst bank in the country to shift from mainframe to open platform.
The bank had an existing legacy system (from Systematics, running on
refurbished mainframes) which was ten years old. The key problems
faced by the bank included high operational costs and difculty in building
interfaces. The bank then realised the need for a simpler system where
interfaces are not an issue and total cost of ownership is lower.
The change was also prompted by the need to acquire business agility
coupled with improved efciency and to have the ability to differentiate
its products and services. Being in a competitive environment, the bank
worked on a tight margin hence cost was an essential consideration.
With these issues in mind, the bank started exploring the possibility of
shifting to a newer technology platform in 2002.
The old system

Cost a critical consideration
Case Studies
The Timeline of the Transformation Project
April
2005
April
2004
4 Qtr
2003
1 Qtr
2003
2002
Implementation
is completed
Implementation
begins with user
training
Selection
process
completed.
Finalises Infosys
Requests for
proposal
from vendors
Explores
possibility of
shifting from
mainframe to
open platform
In 2003, the bank invited proposals from leading vendors that could
meet its technical requirements. The process of selection took six
months, during which the bank analysed all the proposals and bids and
visited two Infosys project sites in India. The bank viewed the venture
as the beginning of a long-term partnership and made the selection
accordingly.
The selection criteria included the functional features of the system, the
quality of the team and the track record of the vendor company. While
technical capability of the system to meet the objectives was essential,
cost was also considered to be a critical factor. Infosys presented a
strong business case following a Gap analysis.
The bank nally selected Infosys to provide the system Finacle for
its retail operations (CASA, loans, deposits and GL). Local rm Total
Information Management Corporation (with whom the bank has a long-
term relationship) was also hired to provide consultation and assistance
in implementation. The project involved replacing its mainframe-based
legacy system with a new-generation open-ended system which runs
on Sun infrastructure. For Infosys, this was its rst big project in the
Philippines. For this reason, involvement of a local partner was an asset
for the bank as well as the vendor.
The project cost was about $4 million. One of the key considerations for
the bank while selecting a system was the nancial impact. It wanted
a system whose cost could be met through the operating prots of the
bank over a period of ve years. In addition, the new system should have
lower operational costs, thus leading to better returns for the bank.
Implementation took approximately one year and the system went
live in April 2005. The implementation posed many challenges such
as localisation and customisation to unique business conditions of the
Philippines. In addition, data stored in multiple mainframe-based systems
had to be cleaned, migrated and consolidated. Some of the items that
Finacle needed were not found in the old system, making the task more
difcult.
The selection process

The new system
The implementation and
deployment process
Case Studies
The project was signicant for the Philippine banking sector because it
was the rst time a local bank shifted from a mainframe-based system to
open technology. For this reason coupled with the fact that it used big
bang implementation it was keenly watched by many in the industry.
The bank took an aggressive approach by adopting big bang, which was
less time-consuming but came with high risk. Most banks, especially
larger ones, prefer a traditional step-by-step rollout due to lower risks.
However owing to the relatively small size of the bank, big bang was
considered achievable and more feasible. The advantage in this approach
is the avoidance of integration issues that arise from having two separate
systems co-existing within the bank during rollout. The implementation
is fast and would not slow the banks transformation process. The bank
felt condent that it could implement the project according to schedule
and it succeeded.
One of the strengths of Union Bank of Philippines has been its adaptability
towards new-generation technology. It is considered a tech-savvy bank
and has proven so by being among the initial few in the country to step
out to replace their entire system. The bank developed an in-house core
team which worked with the Infosys team to full the implementation
plan and to train users for the change in processes.
The success of Union Bank of Philippines in its core banking
transformation has some lessons for other banks undertaking similar
projects. The management should be committed from conception to nal
implementation. This is required of both the bank and the vendor and
was one of the critical success factors for the bank. The bank developed
strong teams with good banking knowledge and got them trained for
the new system to ensure optimum utilisation. The bank faced a certain
amount of resistance and getting everybody on board was a challenge.
Most banks in the Philippines continue to operate on legacy mainframes.
For these banks, UBP has been an example to look up to.
With the new system, the bank aims to reduce its cost by 15% over ve
years. If achieved, this would give it substantial competitive advantage.
Moving from account centricity to customer centricity should help it
provide better customer service and improve its market presence. The
bank has discovered that with the parameterisation of the system, it can
launch new products much faster and with ease. The cost of interfacing
is also lower. In addition, the bank did away with the branch IT network
following core banking replacement. With the new centralised system, the
bank freed up resources previously engaged in branch IT infrastructure.
Additionally, the centralisation of back-ofce functions should give a
boost to its competitiveness
Lessons learnt
The outlook
Case Studies
A2
Appendix II
An Average Request for
Proposal
An average RFP runs into 70-80 pages, with the bank requiring
vendors to submit a whole range of information which would
assist the bank in evaluating the suitability of the system for its
requirements. While some in-depth information is essential to
analyse the product and the vendor, we believe that unnecessary
information simply increases the complexity of the process. Banks
often forget that somebody with the right breath and depth of
knowledge needs to read and analyse all the responses to an RFI
or RFP. For a vendor providing this extent of information, it usually
becomes an unwarranted exercise. For this reason, we believe
that banks should ask for only relevant detailed information. In-
depth critical information gained through a few questions may be
more useful than a laundry list of non-essential information.
What follows is a sample of the table of contents of an average
RFP. Often, the RFP is accompanied by a worksheet that
requires vendors to provide information on 800-900 parameters
which include vendor prole, technology, product, customer
information system, general information, security, and loan and
deposit system information. However, as this worksheet is very
extensive and specic to each banks requirements, we are not
providing a sample of it in our report.
Table of contents
A. Introduction
1 Bank prole
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 Denition 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 Clarication 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 validity
4.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 Condentiality of the evaluation process
6.2 Clarication of vendor proposal
6.3 Examination of vendor proposal and determination of
responsiveness
Average Request for Proposal
6.4 Evaluation methodology
6.5 Banks right to accept or refuse any vendor proposal
7 Award of contract
7.1 Post-qualication
7.2 Award criteria
7.3 Reserved rights
7.4 Notication 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 Vendors 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 Instructions
3.2 Summary of technical proposal
4 Organization and support
5 Application and support
6 General features
7 Business requirement
7.1 Customer information system
7.2 Savings and time deposits system
7.3 Checking deposits system
7.4 Loans system
7.5 General ledger system
7.6 Branch automation system
8 System demonstration requirements
9 Reference site visit requirements
10 Pilot testing requirements
11 Implementation plan
11.1 Implementation approach and methodology
11.2 Scope of work
11.3 Implementation schedule
11.4 Implementation personnel
12 Maintenance and support
13 Vendors expectations from bank
14 Appendices
G. Attachments
1 Glossary of terms
2 RFP forms
2.1 Performance security
3 Standard terms and conditions

Asian Banker - Core Banking Replacement

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Asian Banker - Core Banking Replacement

Загружено:

Авторское право:

Доступные форматы

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

ABOUT THE ASI AN BANKER

Core banking systems market

14 Asian Banker Research Report

16 Asian Banker Research Report

China banks have preference

20 Asian Banker Research Report

Banks need to adopt Service

Asian vendors are increasing

26 Asian Banker Research Report

28 Asian Banker Research Report

30 Asian Banker Research Report

Cost remains the key

Stability is the biggest

Asian Banker Research Report 33

Strengths and weaknesses of

Perceived needs justifying

Core banking system is simply

Core Banking replacement does

40 Asian Banker Research Report

Critical for banks to understand

Banks may also need to

Core banking replacement is

Core Banking System Overview

Outsourcing of software and

Source: Asian Banker Research

Banks approach to core

Increasing shift towards

We divide core banking

Asian Banker Research Report 51

A typical core banking

Banks need to initiate the

Asian Banker Research Report 55

56 Asian Banker Research Report

60 Asian Banker Research Report

Critical factors that determine

Vital to assess vendors

The functionality and

SOA critical for future exibility

Cost should not be driving

68 Asian Banker Research Report

Asian Banker Research Report 69

Seamless and smooth

Testing at all levels is the most

72 Asian Banker Research Report

Asian Banker Research Report 79

The replacement approach

The deployment approaches

82 Asian Banker Research Report

Inherent risks in replacement

Banks cannot afford any margin

Replacing core banking

86 Asian Banker Research Report

Financial justication through

Intangible boost to growth

Critical building blocks of core

Identify the deployment

Phased approach has

Build the system around SOA

94 Asian Banker Research Report

SOA and ESB together can

Asian Banker Research Report 97

For intra-branch transactions,

Asian Banker Research Report 101