Gartner defines a core banking system as a back-end system that processes daily banking transactions and posts updates to accounts and other financial records. Core banking systems typically include deposits, payments, loan and credit, trading processing capabilities with interfaces to general ledger systems and reporting tools. Banks make these services available across multiple channels like automated teller machines, internet or mobile banking and branches.
Many banks implement custom applications for their core banking. Others implement or customize commercial independent software vendor packages. Systems integrators like Cognizant, Capgemini, Accenture, IBM and Tata Consulting Services (chosen by the bank) help implement these core banking packages at banks.
The implementation of a new core banking system, respectively the replacement of an existing solution with a new solution, is a major and long-term investment for a bank. It results in a complex transformation project which often runs over several years – and has a very high failure rate.[1]
So, the key question for everyone involved with core banking implementation projects is how to identify the risk of failures early – and how to avoid it.
This is my personal reference guide on risks and challenges and the best way to handle them based on my experience in leading over 20 projects in 6 countries all around Europe.
1.Scope – Review your scope and ensure it is limited to core banking (backend) to increase your success rate. All other changes should be treated as additional projects. A core banking implementation and migration project is already very complex. Every additional component increases complexity and the risk of failure. Additional components could be one of the following: New balance sheet structure, New front applications (incl. internet or mobile banking), Introducing new technical integration layers, Implementing a new data center, Off-shoring operational tasks
- If you do not limit your scope, you have a high risk of failing. Limiting the complexity and doing things sequentially in different projects with different cut-over dates massively increases your success rate.
2. Timeline - Review your masterplan and check all important milestones, by calculating backward.
- Cut-Over – You need at least 2 weeks to conduct a cut-over as a “big bang” from the moment the infrastructure and environment build up can start until the final go-decision. In case you plan a big bang with a static and position data split or even more complex variations (parallel processing), more time is required from the moment all your implementation activities are finished until the final go-decision is taken as part of the cut-over procedures. (This might be on Sunday at midnight before the first business day with the new solution.)
- Data Migration Tests – From the moment the data migration is fully implemented (all data mapped, and transformation routines developed) until the cut-over preparation can start you need to conduct at least 7-10 migration runs (including selective dress rehearsals over a weekend). It usually takes 6-9 months until the data quality is acceptable, and all balance sheet differences can be explained or are within an acceptable range for the bank and its auditors and cut-over procedures can start.
- Data Migration Implementation – The implementation of the data migration extraction, transformation and load routines including scope definition (which data fields need to be migrated) data mappings and designs (which field of the source data can be mapped to which target fields, 1 to 1 mappings are perfect but often complex transformations are required to fit expectations) as well as the actual implementation, unit and first functional tests require at least 9-12 months before data migration tests can start.
- Acceptance and Integration Test (UAT) – Many functionalities can be tested in isolation but in the end, all is coming together for the correct accounting and daily balance sheet checks as well as the client output to be sent out daily or monthly as well as the regular reporting. These components need time to be tested after all other functionalities are working correctly. You need at least 4-6 months after the overall implementation of the software, including finalized internal and external interfaces and data migration tests, which provide a useful set of data as a basis for the acceptance and integration tests.
- If you plan less time for the listed activities, you have a high risk of failing. – Be very skeptical if people tell you the above can be done quicker in an agile manner.
3. Effort – Make sure all activities are included and the effort is in an acceptable range.
- Implementation effort – The number of identified GAPs or deltas is not higher than the estimated effort in PDs. The implementation of an identified GAP requires at least 1 PD on average. On the other side the number of GAPs and the effort needs to be in a reasonable range (500 = 10.000 PDs)
- Data Migration Effort – Automatic data migration including scope definition, data mapping, transformation implementation as well as test runs and automatic reconciliation can’t be done below 1’000 PDs. Depending on the data fields and data volume it might be much more. Additionally, you should plan with the same number of PDs for business data migration including data cleansing, manual migration, reconciliation and supporting the migration runs from a business perspective. These are often forgotten.
- Integration Effort – At least 50-100% of the implementation effort should be scheduled for the integration effort to build interfaces, conduct conversions and adjust existing applications to ensure the integration of the new core banking system into the existing application landscape, respectively to connect it to the outside world.
- Infrastructure & Environment Management Effort – At least 5-10% of the implementation effort should be scheduled to prepare, manage and maintain the infrastructure, build up the environment, prepare the “builds” and do configuration management.
- Test Effort – The overall test effort for the software (incl. UAT and integration tests, but not unit and IT internal tests), the data migration tests (including dress rehearsals) and the final cut-over ensuring the bank is functioning after cut-over, will be at least 4’000 PDs. If a bank is part of a group, the effort might be closer to 8’000 PDs, due to group requirements for risk management and additional audits as preparation for cut-over.
- Business Transformation – The preparation of the business users and the overall organization is key and requires a communication- and training strategy. Additionally, processes and organizational departments need to be adjusted, legal aspects clarified, terms and conditions edited, and local regulators informed and managed. The additional overall effort might be approximately 20-30% of the implementation effort.
- Project Management – Plan at least an additional 10% of the overall effort as management effort for your project, stream management and a meaningful PMO.
- Program Management – If you are planning to simultaneously implement more than one bank/country or doing back- and frontend sequentially, you need to include another 10-15% of the overall effort as program management effort. Please be aware that you just need program management when having more than one cut-over and therefore more than one project. If a project has just one cut-over it is not a program and doesn’t require program management
- If your effort estimations are outside of the listed range, I believe your program is at risk. – If someone tells you that most or some of these activities are done with internal resources which are “there anyway” and therefore need no planning effort as no costs will occur, I suggest you simply smile... All efforts need to be planned and managed, even if they don’t add additional project costs
4. Progress Tracking – Check if your project management team understands the progress required versus the progress achieved during a certain time (per week or month). This can be done for example as follows: Earned/burned analysis, Burn-down-graphs, Deliverable tracking
- If there is no documentation of what needs to be done to meet the plan within a given timeline versus what has been done during the planned time, you are at risk. If somebody is telling you, that it is all “on track, no prove necessary” – I believe it is time to get nervous.
There are also other reasons why core banking implementation and migration projects fail but to list them all would defeat the purpose of this article.
I strongly believe focusing on scope, time, effort and progress tracking will give you a good indication if your project is well organized. Or not.
Footnote: 1) Definition of “Failure” = Project cancellations, project postponements of > 2 times and/or >= 12 months, negative publicity / press articles (e.g. TBS Bank 2018)
