01-2006-Aggarwal - Roadmap To Successful Core Banking System Replacement

Management Report:
Roadmap to Successful
Core Banking System Replacement
Critical Success Factors and Best Practices
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
Neeti Aggarwal, CFA
Published September 2006

©2006 The Asian Banker
IMP ORTA N T NOT I CE
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.
ABOUT THE ASIAN BANKER
ABOUT THE ASIAN BANKER

Asia’s financial service landscape is undergoing tremendous change and evolution.
Liberalisation, consolidation and rapid technological advances have opened up
tremendous opportunities for financial 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 Journal
• Asian Banker E-newsletters on different segments in the financial 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 Pacific Heads of Retail Banking Annual Meeting
China International Risk Convention (CIRC)
• Roundtable Series / Consultative Forums
Wealth Management Advisory Forum
Consumer Credit Advisory Forum
Risk Advisory Forum
• Industry Briefings
Contact:
THE ASIAN BANKER
10 Hoe Chiang Road
#14-06 Keppel Tower
Singapore 0899315
Tel: (65) 6236 6500
Fax: (65) 6236 6530
http://www.theasianbanker.com
ACKN O W L E D G E M E N T
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 financial services industry. He specialises
in core banking enabled change, business transformation, credit risk management
and strategy development. His career in banking and consulting covers assignments
in Germany, United Kingdom, Switzerland, Turkey, Nepal, Sri Lanka, ASEAN and
many other parts of the world.
He has managed retail and wholesale banking operations for major global banks
in Europe and Asia. After his stint as Deputy General Manager of a joint-venture
merchant bank in Indonesia, his interest turned to financial services consulting. His
consulting assignments constitute a highly diversified portfolio that includes some of
the largest commercial banks in Asia.
Core Banking
Transformation
Table of Contents
1. Core Banking Trends in Asia Pacific

Market Trends
1.1 Prominent recent deals in the region
1.2 Geographic dispersion of deals in recent years and 2006
estimates
1.3 Activity within countries and their vendor preferences
1.4 Estimates of system and software spending in Asia
Pacific
Technical Trends
1.5 Evolution and convergence of core banking systems
1.6 Technology integration in Asian countries
1.7 Trends in platform usage among Asian countries
1.8 Trends in deployment approach
2. Bankers’ Perception Survey on Core Banking System

Selection
2.1 Survey results on key reasons for replacement
2.2 Survey results on factors considered in system selection
2.3 UNIX versus mainframe – survey results on
considerations in system selection
3. Core Banking System – An Overview

3.1 Core banking system – an introduction and definition
3.1.1 Definition of core banking system
3.1.2 What to expect in core banking replacement
Tab le o f Con t e n t s
3.1.3 Rationale for front-end systems replacement

3.2 Overview of the core banking system replacement
project
3.3 Approaches to replacement
4. Phases of Core Banking Replacement and Critical

Considerations
4.1 Phases of core banking replacement – an overview
4.2 Timeline of replacement project stages
4.3 Phase 1 – Business justification and blueprint
4.3.1 Developing business objectives
4.3.2 Delta methodology – assessing future requirements
4.4 Phase 2 – Selection
4.4.1 Reasons for replacement
4.4.2 Considerations in determining selection criteria
4.4.3 Key considerations in vendor selection
4.4.4 The right architecture and platform
4.4.5 Selection process
4.5 Phase 3 – Implementation
4.5.1 Key challenges and critical success factors
4.5.2 Implementation process
4.6 Phase 4 – Deployment
4.6.1 Deployment process
4.6.2 Deployment approaches
4.7 Risk mitigation
4.8 Financial implications
5. Core Banking Replacement Building Blocks

5.1 Application architecture and core banking
5.1.1 Key issues
5.1.2 Deployment strategy
5.2 Service oriented architecture
5.3 Interface considerations
5.4 Coexistence
2 Asian Banker Research Report

Table o f C o ntents
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 Japan, Korea and Taiwan
Asian Banker Research Report 3

Tab le o f Con t e n t s
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

Exec ut ive S umma ry
Executive Summary
Increasing consumer demands, high costs and widespread dissatisfaction
with ageing systems are making it increasingly difficult for Asian bankers
to put off decisions to replace their core banking systems. We feel that the
banking industry worldwide is nearing a time when replacing core banking
systems would be a necessity rather than an option. However the complexity
of the task is such that it is often compared to a heart transplant, involving
huge risks, high costs and substantial time and human resources.
The critical need for replacement stems from rising customer expectations
and existing technical limitations. Banks are finding it imperative to expand
their channels and services while managing operational and technical costs
even as margins are shrinking due to stiff competition. But this is hampered
by technical limitations as many traditional financial institutions are shackled
by a series of heavily siloed non-integrated back-office legacy systems in
which customer information resides in multiple and unconnected locations.
Attempts to integrate these through layers of middleware have just made the
structure more complicated in many cases. On the other hand, abandoning the
antiquated structure itself presents a major challenge from the organisation
and financial perspectives. But competitive pressures are forcing banks
to take speedy actions, as can be seen in our analysis of trends in Asian
markets.
Analysing the Asian markets and the recent core banking replacement
decisions, we found that there has been a gradual rise in the number of core
banking deals in the last two years. Interestingly, almost half of the deals
during this period have come from state-owned Indian banks. These banks
had faltered due to competitive pressure from private banks and have found
it imperative to purchase (in most cases for the first time) new core banking
systems and upgrade themselves technically to improve product innovation,
agility in decision making and cost effectiveness. We expect the Asia-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 first-generation technical

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

E xecu ti ve S u m m a r y
Olympics in 2008. On the other hand, we have found that banks in countries
like Japan and Indonesia are still mulling over the wisdom of replacing.
Once a bank has decided to replace its system, it embarks on a complex

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

we begin with a definition of the core banking system. We define it as a
highly efficient “customer accounting” and transaction processing engine, for
high volumes of back-office transactions and customer-level accounting and
reporting of the deposit and loan products processed in the bank. However
it does not include the front office. Thus we believe that the bank has to
first determine whether it really needs to replace its core system or it can
manage with just front-office replacement. In many cases, it is likely that the
bank needs to replace both along with the general ledger – which would be
a project of even bigger magnitude. If the bank has to change both front end
and core banking, we recommend it be done through the same vendor to
avoid integration issues.
Our research shows that banks which go ahead with replacement should
make a clear transition from their legacy system to the new system. Partially
bringing old elements such as codes, process automation and loss-making
legacy products into the new environment will lead to sub-optimal returns.
We have divided the process of core banking replacement into four phases.
The first phase is business justification and identification of business
requirements through delta analysis. We believe that the bank should, first
and foremost, determine its long-term strategic goals as these would guide
the bank towards the critical requirements for its system. With the business
objectives in mind, banks need to analyse the capabilities and deficiencies
of their existing core banking system to determine the new system’s
requirements – yet during our research, we discovered that only 70% of the
banks in our sample do so. In addition to setting the objectives, the bank
should establish the business and financial justification for the project at this

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 financials
of the organisation but also its viability and competitiveness. Hence banks
need to critically evaluate all available options and select the system that
provides the right DNA (the architecture) to meet its business and strategic
requirements. We believe that the selection process should involve business
representatives from all functional divisions owing to the pervasive nature
of these systems within the organisation. Viewing the project as just an IT
project would be a recipe for failure.
The selection process begins with the issuance of a Request for Proposal
to various vendors. Each of the bids is assessed on both qualitative and
quantitative terms across a matrix of selection criteria. The critical requirements
from a new system are flexibility and scalability to cater to future growth. We
advise banks to ensure that with the new system, they are not simply shifting
to a bigger box which may become a constraint again in a few years’ time,
as this would defeat the whole purpose of replacing the system. Equally
important is that banks should not be enamoured with “bells” and “whistles”
(which are more often than not the front-end features) and should look for
a system that has the requisite processing power rather than just a 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
flexible architecture that has the ability to support the business ambitions of
the bank and allows for future modifications with ease. This can come from
Service Oriented Architecture (SOA). SOA is a relatively recent development
which, in its purest sense, is centred on loosely coupled components which
support generic services and are based on web technology. In a core banking
context, it essentially means reducing barriers in antiquated infrastructure and
creating real-time integration of disparate systems and sharing of databases
on a flexible and easily upgradeable infrastructure. We advise banks to look
for a system that has the flexibility of SOA and to integrate their systems and
components in an SOA-based framework within the bank.
Banks need to select not the “best” system available but the one that is most
appropriate for their particular requirements. Different banks and their unique
requirements are discussed in section 8.
Equally critical is selecting the right vendor. We believe that it is imperative

for banks to consider vendors as long-term partners in growth in today’s
fast-paced environment. The critical vendor assessment criteria include trust

in the vendor’s ability to meet the business objectives (through optimum

customisation and localisation of the product) as well as the vendor’s
reliability, implementation capabilities and financial strength. Vendors that
have a track record of providing international-quality products while meeting
the local needs of banks are more likely to achieve long-term success. The
mix of product and services coupled with pricing are critical considerations.
We have rated leading vendors in Asian markets based on our assessment
and a survey done among bankers – this is discussed in our section on
vendor assessment.
Platform choice is one other critical factor in selection. While mainframe

remains unbeaten in its robustness and stability, UNIX-based systems are
becoming more popular. We have discovered that banks in Asian countries
are increasingly shifting towards the more agile and flexible UNIX systems,
which are perceived to have lower operational and maintenance costs. While
this is true for banks that have lower transaction volumes, it may not be so
for large retail banks. We believe that mainframes continue to have a distinct
advantage in terms of stability and scalability. Hence for mission critical
projects, mainframes would still be preferred for their reliability. However for
small banks (and those banks that are acquiring a core banking system for
the first time and whose transaction volumes are not very high), a UNIX-
based system could meet their requirements. As more than 50% of the 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 configuration and customisation and
designs for interfaces and data conversion. The other critical elements of this
phase are building and testing the system, implementing pilot projects and
conducting business acceptance tests at each stage. We recommend that
banks limit customisation of the core banking system to what is 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
efficacy and success of the project; this would determine whether it progresses
to the next stage. Delta analysis and sign-off at each stage are essential to
ensure that deliverables and expectations match, or else the project can
easily digress from its initial plan and increase in scope through incremental
changes which will lead to schedule and cost overruns.
The next and final phase of the project is deployment. This is probably the
most critical and challenging stage, where the bank undertakes the actual

deployment of the new system. The process involves numerous logistical

issues such as data conversion, interfacing and coexistence.
Banks can approach this transition in two ways – big bang implementation
and gradual deployment. Big bang essentially means all systems go live at
the same time. While this is quicker, it is also riskier. Instead we recommend
phased implementation, where deployment is done in small clusters, though
the bank has to tackle the tricky issue of coexistence. We believe that the
gradual step-by-step approach is appropriate in most cases as it entails lower
risks, facilitates change management and allows changes to be incorporated
in the technical framework as it is being installed (to provide a better fit with
the business).
Data conversion and data mapping are two crucial elements that the bank has
to deal with during deployment. The data migration and conversion process
is often hampered by lack of available information on the old system. Mass
migration requires a large capital investment, takes a few years to implement
and poses a significant risk of service interruptions that can reduce customer
satisfaction. The other critical challenge is to maintain smooth operations
and develop interfaces across delivery channels during transition through
coexistence of two systems.
We believe that banks should predefine the milestones at each stage of the
replacement process and ensure they are adhered to. At any stage, if the
bank finds that it cannot achieve these milestones, it may review its project
and decide whether and how it wants to continue the project.
Our research into change management during replacement shows that the
majority of banks upgrade their system or implement a new one to meet
existing users’ process and work culture requirements. Instead, however,
we recommend that banks align their products, processes and work culture
with the new system. In other words, the replacement should be undertaken
together with product and process rationalisation coupled with work culture
transformation in order to optimise the returns from the new system.
This embracing of new technology requires tremendous effort in change

management, which demands extensive user training and re-engineering
of processes across the organisation. There is often resistance to change
and employee dissatisfaction during the transition. We believe this can be
countered only through effective communication and developing the right
business environment.
We have discovered that just 30% of recent replacement projects had active
CEO involvement. However our research shows that successful projects
require the backing of a strong leader from top management with a strategic

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

Core Banking Trends in
Asia Pacific
1
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 Pacific
Market Trends
1.1 Prominent recent deals in the region
1.2 Geographic dispersion of deals in recent years and 2006
estimates
1.3 Activity within countries and their vendor preferences
1.4 Estimates of system and software spending in Asia Pacific
Technical Trends
1.5 Evolution and convergence of core banking systems
1.6 Technology integration in Asian countries
1.7 Trends in platform usage among Asian countries
1.8 Trends in deployment approach
Core banking Trends in Asia Pacific
1.1 Prominent Recent Deals in the

