Risk Mitigation in a Core Banking Conversion

Transcription

1 Risk Mitigation in a Core Banking Conversion Greg Meidt, chief information officer Chemical Bank Dick Smies, vice president IBS Conversion Services

2 Introduction A core banking migration project typically requires a major investment, along with serious levels of commitment from a bank s business lines and IT. Such a large investment of time and money requires proper risk management and strong governance to ensure all conversion participants understand their responsibilities and the work required of them. Embarking on such an endeavor requires financial institutions to carefully consider the qualifications of their core banking vendor or partner. This point is highlighted in the following quote from a recent Celent study: The core banking system platform is the primary system of record for the accounts of the bank and thus forms the technological foundation on which the bank operates. The process of switching out a core system has been likened to changing an engine on an aircraft in flight. These transformations can be costly and risky. It is important that institutions chose the right vendor. 1 The right vendor should partner with your bank to identify and mitigate risks in a core conversion. Such a partner should bring a proven methodology to the program based on hundreds of conversions and decades of success. For example, the IBS Conversion team performs close to 100 core system conversions annually. With nearly 30 years of providing conversion services to our clients, FIS has identified the most commonly repeated mistakes and/or threats to a successful conversion. This paper leverages FIS experience, combined with the observations of a senior banking executive, to highlight the major risks inherent in a bank conversion initiative. It also identifies steps a bank and their vendor partner (such as FIS) can take to mitigate these risks. Top Conversion Risks by Category How can a bank merging or changing its core system ensure successful conversion of that system? The bank must work with a proven methodology that contains key features that minimize risk and eliminate unknowns. If a bank is not a serial acquirer, the experience of a partner infuses discipline into the conversion risk mitigation process. The following conversion risks are described within five major categories: General Conversion project risks Conversion Planning Phase risks Product Definition Phase risks Customer Acceptance/Readiness Review Phase risks Migration Planning Phase risks (for conversion weekend) Either the bank or the conversion team may face these threats to success. Some risks may exist in more than one phase; however, for simplicity, a risk will appear in the table/phase where it most commonly occurs. The following tables summarize the five categories of risk within a bank conversion initiative and then present the standard approach FIS recommends to mitigate or avoid the risk. 1 Celent, Core Banking Systems for Large Banks, December

3 General Conversion Risks For a conversion to be successful, bank management must communicate the key drivers for the transformation throughout their organization. The team must clearly understand roles and responsibilities for the program as all key stakeholders are engaged at appropriate times during the effort. Everyone in the organization must understand what the new applications are and what they are expected to do. Training on new applications must be thorough and vetted for effectiveness. And at the end of the day, all systems must balance with the guidance of new experts on the new core processing technology. The following risks in Table 1 can occur in multiple phases of the conversion project and are important to note as your bank considers a conversion effort. Table 1: General Conversion risks 1.1) Barriers within the bank prevent FIS from using its standard conversion methodology. 1.2) Conversion teams delay decision making or do not escalate minor issues that could lead to a missed deadline. Note: This risk can also arise at the Customer Acceptance Phase and during an Operational Analysis. The Operational Analysis encompasses the mapping of daily workflows and workload responsibilities by job function. 1.3) Business and IT teams are not properly involved in the initiative. 1.4) Bank audit and compliance teams are brought into the conversion project too late. Note: This risk can also arise at Customer Acceptance Phase. 1.5) End-user training is not scheduled to occur at the optimal time or the wrong people are trained. FIS will review its standard conversion methodology with the bank. A customized conversion plan can then be developed which encompasses FIS processes, procedures, and expectations. The plan determines how and when FIS will engage on various milestones. The conversion project manager will review and manage the sequence of applications and their activities throughout the conversion. FIS recommends multiple communication levels within the bank with issue and action lists maintained by application or project phase. These lists are then available for review as needed. Discussion and escalation are addressed as upcoming events and are monitored. Late decisions or missed deadlines are escalated in a timely and appropriate manner. Early identification of need for individual projects is key so that projects can be staffed accordingly and resources integrated into project s key milestones. FIS recommends establishing audit and compliance review or archive policies early at the start of the project then communicate those needs and requirements to the conversion team. This will assist in establishing communication and conversion documentation review procedures. FIS teams work with the bank on training by first performing a training needs analysis to identify the appropriate bank employees to be trained on the appropriate applications. FIS confidential and proprietary information. 3

