ON-POINT Insight #02 - expertise from the consulting frontline
Core Banking Projects — How to Spot Failure Risks Early by Kerstin Lehmann
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, loans and credit and trading processing capabilities, with interfaces to general ledger systems and reporting tools. Banks make these services available across multiple channels — ATMs, internet or mobile banking and branches.
These systems are the backbone of every bank. Which is why, when replacements or migrations fail, the consequences are enormous. And the truth is: too many of these projects do fail. So how can you tell early on whether your program is heading for success — or disaster?
Why Core Banking Transformations Fail
Many banks develop custom applications for their core banking. Others implement or customize commercial vendor packages. Systems integrators like Cognizant, Capgemini, Accenture, IBM or Tata Consulting Services are often brought in to help.
But whether custom or package-based, the implementation of a new core banking system — or the replacement of an existing one — is always a major, long-term investment. These transformation projects typically span years, involve high complexity and have a notoriously high failure rate. [1]
So, the key question is simple: How can you identify the risks of failure early, and avoid them before they derail your transformation?
A Practical Guide from Experience
This reference guide is based on my experience leading more than 20 core banking projects in six countries across Europe. Below are the four key areas that will make or break your program.
1. SCOPE: Limit Complexity to Increase Success
Review your scope and ensure it is limited to core banking (the back-end). All other changes should be treated as additional projects. Core banking implementation and migration is already highly complex — every extra component multiplies the risk of failure.
Additional components that often cause trouble include:
- New balance sheet structures
- New front-end applications (including internet or mobile banking)
- New technical integration layers
- Data center replacements
- Offshoring operational tasks
If you don’t limit scope, you are highly likely to fail. Sequencing changes into separate projects with different cutover dates massively increases your chances of success.
2. TIMELINE — Be Realistic, Not Optimistic
Your masterplan should be stress-tested against key milestones, working backward. Some examples:.
- 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 cutover 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 cutover 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 someone tells you this can be done “agile and faster,” be skeptical. Cutting corners here almost guarantees failure.
[1] Definition of “Failure” = Project cancellations, project postponements of > 2 times and/or >= 12 months, negative publicity / press articles (e.g. TBS Bank 2018)
3. Effort — Don’t Underestimate What It Takes
Ensure all activities are properly estimated and resourced:
- 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 cannot 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 cutover ensuring the bank is functioning after cutover, 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 cutover and therefore more than one project. If a project has just one cutover it is not a program and does not require program management.
If effort estimations fall outside these ranges, your program is at risk. Don’t let anyone dismiss activities as “covered by internal resources anyway.” All effort must be planned, tracked, and managed.
4. PROGRESS TRACKING — Trust, but Verify
Effective governance requires evidence-based tracking:
Earned value vs. burned hours analysis
Burn-down graphs
Deliverables tracking
If your project reports “on track” without documented proof, it’s time to worry. Lack of transparent tracking is one of the strongest early warning signs of trouble.
Final Thoughts
There are many reasons core banking projects fail — but focusing on scope, time, effort, and progress tracking will give you a clear early indicator of whether your program is well-organized or heading for trouble.
Thinking about a core banking replacement? Don’t wait until it’s too late. Let’s talk early — before the risks multiply — and set your project up for success.
At ON-POINT, we bring consulting expertise from the front line — helping you deliver complex projects with confidence. Reach out to Kerstin Lehmann to start the conversation.