Region
Market Trends 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 significant 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 find it difficult
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.

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.
Core banking systems market Leading Vendors in Asian Countries in Last two Years
continued to be active in 2005
• 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-flex has
emerged as the top vendor in this country.
• The Philippines was rather subdued with just two deals in 2005 (as
compared with five 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
flurry of activity with many small banks upgrading their ageing systems
primarily through local vendors.
No vendor emerges as a • Internationally, one of the biggest deals in the past year was for HSBC’s
clear leader in Asian region,
but some vendors have global operations, which was won by Temenos. The bank is understood
higher market share in certain to be improving further on the present solution. Within the region, DBS
countries
Bank’s core banking deal was another feather in the cap of Infosys, a

leading player in the region, particularly in India.
• Analysing vendor dominance in the region, we discovered that I-flex,

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 significant deal in Asia in the recent two
years though it continues to be a fierce 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 specifically 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

difficult 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
Market Trends Number of Deals in Last two Years and Our Estimates for 2006
Legend
20 Number of deals in 2006(e)
Number of deals in 2005

15 Number of deals in 2004
10
0
a a rs an a a s re a nd
di si he in si ne na
m
po re la
In ay Ot
iw Ch ne pi et a Ko ai
al Ta o
ili
p Vi ng th Th
M I nd Si
Ph S ou
Source: Asian Banker Research
Regional Breakdown of Deals Within Asia for 2005
Philippines Others
5% 13%
Indonesia
5%
India
Greater China 50%
16%
Malaysia
11%
The deals include only core banking deals in the region. It does not include
other applications and systems such as treasury and trade processing.
Indian market is fast reaching • We believe that activity for core banking systems will increase steadily in
saturation; China and Taiwan
are opening up the next 2-3 years in Asia Pacific. The trend in individual countries will,
however, vary based on local market conditions.
• Clearly, India continues to dominate Asia’s core banking systems market

with its 50% share of the total core banking deals by commercial banks
in the region. This is because the emergence of technically advanced

private banks in the country has forced most state-owned banks to

substitute (and in most cases acquire for the first 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 finding
it increasingly difficult 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
Market Trends Activity in Banking Sectors for Core Banking Replacement in Last two Years
Vendor
Preference
Less active, international demand High activity, international demand
International
Vendors Singapore Vietnam
Thailand
Taiwan
Philippines
Indonesia South
Korea Malaysia
India
Local China Legend
Vendors
Trends
indicate likely
shift in future
Less active, unique local needs Highly active, unique local needs
% of banking
sector replacing
05 10 15 20 25 30 CBS in last 2
years
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.
Indian banks have favoured • We believe that almost 25% of the Indian banking sector has entered
technical advancement through
local vendors 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 significant. 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.
Other Asian countries expected • Interestingly, the banking sectors of Thailand and Korea saw no new
to continue to show demand for
core banking transformation 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.

China banks have preference • Most Chinese banks have shown a strong preference for systems
for systems that cater to their
unique needs that are designed to suit their specific 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
first-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 first 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.

1.4 Estimates of System and

Software Spending in Asia
Pacific
Market Trends Investments Made by Asian Banks in Core Banking System Software and Services
($million) (%)
1,000 0.14
800 0.13
600
0.12
400
0.11
200
0 0.10
2004 2005 2006f 2007f
Legend
Estimated spending by Asian banks on purchase of CB system software and services
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.
Steady increase in spending • We have discovered that the cost structure of core banking deals varies
likely to continue; no significant
jump expected in near future
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%.
Deal sizes have varied from • Based on our analysis of recent deals, the system and service cost for
about $5 million for small banks
to more than $50 million for
a small bank (with a size of $1 billion or less) comes to $5 million-10
large wholesale banks 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.

• 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
Technical Trends Evolution of Core Banking Systems
Taishin: FNS
HDFC: I-flex for Baroda: Finacle
HDFC: I-flex for corporate B.Shanghai:
retail OCBC: Silverlake Temenos
StanChart: HSBC-Temenos DBS -

China Bank: KDB: FNS testing open Infosys Central Bank
Kirchman Banco de Oro: Chinatrust: sys of India - TCS
ICICI: Finacle ICBS FNS Kasikorn: IBM China Minsheng - SAP
1970 1990 2004 2005
Legacy Web XML Web services Service-oriented architecture?

systems
Parameterisation
EAI, BPM, WS
J2EE, .NET Business Platform
Convergence in Core Banking Systems
Mainframe
systems
Parameters Towards
J2EE, .NET platforms; EAI, BI, WS integration tools core banking
systems today
UNIX
systems
Evolution of core banking

industry in Asia shows • The first generation of banking technology was represented by the IBM
increasing convergence of
technologies and focus on
mainframe, which had immense data processing capabilities but was not
architecture of systems as efficient in back-office accounting functions. Nonetheless its reliability

and scalability remain unbeaten today. In the next stage of evolution came
parameterisation of processing rules and enhancement in automation
from back- to front-offices. 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
Banks need to adopt Service • Service Oriented Architecture (SOA) is a relatively new concept that
Oriented Architecture
has gained popularity quickly. Herein, business applications are
constructed from independent reusable interoperable services that can
be reconfigured without a vast amount of technical labour. The concept
is based on web services and components that are brought together to
perform specific 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 flexible and easily upgradeable
infrastructure. We discuss this in more detail in section 5.
• On the architectural front, J2EE and .NET are two architectural frameworks
that have evolved in the last few years. These are new-generation flexible

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 flexibility,
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.
Asian vendors are increasing • The growth in demand for core banking systems in Asia Pacific has
their global reach
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-flex and TCS.
Desire to become leading • Desire to become the leading player in the market has led to mergers
player has led to consolidation
in the industry and acquisitions among IT service providers. At the global level, Fidelity’s
acquisition of Sanchez broadened its reach to a larger collection of
banks. Among leading vendors in Asia, TCS acquired FNS in a leap from
their previous alliance. Another example of consolidation in the industry
is Oracle’s acquisition of a stake in I-flex. These players are developing
an increasingly strong foothold in the core banking systems market.
• Greater convergence makes it difficult for bankers to differentiate

between vendors’ value propositions. However standard protocols and
fierce competition have led to more product offerings and price wars – a
boon for the industry as a whole.

1.6 Technology Integration in

Asian Countries
Technical Trends Technology Integration in Asian Countries
Hong Kong
Thailand
India (State Banks) Taiwan
Singapore
Philippines
Australia
China
India (Private Banks)
‘Customer centricity’
‘Account centricity’
Malaysia
Japan
Indonesia
Korea
RM e
ric nd
at ch
ki h
nt d
en s
c C ar
em m
or nc
ce se
n
t
ng
re
ris an
nt a
ity
si w
nc ste
ta ali
io
tw ra
ce ces
ba le
te Br
ne B
va sy
da ntr
d idd
er rvi
ad ing
Ce
an t m
om se
nk
pu
st b
s
bu
cu We
ba
m
Ro
co
re
Co
Developed countries have • We tracked the technical advancement of banking sectors and
shown distinct technical
advancement architectures in several Asian countries. We discovered that the
integration of technology and the movement from account centricity to
customer centricity have varied significantly among Asian countries.
Developed countries such as Japan, Singapore, Hong Kong and Australia
have shown distinct technical advancement not only on the core banking
front but also in their banking systems architecture, achieving customer
centricity through integration.
• On the other hand, developing countries like China, Thailand, Philippines,

Indonesia and Malaysia are far behind. These countries are now moving
towards data centralisation (having advanced from branch automation),
but many of the banks have yet to achieve core banking sophistication.
Architectural integration is still at the initiation stage in these countries.
However we believe that competitive pressures are forcing banks to
expedite this process.
• In India, relatively new private banks have given a new direction and a
significant 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.

1.7 Trends in Platform Usage

Among Asian Countries
Technical Trends Recent Core Banking Acquisition Trends Among Asian Banks
Primarily UNIX-based Primarily Mainframe-

System Users based System Users
● South Korea ● Japan
● China ● Hong Kong
● Pakistan ● Philippines
● Taiwan ● Thailand
● India ● Malaysia
● Vietnam ● Indonesia
● Singapore
Likely to shift to UNIX

Many countries continue to be • Traditionally, Asian banks – particularly those in Korea, Japan and China
primarily mainframe users but
there is a strong shift in favour
– use mainframe-based proprietary systems. The robustness, stability
of UNIX systems and scalability of these systems have been proven over the years and
continue to attract these banks. But in the last five 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 flexibility and agility. Accelerating
Competitive pressures and cost
effectiveness of UNIX-based the trend is the fact that most Asian banks are smaller compared with
systems are driving the shift 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 flexible system.
• For these reasons, we have seen an increasing shift among Korean

and Chinese banks towards UNIX-based systems. However Japan and
many South East Asian countries still seem to be adopting a “wait and

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

core banking systems for the first 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
Technical Trends Deployment Approaches in Recent Core Banking Decision
Existing Bank Asset Size

Implementation
More than
Time $100 billion
Singapore
$20-100 billion
HSBC
Bank State Less than
Bank of India $20 billion
Long Central
Duration Bank of
India DBS
Bank
Industrial
China Bank of
Minsheng Muslim
Korea
Bank Commercial Union
China Bank Cathay Bank of
Development- Allahabad United Philippines
Bank Bank Bank
Short Hua Xia
Duration Bank of
East Asia Bank Bank of
Panshin
Implementation
Gradual Implementation Big Bang Implementation Approach
Bigger banks continue to prefer • The banks have two options in deployment. “Big Bang” implementation
gradual deployment while some
smaller banks choose “big
largely involves a new system which goes live at the same time that
bang” approach 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 Pacific, 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 difficult 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 five years for HSBC.
Similarly, ABN AMRO plans to gradually implement its system in the
Greater China region and some other Asian countries over a period of

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

Bankers’ Perception
Survey on Core
2 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
B anke r ’s Pe r c e p t ion S u r vey
2.1 Survey Results on Key

Reasons for Replacement
Perception Survey on Key Reasons for Replacement
Flexibility
Cost
Integration
Simplification
Technology
Timing problems
Scalability
Errors in processing
Availability
Errors in data
Errors in operation
Other
10 20 30 40 50 60 70 80
% of executives citing area as a problem
• A survey done in Asia Pacific countries last year found that inflexibility,
high cost and difficulty of integration were the three main problems that
banks faced in legacy systems.

Banker ’s Perc ep tio n S urvey
2.2 Survey Results on Factors

Considered in System
Selection
Perception Survey on Factors Considered
Cost
Short product time-to-market
Availability of third party applications
Ease of integration
Vendor reputation and track record
Ranking
Straight through processing/ real-time capability
Truly modular and integrated, single sign-on
Functionality
Scalability
Reliability/ stability
Importance
Cost remains the key • With increasing standardisation and convergence, banks believe that it
consideration when choosing
a core banking system,
is now easier for them to switch from one vendor to another for multiple
regardless of platform 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
benefits that was motivating them to change their core banking systems.
• Another key reason cited by many bankers was their desire to improve
competitiveness through faster rollout of products, product innovation
and differentiation. Availability of third-party applications and ease of
integration were other critical factors that the bankers looked for in system
selection. Vendor reputation and track record also came high in the list.
Trust in the vendor’s ability as well as the vendor’s reliability and fit with
the project are often cited as considerations in the selection process.
• Interestingly, architectural features such as STP, flexibility 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.

2.3 UNIX Versus Mainframe

– Survey Results on
Considerations in System
Selection
Perception of Strengths of Each System
MAINFRAME SYSTEMS UNIX SYSTEMS
42 47
32 37 37
11
21 5
Stability Availability of Total Cost of Scalability Application
Internal Skills Ownership Instability
Availability
Old
Architecture More Vendors
Many banks in Korea and Japan vs Monopoly UNIX systems can be For operational expenses, UNIX
use internal programmers to approximately 50% cheaper systems can be 30-40% cheaper
customise their systems. than mainframe technology. than mainframes.
Interestingly, mainframe systems
are perceived as old, while UNIX
systems are perceived as new,
which is not always true.
Stability is the biggest • In a survey done some months back, we asked bankers what they saw
perceived strength for
mainframe systems, while lower as the strengths and weaknesses of UNIX and mainframe systems. We
TCO is the biggest perceived found that while there are an increasing number of banks favouring UNIX
strength for UNIX systems 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

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 find 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
Mainframe SYSTEM UNIX SYSTEM

Strengths Strengths
Reliability - Highly reliable Cost - Perceived lower total cost of ownership (TCO).
However, in real life operations, the TCO in complexity of
Scalability - Highly scalable, essential for larger banks operation increases with the numbers of users and
transactions volume
Robustness - Robust applications with good track record
Architecture - Considered more flexible architecture. Our
Security - Substantially higher levels of system security 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
Weaknesses Weaknesses
Cost - Cost to acquire and maintain Reliability - Less stable than mainframe systems (but this
could be acceptable for smaller banks)
Agility - Perceived slower development and adaptations
to trends in technology Scalability - Lower level of scalability. Scalability comes at
the cost of overly complex operating environments
Hardware/Software - Fewer hardware and software
suppliers can lead to challenges in negotiating a Security - Lower level of security than mainframe
reasonable pricing if the bank does not posses sufficient systems. Viruses have been found in Unix based
bargaining power environments
Skills - Smaller and hence more expensive pool of Deployment -Not yet proven on large scale though
skilled resources available in the market becoming increasingly popular among smaller banks

Strengths and weaknesses of • Open systems have proved their ability to perform from the security and
proprietary and open systems,
as perceived by respondent technology points of view. According to one banker, “5-10 years ago a
banks large bank would go for mainframe, no questions asked. But in the last
5-10 years things have changed. Any bank today, no matter how big,
may consider switching to open system.”
• On the other hand, most big banks still favour the reliability and stability
of mainframes. Some bankers are inclined towards proprietary systems
as they are used to working on them. Switching to a new technology
would not only involve a huge amount of cost and high risks but also
require effort to get used to the new processes.
• According to one vendor, “Open systems are most appropriate for Asian
banks due to their smaller size compared to many international banks.
They don’t need the scalability of mainframes and the scalability of open
systems has really increased in recent years.” One leading bank in Korea
states that the trend in Korea today is to shift towards UNIX systems
from IBM “due to the availability of small packages that can be easily
integrated in our system [whereas] when we use mainframe we need to
code them which would be a time consuming proposition”.
The right choice varies with banks’ requirements

Our research and analysis of • As can be seen from the survey, platform choice is a dilemma that all
the platform features reveal a
different picture
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

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
Core Banking System – An
Overview
3
There are various definitions of “core banking system” circulating
in the market. We have defined 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 definition

3.1.1 Definition of core banking system
3.2 Overview of the core banking system replacement project
3.3 Approaches to replacement
Core B a n kin g Sy s t e m Over vi ew
3.1 Core Banking System – An

Introduction and Definition
Perceived needs justifying
• Core banking replacement is becoming a hot topic in banking. We
replacement of core banking
system 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 difficult and expensive to maintain and support
- No Common Customer View – Multiple customer views and complex
processes are not easily integrated with the existing technology
infrastructure
- No Product Factory – Innovative, highly interdependent product bundles
are not supported by the existing core banking system; it is laborious to
launch new products and services
- Long Deployment Cycle – Technological inflexibility demands lengthy
development cycles
- No/Limited Basel II Support – New and more complex Basel II-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 justification given for this investment to address all of these issues:
- “We are losing market share. We need to replace our core banking
system now to increase our competitiveness and regain lost markets.”
- “We need to replace our core banking system to have a better
understanding of our customer.”
- “We need to replace our core banking system to be able to bring new
products to the market faster.”
- “We need a core banking-enabled product factory.”
These and similar statements are what we hear when talking to leading
bankers throughout the region.
• The software vendors of course are responding to these needs, by

claiming:

Core Banking Sys t e m O ve rv iew
- “Our system will transform your organisation and make your bank more
competitive.”
- “With our system, you will be able to significantly enhance your CRM
capabilities and gain market share.”
- “Our solution will automate your lending process, improve your collateral
management capabilities and make you Basel II compliant.”
• The key questions which now arise are:
- Are the bankers’ perceptions about the outcome of a core banking

replacement correct?
- Does a “traditional” core banking replacement project address all of
these issues?
- Do the statements made by software vendors truly reflect what their
clients can expect from a core banking replacement project?
To answer these questions, it is necessary to clearly define what a core
banking replacement really is
3.1.1 Definition of a core banking system

Core banking system is simply • We have discovered that there are multiple definitions of core banking
the core processing power of
the bank systems today. However based on our discussions with industry experts,
we can define core banking, in simple terms, as a highly efficient “customer
accounting” and transaction processing engine for high volumes of back-
office transactions. The purpose of a core banking system is thus to
give banks the ability to process large transaction volumes in a fast and
efficient 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 Transaction Processing Engine
Customer Information Repository

Core Banking replacement does not provide
Core Banking replacement does you with an industrial-strength customer Core Banking replacement does
8
not provide you with a front end, information repository which allows ease of not provide you with an industrial-
8 8
CRM or multi-channel capabilities. integration of disparate core systems strength general ledger system,
and ERP capabilities.
Core Banking System
Application Integration
Channel Integration
Reporting
Deposits Loans
Common Services
Product Definition & Management
Front-end Core Banking System General Ledger

System System
9
Core Banking replacement gives you raw
Replacing the Front End is a power. It provides you with a highly efficient Replacing the General Ledger is a
separate system and a separate engine for all your transaction processing separate system and a separate
project needs project
“accounting entries” which are posted into the bank’s GL system

according to its chart of accounts structure for the daily trial balance
sheet preparation. The chart below illustrates the scope of a core banking
replacement project.
What Core Banking Systems Do Not Do
• Core banking systems do not deal with the customer-facing front end
of the bank. Core banking systems also do not deal with the analytics
embedded in an industrial-strength data warehouse design.
• Core banking systems do not include a comprehensive CIR (Customer

Information Repository) though they do include a CIF (Customer
Information File) or CIS (Customer Information System) focused on their
own processing and reporting needs. These components have only the
necessary customer information or capabilities embedded.
• In a Service Oriented Architecture solution, the CIR will sit on top of

the core banking systems, as it is assumed that a bank will always
have multiple core systems which need to interact and share customer
information. The chart below illustrates a typical banking architecture
and shows where the key components reside.

Conceptual Application Architecture Framework

Sales & Service Business
Delivery Core Systems Intelligence
Customer Information Data Warehouse & Data Marts

Delivery Channels
Repository Enterprise data warehouse
Application supporting the
Channels
Physical
with relevant data marts
bank’s delivery channels.
Integrates into the customer
relationship management Workflow Management
Document Imaging Capability Relationship & Risk
and core systems Management Infrastructure
Common customer view and
Data Warehouse
Imaging and Workflow central customer liability. “The
Channel Integration
Imaging and workflow Core Banking customer belongs to the bank”
capabilities e.g. for the and not a booking unit
commercial lending process
Channel Integration
Reporting
Middleware Infrastructure
Deposits Loans Data Mining
Virtual Channels
Integration infrastructure to
Utilise existing information in
link the bank’s systems. A
the data warehouse e.g. to find
modern architecture is built
customer behaviour pattern
around an enterprise service
Common Services
bus utilising an SOA
New Age Channels

Internet-based virtual
delivery channels, including Other Support Systems
Web and WAP services
Source: Immacon Research

Critical for banks to understand • To start an effective core banking replacement programme, the bank
what they would get in core
banking replacement
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

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.

Banks may also need to • To make matters more complicated, it is often important to also change
replace front end to reap
benefits from core banking
the front-end applications, to better reap the benefits of the core banking
replacement 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 find it difficult to
sustain this approach as the project progresses and the limitations of
the package become clearer.
- Package solution customised to the bank’s desired processes:

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

process designers capable of defining the future business and technical
architecture to build and implement the solution. Few banks in the world
are suitably equipped for such an undertaking at this time.
• During package selection, the bank will typically need to choose from
the following scenarios:

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

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

3.2 Overview of the Core Banking

System Replacement Project
Core Banking System Replacement Project – an Overview
Project Stages
Development Development Selection Ongoing

of business Selection of of selection Bidding System of service Implementation technical
objectives approach criteria process selection provider and launch support &
enhancement
Reasons for Select right Evaluate Select software

replacement platform financial vendor and
impact integrator
Gap analysis of Select right Risk-return Identify right

existing architecture analysis approach to
infrastructure implementation
Core banking replacement is • Replacing or even upgrading the core banking system is a complex
almost like a heart transplant
involving high cost, high risk, and high-risk proposition requiring substantial resources and time. Most
and substantial effort and time banks prefer to defer the decision till the change becomes imperative.
The decision making process includes providing financial and business
justification to the management and evaluating the risks and returns; it
is a time consuming process that requires the involvement of not just the
IT people but also decision makers across functions. We believe that
opportunity costs are high and hence a successful bank is one which
can take fast decisions and has adequate management support to carry
them through.
• Risk-return analysis has to be coupled with development of business

objectives, gap analysis of the existing infrastructure and delta analysis
of future needs. We believe that it is critical at all stages of selection
and implementation that banks keep business objectives in mind as the
primary consideration.

Core Banking Replacement Stages
Continuous
Masters of the Improvements
World
"We made it"
Efficiency/ Performance
Euphoric
Project "We will change
start the world"
Disillusioned
"This is hard but we
have passed the
point of no return" The Emperor’s New Clothes
"We got the old systems in
new clothes"
Reality Strike
"The honeymoon
is over"
Scapegoating
"It’s somebody else's mistake"
"How can we get out of this"
Replacement Stages Through the Project

• 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 Purchase of system

Complete
development and software and
outsourcing
implementation services
• Ownership of hardware and • Ownership of hardware • Outsourcing of software and

software hardware
• System integrator hired for
• Software either developed software • ASP hired to meet the core
in-house or purchased from banking needs of bank
vendor • Vendor customises, integrates
and implements solution • ASP maintains the accounts
• Implementation of system done according to the bank’s and branches through its own
in-house requirements data centre, and meets all the
core banking needs of bank
• In-house IT expertise required • Critical to select the right
– suitable for large banks software and vendor with • Charges calculated on per
domain knowledge transaction or per branch basis
• Approach adopted by many
banks in Japan and Korea • Approach adopted by many • ASP provides expertise but
medium and small banks may commoditise service
Bank’s approach to core • Our research shows that banks can choose from multiple approaches for
banking replacement depends
on the availability of financial upgrading or replacing their core banking systems. The most appropriate
and human resources approach would vary with the availability of technical skills, complexity of
the task, availability of products and costs involved.
Buy vs. Build • Many banks, particularly large banks, have preferred to develop systems
in-house to suit their business requirements (as can be seen in many
banks in Japan, Korea and China). This is primarily due to the complexity
of their operations and their desire for flexibility in developing a system to
meet the unique requirements. However this requires extensive capital
investment and channels substantial resources away from the banks’
core business.
• The debate on ‘Build’ versus ‘Buy’ continues among a few top-tier banks
that have the ability to build their own systems. But increasingly, banks
are awakening to their shortcomings as an IT developer and becoming
more inclined to focus on their core business instead.
• Banks select a replacement approach based on their individual

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

Increasing shift towards • The substantial cost, resources and expertise involved in building a
packaged solutions among
smaller- and medium-sized
new system has forced many banks (particularly medium- and smaller-
banks sized banks) to turn to purchasing packaged systems from vendors and
thereafter customising to suit their requirements (either by themselves
or asking a system integrator to customise). For example, State Bank
of India hired TCS as its system integrator; TCS purchased the system
from FNS and customised it to meet the bank’s needs, and then the
bank itself implemented the final 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.
Outsourcing an option • Some banks may prefer a third alternative: complete outsourcing
considered due to low cost and
vendor expertise
to an application service provider (ASP). This frees up resources for
banks as they need not own the hardware or the software for their core
banking activities. Management of the data centre and branches may be
outsourced to a vendor that is adequately equipped and has a proven
track record in providing these services. In return, the banks could pay
the ASP on a per-transaction or per-branch basis.
• While a few second-tier banks in Australia and Japan have turned to

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

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

Phases of Core Banking
Replacement and
4 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 justification 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
The Ph a ses O f C or e Ban ki ng Rep l acement
4.1 Phases of Core Banking

Replacement – An Overview
• In our analysis of best practices for core banking replacement, we
have identified four key phases required for a successful core banking
replacement project, namely:
We divide core banking Core Banking Replacement Project Phases
replacement into four phases
Project Phases
Business
“Delta Driven”
Justification & Selection Deployment
Implementation
Blueprint
Dependent on Chosen
4 - 6 Months 4 - 6 Months 18 - 24 Months
Deployment Approach
Understand Business Imperatives Develop “Long List” for Vendor & Delta Definition Training & Change Programme
Integrator
Achieve Consensus on Business Delta Resolution External & Internal Communication
Driver & Approach for Core Request for Information
Banking Replacement Design Logistics
Finalise Platform Choice, Refine
Define Core Banking Requirements and Develop Build & Test Rollout Schedule
Transformation Strategy eg. “Short List”
Replacement or Transformation Pilot Big Bang or Phased Deployment
Agree on Selection Process
Develop “Delta” Transformation - Delta or Traditional GAP
Blueprint - Scoring or Judgement
- Business Scope & Objective
- Reference Technical & Business Prepare Request for Proposal
..Architecture
- Platform Preference Update / Refine Business Case
- Process Transformation Scope
- Organisation Alignment Bidding & Contracting Process
- Visualisation of “New World”
- Business Case / Financial Impact Award Contract
..Analysis
- Risk-Return Analysis
Source: Immacon SOBIT Methodology
• The Business Justification 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 specifications for the new system, more often than not, resemble
a detailed description of the existing “Old World” legacy system. In

T he Phas es O f Core Banking Re p la ce ment
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 final 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
“Delta Driven”
Implementation
Blueprint
Dependent on Chosen
4 - 6 Months 4 - 6 Months 18 - 24 Months
Deployment Approach
A typical core banking • As time management guru Alan Lakein has taught us, “failing to plan is
replacement project takes 18-
24 months though the duration
planning to fail”. Thus the first phase of the core banking replacement
varies with the extent of change project provides an overall plan for the initiative. It is important for business
and size of bank decision-markers to agree on the business objectives and justification
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
Phase Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Phase 1: Business Justification & Blueprint 4 to 6 months
Understand Business Imperatives
Assess Current Operations The 'future state' defined in the blueprint and visualisation is input to the
RFP requirements and the solution design and underpins the change
Blueprint & Visualise Future Operations management and business transformation efforts.
Prepare Implementation Roadmap
Develop Business Justification
Phase 2: Selection 6 to 9 months

Issue RFI / Refine Vision
Issue RFP & Receive Responses The selection timeframe is dependent on the number of vendors involved
and the level of detail required by the RFI and RFP documents.
Select Systems & Service Provider
Conduct Negotiation & Contracting
Phase 3: "Delta" Driven Implementation 18 to 24 months

Delta Analysis
Detailed Design
Build & Test
Pilot
Phase 4: Deployment
Logistics
Training
Change Management & Communication
Go Live
Fine Tune

4.3 Phase 1 – Business

Justification and Blueprint
Objective: Develop business objectives and establish the vision and
justification for the target future state.
Core Banking Replacement Justification & Blueprint Development
Business
“Delta Driven”
Implementation
Blueprint
Developing business objectives

of core banking system
replacement Project Stages
Understand Blueprint &

Assess Prepare Develop
Visualise the
Business Current Implementation Business
Future
Imperatives Operations Blueprint Justification
Operations
Sign Off
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

Banks need to initiate the • While banks are awakening to the need of advanced and more flexible
process by developing clear
business goals
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 efficiencies towards meeting long term targets.
Requirements for core banking • While the broad requirements from the system functionality would be
system varies between banks
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.
Business objectives should be • These Business objectives should in turn act as key guiding factor in
the guiding factor throughout
the replacement project
establishing selection criteria. These should be forward looking to ensure
suitability of the new system in long term as a bank replaces its system
once in 10-15 years. Nonetheless in today’s fast paced environment it is
extremely difficult for one to judge what the face of market would be after
few years and hence the bank has to ensure flexibility in the system.

Delta methodology requires • Our research into replacement case studies shows that it is imperative
banks to anticipate future needs
and plan accordingly 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

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 define 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 justification, a
financial 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 Justification); 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.
Key Concept 1:
Bank Transformation Stage 1
“Leaving the Legacy Behind”
New World
Do Not
Cross
Legacy Old World Loss

Process Legacy Making
Automation Code Legacy
Products
Old World

Delta Analysis
Key Concept 2:
Delta Analysis
Moving Towards A “Legacy

Free” New World
Old World Reporting

Local Practices
New World
Policies & Procedures
Old Core Banking Products New Core Banking
Processes
Systems Systems
Stakeholder Benefits
................... ...................
................... ...................
................... ...................
................... ...................
Mainframe
New
UNIX Core Banking
System
Delta
AS 400
Analysis
SOBIT Core Banking Implementation Methodology
The Delta not “A Gap” will drive the development of the Delta Definition Documents
Key Concept 3:
Phase
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
“Put A Stake in the Ground”
Phase 0: Setup and Initiation Before Proceeding
System Selection
Programme Initiation
Phase 1: Business Justification & Blueprint

Conduct Delta Analysis
Design Integration
Phase 2: Selection
Build
Business Realignment
Integration
Test
Phase 3: "Delta" Driven Implementation

Pilot
Phase 4: Deployment
Logistics
Training
Milestone:
Next phase will be kicked
off once previous phase’s
sign-off is completed
Design Design Pilot Deployment
Go / No Go Sign-Off Go / No Go Go / No Go
Go / No Go Decision
Milestones
Go Project will continue to the next phase
8
Project Flow
Project will stop until

Stop milestone is signed off
• In summary, successful core banking replacement projects we have seen

are driven by clear business objectives, a strong business justification,

a blueprint for the future and a roadmap on how to reach the target
– all developed in the first phase of the project. This is followed by 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.
Delta methodology would • Key activities to consider for the business justification stage of the project
facilitate business justification
are:
- Define 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
- Define the implementation approach and timeline to achieve the future

state
- Formalise the business justification for the future state

4.4 Phase 2 – Selection

Critical Considerations in the Selection Process
Project Stages
Develop Invite
Identify key Develop Initial filter to Financial
selection presentation
deliverables to Request for eliminate assessment
matrix. Identify from
meet long-term Proposal and unsuitable and final
‘Go’ / ‘No Go’ short-listed
needs invite bids vendors selection
criteria vendors
Consider Develop a Invite bids from Eliminate the Final selection Financial
long-term strategic rating system vendors that products and should assessment is
goals of the bank detailed to have strong vendors that do comprise important but
provide experience in not meet the detailed decision should
objective & similar projects, essential analysis of be based on
subjective reputation and criteria vendor and its product and
assessment track record partners in the vendor
project capability

Identifying the critical current Key Demands from New Systems
and future needs to be met by
new system
Problems with legacy system Demands for new system
Outdated architecture Flexible, scalable
Lack of flexibility Component-based architecture
Lack of scalability Competitive edge
Product-centric Customer-centric with single

view of customer
Disparate systems lacking
information accessibility Easy information access
Long product rollout time Higher efficiency
Slow response time STP ability
Product innovation difficult Product differentiation easy
High operating cost Lower operational and

maintenance cost
High maintenance cost
Lower TCO
Scarce trained manpower

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

technology is one of the prime reasons for change. In countries like India
where private sector banks boast technically advanced systems, it has
become imperative for public sector banks to replace their systems as well
to lower the attrition rate and survive in this competitive environment.
• Many banks have decades-old legacy systems that either fail to support
the latest products or do so with complex and time-consuming effort. The
operational and maintenance costs are steep and available manpower
for maintaining them is dwindling. According to one vendor, ”Just keeping
these systems running can often consume more than 70% of the IT
budget, leaving little money to gain advantage over competitors.”
• While these systems have been stable, they are highly inflexible and
hence largely unsuitable in today’s competitive environment. Many of
these systems were implemented at a time when banks did not engage
in fee-based transactions. Rather than being customer centric, they are
largely account centric.
• Branches need excess staff to maintain systems and back-office 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 difficult, as these involve
the collation of a large amount of data from disparate systems held in
different formats. For example, in legacy systems, a credit card division
may not know about the customer’s savings account. The banks that still
have no centralised customer-centric system are realising it is essential
to acquire one as this would provide them with a single customer view
and easily accessible and deployable real-time information, thereby
improving the banks’ efficiency 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 flexible 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.


Critical factors that determine Focus of Banks with Regard to Selection Criteria
the selection criteria
Business Direction/Goals
5
4 Scale and Complexity of
Existing System/
Operations
Technical Capacities 3
2
1
Human Resources Product Features
Legend
Ideal Bank
Business Culture Process Cost/Financial Impact Average Bank
Scale of 0 to 5 measures level of importance

Source: Asian Banker Research (0 = Not important at all, 5 = Very important)
The bank needs to develop • Selection of the system is a strategic decision which can impact not
selection criteria based on
its unique requirements and
just the growth and financials of the organisation but even its viability
business objectives 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 first 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, flexibility, availability of
human resource, costs and processes of the existing system would
determine the technical capabilities and type of architecture required
of a new system. Integration of the new and existing systems within
the bank and the problems therein would also determine the system
architecture required and the risks involved in the change process.
• The complexity and scale of the bank’s operations would shape its
scalability and flexibility requirements for the architecture and platform.
For example, a large retail bank may prefer mainframes due to reliability

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, flexibility and agility.
• Finally, the right technology should come at the right price. Cost and
financial 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.

Critical considerations in Focus of Banks in Assessing Core Banking System Vendors
assessing IT service providers
Track Record
5
4 Product Functionality
Ongoing Support
3
2
1
Financial Viability Cost / Financial Impact
Legend
Ideal Bank
Commitment to Business Reliability Average Bank
Scale of 0 to 5 measures level of importance

Source: Asian Banker Research (0 = Not important at all, 5 = Very important)
Evaluating vendor track record • Banks cannot bring about transformation in their systems alone. Most
and financial viability is a must,
but equally important is for the
banks see a core banking project as a highly risky proposition, so they
bank to assess its comfort level would invariably like to partner a vendor whom they can trust and believe
with the vendor’s ability 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, financial viability, technical capability, product
features and cost.

• 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.
Vital to assess vendor’s • In addition, the IT partner’s financial strength (to ensure long-term
financial strength for long- viability), ability to continually upgrade products and track record in post-
term viability and technical
enhancement 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 definite plus in their favour.

Understanding the need for the
right architecture
Critical Requirements from System Architecture
Critical Requirements From System Architecture
Flexible, Modular, Customer- Straight Service

Scalable, Integration centric, Through Oriented
Stable Single View Processing Architecture
of Customer
• Ability to meet the long-term growth and ambitions of the bank
• Component-based structure that can be modified and developed with ease
• Integrated customer information to facilitate better customer relationship across functions
• System functionality to support global deployment
• Banks have to select the right architecture for the banking system in
general and the core banking system specifically to suit their unique

The functionality and requirements. Most banks today are shifting their systems to attain more
architecture of the system
along with its suitability to meet flexibility and scalability, similar to moving out of the confines of a small
business goals would be the box. What they need to ensure is that the new system is not like a bigger
key concerns box which quickly becomes a constraint again in a few years’ time.
• Flexibility – With a convergence of financial services and a highly

competitive environment, banks need to display a high degree of
flexibility, agility and efficiency in its processes and product and
service development. Whatever the platform and solution that a bank
selects, it has to be flexible to meet the constantly changing banking
requirements.
• Scalability – Scalability is a particularly important factor for retail

commercial banking. A bank can expect healthy growth rates in this
segment of the market and must plan for an increase in transaction
volume. Another factor to consider is the bank’s strategy in terms of
product offerings and delivery channels.
• Functional requirements – It is essential to have a comprehensive MIS

(management information system) to cover all products, all customer
groupings and all geographical locations. In addition are customised
requirements such as multi-channel, multi-time-zone and multilingual
processing ability to meet the specific 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.
Imperative for banks to have • Modularity – We believe that the system architecture has to be modular.
modular architecture with STP
and single view of customer 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 efficiency, 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-office
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.
Integration of core banking • The architecture of the banking system should integrate the core
system within the banking
system architecture equally banking system such that there is customer centricity with a single view
important of customers across functions. In a customer-centric environment, the

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.
SOA critical for future flexibility • 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 flexible and easily
upgradeable infrastructure.
• Those components should be flexible so they can be reused or combined

to create new business functions both within and across enterprises.
They should embody best practices and should enhance the bank’s
ability to outsource and extend processes to business partners. The
generic nature of the components means they are intended to traverse
silos and departments, thereby facilitating the breakdown of barriers
which only exist for historical, technical and antiquated organisational
reasons. We discuss SOA in more detail in section 5.
Selecting the Architecture
• Most mainframe-based core banking solutions are designed for raw
horse power. The idea here is to support high transaction volumes.
Core banking solutions built on other platforms are typically focused
on functions and features and do not offer the same level of stability,
availability and end-user response time. While these types of solutions
usually cater to small- and medium-sized banks, they have recently been
touted to larger banks with some success.
• Other mid-range solutions were initially built for the wholesale market
and then repackaged as “Integrated Universal Banking Solutions” for
the broader banking market. Some of those integrated solutions are
impressive in terms of functions and features, extending beyond deposits
and loans to include treasury and trade finance products and providing
a common customer information system across the package. However,
these solutions need to be carefully assessed with regard to their support
for the bank’s branch network, which differentiates a universal bank from
the traditional wholesale banking operations for which these systems
were initially designed.

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-specific core banking systems. To the business user, this may
seem counterintuitive; after all, it is the core banking system we want to
select. However, as explained earlier, the functions and features of the
core banking system are not the sole determinants of the appropriate
solution. First, the solution must be able to handle the bank’s requirements
for volume, availability, reliability, scalability, security, response time
and other non-functional qualities. For these, the choice of platform is
paramount.
• There are many aspects which should be considered in platform selection

for mission critical systems:
- Virtualisation of the resources of computer operations – Resources in

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

parallel sysplex, the mainframe is able to achieve availability of up
to 99.999%. Alternative platforms should be measured against this
benchmark. This will facilitate clear decision-making and buy-in of all
stakeholders when faced with lower availability guarantees.
- Security – Security has always been a concern for banking systems.

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

- Platform cost – Typically, platform cost is calculated as either total cost

of ownership or total cost per user. However, measuring total cost is not
straightforward and often results in an underestimation of UNIX costs
due to lower overall availability and the greater number of unplanned
outages. We have, for example, found that the average expected
revenue loss per hour of system downtime could amount to well over
$1 million. Considering that unplanned outages can occur as often as
once or twice a month, the costs can climb quickly.
Cost should not be driving • In summary, we believe that the total cost should not be the driving
factor; identify what is most
suitable based on needs 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.
For smaller banks, UNIX could • On the other hand, for small wholesale banks and banks that do not
prove to be effective but banks
need to consider switching cost 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.

Core Banking Selection Process
Business
“Delta Driven”
Implementation
Blueprint
Project Stages
Select System Conduct

Issue RFI /
Issue RFP & Service Negotiation &
Refine Vision
Provider Contracting
Sign Off
Source: Immacon SOBIT Methdology
• Selection of the right core banking solution is critical for the success of a
project. We have seen retail banks selecting a wholesale core banking
solution and wholesale banks selecting a core banking solution meant
for retail banks. We are also seeing more and more bankers attempting
to make technology decisions, deliberating about Java versus Cobol,
UNIX versus mainframe, SOA, etc. Needless to say, the outcome of
such decisions is often sub-optimal.
• It is important that bankers focus on business solutions and not on a

technology solution. However we believe that business should have the
final 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 first 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 / refine 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 final shortlist to kick
off the Request for Proposal (RFP) process. If the RFI contains too much
detail, it can render the RFP process obsolete and make the preliminary
analysis in the RFI stage very laborious. As the bank has to analyse
and weigh the RFI responses, it is important to keep the workload of the
reviewer to a manageable level.
• A brief, well-written RFI (and RFP) addressing the critical points the
bank is interested in would be more worthwhile for the bank’s reviewers
and management, than a long “laundry list” of functions and features
which describes more or less the existing system of the bank and not

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

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

an agreement on final 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 refine its assumptions about the future-state vision based on
findings 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 final 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
Seamless and smooth

transition to new technology • Core system replacement or even upgrading is a major challenge that
and processes with zero error is can create disruption of service, customer dissatisfaction and employee
the key challenge
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.

• The foremost challenge is data migration and seamless transition to the

new system. This includes the difficult 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 significant 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 difficult 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.
Testing at all levels is the most • The most critical success factor in implementation is thus to test at
critical means of risk reduction
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

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 finish the implementation only by April 2007, four years after its
commencement in 2003.
• In many such projects, trained manpower for new systems may not be
readily available within the bank. It is for this reason that some banks
have resorted to outsourcing their manpower. But the banks need to
remember that a few experts with the right experience and knowledge
may prove to be more useful than an army of staff.
• Finally the bank’s business environment, adaptability to change

and commitment to the project are vital for success not just during
implementation but also during and after deployment. Vendors should
ensure that management is involved in the project from conception till
final 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
Business
“Delta Driven”
Implementation
Blueprint
Project Stages
Detailed Pilot
Delta Analysis Build & Test
Design Implementation
Sign Off
Transformation Approach and Methdology
Phase 1: Phase 2: Phase 3: Phase 4:

Delta Definition Design Build & Test Pilot
Identify Organisational Change - Business Realignment Design - Business Realignment - Align the Training Preparation - Prepare
Determine the changes needed to fit Define the reengineered products bank’s products and services to the training plan, materials and course
the organisation to the new System. and services and business new System. Also align the bank’s trainers.
processes aligned to the new processes and procedures to the
Identify Essential Modifications to System. new System. Pilot Preparation - Identify and
the new System - Every effort should prepare the pilot site, train the pilot
be made to avoid changes to the new System Design - Prepare the Configure & Customise - users and conduct rehearsals to
System but rather to align the design for system configuration. Configure the system as needed, prepare for the actual cutover.
business to the new system. Changes Also design the unavoidable effect the necessary changes to the
to the new Core Banking System modifications identified during the organisation, and make changes to Pilot Go/No Go - Confirm the
should be limited to those essential in Delta Analysis. the system, where absolutely completion of Pilot Preparation
order to meet regulatory necessary. In addition, the interfaces activities and readiness for cutover
requirements. Integration Design - Prepare the between the new System and the of the new System to the Pilot
technical design for the Interfaces, many linked systems are created. community.
Identify Integration Delta - Data Conversion Modules and
Determine the interfaces, conversion Coexistence Modules. Testing - Perform various levels and Pilot & Fine-tune - Cutover the Pilot
modules and coexistence types of testing to the new system site and users to the new System.
development required to integrate the and processes etc. in preparation Identify and fix problems that did not
new System into the bank’s for correct functioning in the live arise in the testing environments.
environment. environment.
Applications Ready For

Delta Analysis Report Design Specifications Applications Ready For Pilot
Deployment
Programme Management & Project Control
• The core banking implementation phase can be divided into four distinct
stages. We came across an interesting concept of delta analysis.
Implementation process • Delta Analysis – A delta analysis is the identification of differences (the
involves delta analysis,
detailed designs and product
“delta”) between the desired state and the selected package, and ways
modification to meet the bank’s to resolve these differences. One objective of the delta analysis is to
requirements identify the package modifications required to address country-specific
regulatory requirements. The package modifications are necessary if
configuration through package-embedded parameters is not possible.
For the remaining delta, there are a number of resolution options
available, such as:

a. No change / Out-of-the-box fits your needs
b. Rationalise process
c. Rationalise product
d. Customise and modify package
The chart below illustrates this approach in more detail:

Requirements Analysis Chart
Delta Analysis & Resolution

Option I: Option II: Option III:
Start : Identify Regulatory
Identify Delta Delta Resolution No change / Rationalise Modify package
Process / Appraisal Requirements Out of the box fits Process / Product
New World
Accept Package
Operations
New Core Banking Regulatory New Core Bank Delta Change Bank
Resolution Product / Process
Solution Procured Modification Capabilities to Match Package
Modify Package
Delta
Input on Package
Regulatory
Modifications Delta
Customisation
Regulatory Regulatory Regulatory Regulatory Regulatory
Customisation Customisation Customisation Customisation Customisation
Core Package Core Package Core Package Core Package Core Package Core Package
No (should be included Yes (Time & Material

Cost Impact in base price) No No
Cost for Modification)
© 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

refinements to suit the future state
- Define and estimate interface, data conversion and coexistence

efforts
Typical deliverables of this task include: Delta Definition and Resolutions,

Configuration Definition, Interface Definition, Data Conversion Definition
and Coexistence Definition

A detailed design done right • Detailed Design – A detailed design of the future solution is needed for
can save the bank substantial
time 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 difficulties 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 configuration

of the selected solution.
- Prepare a detailed integration design for the interfaces, data conversion

and coexistence components.
• Build & Test – The customisation and configuration 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 configure the selected solution
- Prepare operational manuals, training materials and train-the-trainer

programmes

- Customise and configure the interface, data conversion and coexistence

integration components
- Prepare and conduct system, operations and business solution

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

Reference Implementation Methodology
A comprehensive implementation method may be the one that follows:

Comprehensive Implementation Chart
Phase 1: Phase 2: Phase 3: Phase 4: Pilot

Delta Definition Design Build & Test Implementation
Delta Analysis Business Change Business Design Business Build Training Pilot
Preparation
Product Update Procedure
Product Designs Manual Pilot
Rationalisation
Prepare Planning
Process Training Plan
Process Designs Prepare User
Rationalisation Guides
Conduct Train Pilot Users
Gap Resolution Prepare & IT Ops
Analysis System Change Training
System Design System Build Materials
System Pilot Site
Customisation Local Customisation Local Preparation
Designs Customisation Train-the-
System Trainers
Configuration
Core Customisation Core Dress Rehearsal
Designs Customisation
Configuration Analysis Testing
Pilot
Configuration Definition Configuration Designs
System 3 Go/No Go
Configuration System
Integration
Testing
Convert
Integration Integration Design Integration Build Pilot Data
Operations
Interfaces Interfaces Designs Interfaces Testing Pilot End-user
Support
Data Conversion Data Conversion Designs Data Conversion

Business
Application
Solution
Testing Support & Fixes
Coexistence Coexistence Designs Coexistence
1 Sign Off Delta 2 Sign Off Design


4.6 Phase 4 – Deployment

Enterprise-wide rollout of
the system poses critical Objective: Enterprise-wide rollout of the refined future state operation.
challenges, demanding careful
planning and caution at each Core Banking Deployment
stage
Business
“Delta Driven”
Implementation
Blueprint
Project Stages
Change
Logistics Training Mgmt & Go Live Fine Tune
Comm
Sign Off
• 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
finalised:
• Logistics – Managing logistics is critical for the rollout of a new core

banking solution to the branch network. The logistics include rollout
sequence (where, when, how many), possible changes to branch
layout and bank image, and update and/or replacement of hardware
and infrastructure software. It also includes the planning and execution
of training logistics for the enterprise-wide deployment. The bank may
need the hardware to rapidly build and dismantle mobile training branch
environments for hands-on systems training.
• Training – We have discovered that once the new core banking system is
ready for rollout, training is one of the most important activities required
to successfully deploy the new world on an enterprise-wide scale. To
do this, the bank’s project team must fine-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

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 profile 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 significantly 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 identifies 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
predefined 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 final activity in the deployment stage is the fine-tuning
of the operation based on feedback received during deployment.
Successful organisations have gradually turned this fine-tuning activity
into a continuous improvement programme managed and led by former
members of the rollout team.


Comprehensive Implementation Chart
Complete End to End

Integrated solution suitable more for small Suitable more for smaller banks
and medium banks
Risks and complexity higher
Easier to integrate solution from single
supplier Implementation more challenging
Phasing of implementation process Sudden change in processes and culture

reduces risks within organisation
Gradual Implementation Big Bang Approach

Preferred approach by large banks due to This approach can be used for smaller as
complexity and scale well as bigger banks
Lower risk, phased shift in processes Partial replacement less complex as it is

for specific functions / locations
Challenging to have two systems coexist
during implementation Big bang approach can be challenging,
particularly for big banks, but is quicker
Difficult to integrate multiple systems
Partial Replacement
The replacement approach • 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 believe focused, rather than • We strongly believe that for core banking systems, there should be only
integrated, projects are more
suitable for bigger banks one vendor or else there would be immense integration issues. For
the front end and back office, 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.

• 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.
The deployment approaches • While deciding on the replacement approach is easy, deployment
“Big bang” is the quickest but
is probably the most difficult and challenging part of a core banking
also the riskiest project and can be accomplished through multiple approaches. The two
extremes are “big bang approach” where the entire system goes live
at the specified 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 justification for big bang comes from the fact that it is difficult 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 difficult
to implement. Examples of recent big bang deals include Union Bank of
Philippines and Industrial Bank of Korea.
Gradual implementation should • We believe the gradual approach, which is essentially step-by-step
be the preferred mode among
bigger banks
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

monitored. The advantage of this approach is that the entire solution is

deployed at once and can be tested and fine-tuned in a tightly controlled
environment. Should there be any problem, it can be confined to the
cluster. We also recommend that the first 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 specific 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 replacement Inherent Risks in Each Stage of the Project
project
Project Stages
Evaluation risk Selection of Long term

& management vendor, service Solution risk Implementation
technical
commitment providers risk
support risk
• Assessing the technical • Financial viability to • Evaluation of • Ensuring smooth, • Commitment of vendor
and functional provide long term technical capabilities timely and cost effective to provide long term
requirements of the bank relationship and of solution to meet the implementation of new support
technical support business goals system
• Ensuring adequate • Technical advancements
financial, business and • Experience in • Flexibility and • Ensuring adaptation in and their compatibility
management support for successfully adaptability to new the work culture and with the new system
the change implementing similar developments post-implementation
project smooth operations
Banks need to tread carefully • Risks and potential losses in replacing a core banking system are very
as there are hurdles at each
step of the change process high, making it imperative that banks tread with caution at each step.
We have identified five broad stages in the replacement process and
inherent risk characteristics of each.
Project needs business support • Lack of management commitment is one of the primary causes for
in totality
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.
Evaluation at each stage has to • The evaluation of business needs and objectives must be comprehensive,
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.
Improper selection of vendor • Availability of multiple solutions with varying technology and comparable
and system can lead to project
failure functionalities has made this task more difficult. We believe that while an
improper selection of solution could lead to short-term benefits, 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

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 financial viability and track record of
these vendors, but also ensure adequate fit 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.
Banks cannot afford any margin • Transition from an old system to a new technology is a risky proposition
of error in the implementation
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.

4.8 Financial Implications

Investments and Costs Implications
Cost Analysis
Recurring Cost Loss of

Business
Customers
Unexpected
Cost
System
Integration
One Time Cost
Hardware
Core Banking
Planned Unplanned
Planned Costs Unplanned Costs

Core Banking software acquisition and Unexpected delays
maintenance cost
Incremental changes during implementa-
Hardware acquisition and maintenance tion
cost
Scope of project becoming too big
System integration and consulting cost
Resistance to change
Replacing core banking • Ownership of the core banking system is very costly and requires
system has high risks and
huge costs and thus requires
strong commitment and business justification in most cases. It is for this
strong business and financial reason that most banks take considerable time in coming to a decision
justification 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 Pacific 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.

• Recent big deals have shown significant 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 efficacy 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 justification 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
find 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 definite motivations. We discuss these further
in the following section.
Financial justification through Financial Justification of New System
cost savings and revenue
growth Project Stages
Expected deliverables of the new system
Lower
Lower Innovative New
Integrated, operational, Customer
opportunity products, initiatives,
flexible system maintenance centric, STP
costs bundling services
cost
Increased Improved Shorter break Improved Improved Improved

efficiency, margins and even period, competitiveness market revenue
competitiveness return on lower and growth. presence, generation,
and time saving investment manpower cost Customer capture of new business
and higher ROI. relationship market, growth
improved increased fee,
Legend
revenue Direct benefits
Indirect benefits
Direct and indirect financial impact for the bank
While investment is substantial, • While there is clear business justification in the form of intangible
benefits from cost savings, ROI
and business growth could be benefits such as market growth, retaining of competitiveness and long-
more term success, many bankers mull over cost effectiveness and return on
investment (ROI) in order to find financial justification 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-office
integration improve efficiency 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%.

• 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.
Intangible boost to growth • The most critical impact on a bank’s financials is in its revenue growth.
highly possible if bank has the
right system A flexible 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 benefited through a distinct improvement in efficiencies 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 benefits often provide
substantial financial justification for the banks to take the plunge.

Core Banking
Replacement Building
5 Blocks
We have identified 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
C o r e B a n k i n g Re p l a c e m e n t B u i l d i n g B l o c k s
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:
Critical building blocks of core Core Banking Building Blocks
banking transformation
Building Blocks
Service Oriented
Core Banking
Architecture
Process Interfaces
Rationalisation
Deployment
Strategy
Product Coexistence
Rationalisation
Data
Conversion
Project
Organisation & Change
Programme Management
Management
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 bank’s overall systems architecture? What
changes are required? What impact will it have?
• Interface considerations – How many interfaces will we need to build?
Who is going to build it? How can we minimise the risk of slippage in the
interfaces?

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

Identify the deployment • A critical decision for any core banking replacement is the choice
approach most suitable for the
bank’s needs 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:

Big bang is quick but has no • Big Bang is a deployment strategy which assumes that all systems will
margin for error
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 has • Phased Approach is the deployment of the new core banking solution by
manageable risk
branch or regional cluster. It is recommended that the phased deployment
is conducted as a “big bang” for each deployment cluster. This means
that, as in the big bang approach, the entire solution is deployed in one
go – but only for a manageable cluster and not for the entire enterprise.
The advantage of this approach is that banks receive the benefits of
the big bang for all deployment clusters while keeping risks within a
manageable level. For instance, if deployment problems occur, they can
be confined to the cluster and will not affect the entire enterprise. 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 benefits of this approach, especially risk mitigation, more than
compensates for its higher cost and longer deployment period.

5.2 Service Oriented Architecture

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

of reusable business components embedded in computer code. This
definition highlights some of the essential elements of this architecture.
• Herein the services are “loosely coupled”, i.e. not tightly integrated as that
would limit its flexibility. Specifically, each “service” has a corresponding
“contract” which defines what the service does and how it can be used.
We understand that there should ideally be no restriction on how a service
operates internally in order to deliver on its contracted capabilities. This
can enable each service to be altered internally without necessitating
changes to the client applications (which can include other services) so
long as the changes do not alter the contracted definition of the service
and how to use it. If this is achieved, the advantage is clear – one can
modify the internal operations or even replace a given service without
having to modify every programme that uses the same service so long
as the contract is not changed.
• Those who advocate SOA believe that it is not about the internal 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 fit into an SOA environment by exposing its services
through well-defined interface contracts (e.g. for withdrawals, transfers,
clearing, and the like). This would enable the bank to loosely couple their
existing applications with the new core banking system and avoid the
disadvantages of tight coupling.
• According to the definition of Dirk Krafzig, Karl Banke and Dirk Slama
in their book Enterprise SOA (Prentice Hall ISBN 0-13-146575-9), an

Enterprise Service Oriented Architecture can be defined as follows:

Definition of 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

Service In addition there is a
model are the major
Oriented service repository and a
attractions of SOA Architecture service bus
(SOA)
1
The application front-end 1 2 3 4
is the owner of the Application Business Service Service
business processes Front-end Service Repository Bus
2
Services provide business
functionality that the a b c
application front-end and
Contract Implementation Interface
other services can use
3
The service repository
stores the service
Business Logic b1 Data b2
contracts of the individual
services of an SOA
A service consists of...
4
The service bus intercon- a) a service contract that specifies the functionality, usage, and constraints for a client of the service
nects the application b) an implementation that provides business logic and data
front-end and the c) a service interface that physically exposes the functionality
services
A client can be either an application front-end or another service
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 definition)

