Risks in Core Banking Migration

Summary

This article highlights some of the key risks in executing a successful core banking migration program. Many of these risk elements also relate to any large IT project, but are more aligned towards a core banking migration.

Key Risks

A core banking migration project is typically one that involves hundreds of millions of dollars of investment, along with serious levels of commitment from Business and IT. Such a large investment of time and money requires proper risk management and strong governance to ensure that all stakeholders realize the responsibilities they hold and work single-mindedly to fulfil them. At the same time, business as usual needs to be addressed, as well as customer impact should be absolutely minimized.

The following is a listing of the key risks based on our experience of working with Banks engaged in large-scale programs such as core banking implementation.

Program Management

Core banking implementation projects are not just about project management, but rather about program management. A program is a collection of multiple projects each of which have their own timelines, dependencies, RACI* matrices, deliverables, and milestones.

Many banks are not geared up to handle a Program of this size, complexity, and duration. The fact that multiple projects would be involved, and each of these projects would impact others in some way or the other is quite often a rude awakening that comes somewhere during the business analysis phase. Just as an example, some of the key projects streams that would need to run are:

1. Business Requirements Gathering – these would have multiple stages including demonstration of the Model Bank by the vendor, business requirements gathering, functional specifications preparation, etc.
2. Data Migration – which would involve Data Quality Analysis, Data Clean-up, Data Mapping, and Data Migration)
3. Interface Development – for existing and new applications to interface with the new system, as well as implementation of the Enterprise Service Bus, if the Bank is adopting SOA – Service Oriented Architecture[2]
4. Module Development – no matter how much you wish, there will be customization involved, and this has to be overseen properly by the Bank
5. UAT – quite often you will want to do this jointly with an outsourced entity
6. Business-as-usual impact management – more on this in a later section
7. IT operations readiness – this covers the readiness of infrastructure (servers, storage, network), processes (backup, operations, monitoring, troubleshooting), and IT teams (organizational structure to handle program-specific responsibilities)
8. Business operations readiness – this would cover the branches, learning and personnel development, and other business units which would be impacted by the implementation
9. Rollout – the rollout strategy would need to be decided early on as it impacts the entire program in multiple ways. More on this later.

Program Governance

Once you realize the enormity of the task, a proper governance structure needs to be implemented. Some Banks choose to outsource the Program Management office completely. Either ways, this has to be with senior banking personnel embedded into the program governance structure. An outsourced vendor would bring in expertise in the areas of project management, risk management, change management, vendor management, and driving the program forward. Formal manuals may have to be prepared, which clearly spell out the governance structure, along with roles and responsibilities for all key stakeholders, and also define the processes for critical project management practices such as risk, issue, change, and communication management.

Business Commitment

With ongoing pressures of business-as-usual, the business teams may not be fully committed to a program of this scale and complexity. This has multiple impacts right from product selection, scope definition, requirements gathering, UAT, etc. Without the right level of business personnel involvement, the quality of inputs received by the program would suffer. This often results in repeated iterations of deliverables such as the Business Specification Documents (BSDs) and Functional Specifications Documents (FSDs), etc. Also, it may result in a sub-standard product being delivered to the organization.

Vendor Management

The transformation program will typically involve multiple vendors – Core Banking Solution Provider, Project Management, Testing, Data Migration, etc. Each of these vendors will bring to the table their own expertise, but also their own challenges in terms of experience and expertise. The Bank should institute a dedicated vendor management function (part of the Program management team), which deals with vendors on an equal footing and does not get intimidated by their claims of boiler-plate contracts. Legal team should be heavily involved in ensuring the contract is fair, but more tilted in the Bank’s favor than the vendor’s favor. Vendors should be committed to provide “named” personnel, who are available throughout the execution of key project milestones and are based in UAE. No vendor should be allowed to execute a typical “bait-and-switch” strategy when it comes to project resources.

It is also recommended that the Bank should evaluate the role of “System Integrator” to be played by a specialist vendor and not leave this role to be done by the main solution provider who are experts in the Core Banking system, but may not be able to deliver on the overall aspects of implementing the solution within the Bank’s existing environment.

Scope Management

The scoping exercise prior to contract finalization is one of the most important stages. Key stakeholders from all the Bank’s impacted departments should play a role in this. The program team should also institute a challenging mechanism to avoid over-customization of the Core Banking (CB) solution. The requirements gathering team should be encouraged to push people to accept the systems’ way of doing things rather than super-imposing outdated processes onto a state-of-the-art solution. Notes should be exchanged with other banks in the region that have implemented the same solution and challenges that they faced.

Ensuring Quick Wins