4 1.6) Training time requirements and practice time commitments of the staff are underestimated or acceptable practice facilities are not available. 1.7) Balancing is a critical conversion activity that doesn t always get the attention or practice time it deserves. Some user practice requirements may be heavier than others. The bank should provide adequate time and facilities for the staff to practice what they have learned during training. FIS recommends installing and testing practice systems prior to training. Balancing training is provided by the application analysts. It is important that the people who are trained and balance at Readiness Review are the same people who will balance at conversion. Conversion Planning Phase Risks The result of any core conversion depends on proper planning, team participation and close coordination between the financial institution and their core banking conversion partner. The partner should supply planning templates within a methodology that forces discussion and resolution of issues early in the preparation process. Customer-facing applications and critical bank equipment must be accounted for in the planning effort. Processes around technologies such as teller capture and fraud identification must be documented. Any custom development done on the current core banking system must have its features and functionality reflected in the new environment. The following table reflects important risks in the Conversion Planning Phase. Table 2: Conversion Planning Phase risks 2.1) Post-conversion customer support requirements for internet banking products are underestimated. During the first three weeks post conversion, the greatest number of calls to the bank are regarding the setup and use of business and consumer internet banking. The bank should plan on augmenting support staff to handle the increased call volume. 2.2) Statement and notices, print backs, and electronic storage solutions are not properly identified and accounted for in conversion planning. 2.3) Historical data in products such as fraud is not rebuilt. 2.4) An equipment requirement is missed that will impact the conversion unless an order is quickly made and escalated. Conduct planning for these activities early in Conversion Planning to minimize impact on any program milestones. FIS will discuss rebuilding history records with the bank conversion team during conversion planning scope discussion. FIS explains the impact and criticality of preparing certain systems to remain functional. FIS will provide equipment specifications for scanners, printers, servers, validators, etc. that the bank will need for the various applications. FIS confidential and proprietary information. 4

5 The bank should also complete a workstation certification process. 2.5) Assessment of the future-state teller capture environment is incomplete. 2.6) The bank conversion team does not notify the current processor(s) of the conversion on a timely basis. 2.7) Custom code incorporated into the bank s new platform is neither accounted for nor documented. 2.8) Validation of future release schedule for all deconverting platforms software upgrades is not done. 2.9) Experienced application coordinators with indepth knowledge of day-to-day operations are not allocated to the conversion. Or, the number of application coordinators is insufficient, which can overburden too few people coordinating too many applications. 2.10) The bank s staff is not properly leveraged to extend their experience and knowledge on FIS IBS platform and FIS conversion methodology. 2.11) Project challenges can conflict with key resources project availability during summer and end-of-year vacations. 2.12) Internal bank communications regarding the conversion do not provide enough information or is distributed randomly. FIS recommends the bank ensure all equipment is delivered to align with the schedule for Training and Readiness Review. Assessment of teller capture environment capacity and hardware needs (printers/scanners) must be completed early in the project, to minimize impact to any program milestones. Initial file cut date is determined in conversion planning. The bank needs to review contracts with incumbent processors from which data is being converted to determine notification and buyout terms. De-conversion files can then be created on a timely basis. Data conversion is based on those file cuts therefore addressing barriers in advance is recommended. The team must identify any custom code prior to the initial file cut, which will assist FIS in understanding requirements for unique products and services provided by existing bank processors. This validation must be completed and incorporated into project schedules. During conversion planning, the FIS management team will discuss the coordinator responsibilities, tasks and time commitment with the bank to help set expectations and identify any over allocation risks. These subject experts provide great assistance with key conversion milestones and overall coordination of project. FIS provides planning to best allocate subject experts. Vacation schedules should be incorporated into planning for all application activities team member are involved in. FIS recommends dedicating effort to sharing information regarding the conversion on a scheduled and regular basis. Developing an internal communications plan helps inform and FIS confidential and proprietary information. 5