Illustrative Core Banking Architecture
Multi-Channel Core Banking System Bank System
Customer Information General

Branch Ledger
Credit
Reporting / Statement Interface

Call Centre Cards
Channel Integration
Deposits Loans
etc.
ATM
External
Interfaces
Internet
Clearing
Collateral Information House
etc.
Common Services
BahtNet

etc.

5.3 Interface Considerations

SOA and ESB together can
• Our research shows that interfaces are a key concern for any core
reduce the complexity of banking replacement project. Every major application in the bank is
interfaces 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
Branch Cash Core Banking

Application Call Centre Management System Cheque CIS
Online Online Online Batch Batch Online/

Batch
Authorised
Signature Credit Card
Online Online
Audit and Custodian

Control Batch Batch
Old
Data
Agent Service Core Banking Warehouse
Online Batch
System
Financial Donation
Planning
Batch Batch
Human
Resources EAI
Batch Online
Online/
Batch Online Online Batch Batch Online
Loan Payment SWIFT Trade Finance BOND E-Channel
• Transition from the old core banking system to the new core banking
system can be conducted in three steps:

Transtition Phase
Step 2:
Phased migration to Step 3:
Step 1: All accounts
new Core Banking
Implement switching converted to new
System and
layer Core Banking System
coexisting with
Legacy
• The end result is a smooth transition from old to new core banking
system, as illustrated below:
New Core Banking System
Branch Cash Core Banking