A program such as this often leads to elongated project milestones and this can demotivate the team members as well as raise doubts in the minds of the Board members as to whether this investment is really going to yield any results or not. The transformation program team should ensure quick wins are adequately introduced throughout the project delivery schedule and these are well-recognized throughout the Bank.

Financial Control

Programs such as these have a tendency to quickly escalate in terms of budgeted costs. It is extremely important that the Bank institute a dedicated financial control function for the transformation program that tracks capital and operational expenditure on a weekly basis, as well as ensures that payments are made on time (in order not to demotivate vendors), as well as payments are made only when the deliverables are up to the mark and delivered on time. This aspect may further be enhanced by keeping a bonus component for on-time or before-time delivery of key milestones. Cost escalations should also be properly risk-managed through the bid negotiation and contractual stages itself.

People Management

A core banking transformation project can only succeed when all stakeholders are fully committed to it. This means, there would be certain key banking personnel who need to be dedicated to this enterprise, as well as others who would be tapped at various stages of the program. Given typical attrition rates in the Banking industry, the program should not suffer if key people leave. For this, the Bank should consider implementing an incentivizing program that ensures key stakeholders remain committed to the Bank and to the transformation program through the key stages of the program. A strong communications management process that includes senior management – including the Board of Directors – overseeing the progress and appreciating key achievers in words and kind is mandatory for the eventual success of the Program.

Rollout Strategy

One of the aspects that must be addressed pretty much up front is the planned rollout strategy. There is no one right way of doing this, and pain has to be suffered no matter what the strategy being adopted. Options are:

• Big Bang: During a given weekend (say during a long holiday period) everyone switches over to the new system
• Parallel Run: Transactions are posted on both systems and data reconciliation is done end of day. All errors are ironed out before date rollover
• Hybrid: All new customers are created on the new system, while older customers are migrated in a phased manner. GL reconciliation done end of day

Each approach has inherent risks and detailed mitigation measures that must be built in. This has impact throughout the program in terms of interface preparation, reconciliation scripts, data migration approach, and build delivery, as well as testing strategy. A detailed study must be carried out and an informed decision must be taken on this aspect.

Data Migration

This is an aspect that a lot of Banks figure that they will deal with later. But it can spring a lot of rude surprises just as the first build begins to get delivered. Legacy systems quite often not have the rigor for input validation and data integrity controls that newer applications tend to have. Each CB solution has its own requirements in terms of the data quality, necessary data fields, and data formats. Migrating legacy data is not just limited to mapping of the fields, but also requires heavy lifting in terms of data clean-up, data conversion, and quality review of the migrated data. Quite often this might also involve reaching out to branches who in turn would need to reach out to individual customers to obtain missing KYC data.

Infrastructure and Sizing

The sizing requirements can change as the program progresses. Some factors that can influence this are regulatory requirements for longer storage of customer and transaction data, increase in the fields associated with customers (for instance, issuance of a national ID number), introduction of an Enterprise Service Bus (ESB), etc. Not only must the hardware cater for the application requirements today, but also for 5 years down the line when the system will be fully functional. Therefore, business growth plans must be taken into account for at least a 5-year horizon when sizing is being done. Also, multiple factors would influence latency and the responsiveness of the system should be mandated at the start of the program to avoid user rejection due to the system being “too slow”.

Business As Usual (BAU)

While such a major transformation is going on – and a program of this nature would take anywhere from 3-5 years – the Bank has to continue operating as usual. During this time, the business will continue to come up with new requirements for enhancements to the existing core banking system as well as other satellite systems that interface with the core banking system. Now, the core banking system itself is going to get replaced. So these changes reflect a moving target for the Program to achieve. A new requirements management or demand management process needs to be put in place to analyze the impact of these change requests, rationalize them, and only then approve them for implementation. Each such request will represent a scope increase in the CB implementation and subsequent cost impact. Not to mention increase in timelines for further customization of the system.

Conclusion

Multi-million dollar, multi-year programs such as Core Banking transformation require a different mind-set and more mature program management capability than most Bank’s possess in-house. Strong risk management processes can help mitigate the risks from this lack of prior experience by implementing global best practices, bringing the right people to the game, and managing vendors with an iron hand in velvet glove approach. The risks enumerated above are generic and based on our experience. The Bank may use these to build a larger risk register and enumerate strong risk mitigation measures to ensure that the investment of time and money is well worth it, and such a large program helps deliver the benefits original envisaged – faster go-to-market, customer-centric approach, and intelligent insights into consumer behaviour and product profitability.

[* – Responsible, Accountable, Consulted, Informed. A RACI Matrix helps identify who does what at each stage of the project.]