10 steps for an effective core banking system selection

Core Banking Systems are the backbone of products and services that Banks offer. With technology becoming a value differentiator, a wrong system selection may cost tremendous opportunity losses. While there are multiple vendors offering off-the-shelf packages, each one of them claiming they have a long list of implementations across the globe, one needs to be careful that the solution fits the Bank’s requirement, and this is not always easy.

How does one select the best-fit solution for a Bank in the most effective manner? How does one ensure that the selection process is made objective, transparent and focused? Cedar has conducted several Core Banking (and other ERP solutions as well) Selection and Implementation exercises in the region.

Based on our earlier experience, we present 10 steps for effective selection of Core Banking Systems

1. DEFINE BUSINESS NEEDS – AND HAVE THEM OWNED
20% of IT projects reportedly fail to achieve corporate objectives, wasting $500 billion worldwide. It is critical for Banks to comprehend their business requirements – both present and future, be it customer demands on products and services, or compliance requirements for business operations. Business Strategy determines the imperatives for IT infrastructure. For e.g. the IT Requirements for an Investment Bank could be very different from that of a Retail Bank, or one that aspires to be.

Ensure that the requirements are crafted in detail. Requirements could be classified as ‘data’ requirements (e.g. Customer information) or ‘processing’ requirements (e.g. Interest Accrual). It is also important to list down all reporting requirements, and also classify them with their relevant utility- regulatory reporting, MIS and Operational reports.

Requirements should also be defined in terms of technical parameters and vendor related parameters. Defining all the requirements in detail is the foundation of a good selection process. It is also important to have this done by the business users, to ensure that this is ‘owned’ by the business team.

2.PRIORITIZE REQUIREMENTS – FIRST THINGS FIRST
Not all requirements are equally important, some are more critical and need to be prioritized:

  • Domain level: Some business domains are more critical than others. For instance, Islamic Banking would assume a higher priority for Banks that plan to offer Islamic products
  • Unit level: Within a business area, some requirements assume higher criticality than others. For e.g. Capturing a customer’s name, age and address is more critical than his/ her family details. It is important to classify requirements by their priority, in order to differentiate solutions that meet more of ‘critical requirements’ from those that cater just the ‘nice to have’. This also ensures that the final ranking of vendors is on the basis of a Bank’s defined criticality rating, not purely on the overall conformance of vendors

3. DETERMINE SOURCING MODEL – WHAT SUITS YOU BEST?
IT Infrastructure is more than just the Core Banking software. It involves the selection of multiple ancillary applications (e.g. Branch automation) and also other investments in hardware, networking and third-party software.

There are two sourcing models:

  • Prime Vendor Model: Identify a one-stop-shop vendor, for a ‘turnkey’ assignment. The vendor is responsible for sourcing, integration, implementation and providing support for all necessary components. The advantage of this model is having a single point of contact, thereby minimizing effort within the Bank. Yet, this tends to be relatively rigid and marginally expensive.
  • Best of Breed Model: Determine applications / IT components that best suit individual requirements. Choose Best of Breed. This has clear cost-benefit advantage over the Prime Vendor model, yet exposes to a potential risk of “integration cracks”, where diagnosing issues and identifying “whose fault was it” becomes the Bank’s responsibility.

4. DEFINE EVALUATION CRITERIA – UPFRONT
Transparency of the evaluation process depends on defining the criteria upfront. When these criteria are not defined and frozen, there is every chance of being carried away by certain good features of a system or on the contrary, a few limitations overshadowing other features.

Decide upfront on weights to be attached for functional, technical, support and implementation parameters, a chronology of evaluation and scoring methodology. It is also important to ensure that the approach to be adopted during the evaluation, and any other selection criteria to be considered is decided upfront

5. MANAGE RFP PROCESS – BE OBJECTIVE, TRANSPARENT AND FOCUSED
Simple as it may sound, this can be a really tough balancing act, between the degree of detail one needs to get into for clarifying vendor queries, and the time window available for issuing of RFP, and receipt of their responses. The key factor here would be to ensure that information is provided to all vendors, thereby enabling that the process is objective and transparent.

6. EVALUATE SOLUTIONS – FOR WHAT ‘YOU WANT’
Banks get to review demonstrations once a decade whereas vendors make them for a living. Evaluating solutions for “what you want” and not what the vendors would like to show-case is the key to success. In addition to this there are challenges to be met regarding paucity of time, resources and the need for adherence to scoring process. It is impractical for anyone to remember a marathon of demonstrations.

The scoring of vendors should be immediate and consistent. The key aspect to be remembered is that 23% of IT projects do not meet business expectations, due to lack of business-IT alignment. It is therefore important for Business users to evaluate and score.

One should also be careful not to set the goal-post of the second vendor on the basis of what one saw in the first vendor’s presentation! In other words, the evaluation should be consistently based on what is documented in the requirements specification document on ‘absolute terms’, and not on ‘relative terms’. This is critical to ensure that the overall ranking is fair and objective.

7. REFERENCE FEEDBACK – WHOM TO ASK, AND WHAT?
Unless conducted diligently, this could turn out to be a ‘glorified exhibition’. Reference feedback is critical to make qualitative judgment on vendors track record of implementation and support. The important factor is on deciding “whom” to get this feedback from. It has to be another

Bank that is similar to yours in terms of size, operations and services. The other critical element is in determining “what to ask”. Banks stumble upon very interesting revelations during reference checks. What is the point in selecting the “seemingly” most sophisticated solution, whose existing customers reveal otherwise!

8. DEFINE CONTRACTUAL TERMS – IN DETAIL
As they say, devil is in the detail! Care needs to be taken to ensure that all that is required to be committed by the vendor – in terms of resources, deliverables, timeframe, costs, dependencies, etc. are clearly articulated. The success of implementation is directly proportional to the clarity and detail of the vendor agreement.

One also has to ensure here that the contractual terms are inclusive of all necessary documentation that refer to the commitment made by the vendor throughout the evaluation period. This helps in minimizing the conflicts that are almost likely to occur, due to difference in understanding of the user team during evaluation and subsequently, during implementation.

9. FINANCIAL TERMS – READ BETWEEN THE LINES
Measuring “Total Cost of Ownership (TCO)” and getting to compare vendors on “apple-to-apple” terms is indispensable. No negotiation is complete, unless the complete cost of implementation including “hidden costs” and “assumed costs” such as internal resources requirement are compiled.

Cost structures should not be just seen from the software license and implementation point of view. Investments in hardware, networking, third party software, Database, Operating Systems, and additional investment that might be required in data cleansing and migration, training, should all be considered, before arriving at the TCO. Mapping on & off-site activities and linking the payment terms to clearly identified deliverables is also imperative

10. START YOUR PROJECT – WITH HALF THE JOB DONE!
As can be seen in the enclosed figure, timely delivery of the project is dependent on conformance to ‘critical path’. One wrong step either in prioritization or selection process can lead to project overrun On the other hand if you have done the above homework right, then it is half the job done! One can then be confident that the vendor is the “bestfit” for the Bank and also be assured that implementation terms are tightly defined. Execution of large IT projects demand senior management involvement and enormous commitment, and the efforts invested will be rewarded in the long run