Application Call Centre Management System Cheque CIS
Online Online Online Batch Batch Online/

Batch
Authorised
Signature Credit Card
Online Online
Audit and
Control Custodian
Batch Batch
New
Data
Agent Service Core Banking Warehouse
Online Batch
System
Financial
Planning Donation
Batch Batch
Human
W EAI
M
S
Resources
ITC S
NI
Batch Online
H ING ME C HA
Online/
Batch Online Online Batch Batch Online
Loan Payment SWIFT Trade Finance BOND E-Channel

5.4 Coexistence
Coexistence poses
• Our research indicates that as the bank replaces the system using
considerable challenges phased implementation, it often faces the critical issue of coexistence.
demanding complex and Coexistence is the strategy and process taken to operate two core
strategic planning
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 Coexistence Infrastructure New World / Next

Core Banking System Core Banking System
Call Other
Centre Online
ATM Systems Interfaces
Old New
Core Banking Core Banking
System Coexistence System
Switches /
Merge
Clearing
House
Other
Unconverted Branches Batch Converted Branches
Interfaces
• 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 Implications
What is Coexistence Branches Call Centres
how does the bank operate how will inter-branch how will the call centre
while accounts are transactions be handled service requests during
progressively converted to the during coexistence? coexistence?
new core banking system?
Other Online Batch Interfaces