6 The bank staff feels out of touch with the conversion, time-frames, and expectations even though they have been included in team meetings. 2.13) The bank conversion team and the FIS conversion team are not aligned with what applications were contracted to be installed post-conversion. Assumptions about conversion scope are not communicated early and thoroughly and may not be included in the FIS conversion team s schedule. 2.14) The complete set of bank products is not identified and established at the start of the conversion process. 2.15) Owners of post-conversion applications are identified or involved too late in the conversion. 2.16) The bank is unable to stay current in its daily balancing and reconciliation, post-conversion. engage employees. FIS conversion project management can join those meetings. This offers an opportunity to add creativity and extend the excitement of the conversion to all employees. During the conversion planning phase, a detailed scope analysis is reviewed with the bank to include conversion method (automated, manual or set up only) and implementation timing. Expectations are discussed and key feature requirements not defined are reviewed with management for early and fast resolution. Based on the scope analysis (mentioned above), the product set that will be used should be establish in advance of Product Definition Phase to avoid rework and fixes. Application Bank Control set up and software configuration are built around those decisions. FIS tracks and monitors this activity. Post-conversion application owners including database administration, software and IBS Bank Control changes should be identified and involved in communication and early conversion planning. Owners of the applications must participate in conversion planning discussions. Knowledge of the conversion mapping and set-up process will be useful in post-conversion support. Application owners should receive FIS InfoSource bulletins. InfoSource is used to communicate application issues, maintenance, and enhancements. FIS recommends implementing new controls that align with the new process to monitor daily balancing of all reconciliation accounts. Because balancing and reconciliation issues are critical activities, the bank should plan to deploy and prioritize bank resources in a timely manner. The bank conversion team should ensure that the balancing team is adequately staffed and trained. FIS confidential and proprietary information. 6

7 Product Definition Phase Risks The Product Definition Phase within a bank conversion focuses on gathering pertinent data for the initiative along with relevant product information. During this phase, all data, product, and software mapping is completed and definitions are uploaded to a common information storage facility (SharePoint). FIS staff perform product mapping at the bank s site with the appointed bank coordinators (Subject Matter Experts). Definition dates are uploaded to a common calendar to eliminate any overlapping of resources. The following table highlights risks in the Product Definition Phase of a core banking conversion. Table 3: Product Definition Phase risks 3.1) Pre-mapping training of key bank personnel at FIS prior to Product Definition is not conducted. 3.2) A future-state report analysis is not completed on time. Management and operating reports are not prioritized and written out of IBS Business Intelligence (BIC) (or other database report writers) by the needed date(s). 3.3) Officer, branch and cost center schemes are not defined at the onset of the conversion. This training provides orientation of FIS systems and terminology and is critical to the Product Definition Phase and should be done at this point in the program. FIS recommends reviewing all standard system reports as well as bank-authored reports to ensure continuity of reporting post conversion. A project plan should be developed for the rewriting of reports and should identify respective report owners. FIS IBS Consulting can assist to identify future-state reporting requirements. Officer, branch and cost centers are common fields shared across all applications. The bank must identify these items in the Product Definition Phase to avoid rework. FIS tracks a conversion task to monitor this activity. 3.4) IBS Customer Information (CIS) data (customer names, business titles, and addresses) is of poor quality and lacks consistency. 3.5) Clean up of known data integrity conditions that could impact conversion files is not conducted on a timely basis. 3.6) The current processor's transfer relationships are not well documented, contributing to difficulties and delays in setting IBS transfer relationships through IBS Customer Information (CIS). This risk can also aris at the Customer Acceptance Phase. Clean up must be completed on the previous platform, which will assist in the CIS Conversion data quality. IBS Consulting can assist with identifying and fixing data quality issues. Data cleansing must be completed on the previous platform prior to initial file cut or prior to third file cut during the conversion process. Sound project management can ensure these activities take place. Transfer relationships control bank customers ability to transfer funds through e- banking and voice response unit (VRU). Because of this importance, FIS and the bank work to better understand current transfer relationships leading to faster configuration of the IBS transfer relationship. FIS tracks multiple tasks to discuss the present and future functionality of transfers, how they are mapped, what changes must be made, and what to communicate to customers. FIS confidential and proprietary information. 7

