Roadmap to Successful Core Banking System Replacement

Transcription

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
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
4
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
5
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
6
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
7
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 UNIXbased 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
8
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
9
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.
10
1
Core Banking Trends in
Asia Pacific
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.
12
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
continued to be active in 2005
Leading Vendors in Asian Countries in Last two Years
• In China, SAP clinched the core banking systems deal awarded by China
Minsheng Bank, marking the entry of this global vendor in the region.
Chinese banks are increasingly considering replacement; however
following implementation problems in a few Chinese banks, they are
now more cautious about taking the plunge. Taiwan banks did not enter
into a single deal in 2004 but showed sudden activity in 2005. I-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
clear leader in Asian region,
but some vendors have
higher market share in certain
countries
• Internationally, one of the biggest deals in the past year was for HSBC’s
global operations, which was won by Temenos. The bank is understood
to be improving further on the present solution. Within the region, DBS
Bank’s core banking deal was another feather in the cap of Infosys, a
13
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.
14
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
5
0
In
di
a
a
si
ay
al
M
Source: Asian Banker Research
rs
he
Ot
iw
Ta
an
Ch
in
a
I
o
nd
si
ne
a
Ph
p
ili
pi
ne
s
m
na
et
Vi
Si
a
ng
po
re
a
re
th
ou
Ko
S
Th
ai
la
nd
Regional Breakdown of Deals Within Asia for 2005
Philippines
5%
Others
13%
Indonesia
5%
Greater China
16%
India
50%
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
saturation; China and Taiwan
are opening up
• We believe that activity for core banking systems will increase steadily in
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
15
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.
16
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
High activity, international demand
Less active, international demand
International
Vendors
Vietnam
Singapore
Thailand
Taiwan
Indonesia
Philippines
South
Korea
Malaysia
India
Local
Vendors
China
Legend
Trends
indicate likely
shift in future
Highly active, unique local needs
Less active, unique local needs
05
10
15
20
25
30
% of banking
sector replacing
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
technical advancement through
local vendors
• We believe that almost 25% of the Indian banking sector has entered
into core banking replacement deals in the last two years. In absolute
terms, the number is far higher than that of any other country – though
as a percentage of the whole sector, it may not be as 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
to continue to show demand for
core banking transformation
• Interestingly, the banking sectors of Thailand and Korea saw no new
deals in 2005 despite being active in 2004. However there was increased
activity in Taiwan and China. Increasing competition from foreign banks
in these countries is forcing banks to evaluate their core banking
replacement needs. We believe the core banking transformation in these
countries is set to accelerate over the next few years.
17
China banks have preference
for systems that cater to their
unique needs
• Most Chinese banks have shown a strong preference for systems
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.
18
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
(%)
0.14
($million)
1,000
800
0.13
600
0.12
400
0.11
200
0
2004
2005
2006f
2007f
0.10
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
likely to continue; no significant
jump expected in near future
• We have discovered that the cost structure of core banking deals varies
considerably due to multiple factors such as the scale and complexity of
the replacement process. However, generally, we believe that the total
investment required to purchase core banking systems is made up of
software and service cost which constitutes 30%, system integration
cost of 20-25% and hardware and infrastructure cost of 45-50%.
Deal sizes have varied from
about $5 million for small banks
to more than $50 million for
large wholesale banks
• Based on our analysis of recent deals, the system and service cost for
a small bank (with a size of $1 billion or less) comes to $5 million-10
million. For a medium-sized bank ($1 billion-50 billion), it is $25 million30 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.
19
• 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.
20
1.5 Evolution and Convergence of
Core Banking Systems
Technical Trends
Evolution of Core Banking Systems
HDFC: I-flex for
corporate
OCBC: Silverlake
HDFC: I-flex for
retail
China Bank:
Kirchman
ICICI: Finacle
1970
KDB: FNS
Banco de Oro: Chinatrust:
FNS
ICBS
StanChart:
testing open
sys
Kasikorn: IBM
1990
Legacy
systems
Taishin: FNS
Baroda: Finacle
B.Shanghai:
Temenos
HSBC-Temenos DBS Infosys Central Bank
of India - TCS
China Minsheng - SAP
2004
Web
XML
Web services
2005
Service-oriented architecture?
Parameterisation
EAI, BPM, WS
J2EE, .NET
Business Platform
Convergence in Core Banking Systems
Mainframe
systems
Parameters
J2EE, .NET platforms; EAI, BI, WS integration tools
Towards
core banking
systems today
UNIX
systems
Evolution of core banking
industry in Asia shows
increasing convergence of
technologies and focus on
architecture of systems
• The first generation of banking technology was represented by the IBM
mainframe, which had immense data processing capabilities but was not
as efficient in back-office accounting functions. Nonetheless its reliability
21
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 componentbased 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
Oriented Architecture
• Service Oriented Architecture (SOA) is a relatively new concept that
has gained popularity quickly. Herein, business applications are
constructed from independent reusable interoperable services that can
be 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
22
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
their global reach
• The growth in demand for core banking systems in Asia Pacific has
prompted many international vendors such as SAP, Temenos, Fidelity
and Misys to focus increasingly on the region. At the same time, vendors
that began their operations in Asian countries have grown to become
recognised names across the world; these include companies like
Infosys, I-flex and TCS.
Desire to become leading
player has led to consolidation
in the industry
• Desire to become the leading player in the market has led to mergers
and acquisitions among IT service providers. At the global level, Fidelity’s
acquisition of Sanchez broadened its reach to a larger collection of
banks. Among leading vendors in Asia, TCS acquired FNS in a leap from
their previous alliance. Another example of consolidation in the industry
is Oracle’s acquisition of a stake in I-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.
23
1.6 Technology Integration in
Asian Countries
Technical Trends
Technology Integration in Asian Countries
Hong Kong
Thailand
Taiwan
India (State Banks)
Singapore
Philippines
Australia
China
Japan
Indonesia
cu We
st b
om se
er rvi
ce ces
nt a
ric nd
ity
bu
s
an t m
d idd
ba le
si w
c C ar
RM e
Ro
ba
nk
ad ing
va sy
nc ste
em m
en s
t
Co
re
Ce
da ntr
ta ali
ce se
nt d
re
ne B
tw ra
or nc
ki h
ng
co
m
pu
te Br
ris an
at ch
io
n
Korea
Developed countries have
shown distinct technical
advancement
‘Customer centricity’
‘Account centricity’
India (Private Banks)
Malaysia
• We tracked the technical advancement of banking sectors and
architectures in several Asian countries. We discovered that the
integration of technology and the movement from account centricity to
customer centricity have varied 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.
24
1.7 Trends in Platform Usage
Among Asian Countries
Technical Trends
Recent Core Banking Acquisition Trends Among Asian Banks
Primarily UNIX-based
System Users
Primarily Mainframebased 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
primarily mainframe users but
there is a strong shift in favour
of UNIX systems
Competitive pressures and cost
effectiveness of UNIX-based
systems are driving the shift
• Traditionally, Asian banks – particularly those in Korea, Japan and China
– use mainframe-based proprietary systems. The robustness, stability
and scalability of these systems have been proven over the years and
continue to attract these banks. But in the last 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
the trend is the fact that most Asian banks are smaller compared with
many European and multinational banks and hence UNIX systems are
considered adequate for their scalability requirements. Another major
factor that draws many bankers to UNIX is the cost savings. Changes in
regulatory requirements (under Basel II) have also forced banks to look
for an integrated and 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
25
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.
26
1.8 Trends in Deployment
Approach
Technical Trends
Deployment Approaches in Recent Core Banking Decision
Existing
Implementation
Time
Bank Asset Size
More than
$100 billion
Singapore
$20-100 billion
HSBC
Bank
Long
Duration
Central
Bank of
India
DBS
Bank
China
Minsheng
Bank
Short
Duration
China
DevelopmentBank
Bank of
East Asia
Less than
$20 billion
State
Bank of India
Muslim
Commercial
Bank
Allahabad
Bank
Hua Xia
Bank
Gradual Implementation
Industrial
Bank of
Korea
Union
Bank of
Philippines
Cathay
United
Bank
Bank of
Panshin
Big Bang Implementation
Implementation
Approach
Bigger banks continue to prefer
gradual deployment while some
smaller banks choose “big
bang” approach
• The banks have two options in deployment. “Big Bang” implementation
largely involves a new system which goes live at the same time that
all the processes are shifted onto it. This is believed to be the quickest
but probably also the riskiest way to deploy the project. While the
risks are high, the integration problems are minimised as old and new
systems do not coexist. A phased approach, on the other hand, involves
gradual deployment across branches/functions generally through “big
bang” in small clusters. Here, the banks have to face the sticky issue of
coexistence of two systems.
• Our research shows that in Asia 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
27
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.
28
2
Bankers’ Perception
Survey on Core
Banking System
Selection
We have conducted a series of surveys in the Asian banking
sector to strengthen our research on various aspects of core
banking transformation. Our surveys have given us an insight
into how bankers assess various vendors in the region, key
considerations in the selection of a new system, and platform
preference among Asian banks. We have discovered that some
of the common perceptions lack sound foundation.
Bankers’ Perception Survey on Core Banking System
Selection
2.1 Survey results on key reasons for replacement
2.2 Survey results on factors considered in system selection
2.3 UNIX versus mainframe – survey results on considerations in
system selection
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.
30
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
Ranking
Vendor reputation and track record
Straight through processing/ real-time capability
Truly modular and integrated, single sign-on
Functionality
Scalability
Reliability/ stability
Importance
Cost remains the key
consideration when choosing
a core banking system,
regardless of platform
• With increasing standardisation and convergence, banks believe that it
is now easier for them to switch from one vendor to another for multiple
systems. To assess the importance that banks give to various parameters
of selection, we conducted a survey a few months back.
• The survey highlighted the importance of cost in the selection of a core
banking system in Asia. Most banks considered cost savings – through
lowering of maintenance cost or operational cost – as one of the key
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.
31
2.3 UNIX Versus Mainframe
– Survey Results on
Considerations in System
Selection
Perception of Strengths of Each System
UNIX SYSTEMS
MAINFRAME SYSTEMS
47
42
37
32
37
11
21
Stability
Availability of
Internal Skills
Many banks in Korea and Japan
use internal programmers to
customise their systems.
Total Cost of
Ownership
Old
Architecture More Vendors
vs Monopoly
Interestingly, mainframe systems
are perceived as old, while UNIX
systems are perceived as new,
which is not always true.
Scalability
UNIX systems can be
approximately 50% cheaper
than mainframe technology.
Application
Availability
5
Instability
For operational expenses, UNIX
systems can be 30-40% cheaper
than mainframes.
Stability is the biggest
perceived strength for
mainframe systems, while lower
TCO is the biggest perceived
strength for UNIX systems
• In a survey done some months back, we asked bankers what they saw
as the strengths and weaknesses of UNIX and mainframe systems. We
found that while there are an increasing number of banks favouring UNIX
systems due to low cost of ownership, scalability and recent technical
advancements, stability is still perceived to be the biggest strength of
mainframe systems.
• According to one banker, keeping legacy systems running consumes 6070% 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
32
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
operation increases with the numbers of users and
transactions volume
Scalability - Highly scalable, essential for larger banks
Robustness - Robust applications with good track record
Security - Substantially higher levels of system security
Architecture - Considered more flexible architecture. Our
analysis however shows that some of the mainframe
solutions have a more contemporary architecture
"Add on's" - Perceived higher availability of third party
applications. However, our analysis shows that such
applications can also be integrated into mainframe
architectures
Hardware/Software - More choice of hardware systems,
and application software provider
Functionality - Integrated universal Banking solution
often provide higher level of functionality (at the cost of
scalability)
Skills - Larger pool of skilled resources available in the
market
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
reasonable pricing if the bank does not posses sufficient
bargaining power
Security - Lower level of security than mainframe
systems. Viruses have been found in Unix based
environments
Skills - Smaller and hence more expensive pool of
skilled resources available in the market
Deployment -Not yet proven on large scale though
becoming increasingly popular among smaller banks
33
Strengths and weaknesses of
proprietary and open systems,
as perceived by respondent
banks
• Open systems have proved their ability to perform from the security and
technology points of view. According to one banker, “5-10 years ago a
large bank would go for mainframe, no questions asked. But in the last
5-10 years things have changed. Any bank today, no matter how big,
may consider switching to open system.”
• On the other hand, most big banks still favour the reliability and stability
of mainframes. Some bankers are inclined towards proprietary systems
as they are used to working on them. Switching to a new technology
would not only involve a huge amount of cost and high risks but also
require effort to get used to the new processes.
• According to one vendor, “Open systems are most appropriate for Asian
banks due to their smaller size compared to many international banks.
They don’t need the scalability of mainframes and the scalability of open
systems has really increased in recent years.” One leading bank in Korea
states that the trend in Korea today is to shift towards UNIX systems
from IBM “due to the availability of small packages that can be easily
integrated in our system [whereas] when we use mainframe we need to
code them which would be a time consuming proposition”.
The right choice varies with banks’ requirements
Our research and analysis of
the platform features reveal a
different picture
• As can be seen from the survey, platform choice is a dilemma that all
bankers face when they consider replacement. Our in-depth analysis
shows that for smaller Asian banks, a UNIX platform could be more
feasible as they may not need the scalability of the mainframe and UNIX
can be cost effective for a small number of transactions. However our
research shows that for large retail banks, mainframe is likely to still be
the preferred choice because:
- It is more reliable and keeps the system running through most upgrades.
Hence the downtime is low.
- It has the capability to support a large number of users, supports
multiple applications and allows better resource management. This is
especially important where transaction volumes are high.
- It requires less server capacity than UNIX for the same amount of work
and has higher continuous availability (due to less downtime).
• On the cost issue, UNIX-based systems are generally believed to have
a lower total cost of ownership (TCO). However the benchmark, we
believe, should not be total cost of ownership but total cost per user. Our
research indicates that when the bank has large volumes of transactions
and users, the operational cost of mainframe could be lower on a per-user
34
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
35
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
replacement of core banking
system
• Core banking replacement is becoming a hot topic in banking. We
have discovered that many banks are considering core banking system
replacement because of the following perceived needs:
- Ageing Technology Infrastructure – Ageing technology that is
increasingly 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:
38
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
the core processing power of
the bank
• We have discovered that there are multiple definitions of core banking
systems today. However based on our discussions with industry experts,
we can define core banking, in simple terms, as a highly efficient “customer
accounting” and transaction processing engine for high volumes of backoffice 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 customerlevel 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
39
Core Banking System is Transaction Processing Engine
Customer Information Repository
8
Deposits
Loans
Reporting
Core Banking System
Channel Integration
8
Core Banking replacement does not provide
you with an industrial-strength customer
information repository which allows ease of
integration of disparate core systems
Core Banking replacement does
not provide you with an industrialstrength general ledger system,
and ERP capabilities.
8
Application Integration
Core Banking replacement does
not provide you with a front end,
CRM or multi-channel capabilities.
Common Services
Product Definition & Management
Front-end
System
Replacing the Front End is a
separate system and a separate
project
Core Banking System
9
Core Banking replacement gives you raw
power. It provides you with a highly efficient
engine for all your transaction processing
needs
General Ledger
System
Replacing the General Ledger is a
separate system and a separate
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.
40
Conceptual Application Architecture Framework
Sales & Service
Delivery
New Age Channels
Internet-based virtual
delivery channels, including
Web and WAP services
Loans
Reporting
Deposits
Channel Integration
Core Banking
Data Warehouse
Workflow Management
Document Imaging Capability
Channel Integration
Middleware Infrastructure
Integration infrastructure to
link the bank’s systems. A
modern architecture is built
around an enterprise service
bus utilising an SOA
Virtual Channels
Imaging and Workflow
Imaging and workflow
capabilities e.g. for the
commercial lending process
Data Warehouse & Data Marts
Enterprise data warehouse
with relevant data marts
Customer Information
Repository
Physical
Channels
Delivery Channels
Application supporting the
bank’s delivery channels.
Integrates into the customer
relationship management
and core systems
Business
Intelligence
Core Systems
Relationship & Risk
Management Infrastructure
Common customer view and
central customer liability. “The
customer belongs to the bank”
and not a booking unit
Data Mining
Utilise existing information in
the data warehouse e.g. to find
customer behaviour pattern
Common Services
Other Support Systems
Source: Immacon Research
Critical for banks to understand
what they would get in core
banking replacement
• To start an effective core banking replacement programme, the bank
must manage the expectations of all parties involved. Therefore we
believe that it is very important to clearly understand what a “core banking
replacement” really is. In some cases, a bank might not even need to
change the core banking system but just refresh an ageing front-end
system. In other cases, a bank might need to do both, i.e. replace the
core banking system and simultaneously replace the front-end systems
of the bank. This of course is a project of much greater magnitude and is
analogous to changing the wheels in a fast moving car.
What you see is not what you get
• Many banks evaluate core banking systems based on functions and
features. The objective is to get as many bells and whistles as possible.
As the initial selection is very much driven by the business user, the
vendor would score highly with a “pretty” front end and usability.
• The irony here is that the user will not get what he sees. We have
discovered that it is a common and understandable misconception of
business users that front-end screens relate to core banking. This more
often than not leads to sub-optimal results for the core banking project.
• It is crucial to recognise that what the user sees is the front end of a
banking application architecture (a teller system, an advisor workstation,
a kiosk or an internet front-end) but not the “core banking system”. Core
41
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
replace front end to reap
benefits from core banking
replacement
• To make matters more complicated, it is often important to also change
the front-end applications, to better reap the benefits of the core banking
replacement. For the front-end replacement, it is critical to make sure
that the front-end applications can be integrated with the back-end
systems with minimal effort. For a contemporary core banking and frontend 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:
42
We recommend that banks
choose the same vendor for
core banking and front end
- Same vendor for front end and core banking: Here, front-end and
core banking replacement solutions, though separate systems, come
from the same vendor and the vendor is responsible for integrating the
front- and back-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”?
43
3.2 Overview of the Core Banking
System Replacement Project
Core Banking System Replacement Project – an Overview
Project Stages
Development
of business
objectives
Selection of
approach
Development
of selection
criteria
Bidding
process
System
selection
Selection
of service
provider
Reasons for
replacement
Select right
platform
Evaluate
financial
impact
Select software
vendor and
integrator
Gap analysis of
existing
infrastructure
Select right
architecture
Risk-return
analysis
Identify right
approach to
implementation
Implementation
and launch
Ongoing
technical
support &
enhancement
Core banking replacement is
almost like a heart transplant
involving high cost, high risk,
and substantial effort and time
• Replacing or even upgrading the core banking system is a complex
and high-risk proposition requiring substantial resources and time. Most
banks prefer to defer the decision till the change becomes imperative.
The decision making process includes providing 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.
44
Core Banking Replacement Stages
Efficiency/ Performance
Masters of the
World
"We made it"
Project
start
Continuous
Improvements
Euphoric
"We will change
the world"
Disillusioned
"This is hard but we
have passed the
point of no return"
Reality Strike
"The honeymoon
is over"
The Emperor’s New Clothes
"We got the old systems in
new clothes"
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
45
3.3 Approaches to Replacement
Approaches to Core Banking System Replacement
In-house
development and
implementation
• Ownership of hardware and
software
• Software either developed
in-house or purchased from
vendor
• Implementation of system done
in-house
• In-house IT expertise required
– suitable for large banks
• Approach adopted by many
banks in Japan and Korea
Purchase of system
software and
services
• Ownership of hardware
• System integrator hired for
software
• Vendor customises, integrates
and implements solution
according to the bank’s
requirements
Complete
outsourcing
• Outsourcing of software and
hardware
• ASP hired to meet the core
banking needs of bank
• ASP maintains the accounts
and branches through its own
data centre, and meets all the
core banking needs of bank
• Critical to select the right
software and vendor with
domain knowledge
• Charges calculated on per
transaction or per branch basis
• Approach adopted by many
medium and small banks
• ASP provides expertise but
may commoditise service
Bank’s approach to core
banking replacement depends
on the availability of financial
and human resources
• Our research shows that banks can choose from multiple approaches for
upgrading or replacing their core banking systems. The most appropriate
approach would vary with the availability of technical skills, complexity of
the task, availability of products and costs involved.
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.
46
Increasing shift towards
packaged solutions among
smaller- and medium-sized
banks
• The substantial cost, resources and expertise involved in building a
new system has forced many banks (particularly medium- and smallersized 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
considered due to low cost and
vendor expertise
• Some banks may prefer a third alternative: complete outsourcing
to an application service provider (ASP). This frees up resources for
banks as they need not own the hardware or the software for their core
banking activities. Management of the data centre and branches may be
outsourced to a vendor that is adequately equipped and has a proven
track record in providing these services. In return, the banks could pay
the ASP on a per-transaction or per-branch basis.
• While a few second-tier banks in Australia and Japan have turned to
outsourcing, this approach is gaining more attention in other Asian
countries only now. In line with this trend, HP recently signed a tenyear 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.
47
4
Phases of Core Banking
Replacement and
Critical Considerations
Replacing a core banking system is a complex and high-risk
proposition. This section analyses in detail the key requirements,
critical considerations and challenges in each stage of the core
banking system replacement project. Going further, we discuss
the factors that we believe are essential ingredients for success.
This section is targeted at both business decision-makers as well
as IT people involved in the transition process.
Phases of Core Banking Replacement and Critical Considerations
4.1 Phases of core banking replacement – an overview
4.2 Timeline of replacement project stages
4.3 Phase 1 – business 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
replacement into four phases
Core Banking Replacement Project Phases
Project Phases
Business
Justification &
Blueprint
4 - 6 Months
Understand Business Imperatives
Achieve Consensus on Business
Driver & Approach for Core
Banking Replacement
Define Core Banking
Transformation Strategy eg.
Replacement or Transformation
Develop “Delta” Transformation
Blueprint
- Business Scope & Objective
- Reference Technical & Business
..Architecture
- Platform Preference
- Process Transformation Scope
- Organisation Alignment
- Visualisation of “New World”
- Business Case / Financial Impact
..Analysis
- Risk-Return Analysis
“Delta Driven”
Implementation
Selection
4 - 6 Months
Develop “Long List” for Vendor &
Integrator
18 - 24 Months
Deployment
Dependent on Chosen
Deployment Approach
Delta Definition
Training & Change Programme
Delta Resolution
External & Internal Communication
Design
Logistics
Build & Test
Rollout Schedule
Pilot
Big Bang or Phased Deployment
Request for Information
Finalise Platform Choice, Refine
Requirements and Develop
“Short List”
Agree on Selection Process
- Delta or Traditional GAP
- Scoring or Judgement
Prepare Request for Proposal
Update / Refine Business Case
Bidding & Contracting Process
Award Contract
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
50
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.
51
4.2 Timeline of Replacement
Project Stages
Core Banking Replacement Project Phases
Project Phases
Business
Justification &
Blueprint
4 - 6 Months
“Delta Driven”
Implementation
Selection
4 - 6 Months
Deployment
Dependent on Chosen
Deployment Approach
18 - 24 Months
A typical core banking
replacement project takes 1824 months though the duration
varies with the extent of change
and size of bank
• As time management guru Alan Lakein has taught us, “failing to plan is
planning to fail”. Thus the first phase of the core banking replacement
project provides an overall plan for the initiative. It is important for business
decision-markers to agree on the business objectives and 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
Phase 1: Business Justification & Blueprint
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
4 to 6 months
Understand Business Imperatives
Assess Current Operations
Blueprint & Visualise Future Operations
The 'future state' defined in the blueprint and visualisation is input to the
RFP requirements and the solution design and underpins the change
management and business transformation efforts.
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
52
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
Justification &
Blueprint
Developing business objectives
of core banking system
replacement
Selection
“Delta Driven”
Implementation
Deployment
Project Stages
Understand
Business
Imperatives
Assess
Current
Operations
Blueprint &
Visualise the
Future
Operations
Prepare
Implementation
Blueprint
Develop
Business
Justification
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 development 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
53
Banks need to initiate the
process by developing clear
business goals
• While banks are awakening to the need of advanced and more flexible
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
system varies between banks
• While the broad requirements from the system functionality would be
similar for most banks, unique requirements would vary. Improving
competitiveness and garnering market share is one common objective
cited for replacement. In some banks it may actually be a case of ‘survival’
rather than choice that forces the management towards replacement.
• A global bank is likely to require more scalable system with multichannel, 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
the guiding factor throughout
the replacement project
• These Business objectives should in turn act as key guiding factor in
establishing selection criteria. These should be forward looking to ensure
suitability of the new system in long term as a bank replaces its system
once in 10-15 years. Nonetheless in today’s fast paced environment it is
extremely 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
banks to anticipate future needs
and plan accordingly
54
• Our research into replacement case studies shows that it is imperative
for banks to take stock of their current operations in the “old world”
environment, and comprehend the technology infrastructure and
shortcomings. Thereafter, the banks should understand their current
business imperatives and anticipate future needs. These should be the
key drivers for the core banking replacement strategy. Yet, we have
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
55
• 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
Process
Automation
Old World
Legacy
Code
Loss
Making
Legacy
Products
Old World
56
Delta Analysis
Key Concept 2:
Delta Analysis
Moving Towards A “Legacy
Free” New World
Old World
New World
Reporting
Local Practices
Policies & Procedures
Products
Processes
Old Core Banking
Systems
New Core Banking
Systems
Stakeholder
Benefits
...................
...................
...................
...................
...................
...................
...................
...................
Mainframe
New
Core Banking
System
UNIX
Delta
Analysis
AS 400
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
Q1
Phase 2
Q2
Q3
Phase 3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Phase 4
Phase 5
Q2
Q3
Phase 0: Setup and Initiation
Q4
“Put A Stake in the Ground”
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
Go / No Go
Design
Sign-Off
Pilot
Go / No Go
Deployment
Go / No Go
Go / No Go Decision
Milestones
Go
Project Flow
Stop
Project will continue to the next phase
8
Project will stop until
milestone is signed off
• In summary, successful core banking replacement projects we have seen
are driven by clear business objectives, a strong business justification,
57
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
facilitate business justification
• Key activities to consider for the business justification stage of the project
are:
- Define the business objectives and desired outcome of the project
- Assess the current operations and existing IT infrastructure against 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
58
4.4 Phase 2 – Selection
Critical Considerations in the Selection Process
Project Stages
Identify key
deliverables to
meet long-term
needs
Consider
long-term strategic
goals of the bank
Develop
selection
matrix. Identify
‘Go’ / ‘No Go’
criteria
Develop a
rating system
detailed to
provide
objective &
subjective
assessment
Develop
Request for
Proposal and
invite bids
Invite bids from
vendors that
have strong
experience in
similar projects,
reputation and
track record
Initial filter to
eliminate
unsuitable
vendors
Eliminate the
products and
vendors that do
not meet the
essential
criteria
Invite
presentation
from
short-listed
vendors
Final selection
should
comprise
detailed
analysis of
vendor and its
partners in the
project
Financial
assessment
and final
selection
Financial
assessment is
important but
decision should
be based on
product and
vendor
capability
Identifying the critical current
and future needs to be met by
new system
Key Demands from New Systems
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
Scarce trained manpower
Lower TCO
59
• 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.
60
Critical factors that determine
the selection criteria
Focus of Banks with Regard to Selection Criteria
Business Direction/Goals
5
4
Existing System/
Technical Capacities
3
Scale and Complexity of
Operations
2
1
Human Resources
Product Features
Legend
Ideal Bank
Business Culture Process
The bank needs to develop
selection criteria based on
its unique requirements and
business objectives
Cost/Financial Impact
Average Bank
Scale of 0 to 5 measures level of importance
(0 = Not important at all, 5 = Very important)
• Selection of the system is a strategic decision which can impact not
just the growth and financials of the organisation but even its viability
and competitiveness. Therefore it is essential that banks select the
system that provides the right components and architecture to meet their
objectives.
• The architectural components that can meet the functional requirements
of the bank, given its business goals, must 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
61
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
assessing IT service providers
Focus of Banks in Assessing Core Banking System Vendors
Track Record
5
4
Ongoing Support
Product Functionality
3
2
1
Financial Viability
Cost / Financial Impact
Legend
Ideal Bank
Commitment to Business
Evaluating vendor track record
and financial viability is a must,
but equally important is for the
bank to assess its comfort level
with the vendor’s ability
Reliability
Average Bank
Scale of 0 to 5 measures level of importance
(0 = Not important at all, 5 = Very important)
• Banks cannot bring about transformation in their systems alone. Most
banks see a core banking project as a highly risky proposition, so they
would invariably like to partner a vendor whom they can trust and believe
to have the ability to handle a project of that size and nature. The vendors
are generally solution providers and, in most cases, service providers
who implement the solution within the banks. The two often join hands
with a hardware supplier to form a consortium to bid for the project.
Where there are multiple vendors, banks need to decide who would be
the prime vendor.
• The evaluation of vendors involves multiple assessment criteria, foremost
being delivery track record, financial viability, technical capability, product
features and cost.
62
• Banks need partners that have the proven track record to provide them
with the right product and service mix. There are relatively few vendors
that have successfully completed core banking projects of the size and
complexity of tier 1 banks. But for tier 2 and tier 3 markets, there is
more competition. The IT partners’ track record and reputation should be
evaluated in the context of the banks’ unique requirements. For example,
banks in China look for customisation and localisation capability. Similarly,
Indian banks have shown a preference for local vendors.
• In addition, the IT partner’s financial strength (to ensure long-term
viability), ability to continually upgrade products and track record in postimplementation 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.
Vital to assess vendor’s
financial strength for longterm viability and technical
enhancement
• 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,
Scalable,
Stable
Modular,
Integration
Customercentric,
Single View
of Customer
Straight
Through
Processing
Service
Oriented
Architecture
• Ability to meet the long-term growth and ambitions of the bank
• Component-based structure that can be modified and developed with ease
• Integrated customer information to facilitate better customer relationship across functions
• System functionality to support global deployment
• Banks have to select the right architecture for the banking system in
general and the core banking system specifically to suit their unique
63
The functionality and
architecture of the system
along with its suitability to meet
business goals would be the
key concerns
requirements. Most banks today are shifting their systems to attain more
flexibility and scalability, similar to moving out of the confines of a small
box. What they need to ensure is that the new system is not like a bigger
box which quickly becomes a constraint again in a few years’ time.
• Flexibility – With a convergence of 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
modular architecture with STP
and single view of customer
• Modularity – We believe that the system architecture has to be modular.
This means that one part of the system can be changed without affecting
other parts, thereby enabling banks to easily change and enter into
particular segments of operations. For long-term 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
system within the banking
system architecture equally
important
64
• The architecture of the banking system should integrate the core
banking system such that there is customer centricity with a single view
of customers across functions. In a customer-centric environment, the
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 SOAbased 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.
65
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.
66
- 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
factor; identify what is most
suitable based on needs
• In summary, we believe that the total cost should not be the driving
factor in platform selection for a retail bank. For a mission critical system,
considerations such as availability, scalability, reliability and security are
of far higher priority. Cost should only be a barrier for banks that cannot
afford the most suitable platform and are willing to compromise on the
service level of a mission critical system.
For smaller banks, UNIX could
prove to be effective but banks
need to consider switching cost
• On the other hand, for small wholesale banks and banks that do not
have large transaction volumes, the UNIX platform could prove to be
effective. Given the technical advancement in UNIX systems in recent
years and the increased availability of UNIX hardware, software and
technical skills, UNIX is rapidly becoming a preferred choice for smaller
banks and new banks. As these banks have only a handful of branches,
limited multi-channel requirements, lower security requirements and
tolerance for unplanned system downtimes once or twice a month, the
price-performance equation here makes the non-mainframe solutions a
viable option.
• However, for those banks that intend to shift from mainframe to UNIX, or
vice versa, the switching cost and the cost of coexistence of two systems
need to be added to the total replacement cost.
4.4.5 The selection process
Objective: Select and acquire the enabling technology and service
provider.
67
Core Banking Selection Process
Business
Justification &
Blueprint
Selection
“Delta Driven”
Implementation
Deployment
Project Stages
Issue RFI /
Refine Vision
Issue RFP
Select System
& Service
Provider
Conduct
Negotiation &
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
68
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 indepth 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, multichannel 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.
69
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
and processes with zero error is
the key challenge
70
• Core system replacement or even upgrading is a major challenge that
can create disruption of service, customer dissatisfaction and employee
disappointment. Transition from one system involves not just technical
complexities but a plethora of unforeseen problems in areas such as
matching of expectations and deliverables, adaptability of system within
the organisation and change management.
• 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
critical means of risk reduction
• The most critical success factor in implementation is thus to test at
every stage. Banks should develop pilot projects, divide large projects
into phases, and conduct user acceptance tests or, rather, business
acceptance tests to ensure a match between deliverables and
expectations. Also critical is having strong internal teams with good
communication skills and decision-making capability. There should be
71
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.
72
Core Banking Implementation Process
Business
Justification &
Blueprint
Selection
“Delta Driven”
Implementation
Deployment
Project Stages
Delta Analysis
Detailed
Design
Build & Test
Pilot
Implementation
Sign Off
Transformation Approach and Methdology
Phase 1:
Delta Definition
Identify Organisational Change Determine the changes needed to fit
the organisation to the new System.
Identify Essential Modifications to
the new System - Every effort should
be made to avoid changes to the new
System but rather to align the
business to the new system. Changes
to the new Core Banking System
should be limited to those essential in
order to meet regulatory
requirements.
Identify Integration Delta Determine the interfaces, conversion
modules and coexistence
development required to integrate the
new System into the bank’s
environment.
Delta Analysis Report
Phase 2:
Design
Phase 3:
Build & Test
Business Realignment Design Define the reengineered products
and services and business
processes aligned to the new
System.
Business Realignment - Align the
bank’s products and services to the
new System. Also align the bank’s
processes and procedures to the
new System.
System Design - Prepare the
design for system configuration.
Also design the unavoidable
modifications identified during the
Delta Analysis.
Configure & Customise Configure the system as needed,
effect the necessary changes to the
organisation, and make changes to
the system, where absolutely
necessary. In addition, the interfaces
between the new System and the
many linked systems are created.
Integration Design - Prepare the
technical design for the Interfaces,
Data Conversion Modules and
Coexistence Modules.
Design Specifications
Testing - Perform various levels and
types of testing to the new system
and processes etc. in preparation
for correct functioning in the live
environment.
Applications Ready For Pilot
Phase 4:
Pilot
Training Preparation - Prepare
training plan, materials and course
trainers.
Pilot Preparation - Identify and
prepare the pilot site, train the pilot
users and conduct rehearsals to
prepare for the actual cutover.
Pilot Go/No Go - Confirm the
completion of Pilot Preparation
activities and readiness for cutover
of the new System to the Pilot
community.
Pilot & Fine-tune - Cutover the Pilot
site and users to the new System.
Identify and fix problems that did not
arise in the testing environments.
Applications Ready For
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
involves delta analysis,
detailed designs and product
modification to meet the bank’s
requirements
• Delta Analysis – A delta analysis is the identification of differences (the
“delta”) between the desired state and the selected package, and ways
to resolve these differences. One objective of the delta analysis is to
identify the package 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:
73
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
Start :
Process / Appraisal
Identify Regulatory
Requirements
Identify Delta
Delta Resolution
New World
Operations
Option I:
No change /
Out of the box fits
Option II:
Rationalise
Process / Product
Option III:
Modify package
Accept Package
+
New Core Banking
Solution Procured
Regulatory
Modification
New Core Bank
Capabilities
Change Bank
Product / Process
to Match Package
Delta
Resolution
Modify Package
Delta
Input on Package
Regulatory
Modifications
Core Package
Cost Impact
Delta
Customisation
Regulatory
Customisation
Regulatory
Customisation
Regulatory
Customisation
Regulatory
Customisation
Core Package
Core Package
Core Package
Core Package
Core Package
No
Yes (Time & Material
Cost for Modification)
No (should be included
in base price)
No
Regulatory
Customisation
© 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
74
A detailed design done right
can save the bank substantial
time
• Detailed Design – A detailed design of the future solution is needed for
the subsequent Build & Test stage of the project. A detailed design done
right can save a bank a lot of time and money by avoiding unnecessary
rework and change requests. Many projects run into 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
75
- 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
76
Reference Implementation Methodology
A comprehensive implementation method may be the one that follows:
Comprehensive Implementation Chart
Phase 1:
Delta Definition
Delta Analysis
Phase 2:
Design
Business Design
Business Change
Product
Rationalisation
Process
Rationalisation
Conduct
Gap
Analysis
Phase 3:
Build & Test
Business Build
Product Designs
Update Procedure
Manual
Process Designs
Prepare User
Guides
Resolution
System Change
System Design
System
Customisation
System Build
Local Customisation
Designs
Local
Customisation
Core Customisation
Designs
Core
Customisation
Configuration Designs
System
Configuration
System
Configuration
Configuration Analysis
Configuration Definition
Integration
Interfaces Designs
Interfaces
Data Conversion
Data Conversion Designs
Data Conversion
Coexistence
Coexistence Designs
Coexistence
1
Sign Off Delta
2
Pilot
Training
Preparation
Pilot
Planning
Prepare
Training Plan
Prepare
Training
Materials
Train Pilot Users
& IT Ops
Pilot Site
Preparation
Train-theTrainers
Dress Rehearsal
Testing
System
Integration
Testing
Integration Build
Interfaces
Integration Design
Phase 4: Pilot
Implementation
Operations
Testing
Business
Solution
Testing
3
Pilot
Go/No Go
Convert
Pilot Data
Pilot End-user
Support
Application
Support & Fixes
Sign Off Design
77
4.6 Phase 4 – Deployment
Enterprise-wide rollout of
the system poses critical
challenges, demanding careful
planning and caution at each
stage
Objective: Enterprise-wide rollout of the refined future state operation.
Core Banking Deployment
Business
Justification &
Blueprint
Selection
“Delta Driven”
Implementation
Deployment
Project Stages
Logistics
Training
Change
Mgmt &
Comm
Go Live
Fine Tune
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
78
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.
79
Comprehensive Implementation Chart
Complete End to End
Integrated solution suitable more for small
and medium banks
Suitable more for smaller banks
Risks and complexity higher
Easier to integrate solution from single
supplier
Implementation more challenging
Phasing of implementation process
reduces risks
Sudden change in processes and culture
within organisation
Gradual Implementation
Big Bang Approach
Preferred approach by large banks due to
complexity and scale
This approach can be used for smaller as
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
integrated, projects are more
suitable for bigger banks
• We strongly believe that for core banking systems, there should be only
one vendor or else there would be immense integration issues. For
the front end and back 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.
80
• 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
“Big bang” is the quickest but
also the riskiest
• While deciding on the replacement approach is easy, deployment
is probably the most difficult and challenging part of a core banking
project and can be accomplished through multiple approaches. The two
extremes are “big bang approach” where the entire system goes live
at the 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 fullscale 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
be the preferred mode among
bigger banks
• We believe the gradual approach, which is essentially step-by-step
replacement, should be the preferred mode of implementation among
large banks as the complexity and risks in the process are lower. A
phased implementation also deploys the entire core banking solution in
one big bang similar to the enterprise-wide big bang.
• The key difference between a phased implementation and an enterprisewide big bang is that the phased implementation is conducted in stages,
in successive deployment clusters which are closely controlled and
81
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.
82
4.7 Risk Mitigation
Inherent risks in replacement
project
Inherent Risks in Each Stage of the Project
Project Stages
Evaluation risk
& management
commitment
• Assessing the technical
and functional
requirements of the bank
• Ensuring adequate
financial, business and
management support for
the change
Selection of
vendor, service
providers
Solution risk
Implementation
risk
• Financial viability to
provide long term
relationship and
technical support
• Evaluation of
technical capabilities
of solution to meet the
business goals
• Ensuring smooth,
timely and cost effective
implementation of new
system
• Experience in
successfully
implementing similar
project
• Flexibility and
adaptability to new
developments
• Ensuring adaptation in
the work culture and
post-implementation
smooth operations
Long term
technical
support risk
• Commitment of vendor
to provide long term
support
• Technical advancements
and their compatibility
with the new system
Banks need to tread carefully
as there are hurdles at each
step of the change process
• Risks and potential losses in replacing a core banking system are very
high, making it imperative that banks tread with caution at each step.
We have identified five broad stages in the replacement process and
inherent risk characteristics of each.
Project needs business support
in totality
• Lack of management commitment is one of the primary causes for
project failure. We believe that a core banking replacement project needs
business and management support in totality and the project should not
be perceived as an IT project. Management commitment should not be
limited to simply business and managerial involvement at all stages of
the project but extend to strong leadership support that sees the project
through.
Evaluation at each stage has to
be comprehensive
• The evaluation of business needs and objectives must be comprehensive,
as inadequate assessment of technical and functional requirements will
lead to improper selection and possibly expectation/deliverable mismatch
at a later stage. It is critical for the bank to understand the type and depth
of functionality provided by the core banking solution in the context of its
own requirements and replacement objectives.
Improper selection of vendor
and system can lead to project
failure
• Availability of multiple solutions with varying technology and comparable
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
83
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
of error in the implementation
• Transition from an old system to a new technology is a risky proposition
in any organisation. It is more so in the case of banks due to the high
risk of potential losses and errors in a scenario where they cannot allow
a margin of error.
• Risks are present at all corners, whether it is system customisation,
data migration, consolidation of multiple systems, integration of multiple
processes or user adaptation to new processes. Another risk is the
possible lack of long-term support from vendors, which could translate
into faster obsolescence of the system and inability to meet expectations
amid the constantly changing dynamics of the banking sector.
• Analysing various risk elements in the planning stage of the project would
help ensure the adequacy of selection criteria and lower the likelihood of
expectation/deliverable mismatch at a later stage.
84
4.8 Financial Implications
Investments and Costs Implications
Cost Analysis
Loss of
Business
Customers
Recurring Cost
Unexpected
Cost
System
Integration
One Time Cost
Hardware
Core Banking
Planned
Planned Costs
Core Banking software acquisition and
maintenance cost
Hardware acquisition and maintenance
cost
System integration and consulting cost
Unplanned
Unplanned Costs
Unexpected delays
Incremental changes during implementation
Scope of project becoming too big
Resistance to change
Replacing core banking
system has high risks and
huge costs and thus requires
strong business and financial
justification
• Ownership of the core banking system is very costly and requires
strong commitment and business justification in most cases. It is for this
reason that most banks take considerable time in coming to a decision
to replace or even upgrade their system. The cost components of the
total capital expenditure are software and service cost which constitutes
30%, system integration cost of 20-25% and hardware and infrastructure
cost of 45-50%.
• The software and service cost is highly dependent on the scale and
complexity of the project. For example, it could be $100 million or more
in large global banks but it has generally been much lower for smaller
Asia 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.
85
• 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
86
growth in the long term are definite motivations. We discuss these further
in the following section.
Financial justification through
cost savings and revenue
growth
Financial Justification of New System
Project Stages
Expected deliverables of the new system
Integrated,
flexible system
Increased
efficiency,
competitiveness
and time saving
Lower
opportunity
costs
Improved
margins and
return on
investment
Lower
operational,
maintenance
cost
Shorter break
even period,
lower
manpower cost
and higher ROI.
Customer
centric, STP
Improved
competitiveness
and growth.
Customer
relationship
improved
Innovative
products,
bundling
Improved
market
presence,
capture of new
market,
increased fee,
revenue
New
initiatives,
services
Improved
revenue
generation,
business
growth
Legend
Direct benefits
Indirect benefits
Direct and indirect financial impact for the bank
While investment is substantial,
benefits from cost savings, ROI
and business growth could be
more
• While there is clear business justification in the form of intangible
benefits such as market growth, retaining of competitiveness and longterm 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%.
87
• 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
highly possible if bank has the
right system
• The most critical impact on a bank’s financials is in its revenue growth.
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.
88
5
Core Banking
Replacement Building
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
banking transformation
Core Banking Building Blocks
Building Blocks
Service Oriented
Core Banking
Architecture
Process
Rationalisation
Interfaces
Deployment
Strategy
Product
Rationalisation
Project
Organisation &
Programme
Management
Coexistence
Data
Conversion
Change
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?
90
• 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
approach most suitable for the
bank’s needs
• A critical decision for any core banking replacement is the choice
of deployment strategy. There are primarily two options: big bang
implementation or a phased rollout by cluster. For each approach, there
are a number of variations. But for the purpose of this document, we will
focus on the two broad options:
91
Big bang is quick but has no
margin for error
• Big Bang is a deployment strategy which assumes that all systems will
be deployed at the same time in one big bang. As a result, banks do not
need to worry about coexistence or the more complex rollout logistics
of a phased approach. The disadvantage of the big bang is that there
is little or no margin for error. If a large bank is considering big bang
deployment, it should conduct massive training and repeated conversion
rehearsals over some period of time. The transition planning also has to
ensure that all conversion logistics are in place, i.e. hardware, systems
software, network, etc. Analysing best practices, we have found that
conversion rehearsals should always include a month end. We see the
big bang option as the most risky approach, only worth considering for
small banks.
Phased approach has
manageable risk
• Phased Approach is the deployment of the new core banking solution by
branch or regional cluster. It is recommended that the phased deployment
is conducted as a “big bang” for each deployment cluster. This means
that, as in the big bang approach, the entire solution is deployed in one
go – but only for a manageable cluster and not for the entire enterprise.
The advantage of this approach is that banks receive the benefits of
the big bang for all deployment clusters while keeping risks within a
manageable level. For instance, if deployment problems occur, they can
be confined to the cluster and will not affect the entire enterprise. 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.
92
5.2 Service Oriented Architecture
Build the system around SOA
which would provide the bank
with business flexibility
• We believe it is essential that the bank has the right architecture to
suit its core banking needs. The architecture is important because it
will set the foundation for the future. Choosing an ageing and inflexible
architecture will lock the bank in the past before it even starts with the
deployment of its core banking solution. Service Oriented Architecture
(SOA) is a relatively new concept that has been gaining popularity lately.
While vendors often talk about it, many banks consider it just as a new
buzzword. The fact remains that this is a new technology which 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
93
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
attractions of SOA
1
The application front-end
is the owner of the
business processes
In addition there is a
Service
Oriented
Architecture
(SOA)
model are the major
1
service repository and a
service bus
3
2
Application
Front-end
Business
Service
Service
Repository
4
Service
Bus
2
Services provide business
functionality that the
application front-end and
other services can use
a
b
Contract
c
Implementation
Interface
3
The service repository
stores the service
contracts of the individual
services of an SOA
Business Logic
b1
Data
b2
A service consists of...
4
The service bus interconnects the application
front-end and the
services
a) a service contract that specifies the functionality, usage, and constraints for a client of the service
b) an implementation that provides business logic and data
c) a service interface that physically exposes the functionality
A client can be either an application front-end or another service
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)
94
Illustrative Core Banking Architecture
Multi-Channel
Core Banking System
Customer Information
Branch
Loans
Collateral Information
Common Services
Credit
Cards
etc.
Channel Integration
Internet
Deposits
General
Ledger
Reporting / Statement Interface
Call Centre
ATM
Bank System
etc.
External
Interfaces
Clearing
House
BahtNet
etc.
95
5.3 Interface Considerations
SOA and ESB together can
reduce the complexity of
interfaces
• Our research shows that interfaces are a key concern for any core
banking replacement project. Every major application in the bank is
interconnected, or interfaced with the core banking system, as illustrated
in the chart below. According to some experts, an enterprise service
bus (ESB) and an SOA together can help to reduce the number and
complexity of interfaces, enabling the bank to focus on its core business
rather than the maintenance of an IT infrastructure.
Old Core Banking System
Branch
Application
Online
Authorised
Signature
Audit and
Control
Call Centre
Online
Cash
Management
Online
Cheque
Batch
CIS
Online/
Batch
Credit Card
Online
Batch
Batch
Custodian
Old
Core Banking
System
Online
Human
Resources
Batch
Online
Agent Service
Financial
Planning
Core Banking
System
Batch
Data
Warehouse
Donation
Batch
Batch
Batch
Online
EAI
Batch
Online
Loan
Payment
Online
SWIFT
Online/
Batch
Trade Finance
Batch
BOND
Online
E-Channel
• Transition from the old core banking system to the new core banking
system can be conducted in three steps:
96
Transtition Phase
Step 2:
Phased migration to
new Core Banking
System and
coexisting with
Legacy
Step 1:
Implement switching
layer
Step 3:
All accounts
converted to new
Core Banking System
• The end result is a smooth transition from old to new core banking
system, as illustrated below:
New Core Banking System
Branch
Application
Online
Audit and
Control
Online
Online
Batch
CIS
Online/
Batch
Credit Card
Online
Batch
Batch
Custodian
New
Core Banking
System
Online
Batch
Data
Warehouse
Donation
Batch
Batch
W
S
Human
Resources
Cheque
Batch
Online
Agent Service
Financial
Planning
Core Banking
System
Batch
Batch
Online
Loan
Payment
ITC
H
EAI
M
Authorised
Signature
Cash
Management
Call Centre
ING ME
Online
SWIFT
S
NI
C HA
Online/
Batch
Trade Finance
Online
Batch
BOND
Online
E-Channel
97
5.4 Coexistence
Coexistence poses
considerable challenges
demanding complex and
strategic planning
• Our research indicates that as the bank replaces the system using
phased implementation, it often faces the critical issue of coexistence.
Coexistence is the strategy and process taken to operate two core
banking systems concurrently for a limited period of time. Coexistence
describes in detail which methods, such as switches, merges and manual
processes, are used to process transactions between the old and new
worlds.
• A critical question in core banking replacement is how the bank should
deal with coexistence issues, assuming that it chooses this deployment
option. Coexistence planning is a very complex activity. But contrary to
the common myths, it is clearly doable and it works.
Coexistence Environment Overview
Old World / Legacy
Core Banking System
Coexistence Infrastructure
Call
Centre
Systems
ATM
Old
Core Banking
System
New World / Next
Core Banking System
Other
Online
Interfaces
Coexistence
Switches /
Merge
New
Core Banking
System
Clearing
House
Unconverted Branches
Other
Batch
Interfaces
Converted Branches
• We have come across different methods of managing coexistence and
interfaces. Described below are types of interfaces that we believe are
the better ways of dealing with coexistence.
98
Coexistence Implications
What is Coexistence
how does the bank operate
while accounts are
progressively converted to the
new core banking system?
how will inter-branch
transactions be handled
during coexistence?
how will the call centre
service requests during
coexistence?
Other Online
Interfaces
ATM Transactions
how will ATM transactions
be processed during
coexistence?
Call Centres
Branches
how will other online
interfaces be processed
during coexistence?
Batch Interfaces
(Outward Clearing)
how will outgoing batch
during coexistence?
Batch Interfaces
(Inward Clearing)
how will incoming batch
during coexistence?
Other Implications
how will sweeping and
other features be
processed during
coexistence?
99
5.4.1 Branches
For intra-branch transactions,
business should make the
decision on coexistence
approach
• In most banks, the branches account for the bulk of customer-facing
transactions. A key question to be answered here is how the bank wants
to treat the different types of possible intra-branch transactions. As most
affect the customer and the bank’s relationship with him, we believe
that it is important to have business involved in all of these discussions
and let business make the final decision on how to proceed. After all,
business will know its customer better than IT does. There are a number
of options:
Branches During Coexistence
Customer has account in a
new branch and wants to
transact at an old branch
Customer has account in an
old branch and wants to
transact at a new branch
Old Branch
New Branch
Coexistence Options
Feature
Option 1
2-way Support
Option 2
1-way Support
Option 3
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.
100
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
101
• 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
102
• 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
103
• 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
System
h
Batc
Batch
Splitter
Switch
External
System
During rollout, the
files need to be split
to send the data to
the appropriate
system…
Old
Core Banking
System
104
• 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
Batc
New
Core Banking
System
Batch
Combiner
External
System
Old
Core Banking
System
During rollout, the
new system will also
generate this data
for converted
accounts …
A ‘Combiner’ will
therefore be needed
105
• Other types of transactions need to be analysed on a case-by-case
basis. Typically these transactions centre on inter-branch sweeping and
standing orders, as illustrated in the chart below:
Other Coexistence Implications
Inter-Branch
Sweeping
Standing Orders
Amend the systems to
pass the transactions out
Amend the systems to
pass the transactions out
Create an external system
for inter-branch sweeps
Create an external system
for inter-branch standing orders
Manual processes
Manual processes
Others
Each situation will have to
be judged on
Criticality
Volume
Complexity
A decision is then made on
the best solution available
106
5.5 Data Cleansing and Data
Conversion
Data cleansing should be a
separate project distinct from
the core banking project
• Our research shows that data cleansing and data conversion are of the
utmost concern for most banks around the world. We believe that data
cleansing should not be conducted as part of a core banking project.
In our opinion, data cleansing is an entirely separate project with its
own organisation structure and milestones. It should be an ongoing
operation (rather than a one-off project) at the bank and great care
should be taken to avoid creating dependencies between data cleansing
and the core banking project. Placing data cleansing objectives with
the data conversion team is tantamount to asking for unclean data to be
converted.
• Data should be cleaned either before or after it is converted, but not
during the conversion exercise, and not by the data conversion team.
This is important as cleansing of customer data cannot be resolved with
technology alone, but requires the hands-on involvement of the bank’s
customer-facing personnel. Note, however, that other types of data
transformation are required during the core banking data conversion
to accommodate differences in data format between the old and new
systems or to auto-set default values for new 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
executed in three stages
• Data conversion, on the other hand, is an important part of the core
banking replacement project. It can be executed in three stages, as
illustrated in the chart below:
107
Data Cleansing and Data Conversion
Data Conversion
Old
Core Banking
System
New
Core Banking
System
... what it takes :
Step 1: Data Mapping
Data
Data
Customers
Accounts
Standing Instructions
Transaction History
Etc…
Step 2: Data Conversion
Extracts
Step 3: Data Conversion
Loads
Customers
Accounts
Transaction History
Etc…
Data Cleansing
• Data mapping – Our research shows that banks start the data conversion
process with data mapping. This essentially entails mapping the oldworld 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”
Core Banking System
“New World”
Core Banking System
Product
Current Account
Data Mapping Considerations
Is there a corresponding product for each of
our existing products?
Current Account
Can we rationalise our products to fit the
supported products in the new CBS?
Attributes
Account No.
Account No.
Does the new system’s account number
structure match our existing structure?
Should our account number structure
continue to have meaning?
Current
Account
Acc
Branch
Code
Acc Product Code
When will we run out of account numbers?
What should be the length of the account
number? What are the implications for the
new system, cheques, passbooks, ATM
transaction records, etc. ?
Acc Sequence No.
Acc Check Digit
Domicile Branch Code
Domicile Branch Code
Account Open Date
Account Open Date
Interest Rate Method
Interest Rate Method
Limit
Limit
Special Field1
Is there a one-to-one mapping of fields for
this product (i.e. Current Accounts)?
Is there a one-to-one mapping of field values
(e.g. are our interest rate methods supported
by corresponding methods in the new CBS)?
How do we handle custom fields (e.g.
Special Field1)? Should we
customise the new CBS or rationalise the
requirement?
Is the source data “clean” and acceptable?
108
• 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
DATA
Customers
Accounts
Transaction History
Etc…
Extract Modules
Conversion Staging Area
Old
Core Banking
System
Conversion
Data
Extracted data ready for loading
Conversion data file layout as
required by new core banking
system
Conversion
Reports
Data
• 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.
109
Data Conversion Loads
"Old" World
"New" World
Step 3 : Data
Conversion Loads
DATA
Customers
Accounts
Transaction History
Etc…
Conversion
Data
Extracted data ready for loading
Conversion data file layout as
required by new core banking
system
Conversion
Reports
Data
Load Modules
Extract Modules
Conversion Staging Area
Old
Core Banking
System
New
Core Banking
System
DATA
Customers
Accounts
Transaction History
Etc…
Report Generator
Reports
Conversion
reconciliation
and verification.
110
5.6 Product Rationalisation
Data conversion can be
executed in three stages
• We have discovered that product rationalisation is also an important
element of successful replacement projects. Product rationalisation is
essentially the process of assessing the value of the bank’s current
product and service offerings, i.e. whether a product or service is still
competitive and profitable or should be deemed “sunset”. This is the
time to ask not only where the bank is with its current offerings but also
where it wants to be in the future. Banks often also check if an existing
product or service can be migrated to the new platform in a cost 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.
111
5.7 Process Rationalisation
Process rationalisation can
overhaul outdated processes
112
• Core banking replacements will impact most of the front- and back-end
users. Hence, process rationalisation provides the bank with a chance
to overhaul its fragmented and perhaps outdated business processes as
an explicit outcome of the core banking enabled transformation. It allows
discontinuation of legacy processes and elimination of paper-based or
semi-automated processes. It also provides an opportunity for process
re-engineering to utilise the new core banking solution to its fullest.
6
Critical Success Factors
and Best Practices
Organisation of the project and management of the change are
critical issues for projects of such a scale. We have 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
delineate the responsibilities
and accountabilities of project
decisions
• We believe that a project of the magnitude and scale of a core banking
replacement requires strong project organisation and programme
management. In addition, the project organisation should be adjusted
depending on the phase of the project.
Business Transformation Team Structure
Project Organisation
Steering Committee
Programme Director
PMO Support Team
QA
Core Banking Enabled
Core Banking Enabled
Business
Process
Organisation
& Change
Business Transformation
Team Process
Coordination & Decision
Benefit
Realisation
Transformation Technology
Others
Teller
Core Banking
Functional
Technical
Common Activities
Architecture &
Integration
Data
Migration
Deployment
Testing
New World
Cluster
Pilot
Source: Immacon SOBIT Research
• Our research has led us to a few best practices in programme organisation
which we discuss below. The overall responsibility for the project should
lie with the project steering committee. This committee should be chaired
by the CEO and it is important that he demonstrates commitment to the
project. Other members of the steering committee should include the
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.
114
• 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
Core Banking
System Project
Manager
Technical Support
Project Office
Stage 1
Core Banking
System Business
Team
Delta Analysis Team
Stage 1
Delta Analysis & Design
Interface Analysis and
Design Team
Significant Third
Party Resource
Involvement
Conversion &
Coexistence Design
Team
Product Realignment
Process Realignment
115
• 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
Build & Test
Core Banking
System Project
Manager
Technical Support
Project Office
Stage 2
System
Implementation
Team
Significant Third
Party Resource
Involvement
Interfaces Team
Testing Team
Training &
Procedures
Team
Customer
Application
Team
Online
Interfaces
Business
Testing Team
Train-theTrainers
Training Team
Deposits
Application
Team
Batch
Interfaces
Integration
Testing Team
User
Procedures
Team
Loans
Application
Team
Coexistence
Development
Team
Operations
Testing Team
Online
Application
Team
Accounting &
Other Apps
Team
Legacy Systems
Teams
Data
Conversion
Load Team
3rd Party
Interface
Systems Teams
Conversions
Data Extracts
Teams
Pilot Site
Selection Prep.
Go /No Go
Assessment (ext.
Accountants)
116
• The third stage of the project sees a move from the technical buildand-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
Pilot
Core Banking
System Project
Manager
Technical Support
Project Office
Stage 3
Significant Third
Party Resource
Involvement
Pilot Team
Data Conversion &
Coexistence Support
Team
Core Banking System
Pilot User Support
Team
Pilot User Training
Team
3rd Party Interface
System Fix Team
Legacy System Fix
Team
Conversion Data
Extracts Support
Teams
Core Banking System
Applications Fix
Teams
Interfaces Support
Team
117
6.2 Critical Success Factors and
Best Practices in System
Selection
Key Success Factors in Selection
Selection Process
Goals
Managerial and
financial
commitment
Set Business
Direction
Business decision
to change
Take Strategic
Decision
Long term
impact on the
organisation,
growth,
processes and
culture
Existing
system, size of
bank, business
goals
Establish
Functional
Requirement
Flexibility,
adaptability,
compatibility
and financial
impact
Required
system
architecture
and platform
Establish
Technical
Requirement
System
Selection
Software
platform, type of
solution and
hardware
Selection of a system requires
managerial and business
support from all sections and a
clear focus on business goals
• The impact of core banking system transformation would be visible over
the long term in the performance of the organisation. A bank replaces its
system once every 10-15 years (sometimes even longer), and thus it is
essential that the bank develops clear objectives and its expectations
are detailed to ensure suitability of the system and to avoid a mismatch
between deliverables and expectations. The bank should be clear
whether it needs to replace the core banking system, the front end, or
both. It must not be enamoured with “bells” and “whistles” as these only
represent the front end and not the real core banking system.
Ensure involvement of business
representatives and develop a
matrix for evaluation
• The rapid pace of change in the banking business makes it extremely
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
118
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
architecture should facilitate
growth plans
• We recommend that banks leave the old world behind and move to the new
system in entirety. While this poses significant transformation challenges,
it would ensure optimum returns as there would be no “legacy baggage”.
But the bank must ensure that the system functionality, platform and
technology are right for its needs and it would not be wise to just choose
the “best” in the market. The architectural components of the system
and its raw processing ability are critical. The technology should easily
integrate with existing systems within the bank, facilitate differentiation,
assist in quick decision-making, improve competitiveness through faster
product development and, at the same time, improve returns through
lower operational and maintenance costs.
• Further, the architecture of the selected system should facilitate
growth plans. There may be cases where the functional and technical
capabilities of a system make it scalable but not flexible, or vice versa. In
such a scenario, banks may just be shifting their systems from a smaller
box to a bigger box where growth may be constrained again within a
few years. This should be avoided at all costs. The architecture should
be component-based as this would allow for the possibility of making
future additions to the system. We highly recommend an SOA-based
system that can provide flexibility for future changes. Banks can select a
packaged system that has the ready processing capacity and customise
the front end to suit the user needs.
• Finally, it is important that bankers do not lose sight of business objectives
and get wrapped up in architectural discussions and process redesign
issues that are too broad or diffused to add value to the business. They
should aim for quick decision-making and system selection in order to
prevent opportunity costs from rising further.
119
6.3 Critical Success Factors and
Best Practices in Vendor
Selection
Success Factors in Vendor Selection
Project Stages
Evaluating service providers
Identify
vendors with
track record
and reputation
Track record and
technical ability of
the product to
meet the
functional
requirement
Evaluate
financial
strength and
viability
Ability to tide
over
downtrends and
sustain
technical
advancements
Evaluate
experience
with similar
projects
Ability to meet
the unique local
requirements
and yet provide
the requisite
quality
standards
Evaluate
commitment
to business &
technical
enhancement
Financial ability
and
commitment
towards long
term technical
advancement
and services
Evaluate postimplementation
support and
services
Reputation and
long term
commitment to
provide ongoing
support and
future
integrations
Suitability of IT partner for
unique requirements of the
project and its commitment to
provide long-term technical
support are crucial
• System selection and vendor selection go hand in hand. Vendors and
service providers can no longer be viewed as just IT suppliers. Instead,
they are partners in the long-term success of a bank. The selection, in
many cases, is based primarily on cost savings, which ironically may
prove to be a costly mistake in future. The basis of decisions should be
the vendor’s capabilities and not pricing.
Select the right mix of product
and services
• It is imperative that banks ensure the vendor provides the right mix of
product and services required to meet the objectives and ambitions of
the business and the unique requirements of the project. The relationship
between system provider and system integrator should also be evaluated
and their track record in managing projects as a team needs to be
analysed.
• Equally important is that the bank has to evaluate its own comfort level
with regard to the vendor’s reliability and suitability for the particular
project. If the bank has an existing system from the vendor, there could
be a distinct 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.
120
Select vendors that involve
local people in customisation
• We have seen projects of even leading international vendors fail despite
excellent track record and strong technical capability. The main cause was
lack of local knowledge and ability to cater to the unique conditions of the
banking environment in that country. Cost aside, the bank should select
those vendors that involve local people in the process of customisation
and localisation, and ensure that they provide international quality while
meeting the local standards. Vendors that have already customised a
product for a particular country are likely to be more suitable to undertake
future projects in that country.
• Finally, the bank should select a vendor that has the commitment and
ability to continually enhance the product so that future upgrading of the
system would be easier. The IT partner should be one with whom the
bank can maintain a long-term relationship, both through ongoing postimplementation technical services and through future products.
121
6.4 Best Practices for Vendors (for
Successful Implementation)
Key Success Factors for Implementation
Project Stages
Successful Implementation
Understand
unique
requirements,
expectation of
the bank
Banks should
develop strong
team to guide the
vendor
Involve local
people to meet
unique local
requirements
Develop
empathy with
business
environment
User training
to adopt new
processes in
work culture
Excellent
communication
skills to
motivate and
meet resistance
to change
Thorough
testing at
each stage.
Develop pilot
project
Develop pilot
projects to
ensure
expectation and
deliverables
match. User
acceptance
tests at all
levels
Ensure
seamless
integration and
timely
implementation
Timely data
cleaning,
migration and
integration with
existing system
with zero error
Provide long
term
partnership to
the bank
Postimplementation
support through
ongoing
services and
future upgrades
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
ownership for project within the
bank
• We believe the basic ingredient for success is the ability of the vendor
to understand the business requirements. Clarity of banks and vendors
on both the requirements from the new system and the requisite
deliverables would lessen the risk of expectation/deliverable mismatch
and help the vendors to customise and localise the system as per the
unique requirements of individual projects.
Develop empathy with working
environment
• Vendors should ensure that within the bank, there is strong business
ownership, management involvement and a business environment
conducive for implementing the project. There must be a common ground
for decision making, where the banks and service providers can interact
to find solutions for inevitable hiccups. The aim is to meet the objectives
and achieve timely completion coupled with high quality, but balanced
with the costs involved. It is important that the right mix of people within
the bank is involved in the process.
Begin user training even before
deployment of system
122
Redesign processes within the
bank for optimum returns
Conduct testing and user
acceptance tests at all levels
• Vendors need to ensure optimum utilisation of communication channels.
Besides having domain knowledge, the service provider has to develop
empathy with the working environment and culture to meet the unique
local requirements. Allocation of the right expertise is crucial. Equally
essential is that the vendor selects its partner carefully and chooses
one that has the requisite expertise. In addition, when there are multiple
vendors in a team, the accountabilities, responsibilities and decisionmaking 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 acrossthe-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.
123
7
Unique Core Banking
Replacement
Considerations
This section covers the unique business considerations, functional
requirements and key challenges faced by different types
of banks. Going further, we have also analysed the problems
and system demands from unique situations like mergers and
acquisitions.
Unique Core Banking Replacement Considerations
7.1 A large multinational bank
7.2 A small commercial bank
7.3 An Islamic bank
7.4 “Internet only” banks
7.5 Mergers and acquisitions of banks
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
in large multinational bank is
highly complex
126
• For most top-tier large banks, the key consideration for replacement
has been to overcome the limitations of their antiquated legacy system
and disparate systems with spaghetti structures caused by extensive
middleware and multi-application connectivity. Thus the banks essentially
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.
Banks need a scalable and
robust system to handle high
volumes
• Most off-the-shelf systems are not suitable for the volume and unique
requirements of a large multinational bank, and hence substantial
customisation of the packaged solution is necessary during
implementation. However, a better approach would be to customise the
front end rather than the core processing system. This would make it
imperative for the bank to either utilise the services of an experienced
system integrator (e.g. SBI) or undertake further development on existing
systems to meet its complex needs (as in the case of HSBC).
• The platform of choice for large banks should be mainframe, which has
proven its ability to meet scalability needs and handle large transaction
volumes. As most large banks have legacy systems that are based on
mainframes, this would make transition more feasible and lower the
switching costs.
• The requirements from a system should 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.
Vital requirement is seamless
connectivity across functions
and locations
• We believe that past experience with similar large projects and reliability
would be critical considerations in vendor selection. Long-term support
would be essential, whereas pricing is not likely to be a key issue.
• Many large banks have systems that were developed in-house. But often,
the people who developed these systems (or know the software codes)
127
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.
128
7.2 A Small Commercial Bank
A small commercial bank
Unique features
System requirements
• Less complexity and smaller
scale of operations
• Need agility and flexibility from
system
• Lack of trained IT manpower
• Capability to innovate and
differentiate products and
services
• Investment size and cost savings
are critical considerations
• Smaller geographic spread and
fewer number of branches –
faster implementation
• Outsourcing a feasible option
• Compete on basis of cost
effectiveness
• Need integrated and centralised
system
• Likely to need services for
customisation and localisation
Competitiveness through
flexibility and cost effectiveness
are considered essential for
growth
• A small bank with a modest asset base and localised operations has
its own unique business considerations for selecting a system vendor
and service provider. Most small banks see cost as a critical business
consideration and essentially require systems that have a low cost of
ownership, particularly in terms of operational and maintenance costs.
• To retain competitiveness, most banks need flexibility and agility from
their systems to be able to provide differentiated products and to roll
out products with speed. A customer-centric system that can help the
banks to focus on fee-based transactions and product innovations
to tap consumer demand is important. This can be achieved 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
aggressive approach by
adopting new-generation
technology and big bang
deployment
• While mainframes are proven technology across the globe, UNIX
may also be feasible for small banks as their scalability and volume
requirements are low. Due to manpower constraints, most banks do
not have the ability to develop the software internally and thus prefer
packaged solutions. There has been an increasing trend among smaller
banks to acquire integrated solutions to take advantage of end-to-end
129
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.
130
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
Islamic banks has forced
the banking sector to look
for systems that provide
compliance with Islamic law
• Over the last two decades, hundreds of Islamic banks have mushroomed
across the world to cater to the unique requirements of Islamic finance.
Islamic banks are common in the Middle East but have sprung up as
far away as London and the Philippines. Within the Asia Pacific region,
Malaysia and Indonesia are two countries that have shown rapid growth
in Islamic banking.
• The bedrock of Islamic banking is the principle of shared risk. Interest
payment is regarded as exploitation in Islam because depositors and
lenders make money without providing labour or sharing risks. Shariah
law requires profits to be shared and bans investment in certain industries
such as those related to alcohol and gambling. It also prohibits interest
payments and the handling of money as a commodity. Hence Islamic
banks pool deposits to invest in construction, commodities trading 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
to integrate core banking
features with Islamic principles
• This requires the system to have the ability to integrate basic core banking
features with strong Islamic banking functionality. A system that can offer
sophisticated and innovative Islamic products and services coupled with
operational 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
131
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.
132
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
flexibility for innovative products
is essential for “internet only”
banks
• “Internet only” banks, a relatively new concept, are specialised banks
that compete with brick-and-mortar banks (conventional banks) on the
basis of convenience, lack of locational constraint and lower costs. These
banks offer innovative products and services online round the clock and
seek to do it cost effectively. As they have lower fixed, operational 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.
133
• 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.
134
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
• Systems of pre-merger entities
are migrated onto one platform
• Data migration has high risks
• Time consuming
• May be followed by core banking
replacement after a few years
M&A requires system migration
or integration, either of which is
risky and challenging
Integration
• Linking the core banking systems
so that they effectively function as
one platform
• Difficult for two systems to coexist
• Time consuming and costs can be
high
• May be followed by core banking
replacement after a few years
• Mergers and acquisitions can be nightmares for IT professionals of the
banks involved as they are invariably followed by restructuring of the
core banking systems. This is largely because the duplicate systems
impede growth due to their high maintenance and operational costs.
Further, running two separate systems makes it 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.
135
• 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.
136
Country Trend Analyses
8
This section analyses the trends in core banking system replacement 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
• Most tier 1 and tier 2 banks have already
made decisions; some small banks likely to
replace their systems
• Has been quite an active market for core
banking in last 2-3 years
• Many banks have gone for centralised and
end-to-end solutions
• Leading vendors are Infosys, I-flex and
FNS(TCS)
• Banks have preferred local vendors due to
familiarity with local system, sophistication
of technology and cost effectiveness
•Fewer opportunities in future as market is
reaching saturation soon
Demand characteristics
• Data centralisation of public sector banks
and stiff competition have led to demand
for better customer service and product
enhancement
• More banks prefer open system and new
technology
• Most Indian banks prefer changing their
infrastructure from bottom up rather than
adding applications due to archaic structure
• Preference for local vendors
• Cost is not a major consideration
• Partial replacement in some banks likely to
be followed by purchase of application
software for remaining functions
Source: Asian Bank Research
After active spell in last 3-4
years, Indian core banking
market may be reaching
saturation soon
• India is a unique country from the core banking perspective. Till five
years back, most banks in the country were working on mere branch
automation and most state-owned banks did not even have a core
banking system owing to lack of infrastructure and network readiness to
provide a centralised system. New private-sector banks then came into
the market with a distinct technical advantage which led to substantial
customer attrition in state-owned banks.
• Competition within the banking sector of this country is rising as
foreign banks are becoming more aggressive, growing through both
acquisitions and expansion of operations. Aggressiveness of the private
banks has thus forced most state-owned banks to replace their core
banking systems with advanced, centralised systems that are not only
competitive but also cost effective. In the last two years, almost 30% of
the country’s banks (most of these being state-owned) have taken the
decision to replace their core systems. Because of this, almost 50% of
deals in Asia during this period have come from India.
• Prominent deals in the last few years include State Bank of India with
TCS, Canara Bank with I-flex (for a $49 million project), Central Bank
of India with TCS (for a project costing 150 crore rupees or about $33
138
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.
139
8.2 China
IT Infrastructure development of Chinese banks
Branch
Computerisation
Branch
Networking
Market Trends
• Increasing number of core banking deals;
leading vendors include FNS, Misys,
Temenos and System Access
• Banks treading cautiously in selection of
systems and vendors following deal failures
• Tier1 and Tier 2 banks looking for
international standards in new systems but
need systems to provide for local practices
• Many Tier 1 banks using in-house systems
and increasingly considering new
technology
• Many smaller banks still prefer local
vendors
Data
Centralisation
Integrated Core
Banking Systems
Demand Characteristics
• Increasing foreign competition as foreign
banks gain full access in 2007
• Need to keep pace with rapid growth and
market demand
• Traditional accounting system being challenged by new business and foreign banks
• Need product that meets the unique local
requirements, e.g. language, business
environment
• Higher costs and implementation risk due
to unique requirements; needs involvement
of local people
• Lack of prominent local vendors
Source: Asian Bank Research
Market-driven and regulatory
pressures are forcing many
banks to consider replacing
their systems
• Regulatory and market-driven competitive pressures are forcing banks in
China to consider replacing their core banking systems. Market pressure
comes from the arrival of foreign stake-holding in banks and customers
becoming more demanding on quality of services and products. The
robust growth of the Chinese economy has attracted financial institutions
from across the globe.
• On the regulatory front, under China’s WTO commitments, foreign banks
will gain full access to its banking sector in 2007. In addition, the country
is gearing up to host the 2008 Olympics. With this background, most
banks in the country are awakening to the need for technically advanced
and competitive systems.
• We believe all Chinese banks are now somewhere between branch
computerisation and integrated core banking in terms of IT infrastructure.
Only a few leading banks like Bank of Shanghai, ICBC, China Minsheng
140
Only a few banks have
upgraded to an integrated core
banking system
Bank, China Development Bank and CITIC Bank have upgraded to an
integrated core banking system.
• There is increasing interest in core banking system replacement among
banks, with many medium and small banks mulling over the decision and
some evaluating vendors. We have seen a gradual growth in number of
deals in the last couple of years and expect the trend to continue and
probably accelerate as competition intensifies. The platform of choice
continues to be mainframe, which is more appropriate considering the
large branch network and high transaction volumes.
Smaller banks continue to
prefer local vendors
• We have discovered that the uptake of core banking systems has been
slow in the country as a whole because the banks have been very
cautious. Additionally, we have observed that tier 1 banks (and now
increasingly tier 2 banks) prefer international vendors for the quality of
their solutions and services, whereas many smaller banks continue to
prefer local vendors due to the lower cost and higher level of trust and
reliability. There continues to be a certain level of doubt in the market
about the ability of foreign vendors to meet the local requirements of
Chinese banks. Deal implementation problems have also been reported
in cases like CITIC Bank, whose replacement project was done by
Fiserv.
• Many banks in China are looking at point solutions in, for example, trade
finance and treasury rather than at core banking system replacement.
We believe this reflects their short-term objective of attracting foreign
funds.
China presents a good
opportunity for those who have
technical capability and domain
knowledge to meet the unique
requirements of banks
• Most banks in China have unique requirements such as ability to deliver
in Mandarin and capability to customise and localise the solution to
suit their business conditions. For this reason, most vendors that are
providing solutions to Chinese banks are setting up centres in China and
employing local people.
• Recent prominent deals include China Minsheng Bank by SAP, which
also marks the entry of the global vendor into this region, Hua Xia Bank
by TCS, and ICBC Beijing and Bank of Shanghai by Temenos.
141
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
Banks in Japan are struggling
with rising maintenance
cost and scarcity of trained
manpower
• The level of technical sophistication among Japanese banks is one of
the highest in Asia with most banks having basic integrated CRM. Japan
has traditionally had largely mainframe-based systems, most of which
are proprietary systems developed in-house. Reliance on these stable
and robust systems has been widely accepted in the country and thus the
banks have been relatively slow in patronising the UNIX technology.
• However the banks are increasingly acknowledging the need to reduce the
high maintenance cost of these systems as the manpower for managing
them is dwindling. In Japan, this is known as the “2007 problem” as that
is the year when Cobol-trained manpower starts retiring. Another factor
that is likely to move the market is the increasing foreign share in the
Japanese banking sector.
• Various mergers in the Japanese banking sector have also led to complex
142
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
towards new-generation
technology among Korean
banks
Taiwan
Taiwan offers a good
opportunity to IT companies
with its increasing shift towards
open-end technology
• We believe that technical advancement among banks in Korea has
reached integrated core banking and robust middleware. Till a few years
back, most banks in Korea used mainframe-based legacy systems. But
in the last few years, there has been an increasing shift towards UNIXbased 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 is one of the few countries where there was a sudden surge
of activity in 2005, with four banks going for core banking deals as
compared with 2004 when there were none. We believe that most banks
still lack the 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
143
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.
144
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
market where banks replace
ageing systems to maintain
competitiveness
• Banks in developing South East Asian countries like Thailand, Malaysia
and the Philippines have an existing base of first-generation infrastructure.
However this was purchased 15-20 years back. Hence, not only is it
outdated but it has also reached a stage where managing and upgrading
it are extremely complex tasks. The key requirement for these banks is
thus to have a suitable architecture that is technically advanced to give
them a competitive boost as well as scalability.
• The motivation for change varies. But change is happening. According
to one leading vendor, “South East Asian countries such as Malaysia
and Indonesia are cyclical markets. People go out and replace system
145
Many Malaysian banks look for
capability to adapt to Islamic
banking
about every 15 years. They are [returning] to that; it is time to look and
replace again. There is no economic pressure; it is just retirement and
renewal strategy.”
• In Malaysia, in the last three years, we have seen many small and
medium banks coming to the market to replace their systems. Many of
them have chosen vendors that can provide them with Islamic banking
capability. For this reason, local vendors such as Microlink and Silverlake
are popular in the country. We understand that the leading bank of
Malaysia, Maybank, is also in the process of evaluating vendors for
changing its core banking system. Given the small size of the country’s
banking sector, the change is noticeable. The aim of the banks is to have
integrated core banking systems.
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.
Many banks in Indonesia
continue to operate on highcost legacy systems
• We have seen very few deals from this country lately. The only prominent
one in recent times is DBS Bank – in 2005, the bank appointed Infosys
to provide an integrated system for its domestic retail operations.
• Technical advancement among smaller banks in Indonesia leaves much
to be desired, with some of them still working on branch computerisation.
Some technically advanced banks have set up a centralised data system.
We believe that many smaller banks in Indonesia continue to operate on
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.
146
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
148
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.
149
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 = Fidelity Sanchez
A = Fiserv
U = TCS Bancs
U = I-flex
U = Infosys
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
150
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.
151
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 wellimplemented 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
commitment at all times
• To ensure that the project has management commitment at all times,
there should be adequate business ownership and decision making
should involve people from business functions. We believe that strong
project sponsorship from top management is critical for its success.
Viewing the project as just an IT project would be a recipe for failure.
The bank should also develop strong internal teams to communicate
and coordinate with the service providers to ensure deliverables match
the business objectives.
Effective communication
is essential for change
management
• There is bound to be resistance to change and employee dissatisfaction,
which can only be countered through effective communication and
154
C o nclus io n
developing the right business environment. Internal teams should be
developed to conduct training and overcome employee resistance.
Process restructuring and
product rationalisation should
accompany the process
• For the change to yield optimum returns, it should be adopted at all
levels within the organisation. The bank should shift from old world to
new world in entirety. Product rationalisation and process restructuring
would facilitate optimal utilisation of the new system and thus should
accompany this transition. Failure to do so would lead to old processes
being tied to the new system and eventually a mismatch between
expectations and deliverables.
155
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
relationship
• For long-term success, it is essential that service providers see each
project as a long-term relationship. Besides maintaining high technical
standards, they need a track record of successful implementation. Every
project has its unique characteristics and requirements which need to be
addressed with utmost diligence.
Employ right people with
domain knowledge
• Having the right people with domain and business knowledge to suit
the local requirements of individual projects is essential for successful
implementation. An army of men cannot replace a few critical people.
Needless to say, the technical ability and track record of the vendor
are most critical in the selection process. Service providers must invest
continually in technical advancements. Equally important is catering to
the local conditions while providing international quality in the product
and services.
Ensure deliverables and
expectations match through
effective communication
• Ensuring that deliverables are in line with the expectations of the bank
requires clear communication at all levels. This would involve user
training and the challenging task of managing process and work-culture
change within the bank.
• There should be fool-proof testing at each step in addition to other
strategies for risk minimisation. Successful implementation of each
project is a step in building the market presence and reputation of the
service provider.
156
A1
Appendix I
Case Studies
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
project. Strong internal teams
Highly complex task with almost 8,000
branches
Almost non-existent previous core banking
system, easing integration issues
Implementation time-consuming due to
wide reach
Vendor has previous experience in country
and strong alliance with system integrator
Large human resource requirement for
in-house implementation
System Integrator is familiar with unique
business requirements in India
Existing independent branch system
Opportunities
Core banking replacement project
extended to 4 associated banks
Threats
Difficult to change processes and work
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
of customer and frees resources for better
service
10 million transactions per day. Scale of
data migration huge with zero margin for
error
Largest commercial bank of
India found it necessary to
purchase new system to face
competition and reduce attrition
rate
• State Bank of India (SBI) is the largest commercial bank of India with
8,000 branches across India and a global presence in 20 countries. This
two-century-old organisation has not only a wide spread but also a deep
reach into the interiors of the country. Till a few years back, it was working
on basic branch automation and a rudimentary legacy system. However,
competitive pressures from private sector banks and the opening up of
the economy made it necessary for the bank to purchase technicallyadvanced 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
158
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
Conceptualised
with KPMG as
consultant
Selection
process.
Preparing RFP
took 6 months
Implementation
process begins
at pilot
branches
200 branches
migrated
2000
2002
2003
2004
3,000 branches
(50% bank's
business)
migrated
85% of Business
migrated to new
system
Implementation
completed
April
2006
August
2006
April
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.
159
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
implementation process
• Owing to the size of the organisation, the customisation of software and
the user training and training for implementation were, in that order, the
two most 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
160
• 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-toincome 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.
161
Case S tu d i e s
A1.2 Union Bank of Philippines
SWOT Analysis
Strengths
Weaknesses
Relatively small bank with 111 branches,
making replacement less complex
Data migration from multiple existing
systems and integration was complex
Willingness and adaptability to change
from mainframe legacy to new technology
Data cleanup was difficult as Finacle
required some parameters which old
system did not have
Willingness to take risks to improve
competitiveness
Opportunities
Centralised the back-office operations with
the new system
Lack of in-house IT manpower. Cost also
an issue
Threats
Shifting from legacy to open system
required change in processes and
business culture
Growing economy. Acquisition of new
customers and markets possible through
differentiation of products and services
New system required extensive user
training and acceptance at all levels
Availability of multiple vendors for open
technology made choice easier
Big bang approach has higher risks. Tried
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.
Cost a critical consideration
162
• 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
shifting to a newer technology platform in 2002.
Ca s e S tud ie s
The Timeline of the Transformation Project
Explores
possibility of
shifting from
mainframe to
open platform
2002
Requests for
proposal
from vendors
Selection
process
completed.
Finalises Infosys
Implementation
begins with user
training
Implementation
is completed
1 Qtr
2003
4 Qtr
2003
April
2004
April
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 longterm 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
deployment process
• Implementation took approximately one year and the system went
live in April 2005. The implementation posed many challenges such
as localisation and customisation to unique business conditions of the
Philippines. In addition, data stored in multiple mainframe-based systems
had to be cleaned, migrated and consolidated. Some of the items that
Finacle needed were not found in the old system, making the task more
difficult.
163
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
164
A2
Appendix II
An Average Request for
Proposal
An average RFP runs into 70-80 pages, with the bank requiring
vendors to submit a whole range of information which would
assist the bank in evaluating the suitability of the system for its
requirements. While some in-depth information is essential to
analyse the product and the vendor, we believe that unnecessary
information simply increases the complexity of the process. Banks
often forget that somebody with the right breath and depth of
knowledge needs to read and analyse all the responses to an RFI
or RFP. For a vendor providing this extent of information, it usually
becomes an unwarranted exercise. For this reason, we believe
that banks should ask for only relevant detailed information. Indepth 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
166
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
167
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
168

Roadmap to Successful Core Banking System Replacement

Transcription

Similar documents

Time to go banking? The electric is off. The phones are dead. The

carta de cliente en ingles

Company Fact Sheet

- Aftab Communication Group

the new website is coming online oct 5, 2015

here - Northeastern NY PGA

Banking Sector

our brochure. - Arroyo SECO Network of Time Banks

Haber Asobancaria.ppt [Read-Only]

Please tag my deposit account to my new card.