ATM Transactions
Interfaces (Inward Clearing)
how will ATM transactions how will other online how will incoming batch
be processed during interfaces be processed interfaces be processed
coexistence? during coexistence? during coexistence?
Batch Interfaces
Other Implications
(Outward Clearing)
how will outgoing batch how will sweeping and

interfaces be processed other features be
during coexistence? processed during
coexistence?

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

new branch and wants to old branch and wants to
transact at an old branch transact at a new branch
Old Branch New Branch
Coexistence Options
Option 1 Option 2 Option 3
Feature 2-way Support 1-way Support No Support
Old branches can access new accounts Yes No No
New branches can access old accounts Yes Yes No
ATMs can access all accounts Yes Yes Yes
Development effort / risk High Low None
• At first glance, the two-way option may look like the best choice. However
we understand that it comes with a high cost for building the coexistence
interfaces. After analysing transaction volumes, banks may find it
worthwhile to consider option 3, “No Support”, as a feasible alternative.
In our review, we learnt that business usually understands and supports
this approach for standard branch services (e.g. deposits, withdrawals
and transfers). The business rationale is that the potential inconvenience
is only for a limited time and can be managed through good customer
communication, especially where there is low to moderate transaction
volume. Our research indicates that if the bank is replacing its front-end
system and core banking system at the same time, option 3 is preferable
because it reduces the need for temporary integration between the old
front end and the new core banking system and between the new front
end and the old core banking system.

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
New
Core Banking
System
Call Centre
System
Online Transaction
Switch
Old
Core Banking
System


• 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
New
Core Banking
System
ATM Tandem ATM Switch
Old
Core Banking
System


• These are treated with the same strategy, i.e. the use of online
switches.
Online Transactions During Coexistence
New
Core Banking
System
Online Transaction
Switch
External
System
Old
Core Banking
System


• 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
New
Core Banking
h
Batc
System
Batch
Splitter
Switch
External
System
During rollout, the

files need to be split
to send the data to
the appropriate Old
system… Core Banking
System


• 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
h
New Batc
Core Banking
System
Batch
Combiner
External
System
During rollout, the

new system will also
Old generate this data
Core Banking for converted
System accounts …
A ‘Combiner’ will
therefore be needed


• 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
Standing Orders Others
Sweeping
Amend the systems to Amend the systems to Each situation will have to
pass the transactions out pass the transactions out be judged on
Create an external system Create an external system Criticality
for inter-branch sweeps for inter-branch standing orders Volume
Complexity
Manual processes Manual processes A decision is then made on
the best solution available

5.5 Data Cleansing and Data

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

during the conversion exercise, and not by the data conversion team.
This is important as cleansing of customer data cannot be resolved with
technology alone, but requires the hands-on involvement of the bank’s
customer-facing personnel. Note, however, that other types of data
transformation are required during the core banking data conversion
to accommodate differences in data format between the old and new
systems or to auto-set default values for new fields in the new system.
But these should not be confused with data cleansing, which changes
the meaning of existing data rather than its format or structure.
Data conversion can be • Data conversion, on the other hand, is an important part of the core
executed in three stages
banking replacement project. It can be executed in three stages, as
illustrated in the chart below:

