BANKING INFORMATION SYSTEMS
LECTURE 9
CBS Solutions History
Recent Developments in Packaged
Solutions
• The core banking systems area is becoming
more mature with packaged solutions
increasingly attaining a functional richness
that was previously available only from inhouse legacy solutions.
• They are also aFaining a technical and
organiza<onal level that meets the business
expecta<ons in terms of agility, <me to
market and opera<onal support.
Recent Developments - Functionality
• There hasn’t been any fundamental change
in the functionality required from core
banking systems.
• This means that many core banking system
vendors have been able to bridge the
functionality gap between them and the
leading platforms.
Recent Developments - Functionality
• Some vendors have been able to improve the
volume-processing capabilities of their
functionally broader or more advanced systems.
• As a result, advanced functionality that was
previously limited to private banking clientele,
for example, is now available in core banking
systems that are able to handle the volumes
commonly arising in the mass retail banking
market.
Recent Developments - Technology
• There has been a move away from
dependencies on hardware platforms and
operating systems.
• The vendor offerings have access to a larger
marketplace.
• This has given banks access to a much larger
set of vendors and solutions.
Recent Developments - Technology
• Banks can operate core banking systems on
their platform of preference.
• Some banks prefer to stay on their wellembedded and reliable mainframe
infrastructure.
• Others move to highly scalable commodity
platforms, freeing them from a lock-in to an
increasingly small set of expensive mainframe
specialists.
Recent Developments - Messaging,
Service Orientation, and Architecture
• The expectations for rapid time to market for
products and the corresponding operational
support are quickly outstripping the capacity of
development organizations to facilitate change.
• This is leading to major developments in the
core banking area, especially messaging, service
orientation and architecture.
• Messaging middleware has become a de facto
standard.
Recent Developments - Messaging,
Service Orientation, and Architecture
• Business process modeling and orchestra<on is
on the rise. All this will give banks a great deal of
freedom.
• A bank can buy the services that are available on
the market from vendors, service-enable
existing legacy systems or create its own
services in areas where it feels this gives the
bank an advantage in the market.
• And it can outsource when it feels that a service
is not its core competence.
Market Future
• In the past, there were a large number of
specialized solutions in the market.
• Some were strong in account handling,
others strong in wholesale or retail lending
and finally there were separate financial
accounting solutions.
• All these packages had their own, proprietary
architectural footprints.
Market Future
• Nowadays there seems to be a move towards
alignment with the architecture stacks and
frameworks of the ERP giants SAP and Oracle in this
market.
• This should deliver the additional benefits promised
in some of the initiatives of these ERP giants:
-
Embedded business intelligence
Integrated customer relationship management
Integrated financial accounting and reporting
Integrated risk management
Regulatory compliance
Fraud detection
Package Based Solutions
• The four main phases are:
Make or Buy
Selec<on
Implementa<on
Opera<on
Make or Buy
Selec<on
Implementa<on
Opera<on
Phase 1: Make or Buy
• A major consideration for banks with a demand
for system replacement is whether to build it inhouse or buy an off-the-shelf package.
• Most large banks have until recently preferred
the in- house route, on the basis that core
banking systems are responsible for the most
critical tasks of bank operations and require
complete and ultimate control by the bank.
• Therefore, they did not want to rely on vendor
solutions for managing accounts and processing
transactions.
Core Banking Systems Options
1. Do nothing but continue the normal maintenance on
the current system(s).
- For the old legacy systems this means maintenance costs and
risks will increase significantly as <me passes, so another
decision will normally have to be made in the next few years.
2. Develop a new system in-house.
- Although cost and risk may well rule this out, this is still the
biggest competitor, mostly because of the influence of the IT
department, and from the end-user perspective the number
of changes will be limited.
- If this alternative is chosen, risks can be mitigated by opting
for approaches based on service-oriented architecture or
model-driven architecture.
Core Banking Systems Options
3. Obtain a packaged solution.
- The challenge of this option is to find a packaged solution
that is suitably scalable and that will integrate into the bank’s
technical environment.
- Plug-and-play packaged solutions provide flexibility in
product development and deployment and enable lower cost
development through buying commoditized development
services from third-party suppliers.
- Changes in the current processes are unavoidable in order to
benefit from the strengths of a packaged solution.
- Choosing a packaged solution makes it possible to take
advantage of functionalities developed for other banks. This
makes it possible to benefit from these functionalities within
short timeframes.
Core Banking Systems Options
4. Outsource the service.
- The challenges of this option are to integrate
with and manage such a service.
- Outsourcing can offer ways to defray capital
costs and reduce risk.
- Outsourcing can be based on the company’s
own solution or a (new) package.
- The size of the bank is likely to influence which
op<on is preferable.
Phase 2: Selection
• Selecting the right system can make an
enormous difference in terms of market
offerings and process efficiency.
• The package selection method is used to select a
software package that best matches the
business needs of the client.
• The method supports and objectifies decision
making with respect to soft ware selection and
consists of seven streams and five phases.
Make or Buy
Selec<on
Implementa<on
Opera<on
Selection Methodology
Selection Methodology
• The starting point of the method is a business
requirement to automate a business
functionality by using a standard soft ware
package.
• Standard software is defined as a software
package that is supplied by a software vendor
and has 80 percent of the required functionality
out of the box.
• The method can be used to select one or a
combination of software packages.
Selection Methodology
• The selection method is used to devise
objective criteria so that the decision process
is rationalized.
• A properly executed package selection can
save a lot of time during implementation of
the package.
Selection Methodology
1. Start Up
The purpose of the start-up effort is to ensure
that sufficient resources are available to the
project, so that a clear plan with deadlines is in
place, the members of the project team are
aware of their responsibilities, and that there is
sound management buy- in to the project.
Selection Methodology
2. Focus and Direct
• Scopes the package selection project, answering
the questions as to why the business will start
the project, what goals the business will again,
what approach will be used by the project to
again the goals and what the limits of opera<on
of the project are.
• The focus is business-oriented.
Selection Methodology
3. Define the Short List
• In this phase the project team tries to deliver a
shortlist of three to five packages which most closely
match the current and future requirements specified
by the organization.
• After a long list of packages has been drawn up a
Request for Information (RFI) is sent to these vendors.
• Based on the answers to the RFI, a shortlist is drawn
up which will serve as the basis for the remainder of
the selection process.
Selection Methodology
4. Evaluate
• This phase provides the package evaluation process.
• During this package selection phase, the project team
will conduct a thorough review and analysis of several
potential short-listed software tools which meet the
client’s business requirements and enable the desired
business processes.
• This phase ends with one preferred potential software tool which meets the client’s business
requirements.
Selection Methodology
5. Validate
•
In the validate phase, the package solution will be tested in full practice.
•
The provider will have to install the system in a client’s test environment.
The reason for doing this is to eliminate the final uncertainties.
•
The validate phase is included for the checking of all functions. To start
this phase, the client signs a letter of intent. In this letter of intent he
declares that he will purchase the package subject to a positive
validation in this phase.
•
This validation phase is optional. In most situations, all the information
gathered in combination with a short proof of concept in the evaluation
phase will be sufficient to reach a decision.
Selection Methodology
6. Confirm and Finalize the Preferred Solution
• The objective of this phase is to get the final
sign-off of the package selection project.
• With this sign-off the client agrees to the
solution as advised by the project team.
Integrated vs. Best of Breed
• An important aspect is the choice of an
integrated system or a ‘best of breed’
infrastructure.
• Smaller institutions will often have a preference
for integrated systems.
• A well-chosen system provides all the necessary
functionality, causes not too much trouble with
interfacing and innovation, and is supported by
the vendor.
Integrated vs. Best of Breed
• The selection of a core banking system is a strategic
decision with long-term implications.
• The future business vision needs to be established in
order to determine what business setting the new
banking system will have to support in the future.
• It is essential to select a system that not only supports
the current situation, but allows the organization to
respond to future market demands and change its
value proposition and customer experience
accordingly.
Integrated vs. Best of Breed
• Large and sophisticated banks, however, will
opt for a ‘best of breed’ infrastructure.
• No single system totally covers their
requirements, so they have to choose specific
software components for specific
func<onali<es.
Selection Criteria
• System selection does not mean choosing a
system with the most extensive functionality.
• It is a dynamic process in which different
selection criteria must be matched with existing
and future business processes and system
architectures.
• There should be a match between the business
processes, the system and the organization.
Selection Criteria
• The system selection process must be driven
primarily from a business perspective, rather
than being treated as a choice between
change and improvement of the current
state.
• Any emotional bias towards an existing
solution will introduce hidden variables that
influence the decision.
Selection Criteria
Vendor
Support and Services
Implementa<on and Migra<on
Func<onal Aspects
Technical Aspects
Business Value
Security
Selection Criteria: Vendor
• Selecting a core banking solution should not be a
tactical, point-driven, decision making effort.
• The viability of a vendor is a crucial element in the
search for a replacement system.
1.
2.
3.
4.
5.
6.
7.
Analyze a vendor’s viability financially.
Scrutinizing technical competence
Vendor’s development capability
Quality of support
Marketing and sales reach
Alliances and partnerships
Management performance.
Selection Criteria: Support and
Services
• Having a good understanding of the support
and services a vendor provides during the
implementation project and once the
solution is in production.
- What is the release and upgrade strategy?
- How are new requirements incorporated in the
solution?
- What types of consultants are available during
the implementation project?
Selection Criteria: Implementation
and Migration
• The implementation practice of the vendor.
• Failure to perform due diligence regarding
vendor project management capabilities has
the potential to drive implementation costs
exponentially and dispirit bank staff.
• It is vital to talk with a vendor’s customers to
gain ‘real world’ experiences.
Selection Criteria: Implementation
and Migration
• Vendors will have their targeted list of
references for use in the sales cycle.
• It is important to talk with banks that have
similar profiles - how they use the system and
matching scale - to gain a more balanced
perspective.
• However, be aware that the banks on these lists
often receive preferential treatment from the
vendor.
Selection Criteria: Functional Aspects
• Functionality is the most important criterion
in the system selection process.
• When evaluating a system’s functionality in
relation to the needs of the bank’s business,
it is imperative to consider not only the
current needs and functionality, but also
future needs, as well as the vendor’s policy
towards upgrades, changes, and additions.
Selection Criteria: Technical Aspects
• The organization’s existing technical
infrastructure and capabilities limit the
choices.
• Adding new components to an existing
technical architecture can substantially
influence operational and maintenance costs.
Selection Criteria: Business Value
• Return on investment (ROI) is an important
criterion, but does not solely define the true
value of IT investments.
• A more practical measure is the business
value of IT that takes ROI into consideration
as well as other important factors, such as
strategic alignment, architecture, risk, and
business process impact.
Selection Criteria: Security
• The assessment of a solution in terms of its fit
with the bank’s internal security standards helps
to prevent a lot of discussion during the
implementation project.
• By involving the departments responsible for
the security aspects, any gaps can be properly
identified.
• These gaps can either be filled by the vendor in
its next release, or resolved by specific activities
during the implementation project.