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 in-house 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 well-embedded 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 in-house 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 soft-ware 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.   Analyze a vendor’s viability financially. 2.   Scrutinizing technical competence 3.   Vendor’s development capability 4.   Quality of support 5.   Marketing and sales reach 6.   Alliances and partnerships 7.   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.