Data Cleansing and Data Conversion
Old Data Conversion New

System System
... what it takes :
Step 1: Data Mapping
Data Data
Step 2: Data Conversion
Customers Extracts Customers
Accounts Accounts
Standing Instructions Standing Instructions
Transaction History Step 3: Data Conversion Transaction History
Etc… Loads Etc…
Data Cleansing
• 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

“Old World” “New World”
Core Banking System Core Banking System Data Mapping Considerations
Product Is there a corresponding product for each of
Current Account Current Account our existing products?
Can we rationalise our products to fit the

supported products in the new CBS?
Attributes Does the new system’s account number
Account No. Account No. structure match our existing structure?
Current
Acc Account
Branch Code Should our account number structure
continue to have meaning?
Acc Product Code
When will we run out of account numbers?
Acc Sequence No. What should be the length of the account
Acc Check Digit
number? What are the implications for the
new system, cheques, passbooks, ATM
transaction records, etc. ?
Domicile Branch Code Domicile Branch Code
Is there a one-to-one mapping of fields for
this product (i.e. Current Accounts)?
Account Open Date Account Open Date
Is there a one-to-one mapping of field values
(e.g. are our interest rate methods supported
Interest Rate Method Interest Rate Method by corresponding methods in the new CBS)?
How do we handle custom fields (e.g.

Limit Limit Special Field1)? Should we
customise the new CBS or rationalise the
requirement?
Special Field1
Is the source data “clean” and acceptable?

• 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
Step 2 : Data
Conversion Extracts
Conversion Staging Area
Old
Core Banking
Extract Modules
System Conversion
Data
Extracted data ready for loading
DATA Conversion data file layout as

required by new core banking
system
Customers
Accounts Conversion
Standing Instructions Reports
Transaction History Data
Etc…
• Data conversion loads – This is the final stage where customer and
account information is loaded into the new core banking system and
reconciliation reports are automatically generated.

Data Conversion Loads
"Old" World "New" World

Step 3 : Data
Conversion Loads
Conversion Staging Area
Old New
Load Modules
Extract Modules
System Conversion System
Data
Extracted data ready for loading
DATA Conversion data file layout as DATA

required by new core banking
system Customers
Customers Accounts
Accounts Conversion Standing Instructions
Standing Instructions Reports Transaction History
Transaction History Data Etc…
Etc…
Report Generator
Conversion
reconciliation
Reports
and verification.

5.6 Product Rationalisation

Data conversion can be • We have discovered that product rationalisation is also an important
executed in three stages
element of successful replacement projects. Product rationalisation is
essentially the process of assessing the value of the bank’s current
product and service offerings, i.e. whether a product or service is still
competitive and profitable or should be deemed “sunset”. This is the
time to ask not only where the bank is with its current offerings but also
where it wants to be in the future. Banks often also check if an existing
product or service can be migrated to the new platform in a cost 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 define the future market offerings in terms of:
a. products/services to be discontinued,
b. products/services to be redesigned and renewed, and
c. new products/services to be introduced with the launch of the new

core banking system.
• Hence, product rationalisation has a number of benefits for the core

banking replacement programme. It enables the bank to take full
advantage of the capabilities of the new core banking solution. It
simplifies the sales process through consolidation of “like offerings” into
core banking “configurable” products.
• It also provides an opportunity to discontinue products/services that

are not, or not adequately, contributing to the bottom line. In addition,
it mitigates the risk of project delay and failure as the bank avoids
unnecessary customisation to support redundant old-world products.

5.7 Process Rationalisation

Process rationalisation can • Core banking replacements will impact most of the front- and back-end
overhaul outdated processes
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.

Critical Success Factors
and Best Practices
6
Organisation of the project and management of the change are
critical issues for projects of such a scale. We have identified 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)
C r i t i c a l S u c c e s s Fa c t o r s a n d B e s t P ra c t i c e s
6.1 Project Organization and

Programme Management
Programme organisation should • We believe that a project of the magnitude and scale of a core banking
delineate the responsibilities
and accountabilities of project replacement requires strong project organisation and programme
decisions management. In addition, the project organisation should be adjusted
depending on the phase of the project.
Business Transformation Team Structure
Project Organisation
Steering Committee
Programme Director
QA PMO Support Team
Core Banking Enabled Core Banking Enabled

Business Transformation
Business Organisation Benefit Team Process
Process & Change Realisation Coordination & Decision
Transformation Technology
Others
Common Activities Deployment
Teller
Core Banking New World
Architecture & Data Cluster
Testing Pilot
Integration Migration
Functional Technical
Source: Immacon SOBIT Research
• Our research has led us to a few best practices in programme organisation

which we discuss below. The overall responsibility for the project should
lie with the project steering committee. This committee should be chaired
by the CEO and it is important that he demonstrates commitment to the
project. Other members of the steering committee should include the
bank’s full-time programme director, heads of all the business units, the
CIO, and key risk-management and finance personnel.
• We believe that the bank’s full-time programme director should have
complete authority over the project. The programme director should be
empowered to make decisions after consultation with business and IT.
He needs the authority to make the final 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.

• The programme director should be supported in his day-to-day activities

by the project managers for the business and technology transformation.
The first stage of the project deals primarily with issues of business
and technology transformation: delta analysis, interface analysis and
design, conversion and coexistence. An important aspect of this phase
is the delta resolution for product/process realignment. These activities
will require substantial full-time involvement and empowerment of the
business specialist and the IT specialist, both of whom must have a
good understanding of the bank’s legacy systems.
• The project organisation will change depending on the stage of the
project. The charts below illustrate the different stages of the project
and the corresponding organisation required to execute the project
effectively. Banks should ensure that the core programme leadership
team is always full-time and leads the project for the entire duration of
the exercise. We believe that the programme organisation can be divided
into three broad stages.
• 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 first stage of the project is focused on diagnosing the current
business and IT environment in the bank and defining how the bank
should operate in future. Based on the current environment and the
target environment, the bank defines 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
Stage 1
Core Banking
System Project Delta Analysis & Design
Manager
Technical Support Project Office
Stage 1 Significant Third

Party Resource
Core Banking Involvement
System Business
Team
Conversion &
Interface Analysis and Coexistence Design
Delta Analysis Team
Design Team Team
Product Realignment
Process Realignment


• 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
Stage 2
Core Banking
System Project Build & Test
Manager

Party Resource
Involvement
System Training &
Implementation Interfaces Team Testing Team Procedures
Team Team
Customer Train-the-
Online Business
Application Trainers
Interfaces Testing Team
Team Training Team
Deposits User
Batch Integration
Application Procedures
Interfaces Testing Team
Team Team
Loans Coexistence
Operations
Application Development
Testing Team
Team Team
Online
Application
Team
Accounting & Legacy Systems Conversions Pilot Site
Other Apps Teams Data Extracts Selection Prep.
Team Teams
Data 3rd Party Go /No Go
Conversion Interface Assessment (ext.
Load Team Systems Teams Accountants)


• The third stage of the project sees a move from the technical build-
and-test stage to the pilot implementation stage. The focus here is the
deployment of a live pilot, to test and fine-tune the new core banking
solution and its processes and procedures.
Stage 3 Project Organisation, Pilot
Stage 3
Core Banking
System Project Pilot
Manager

Party Resource
Involvement
Pilot Team
Data Conversion & Core Banking System Core Banking System

Pilot User Support Interfaces Support
Coexistence Support Applications Fix
Team Team
Team Teams
Pilot User Training 3rd Party Interface

Team System Fix Team
Conversion Data
Legacy System Fix
Extracts Support
Team
Teams

6.2 Critical Success Factors and

Best Practices in System
Selection
Key Success Factors in Selection
Selection Process
Goals Managerial and Existing Required
financial system, size of system
commitment bank, business architecture
goals and platform
Establish Establish
Set Business Take Strategic System
Functional Technical
Direction Decision Selection
Requirement Requirement
Business decision Long term Flexibility, Software

to change impact on the adaptability, platform, type of
organisation, compatibility solution and
growth, and financial hardware
processes and impact
culture
Selection of a system requires • The impact of core banking system transformation would be visible over
managerial and business
support from all sections and a the long term in the performance of the organisation. A bank replaces its
clear focus on business goals 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.
Ensure involvement of business • The rapid pace of change in the banking business makes it extremely
representatives and develop a
matrix for evaluation difficult to picture the banking landscape in the years to come. For this
reason, the right selection would be one with a forward-looking flexible
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

commitment to successful implementation. The selection process should

involve key representatives from functional divisions as they would be the
ultimate users. But users see only the front end, while IT people may be
more aware of the technical requirements in terms of processing power.
Thus it is necessary to involve both the teams and ensure coordination
while avoiding/resolving conflicts.
• A detailed matrix of selection criteria should be developed. Each solution

and vendor needs to be evaluated on this matrix, and the system that can
provide the highest value to the organisation should be selected. Having
a consultant (who has experience with similar projects and awareness
of unique local requirements) to guide the bank would further strengthen
the selection process.
Functional capabilities and • We recommend that banks leave the old world behind and move to the new
architecture should facilitate
growth plans system in entirety. While this poses significant transformation challenges,
it would ensure optimum returns as there would be no “legacy baggage”.
But the bank must ensure that the system functionality, platform and
technology are right for its needs and it would not be wise to just choose
the “best” in the market. The architectural components of the system
and its raw processing ability are critical. The technology should easily
integrate with existing systems within the bank, facilitate differentiation,
assist in quick decision-making, improve competitiveness through faster
product development and, at the same time, improve returns through
lower operational and maintenance costs.
• Further, the architecture of the selected system should facilitate

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

and get wrapped up in architectural discussions and process redesign
issues that are too broad or diffused to add value to the business. They
should aim for quick decision-making and system selection in order to
prevent opportunity costs from rising further.

6.3 Critical Success Factors and

Best Practices in Vendor
Selection
Success Factors in Vendor Selection
Project Stages
Evaluating service providers
Evaluate
Identify Evaluate Evaluate Evaluate post-
commitment
vendors with financial experience implementation
to business &
track record strength and with similar support and
technical
and reputation viability projects services
enhancement
Track record and Ability to tide Ability to meet Financial ability Reputation and
technical ability of over the unique local and long term
the product to downtrends and requirements commitment commitment to
meet the sustain and yet provide towards long provide ongoing
functional technical the requisite term technical support and
requirement advancements quality advancement future
standards and services integrations
Suitability of IT partner for • System selection and vendor selection go hand in hand. Vendors and
unique requirements of the
project and its commitment to service providers can no longer be viewed as just IT suppliers. Instead,
provide long-term technical they are partners in the long-term success of a bank. The selection, in
support are crucial many cases, is based primarily on cost savings, which ironically may
prove to be a costly mistake in future. The basis of decisions should be
the vendor’s capabilities and not pricing.
Select the right mix of product • It is imperative that banks ensure the vendor provides the right mix of
and services
product and services required to meet the objectives and ambitions of
the business and the unique requirements of the project. The relationship
between system provider and system integrator should also be evaluated
and their track record in managing projects as a team needs to be
analysed.
• Equally important is that the bank has to evaluate its own comfort level
with regard to the vendor’s reliability and suitability for the particular
project. If the bank has an existing system from the vendor, there could
be a distinct benefit 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.

Select vendors that involve • We have seen projects of even leading international vendors fail despite
local people in customisation
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.

6.4 Best Practices for Vendors (for

Successful Implementation)
Key Success Factors for Implementation
Project Stages
Successful Implementation
Understand Thorough Ensure

unique Involve local User training Provide long
testing at seamless
requirements, people to meet to adopt new term
each stage. integration and
expectation of unique local processes in partnership to
Develop pilot timely
the bank requirements work culture the bank
project implementation
Banks should Develop Excellent Develop pilot Timely data Post-

develop strong empathy with communication projects to cleaning, implementation
team to guide the business skills to ensure migration and support through
vendor environment motivate and expectation and integration with ongoing
meet resistance deliverables existing system services and
to change match. User with zero error future upgrades
acceptance
tests at all
levels
Understand the business needs • 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.
Ensure strong business • We believe the basic ingredient for success is the ability of the vendor
ownership for project within the
bank 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.
Develop empathy with working • Vendors should ensure that within the bank, there is strong business
environment
ownership, management involvement and a business environment
conducive for implementing the project. There must be a common ground
for decision making, where the banks and service providers can interact
to find solutions for inevitable hiccups. The aim is to meet the objectives
and achieve timely completion coupled with high quality, but balanced
Begin user training even before with the costs involved. It is important that the right mix of people within
deployment of system
the bank is involved in the process.

Redesign processes within the • Vendors need to ensure optimum utilisation of communication channels.
bank for optimum returns
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
Conduct testing and user vendors in a team, the accountabilities, responsibilities and decision-
acceptance tests at all levels
making process must be clear and a ”prime vendor” must be identified.
• Technical skills to integrate the existing systems and migrate data

from old to new system are indispensable, but equally important are
communication skills for user training and change management. User
training should begin much before implementation to ensure smooth
transition. The vendor should conduct seminars and training sessions
for users in phases, with the involvement of a strong internal team from
the bank.
• Internal processes within the bank need to be redesigned and aligned

with the capabilities of the new core banking system. Application- and
process-specific initiatives can bring about cost savings as well as
improve efficiencies 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.

Unique Core Banking
Replacement
7 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
Uniqu e C on s i d e ra t io n s
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
Replacing core banking system

• For most top-tier large banks, the key consideration for replacement
in large multinational bank is
highly complex 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

Unique Co ns id e ra tio ns
need to eliminate duplicated systems, integrate systems across multiple

functions, add functionality in the core system, and improve the database
and its connectivity.
• For a bank with branches across countries, millions of customer accounts

and large transaction volumes, core banking system replacement is a
massive project which requires a very strong business justification. Most
large banks take years to reach a decision on core banking replacement.
It is a multi-year project where clarity on system requirements is vital.
The banks need to determine whether a front-end replacement would
suffice 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
Banks need a scalable and
robust system to handle high systems to meet its complex needs (as in the case of HSBC).
volumes
• 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 reflect long-term strategic goals of

the bank. The banks essentially need systems that are integrated across
functions and locations to facilitate the implementation of competitive
strategies with a customer-centric view. This may demand customisation
on the front end and transition to a component-based banking system
architecture such as SOA.
• The functionality across multiple operations has to be complemented

with stability, reliability, scalability, robustness and flexibility to enable
the bank to introduce new products and services with ease and speed.
Compatibility and integration of multiple applications throughout the
organisation is essential for large retail banks.
• We believe that past experience with similar large projects and reliability
would be critical considerations in vendor selection. Long-term support
Vital requirement is seamless
connectivity across functions would be essential, whereas pricing is not likely to be a key issue.
and locations
• Many large banks have systems that were developed in-house. But often,
the people who developed these systems (or know the software codes)