8 Customer Acceptance/Readiness Review Phase Risks The Customer Acceptance Phase involves educating bank employees on their verification responsibilities for conversion test reports. Test reports and software are reviewed, with critical reports and data field being identified. The Readiness Review phase consists of a three-day exercise to ensure the FIS and bank project teams are fully prepared for the upcoming conversion. During this phase they can: Evaluate the success of training and level of procedural knowledge of bank staff Require participation of all key bank staff Execute test scripts Review workloads and workflows Test item processing, new forms, enhancements and third party integration Integrate the Readiness Review plan with any development testing plans The following table describes risks in the Customer Acceptance and Readiness Review Phase of a bank conversion. Table 4: Customer Acceptance and Readiness Review risks 4.1) Test reports and exception messages are not adequately verified. 4.2) Software configuration is not fully reviewed and confirmed prior to conversion. 4.3) Readiness is not verified for each bank employee impacting the conversion. 4.4) Full end-to-end testing, that includes third-party processing systems with new interfaces, is not performed prior to conversion. FIS recommends creating a verification plan to ensure an adequate sample of account scenarios is reviewed and exception messages are handled appropriately. FIS tracks Customer Acceptance application milestones in the conversion project plan. FIS recommends a full Readiness Review process that involves the bank testing all configurations, starting with an initial data conversion through end-user acceptance, reporting and closeouts. This effort will identify missed configurations and timings for the production conversion. Aligning this test with the defined program scope and with conversion discussions ensures the best outcome. At a minimum, a verification plan must be created to ensure the software is adequately configured to meet the Software Configuration Customer Acceptance milestones. Readiness should be verified through training and Readiness Review exercises. Use FIS best practices in interface coordination. Where feasible, third-party systems should be a part of the Readiness Review simulation to ensure they perform according to expectations. Testing of these systems is discussed as part of the conversion planning process. Third-party vendors should supply contacts to the conversion project team. Project plans will be developed for each individual interface to ensure they meet milestones. FIS confidential and proprietary information. 8

9 Migration Planning for Conversion Weekend Phase Planning for the big event of the conversion, the weekend the switch to the new core banking system becomes a reality, is key to the success of the program. Steps in this vital planning and ultimate activity include: Completing final documentation for final night processing Developing a conversion weekend playbook Converting and verifying data files Recording bank balances as of last processing date on the incumbent core processing system Completing any necessary equipment installations Converting data and balances between old and new systems Providing any critical conversion weekend updates The last table highlights the risks in the Migration Planning for Conversion Weekend Phase of a bank conversion. Table 5: Migration Planning for Conversion Weekend risks 5.1) End-customer communications are not carefully planned. 5.2) Conversion playbook and de-conversion requirements are not completed in detail. 5.3) Call center planning for internal and external customers is not conducted. 5.4) Onsite FIS support during conversion week is not coordinated. 5.5) Regular review meetings during conversion week are not scheduled. 5.6) Energy levels too low. This communication should be part of the planning throughout the project and prior to golive weekend. A delivery-level communication plan should be developed and deployed. These documents should detail all relevant application and integration activities. FIS can supply generic examples as a guide for bank efforts. Planning for additional bank call center staffing for the first three weeks after transition is key. This should be part of the Migration Planning for Conversion Weekend Phase. Staffing in operational areas and call centers ensure issues are addressed and balancing is completed on a priority basis. The FIS team will staff appropriately and coordinate resource deployment during conversion week. Status must be provided on conversion progress to all key application stakeholders, operations, and infrastructure teams. FIS will schedule and coordinate regular review meetings during conversion week. Food and beverages are a must! FIS confidential and proprietary information. 9

10 Summary Core banking conversions require a different mindset and a more mature risk mitigation mind-set. Strong risk management processes can help manage the risks in this type of initiative and overcome lack of prior experience by implementing conversion best practices. The key to success is bringing the right people in at the right time to raise, understand, and resolve issues early in the process. For More Information For more information on how FIS helps mitigate conversion risk and improve outcomes on complex initiatives, contact your FIS strategic account manager (SAM), or call FIS confidential and proprietary information. 10