Procurement dos and don’ts for core banking systems

This post is written by Malith Gunasekara, SBI Lead IT Advisor. 

One of the main pillars in implementing an alternative delivery channels project is the backend core banking system (CBS), which provides the necessary “rails” to support front end systems such as branchless banking, ATM systems, Internet banking and other delivery channels, as well as integration to other business and operational specific software such as treasury management, leasing, anti money laundering, credit scoring, data warehousing and mining to name a few.

Photo credit: Office of the US Trade Representative

Without a stable, time-tested, scalable and secured CBS that complies with international technical standards, implementation of ADC will pose challenges and risks that may result in failure.  Procurement of the base, the CBS is vital and is mission critical for any financial institution as it has the ability to “make or break” that institution.

The current statistics show that most financial institutions have changed their financial software or CBS more than once in 7-10 years. The reasons are many but most end up with unsatisfactory results due to the process and methodology adopted during the procurement process.

The first step in the procurement process is to review the FI’s business plan. In the absence of a plan, the management should define their business objectives for the next 3-5 years – and it is best to define these at a workshop where all participants have an opportunity to contribute. Most procurement processes have been carried out without agreement or identification of business objectives, which resulted in IT systems not meeting user requirements and being obsolete. These are costly mistakes amounting to millions of dollars, when all costs are included.

Identifying user requirements in detail is important and also defining or documenting them in a meaningful manner that the vendor or supplier can understand is equally important. Most FIs will not have internal resources and knowledge for new business areas and it’s best to contract such requirements to external experts. For computerizing existing business areas, it is key to include users. If not, the procured system becomes the “consultant’s system”.  User requirements should include all work and process flows, controls, audit, reporting (internal, external, operational and management), online info etc. in detail. Procurement Request for Proposals (RFPs) with 3-10 page user requirements are termed as a “recipe for disaster’ as they are not detailed enough.

Vendor proposals should be short listed based on an evaluation criteria. The short listed vendors should be invited to present their solution to a Procurement Team, which should include the management, internal audit, IT and users. Presentations should be simulation of the requested system and not PowerPoint presentations. If required, dummy data should be provided so that simulation would be meaningful.

These are only some of the dos and don’ts, but most are identified during the procurement process by experienced consultants and they ensure risks are mitigated during the procurement process. FIs should view consultants as facilitators to the procurement process and not decision makers for the FI.  Finally, before commencing implementation of ADC, the implemented CBS should be used in a live environment.

These dos and don’ts should provide a starting point for smooth implementation of core banking systems, to make any alternative delivery channels effort more streamlined.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s