are no longer with the organisation. This makes the tasks of deployment,
data conversion and data migration extremely difficult 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 difficult 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

A small commercial bank
Unique features System requirements

• Less complexity and smaller • Need agility and flexibility from
scale of operations system
• Lack of trained IT manpower • Capability to innovate and
differentiate products and
• Investment size and cost savings services
are critical considerations
• Compete on basis of cost
• Smaller geographic spread and effectiveness
fewer number of branches –
faster implementation • Need integrated and centralised
system
• Outsourcing a feasible option
• Likely to need services for
customisation and localisation

Competitiveness through
flexibility and cost effectiveness
are considered essential for • A small bank with a modest asset base and localised operations has
growth its own unique business considerations for selecting a system vendor
and service provider. Most small banks see cost as a critical business
consideration and essentially require systems that have a low cost of
ownership, particularly in terms of operational and maintenance costs.
• To retain competitiveness, most banks need flexibility and agility from

their systems to be able to provide differentiated products and to roll
out products with speed. A customer-centric system that can help the
banks to focus on fee-based transactions and product innovations
to tap consumer demand is important. This can be achieved 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.
Small banks can take

• While mainframes are proven technology across the globe, UNIX
aggressive approach by may also be feasible for small banks as their scalability and volume
adopting new-generation requirements are low. Due to manpower constraints, most banks do
technology and big bang
deployment 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

