Most banks in the Middle East run on a core that was installed between 2000 and 2015, has been upgraded two or three times, and is wrapped in a decade of customisations nobody fully documents. It posts correctly, it passes audit, and it is the reason every new digital feature takes nine months. Core banking modernisation is the programme every CIO has on the roadmap and most are afraid to start, because the industry remembers the big-bang replacements that ran three years late.
The good news is that the big bang is no longer the only option. This guide lays out the three modernisation patterns that work in practice, how to choose between them, and the one piece of architecture every pattern depends on.
Why the pressure is rising now
Three forces have changed the arithmetic. Instant payment rails such as sarie, Aani and WAMD expect the core to post and confirm in seconds, around the clock, with no end-of-day window. Open banking frameworks in Saudi Arabia, the UAE and Oman expose account data to third parties in real time, so a slow or inconsistent core becomes visible inside competitors’ apps. And digital-only banks launched since 2022 are running on cloud-native cores with release cycles measured in days, which resets what customers consider normal.
The old core was designed for branches that closed at four and batches that ran overnight. None of the three forces above tolerate that model.
Pattern one: hollow out the core
The first and least risky pattern leaves the system of record where it is and moves everything else out. Customer data, product catalogue, pricing, limits, notifications, onboarding, card controls and the channel logic that grew up inside the core are re-implemented as services around it, and the core is reduced to ledgers, accounts and postings. A digital banking platform in front of the core carries the customer journeys; an integration layer translates between them.
This pattern delivers visible change in months, because the customer-facing work does not wait for the ledger migration. Its limit is that the core still sets the ceiling on real-time behaviour and product flexibility, so it is usually the first phase rather than the destination.
Pattern two: strangler migration, product by product
The second pattern introduces a new core alongside the old one and moves products across one at a time, starting with the simplest or the newest: a new savings product, a youth account, prepaid cards, then current accounts, then lending. Each product runs on exactly one core at any time; the integration layer routes by product and customer so channels do not know or care which ledger answered.
The hard parts are the shared functions. General ledger consolidation, regulatory reporting, customer 360 and the data warehouse must read from both cores for the duration of the migration, which can be two to four years. Banks that under-invest in this dual-running period are the ones whose migrations stall at sixty percent.
Pattern three: greenfield digital bank
The third pattern builds a new bank on a new core, under the existing licence or a new digital banking licence, and migrates customers who choose to move. Several Gulf banks have taken this route, launching digital brands on cloud-native cores with their own product set and then deciding later whether to fold the parent in. It is the fastest route to a modern stack and the slowest route to retiring the old one, because the legacy core keeps running for as long as legacy customers stay.
It works best when the strategy is genuinely to acquire a different segment, not merely to escape the old technology.
The piece every pattern depends on: the integration layer
Whichever pattern you choose, success depends on a layer between channels and cores that owns the canonical data model, exposes stable APIs to every channel and partner, routes requests to the right system of record, and publishes events as things happen. Done well it also becomes the open banking API foundation, the source for real-time analytics and fraud scoring, and the place where product logic lives after it leaves the core.
Treat it as a product with its own roadmap and team, not as middleware a vendor bolts on. The banks whose modernisations finish are the ones where this layer was built first and the core migration ran behind it.
Choosing a pattern
A rough rule: hollow out the core if your core is stable, your channels are the pain and you need results inside a year. Strangle the core if your product roadmap is blocked by the ledger and you can fund a multi-year programme with disciplined dual running. Go greenfield if the business case is a new segment or a new licence, and be honest that it does not retire the old core by itself.
In every case, sequence the work so that customers see improvement every quarter. A modernisation that is invisible for two years loses its sponsors.
How Eurisko fits
Eurisko has delivered digital banking channels and integration layers for banks in Lebanon and the Gulf since 2009, in front of Temenos, Finastra, Oracle and in-house cores. Our Eurisko DXP platform is designed to run in front of any core and to keep running through a migration, which is why hollow-the-core is usually where our engagements start. If you are planning a core programme, we are happy to review the sequencing with your team.
