Core banking replacement has a reputation, and it is mostly deserved. Programmes run late, budgets double and the new platform goes live with half the products it was meant to carry. Yet the case for modernisation in the region has rarely been stronger. Digital-only propositions, instant payment schemes and open finance all ask more of the core than platforms designed for branch banking can give.
The banks that get through it well have one thing in common. They treat the core as a business decision with a technology component, not the other way round.
The old core is not just a system. It is fifteen years of business rules that nobody wrote down.
Three ways core programmes go wrong
The big-bang ambition. One migration weekend, every product, every customer. It looks efficient on the plan. In practice it concentrates all of the risk into a single event and gives the programme no way to learn before it matters.
Migrating the product catalogue as it is. Most banks carry hundreds of product variants, many with a handful of customers. Configuring each of them on the new platform is where time and money disappear. The rationalisation decision belongs to the business, and it has to be made before the build, not during it.
Undocumented business rules. The legacy core holds years of fee logic, exceptions and regulatory workarounds. Nobody fully knows what it does until something breaks in testing. Programmes that skip the discovery work pay for it later, at a much higher rate.
Lead with the business case, not the vendor
Vendor selection is usually the first visible step, and it is often taken too early. The better sequence starts with the outcomes: which propositions the bank needs to launch, which costs it needs to remove and which regulatory obligations the current platform cannot meet. The target architecture follows from that, and the vendor follows from the architecture.
This is also where ownership is settled. If the programme sponsor sits in technology alone, product rationalisation and process redesign will be treated as someone else's problem. A business sponsor with authority over the product catalogue changes the economics of the whole programme.
Modernise progressively
Replacement does not have to mean a single cut-over. Many institutions are building a modern digital layer alongside the existing core and moving products and segments across in waves. When we helped a local bank launch a digital-only proposition, a cloud-native platform ran alongside the existing bank. Customers were onboarded in minutes, and the bank learned what the new platform could do before committing its whole book to it.
Each wave should carry a business outcome, a defined product set and a clear decommissioning step. A programme that adds a new platform without retiring the old one has increased its cost base, not reduced it.
Three questions before you sign
Which products will not move, and who has agreed to retire them? What does the current core do that nobody has documented? And what is the first business outcome the new platform will deliver, and when? If those answers are clear, the technology decision becomes much easier.