integration through a single product and vendor (which may be difficult

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 suffice. 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
Recent spurt in number of • Over the last two decades, hundreds of Islamic banks have mushroomed
Islamic banks has forced
the banking sector to look
across the world to cater to the unique requirements of Islamic finance.
for systems that provide Islamic banks are common in the Middle East but have sprung up as
compliance with Islamic law far away as London and the Philippines. Within the Asia Pacific region,
Malaysia and Indonesia are two countries that have shown rapid growth
in Islamic banking.
• The bedrock of Islamic banking is the principle of shared risk. Interest

payment is regarded as exploitation in Islam because depositors and
lenders make money without providing labour or sharing risks. Shariah
law requires profits to be shared and bans investment in certain industries
such as those related to alcohol and gambling. It also prohibits interest
payments and the handling of money as a commodity. Hence Islamic
banks pool deposits to invest in construction, commodities trading and
other businesses that do not profit from interest payments. Commercial
borrowers pay the bank and its depositors a share of their profits instead
of interest.
System should have the ability • This requires the system to have the ability to integrate basic core banking
to integrate core banking
features with Islamic principles
features with strong Islamic banking functionality. A system that can offer
sophisticated and innovative Islamic products and services coupled with
operational efficiency 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

banking, and help already established Islamic banks to stay competitive

in the market. The growing demands require that the new system is not
only flexible 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 profits can be difficult. Thus the system should have
flexible 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
Cost effectiveness with • “Internet only” banks, a relatively new concept, are specialised banks
flexibility for innovative products
is essential for “internet only”
that compete with brick-and-mortar banks (conventional banks) on the
banks basis of convenience, lack of locational constraint and lower costs. These
banks offer innovative products and services online round the clock and
seek to do it cost effectively. As they have lower fixed, operational and
maintenance costs and the cost benefits are passed on to customers,
the fees are generally lower and the interest rates competitive.
• Most of these banks are small and do not have adequate manpower to
customise and implement the core banking systems. For this reason,
they prefer packaged solutions, with cost being a major consideration
in selection. The transaction volumes are not as high as those of
conventional banks and multi-channel delivery capability is not necessary.
The front end, however, may need customisation to suit the unique user
needs for this type of bank.
• These banks maintain their competitive edge through innovative

products and services offered online to the customers. Speed is essential
and hence system flexibility and agility are key requirements. Quick
decision-making and reduced product-rollout time are equally important.
Scalability is not critical, so a UNIX-based system may suffice.
• 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.

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

7.5 Mergers and Acquisitions 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
Migration Integration
• Systems of pre-merger entities • Linking the core banking systems
are migrated onto one platform so that they effectively function as
one platform
• Data migration has high risks
• Difficult for two systems to coexist
• Time consuming
• Time consuming and costs can be
• May be followed by core banking high
replacement after a few years
• May be followed by core banking
replacement after a few years
M&A requires system migration • Mergers and acquisitions can be nightmares for IT professionals of the
or integration, either of which is
risky and challenging 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 difficult for the banks to
have an integrated view of the customer. Thus banks have to ultimately
consolidate the two systems, resulting in integrated databases and core
banking.
• Restructuring can be done by two means – migration or integration. Both

the options are high risk, involve huge costs and normally take several
years to accomplish. Implementation problems may lead to errors that
can easily shake the customer’s confidence in the bank.
• In migration, the systems of pre-merger entities are migrated onto one

platform. Take the example of Bank of Tokyo, whose business was
migrated onto Mitsubishi Bank’s core platform. However, data migration
can be almost as risky as a core banking replacement project.

• Integration entails linking the two systems so that they effectively

function as one platform. This project can be equally challenging and
may require anywhere from six months to several years to implement. In
Japan, three banks merged to form Mizuho Bank using the integration
approach. But even as two banks are able to integrate their core banking
systems through robust middleware and other technical advancement,
customisation of the front end is likely to be essential.
• Other than technical challenges in the process, it can be difficult to

get two banks to reach an agreement on platform, system and system
integrator. In some cases, a third approach may also be feasible, where
a financially strong purchaser installs a new core banking system within
the bank in order to meet aggressive business objectives. As we have
discussed, this would involve high costs and risks but may also result in
long-term growth for the bank if done properly.
• At the end of it all, the banks must have a system that is suitable for the
transaction volumes and processing needs of the combined bank and
meets the objectives of the merger.

Country Trend Analyses
8
This section analyses the trends in core banking system re-
placement in a few leading countries within Asia. The market
trends, demand characteristics and unique requirements of
each country are explored.
Country Trend Analyses
8.1 India
8.2 China
8.4 South East Asia – Indonesia, Malaysia, Thailand and Singapore
Country Tre n d A n a lyses
8.1 India
Market Trends Demand characteristics

• Most tier 1 and tier 2 banks have already • Data centralisation of public sector banks
made decisions; some small banks likely to and stiff competition have led to demand
replace their systems for better customer service and product
enhancement
• Has been quite an active market for core
banking in last 2-3 years • More banks prefer open system and new
technology
• Many banks have gone for centralised and
end-to-end solutions • Most Indian banks prefer changing their
infrastructure from bottom up rather than
• Leading vendors are Infosys, I-flex and adding applications due to archaic structure
FNS(TCS)
• Preference for local vendors
• Banks have preferred local vendors due to
familiarity with local system, sophistication • Cost is not a major consideration
of technology and cost effectiveness
• Partial replacement in some banks likely to
•Fewer opportunities in future as market is be followed by purchase of application
reaching saturation soon software for remaining functions
Source: Asian Bank Research
After active spell in last 3-4 • India is a unique country from the core banking perspective. Till five
years, Indian core banking
market may be reaching years back, most banks in the country were working on mere branch
saturation soon automation and most state-owned banks did not even have a core
banking system owing to lack of infrastructure and network readiness to
provide a centralised system. New private-sector banks then came into
the market with a distinct technical advantage which led to substantial
customer attrition in state-owned banks.
• Competition within the banking sector of this country is rising as

foreign banks are becoming more aggressive, growing through both
acquisitions and expansion of operations. Aggressiveness of the private
banks has thus forced most state-owned banks to replace their core
banking systems with advanced, centralised systems that are not only
competitive but also cost effective. In the last two years, almost 30% of
the country’s banks (most of these being state-owned) have taken the
decision to replace their core systems. Because of this, almost 50% of
deals in Asia during this period have come from India.
• Prominent deals in the last few years include State Bank of India with
TCS, Canara Bank with I-flex (for a $49 million project), Central Bank
of India with TCS (for a project costing 150 crore rupees or about $33

Count ry Tre nd Ana ly s e s
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 greenfield 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-flex 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 difficult 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
IT Infrastructure development of Chinese banks
Branch Branch Data Integrated Core

Computerisation Networking Centralisation Banking Systems
Market Trends Demand Characteristics

• Increasing number of core banking deals; • Increasing foreign competition as foreign
leading vendors include FNS, Misys, banks gain full access in 2007
Temenos and System Access
• Need to keep pace with rapid growth and
• Banks treading cautiously in selection of market demand
systems and vendors following deal failures
• Traditional accounting system being chal-
• Tier1 and Tier 2 banks looking for lenged by new business and foreign banks
international standards in new systems but
need systems to provide for local practices • Need product that meets the unique local
requirements, e.g. language, business
• Many Tier 1 banks using in-house systems environment
and increasingly considering new
technology • Higher costs and implementation risk due
to unique requirements; needs involvement
• Many smaller banks still prefer local of local people
vendors
• Lack of prominent local vendors
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
Market-driven and regulatory
pressures are forcing many
becoming more demanding on quality of services and products. The
banks to consider replacing robust growth of the Chinese economy has attracted financial institutions
their systems from across the globe.
• On the regulatory front, under China’s WTO commitments, foreign banks

will gain full access to its banking sector in 2007. In addition, the country
is gearing up to host the 2008 Olympics. With this background, most
banks in the country are awakening to the need for technically advanced
and competitive systems.
• We believe all Chinese banks are now somewhere between branch

computerisation and integrated core banking in terms of IT infrastructure.
Only a few leading banks like Bank of Shanghai, ICBC, China Minsheng

Only a few banks have Bank, China Development Bank and CITIC Bank have upgraded to an
upgraded to an integrated core
banking system 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 intensifies. 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
Smaller banks continue to
prefer local vendors
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
finance and treasury rather than at core banking system replacement.
We believe this reflects their short-term objective of attracting foreign
funds.
• Most banks in China have unique requirements such as ability to deliver

China presents a good in Mandarin and capability to customise and localise the solution to
opportunity for those who have
technical capability and domain suit their business conditions. For this reason, most vendors that are
knowledge to meet the unique providing solutions to Chinese banks are setting up centres in China and
requirements of banks 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.


Trend Analysis in Japan, Korea & Taiwan
Issues and Trends in Japan

• 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
Issues and Trends in Korea

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

• 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
Japan • The level of technical sophistication among Japanese banks is one of

Banks in Japan are struggling the highest in Asia with most banks having basic integrated CRM. Japan
with rising maintenance has traditionally had largely mainframe-based systems, most of which
cost and scarcity of trained
are proprietary systems developed in-house. Reliance on these stable
manpower
and robust systems has been widely accepted in the country and thus the
banks have been relatively slow in patronising the UNIX technology.
• However the banks are increasingly acknowledging the need to reduce the
high maintenance cost of these systems as the manpower for managing
them is dwindling. In Japan, this is known as the “2007 problem” as that
is the year when Cobol-trained manpower starts retiring. Another factor
that is likely to move the market is the increasing foreign share in the
Japanese banking sector.
• Various mergers in the Japanese banking sector have also led to complex

systems that typically would need upgrading or replacement to reduce

complexity and improve efficiency. Ageing systems and competitive
pressures are likely to bring about increased activity on the core banking
front over the next few years. Interestingly, a notable trend has been the
formation of smaller new-generation banks in Japan which tend to look
at new-generation technology.
• Indications are there but a substantial shift towards undertaking this

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

• We believe that technical advancement among banks in Korea has
towards new-generation reached integrated core banking and robust middleware. Till a few years
technology among Korean back, most banks in Korea used mainframe-based legacy systems. But
banks
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 efficient 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
Taiwan offers a good • Taiwan is one of the few countries where there was a sudden surge
opportunity to IT companies of activity in 2005, with four banks going for core banking deals as
with its increasing shift towards compared with 2004 when there were none. We believe that most banks
open-end technology
still lack the confidence 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

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

8.4 South East Asia – Indonesia,

Malaysia, Thailand and
Singapore
Trend Analyses of South East Asia Countries
Issues and Trends in Indonesia
• 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
Issues and Trends in Malaysia
• 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 Thailand

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

• Considered a relatively mature and saturated market
• Many banks technically advanced with integrated CRM; banks replace to
upgrade and improve competitiveness
South East Asia is

predominantly a cyclical • Banks in developing South East Asian countries like Thailand, Malaysia
market where banks replace and the Philippines have an existing base of first-generation infrastructure.
ageing systems to maintain
competitiveness
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

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.”
Many Malaysian banks look for
capability to adapt to Islamic
banking • In Malaysia, in the last three years, we have seen many small and
medium banks coming to the market to replace their systems. Many of
them have chosen vendors that can provide them with Islamic banking
capability. For this reason, local vendors such as Microlink and Silverlake
are popular in the country. We understand that the leading bank of
Malaysia, Maybank, is also in the process of evaluating vendors for
changing its core banking system. Given the small size of the country’s
banking sector, the change is noticeable. The aim of the banks is to have
integrated core banking systems.
Singapore is a saturated market
• 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.
Many banks in Indonesia
continue to operate on high-
cost legacy systems • 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
inefficient 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 inefficiency
and competitive pressures.

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

9.2 Market positioning
Vendo r A s s e s s m e n t
9.1 Vendor and Product

Assessment
Our Assessment of Vendor and Their Product
The key vendors in the region and their core banking products have been
analysed based on a survey done across banks in Asia. This has been
complemented with our research into their products, track record and
financial strength and a quantitative analysis of the recent decisions.
We have divided our assessment into two parts. First is vendor assessment
based on four parameters and second is product assessment based
on five parameters. The analysis has been done for only core banking
systems and not other solutions.
Vendor assessment – methodology
• Reliability – Reliability of the vendors in the region has been judged

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

vendors on the basis of their financial standing in absolute numbers and

Vendor As s es s ment
their growth over the last three years. The analysis has included key
indicators such as revenue, operating profit, net income and net worth,
among others.
• Current presence in Asia – The vendors’ presence in Asia has been

judged on the number of core banking deals that they acquired in 2004
and 2005. The spread of these deals across Asian countries has given
us a background on the number of countries where the vendor has
managed to make its presence felt. This has been complemented with
research into local presence through offices.
• 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 specific requirements while providing
international quality. We have further analysed the local presence of the
product in individual countries and the success of customisation.
• Product support – This has been analysed through a survey where

bankers were asked to assess the product on post-implementation
support services.
• Presence among big banks – The presence of vendors among large

banks in Asia has been determined based on the number of deals that
the vendors have won in recent years from large Asian banks. The
suitability of the product architecture to meet the requirements of large
multinational banks has also been analysed.
• Deals with small banks – The presence of vendors among small banks
has been assessed on the number of deals won by the vendors for small
and mid-size banks in Asia.
• Market perception of product – A survey done recently among Asian

banks has enabled us to assess the market perception of the product
based on its functionality and architecture.

Vendo r A s s e s s m e n t
9.2 Market Positioning

Product Positioning – As we see it
SOA/RDB Unproven Emerging Leaders Legend

X = Mainframe
X = Fidelity Core Bank X = Temenos Core Bank U = UNIX
A = AS4000
Architectural
Advancement
A = Silverlake U = I-flex
U = TCS Bancs U = Infosys
U = Fidelity Sanchez
A = Fiserv X = Fidelity Systematics
U = Temenos Globus
Traditional/
Flat-file DB Niche Players Ageing Architecture
Market Penetration
Low
High
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

significant history of implementation in Asia and hence market penetration
is rather low. However the prospects look good, as the architecture is
relatively new and more flexible. There seems to be only one product
in this category and that is Fidelity Corebank, a mainframe-based core
banking system.
• Emerging leaders – This segment comprises those products that are

technically advanced and have higher market penetration following
implementation across banks in Asia. We believe that the 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 classification of new architecture implies products
that have relational database and are more suitable for Service Oriented
Architecture. In contrast, old architecture is used for those systems that
were built long ago and have a traditional flat-file database system. Since

Vendor As s es s ment
their inception, some of these products have undergone architectural

changes and a certain level of technical advancement. As these products
have been in the market for a long time, their market penetration is
considerably high. Many UNIX systems such as Infosys Finacle, TCS
Bancs and I-flex Flexcube are in this segment. Among mainframes,
Fidelity Systematics is also positioned here. Fidelity Systematics had
high penetration in the market a few years back, but in recent years it
has not had any major implementation in Asia.
• Niche players – The products in this category specifically cater to

niche segments such as wholesale banks and small retail banks.
Understandably, their market penetration is lower. For example, we
believe Globus of Temenos is more of a wholesale banking package,
while Fiserv ICBS and Fidelity Sanchez are more suitable for smaller
banks.

Conclusions
10
Our research leads us to certain conclusions on success in core
banking which we discuss here in two sections. The first 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
Conc l u si o n
10.1 Conclusion 1 – For Bankers

Summarising Success Factors for Banks
Lack of business commitment
and willingness to adopt
changes within bank can
lead to failure of even well-
implemented projects
People and work

culture adaptation
Embrace change management
Strong leadership & decision making
Management and business commitment
Clear business direction, goals and business intelligence
Have clear business goals • We believe that the following elements are essential for a successful
core banking project.
• The bank must have clear business direction and goals, which would
be the guiding principles for all stages of the project from selection
to implementation. This would also ensure that the project has
adequate justification and support from the business perspective and
the implementation does not stray from requirements because of
enamouredness with technical enhancements.
Ensure total business • To ensure that the project has management commitment at all times,
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.
Effective communication • There is bound to be resistance to change and employee dissatisfaction,
is essential for change
management
which can only be countered through effective communication and

C o nclus io n
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
Process restructuring and new world in entirety. Product rationalisation and process restructuring
product rationalisation should
accompany the process
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.

Conc l u si o n
10.2 Conclusion – For Vendors

Summarising Success Factors for Vendors
Long-term commitment to
enhance product quality and
“partnership” role in project are
crucial for success of IT service
providers
Reputation, track
record
Partners in projects, not just

vendors
International quality standards

meeting local needs
Technical enhancements
Long term commitment to business
View project as long-term • For long-term success, it is essential that service providers see each
relationship
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.
Employ right people with • Having the right people with domain and business knowledge to suit
domain knowledge
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.
Ensure deliverables and • Ensuring that deliverables are in line with the expectations of the bank
expectations match through
effective communication
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.

Appendix I
Case Studies
A1
Case Studies
A1.1 State Bank of India

A1.2 Union Bank of Philippines
Case S tu d i e s
A1.1 State Bank of India

SWOT Analysis
Strengths Weaknesses
In-house IT capability to implement the Highly complex task with almost 8,000
project. Strong internal teams branches
Almost non-existent previous core banking Implementation time-consuming due to

system, easing integration issues wide reach
Vendor has previous experience in country Large human resource requirement for
and strong alliance with system integrator in-house implementation
System Integrator is familiar with unique Existing independent branch system

business requirements in India
Opportunities Threats
Core banking replacement project Difficult to change processes and work
extended to 4 associated banks culture in a 200-year-old organisation with
branches extending to remote areas
Increased competitiveness and improved
efficiency Lack of ownership of data at the user level
Centralised system that gives single view 10 million transactions per day. Scale of
of customer and frees resources for better data migration huge with zero margin for
service error
Largest commercial bank of • State Bank of India (SBI) is the largest commercial bank of India with
India found it necessary to
purchase new system to face
8,000 branches across India and a global presence in 20 countries. This
competition and reduce attrition two-century-old organisation has not only a wide spread but also a deep
rate 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-efficient systems that could meet its functional and
technical requirements.
The old system • Under the old system, the bank had computerised 2,050 branches on a
standalone basis. Thus each branch had its own independent system,
which it maintained and managed. The system was Bankmaster (now
under Misys) and it was used in 75% of the bank’s branches. However,
as each branch was independent, consistency and integration of systems
within the bank was not possible and customers could not freely approach
other branches of the bank.
• Inherent problems with the existing system and the competitive climate
in the industry thus forced the bank to undertake the massive project of

Ca s e S tud ie s
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-office 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
Project Selection Implementation 3,000 branches

Conceptualised process. process begins (50% bank's 85% of Business
with KPMG as Preparing RFP at pilot 200 branches business) migrated to new Implementation
consultant took 6 months branches migrated migrated system completed
2000 2002 2003 2004 April August April

2006 2006 2007
The selection process • 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 financial bids. Suitable vendors were selected
based on the technical bids and their pricing was one of the final decisive
criteria.

Case S tu d i e s
• FNS Bancs was considered the most suitable to meet the bank’s
requirements. TCS was chosen as system integrator as it had the distinct
advantage of being aware of local business practices, work culture and
regulations and thus was well-placed to understand the requirements
of the bank. Strong alliance between FNS and TCS was another factor
that contributed to the selection of FNS as the vendor. This, however,
meant moving to the UNIX platform which was relatively less proven
than mainframe for a bank of this size.
Customisation and • Owing to the size of the organisation, the customisation of software and
implementation process
the user training and training for implementation were, in that order, the
two most difficult 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 significant 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 was phased • 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.
The change management • 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

Ca s e S tud ie s
previously where there was an entrepreneurial feeling as they managed

the system and customised it to meet unique local requirements. This
demanded a strong acceptance of change management within the bank,
with staff roles changing and business processes being restructured
across all users. SBI met this challenge through strong internal teams
and effective communication. The change process is likely to continue
even after the new system has been fully implemented.
• By mid-2006, 85% of the bank’s business would have been transferred

to the new system. By March 2007, SBI expects to have rolled out its
core banking system to almost all of its domestic branches and those of
the four associate banks.
The outlook • 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 significant improvement.
We expect this new system to give a strong boost to the bank’s future
growth. However the effectiveness of the system for such a large bank
can only be seen after it has been implemented across all branches.
• For its international operations, the bank recently chose Infosys to

provide a single integrated solution across all branches as it felt that
TCS’s resources were already tied up with its domestic project. It is
also believed to be implementing a new trade solution. In addition, the
bank is undertaking a business process restructuring exercise in order
to improve its efficiency. With all these initiatives, SBI should remain a
formidable player and retain its stronghold in the Indian market.

Case S tu d i e s
A1.2 Union Bank of Philippines

SWOT Analysis
Strengths Weaknesses
Relatively small bank with 111 branches, Data migration from multiple existing
making replacement less complex systems and integration was complex
Willingness and adaptability to change Data cleanup was difficult as Finacle

from mainframe legacy to new technology required some parameters which old
system did not have
Willingness to take risks to improve
competitiveness Lack of in-house IT manpower. Cost also
an issue
Opportunities Threats
Centralised the back-office operations with Shifting from legacy to open system
the new system required change in processes and
business culture
Growing economy. Acquisition of new
customers and markets possible through New system required extensive user
differentiation of products and services training and acceptance at all levels
Availability of multiple vendors for open Big bang approach has higher risks. Tried
technology made choice easier for first time in the country
Lower TCO in new technology
The old system • 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
first 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 difficulty 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 efficiency 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
Cost a critical consideration shifting to a newer technology platform in 2002.

Ca s e S tud ie s
The Timeline of the Transformation Project
Explores
possibility of Selection
shifting from Requests for process Implementation
mainframe to proposal completed. begins with user Implementation
open platform from vendors Finalises Infosys training is completed
2002 1 Qtr 4 Qtr April April

2003 2003 2004 2005
The selection process • 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 new system • The bank finally selected Infosys to provide the system Finacle for
its retail operations (CASA, loans, deposits and GL). Local firm 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 first 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 financial impact. It wanted
a system whose cost could be met through the operating profits of the
bank over a period of five years. In addition, the new system should have
lower operational costs, thus leading to better returns for the bank.
The implementation and • Implementation took approximately one year and the system went
deployment process
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
difficult.

Case S tu d i e s
• The project was significant for the Philippine banking sector because it
was the first time a local bank shifted from a mainframe-based system to
open technology. For this reason – coupled with the fact that it used ”big
bang” implementation – it was keenly watched by many in the industry.
• The bank took an aggressive approach by adopting big bang, which was
less time-consuming but came with high risk. Most banks, especially
larger ones, prefer a traditional step-by-step rollout due to lower risks.
However owing to the relatively small size of the bank, big bang was
considered achievable and more feasible. The advantage in this approach
is the avoidance of integration issues that arise from having two separate
systems co-existing within the bank during rollout. The implementation
is fast and would not slow the bank’s transformation process. The bank
felt confident 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 fulfil the implementation
plan and to train users for the change in processes.
Lessons learnt • 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 final
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.
The outlook • With the new system, the bank aims to reduce its cost by 15% over five
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-office functions should give a
boost to its competitiveness

Appendix II
An Average Request for
A2 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 profile, technology, product, customer
information system, general information, security, and loan and
deposit system information. However, as this worksheet is very
extensive and specific to each bank’s requirements, we are not
providing a sample of it in our report.
Average Request for Proposal
Table of contents
A. Introduction
1 Bank profile
1.1 Vision
1.2 Mission
1.3 History and background
2 Bank products and services
3 Purpose
4 Eligibility requirements
4.1 Eligible vendors
4.2 Eligible products and services
4.3 Cost of this request for proposal
5 Definition of terms
B. Request for Proposal (RFP) Process
1 RFP contact details

2 Overview of the RFPprocess and schedule
2.1 RFP process
2.2 RFP schedule
3 RFP documents
3.1 Clarification of RFP documents
3.2 Pre-submission conference
4 Vendor proposal preparation
4.1 Language
4.2 Statement of compliance
4.3 Vendor proposal conditions
4.4 Vendor proposal 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 Confidentiality of the evaluation process
6.2 Clarification of vendor proposal
6.3 Examination of vendor proposal and determination of
responsiveness

6.4 Evaluation methodology

6.5 Bank’s right to accept or refuse any vendor proposal
7 Award of contract
7.1 Post-qualification
7.2 Award criteria
7.3 Reserved rights
7.4 Notification of award
7.5 Signing of the contract
7.6 Performance security
7.7 Corrupt or fraudulent practices
C. Commercial Terms and Conditions
1 Standard terms and conditions

2 Other terms and conditions
2.1 Responsibility
2.2 Delivery
2.3 Storage
2.4 Transportation, marking, labeling, packing and shipment
2.5 Transfer of risk and title
D Background and Vendor Proposal Requirements
1 Background and vendor proposal requirement

1.1 Background
1.2 Overview and scope
1.3 Architecture
1.4 System demonstration requirements
1.5 Reference site visit requirements
1.6 Pilot testing requirements
2 Implementation plan
3 Maintenance and support
4 Vendor’s expectations from bank
E. Financial Vendor Proposal Requirements
1 Overview
2 Price
3 Payment terms and conditions
3.1 Payment milestones

3.2 Payment due dates

3.3 Payment conditions
F. Statement of Compliance (Requirements Matrix)
1 Answering the requirements matrix

2 Requirements matrix
3 Executive summary
3.1 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 Vendor’s expectations from bank
14 Appendices
G. Attachments
1 Glossary of terms
2 RFP forms
2.1 Performance security
3 Standard terms and conditions

01-2006-Aggarwal - Roadmap To Successful Core Banking System Replacement

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-2006-Aggarwal - Roadmap To Successful Core Banking System Replacement

Uploaded by

Copyright:

Available Formats

Management Report:

Neeti Aggarwal, CFA

Published September 2006

First Publication: 15 September 2006

© 2006 The Asian Banker. All rights reserved

ABOUT THE ASIAN BANKER

Asian Banker Publications: incisive news and information on transformational

1. Core Banking Trends in Asia Pacific

2. Bankers’ Perception Survey on Core Banking System

3. Core Banking System – An Overview

3.1.3 Rationale for front-end systems replacement

4. Phases of Core Banking Replacement and Critical

5. Core Banking Replacement Building Blocks

2 Asian Banker Research Report

6. Critical Success Factors and Best Practices

7. Unique Core Banking Replacement Considerations

8. Country Trend Analyses

Asian Banker Research Report 3

8.4 South East Asia – Indonesia, Malaysia, Thailand and

A1. Appendix I – Case Studies

A1. Appendix II – An Average Request for Proposal

4 Asian Banker Research Report

Looking at the trend in countries that have first-generation technical

Asian Banker Research Report 5

Once a bank has decided to replace its system, it embarks on a complex

To better comprehend the complicated process of core banking replacement,

6 Asian Banker Research Report

early stage of the process.

We have discovered that one of the challenges is picturing the banking

Equally critical is selecting the right vendor. We believe that it is imperative

Asian Banker Research Report 7

in the vendor’s ability to meet the business objectives (through optimum

Platform choice is one other critical factor in selection. While mainframe

The third phase of the project is implementation. The key objective is to

8 Asian Banker Research Report

deployment of the new system. The process involves numerous logistical

This embracing of new technology requires tremendous effort in change

Asian Banker Research Report 9

10 Asian Banker Research Report

Core Banking Trends in Asia Pacific

1.1 Prominent Recent Deals in the

• Analysing the recent decisions, we noticed three significant trends.

• Looking at the geographic dispersion of recent decisions, we discovered

12 Asian Banker Research Report

Asian Banker Research Report 13

leading player in the region, particularly in India.

• Analysing vendor dominance in the region, we discovered that I-flex,

• TCS-FNS and Infosys are strong in this region, particularly in India.

• Globally, Islamic banking is a fast growing sector with banks demanding

• In summary, we believe that international vendors have found it

14 Asian Banker Research Report

1.2 Geographic Dispersion of

Number of deals in 2005

Regional Breakdown of Deals Within Asia for 2005

Source: Asian Banker Research

• Clearly, India continues to dominate Asia’s core banking systems market

Asian Banker Research Report 15

private banks in the country has forced most state-owned banks to

• Taiwan witnessed a recent surge in core banking deals, though mostly

16 Asian Banker Research Report

1.3 Activity Within Countries and

Source: Asian Banker Research

The level of activity is represented by the percentage of commercial banks