The Data Problem Behind MENA Banking's 2026 Deadlines

Ask a bank in this region what its biggest technology challenge is and you will usually get an answer about a system: the core is old, the warehouse is slow, the fraud platform generates too much noise. Ask the same bank what its biggest regulatory challenge is and you will get an answer about a deadline.

They are the same answer. Nearly every deadline arriving in Middle Eastern and North African banking between now and the end of the decade resolves, on inspection, to a single question: can this institution produce a specific set of data, correctly, quickly, and with a defensible account of where it came from? That is not a banking problem. It is a data engineering problem wearing a regulatory hat.

And the window is no longer abstract. Federal Decree-Law No. 6 of 2025, the UAE's new Central Bank law, expressly brings Open Finance Services into the CBUAE's licensed-activity framework, whose one-year transitional period for compliance ran to 16 September 2026; that grace period is now over. The Open Finance Regulation's phased onboarding of mandated institutions begins with all banks, including branches of foreign banks, and insurance companies. Dates differ by market and by supervisor, but they share a direction: the period in which data readiness could be treated as a next-year problem has closed.

This article sets out what is actually being asked, why the architecture in most regional banks struggles to answer it, and what the order of work looks like for institutions that want to stop firefighting.

Five Banking Problems That Are Actually Data Problems

These five come up most often in regional institutions. None is unique to this region. What is distinctive is how many are being confronted at once, and under what constraints.

The customer who exists five times.

A regional bank of any age holds the same customer in several places: retail core, cards, lending or collections, an Islamic banking subsidiary on a separate stack, treasury, and increasingly a digital-only brand launched alongside the parent. Each has its own identifier, its own address record, its own view of the relationship, and no reliable link between them. The commercial cost is familiar: cross-sell is guesswork, relationship pricing cannot be applied consistently, a customer onboarded in one channel is asked for the same documents in another. The regulatory cost is newer and larger. Open finance asks the bank to expose a customer's position on demand, through a standardised interface, in real time. An institution that cannot reliably say internally which accounts belong to which person cannot expose that reliably to a third party. The API is the easy part; the entity resolution behind it is the work.

Reporting that cannot show its working.

IFRS 9 is enforced across the GCC, requiring twelve-month expected credit loss on Stage 1 exposures, lifetime expected credit loss on Stages 2 and 3, and forward-looking macroeconomic inputs folded into the calculation. In a large number of institutions that calculation is assembled in spreadsheets: extracts pulled from the core, adjusted by hand, combined with a macroeconomic overlay from the risk team, reconciled under pressure at each period end. It produces a number. What it does not produce is lineage: a machine-readable answer to which source records, which transformations and which assumptions produced that specific figure. When a supervisor asks, a team reconstructing the answer manually spends weeks on archaeology, and because the same weakness affects capital reporting, liquidity returns and regulatory submissions, that cost is paid repeatedly. Lineage is not a compliance nicety. It is the difference between answering a supervisory query in an afternoon and answering it in a month.

Financial crime teams buried in false alarms.

The region's anti-money-laundering environment has tightened, and expectations of transaction monitoring have risen with it. Most monitoring systems in production were configured with rule thresholds years ago and have been tuned conservatively ever since, because a missed alert is a regulatory problem and a false one is merely operational. The result is familiar to anyone who has sat with a financial crime team: a queue dominated by legitimate activity, analysts working through it under service-level pressure, and no reliable way to tell whether the genuine cases are being found or buried. The instinct is to buy a better detection engine. The more effective intervention is upstream. Alert quality is a function of the features fed into detection: counterparty resolution, complete transaction history, correct segmentation, reliable geography. Where those inputs are fragmented no model will perform, because it is being asked to distinguish between records that are not consistently described in the first place. Improving feature quality usually cuts false positives further than replacing the engine, and costs less doing it.

Real-time rails on batch-era foundations.

Payment infrastructure here has changed faster than the data infrastructure behind it. The UAE's Aani instant payment platform launched in 2023 under the CBUAE's Financial Infrastructure Transformation programme, the Jaywan domestic card scheme followed in 2024, and Saudi Arabia runs sarie instant payments alongside mada. These rails are always on, and they are being used: Al Etihad Payments reported this year that Aani has passed 12.5 million registered users, with transfers up sixfold year on year, roughly 774,000 merchants on the platform, and account-to-account transactions settling in around three seconds. Most of the analytical and control systems watching those rails are not always on. A fraud model scored against yesterday's batch cannot intervene in a payment that settles in seconds. A limit check reading a balance refreshed overnight is checking a number that is no longer true. A liquidity view assembled each morning describes a position the bank has already left. The gap tends not to be noticed until something goes wrong on a weekend, because batch architecture fails quietly: it still produces an answer, the answer is simply stale. Moving to streaming is significant engineering and it is rarely needed everywhere. But it is needed precisely where the money moves in real time, and that surface expands every year.

AI programmes that stall before they start.

Appetite is not the constraint here; Gulf institutions have been among the more aggressive adopters globally. The constraint is what the models are asked to run on. EY's Financial Services CTO Survey found 68% of technology chiefs citing legacy systems as the single most significant obstacle to AI adoption, and Grant Thornton's 2026 survey of 950 executives reached the same conclusion from the data side: data readiness remains a defining barrier in banking, tracing back to inconsistent definitions across business lines and siloed systems never built to communicate, with half of respondents citing governance and compliance gaps behind AI underperformance or failure. This is the most expensive version of the pattern because it fails late. A proof of concept succeeds on a clean extract prepared by hand, the decision is taken to move it into production, and only then does it emerge that the feature the model depends on is available monthly, or is populated inconsistently across source systems, or cannot be reproduced for a supervisor asking why a customer was declined. The programme does not fail on the modelling. It fails on the plumbing, after the budget has been committed.

The Constraint That Makes This Region Different

A bank in Frankfurt or London facing the same five problems can reach for a well-documented reference architecture and a global cloud region. Institutions here cannot simply copy that, because of where the data is allowed to sit and who is allowed to touch it.

The CBUAE's Outsourcing Regulation for Banks requires a notice of no objection before an activity is outsourced. Agreements must preserve the bank's full ownership of the data it shares, guarantee unfettered access to it for the life of the agreement and on termination, and ensure the Central Bank can access it on request; confidential customer data is not to be processed outside the UAE without prior approval. SAMA's Cloud Computing Framework makes data sovereignty a foundational principle and applies in-kingdom hosting requirements across supervised entities.

The consequences are architectural, and they are the ones most often discovered late. Region selection becomes a design decision, not a deployment detail: a managed service unavailable in a compliant region is unavailable to the project, however good it is. Exit has to be designed in from the start, because a requirement for unfettered access to your own data on termination is a requirement for open formats, portable pipelines and no proprietary lock-in at the storage layer. Cross-border access by an offshore engineering team is a regulated act, not an operational convenience, and it is where offshore delivery models most often come apart because it was never priced into the business case. Supervisory access has to be a capability, not a favour: if the regulator can request the data, the platform must be able to produce it without a heroic effort each time.

None of this makes good architecture impossible. It makes imported architecture unreliable. The reference designs published by the large platform vendors assume a freedom of placement that supervised institutions here do not have, and the gap between the diagram and the rulebook is where projects lose quarters.

The Second Constraint: People

The other thing that cannot be imported is the team.

Emiratisation targets apply to banks through the CBUAE's Ethraa programme, with further national representation targets and monthly penalties for unfilled positions applying to larger employers generally. Saudi Arabia's Nitaqat programme applies profession-specific quotas that keep expanding, and Qatar, Bahrain and Oman run their own localisation regimes. Technology is consistently the hardest function in which to hit these targets, and data engineering among the hardest roles within it: Gulf demand for data engineers, cloud architects and platform specialists runs well ahead of supply, and salary inflation reflects it.

That leaves banks in an awkward position. The regulatory programme requires senior data engineering capability now. The localisation programme requires that a growing share of that capability be national. The market cannot supply both at once, so institutions default to contractors, which fills the seat, meets no localisation target, and leaves nothing behind when the contract ends.

The way through is not to choose between delivery and capability but to structure engagements to produce both: experienced engineers delivering the platform, working alongside a cohort of local engineers trained on the institution's own systems, with an explicit handover point. It takes longer to set up than pure staff augmentation and costs more in the first quarter. It is the only structure that leaves the bank able to run what has been built.

Getting the Order Right

Institutions that make progress here, and a number in the region demonstrably are making it, differ from those that do not in one respect: sequencing. The failing pattern is recognisable: a bank starts with the most visible deliverable, usually the AI programme or the customer-facing API, and finds the foundations missing halfway through. This order costs less.

First, fix ingestion and identity.

Get data out of the source systems reliably, on a schedule that matches how it is used, and resolve customer and account entities across those systems. It is unglamorous and it is the single largest determinant of what becomes possible later. Nothing downstream works properly without it.

Second, make lineage automatic.

Every regulated number should be traceable to its sources by machine, not by memory. Build it in at the outset; retrofitting lineage across an established estate is one of the most expensive projects a bank can undertake, and it is always undertaken under deadline.

Third, add streaming only where money moves in real time.

Payments, fraud, limits and liquidity need it. Monthly management reporting does not. Treating streaming as a platform-wide upgrade rather than a targeted one multiplies cost and operational risk for no regulatory benefit.

Fourth, design for residency from the first diagram.

Sovereignty constraints are cheap to accommodate at design time and extremely expensive to retrofit. Decide where data will sit, who may access it from where, and how it leaves on termination, before the first service is provisioned.

Fifth, treat AI as a consumer of the platform, not a project beside it.

Models should draw on the same governed, lineage-tracked data as regulatory reporting. Where they draw on a parallel set of hand-built extracts, the institution has quietly created a second, ungoverned data estate, and it will be asked to explain it.

Conclusion

The regulatory agenda in MENA banking has changed faster in the past three years than in the fifteen before it, and it has changed in a consistent direction. Open finance, instant settlement, expected credit loss modelling, financial crime supervision and AI governance all ask the same thing: produce accurate data on demand, quickly, and explain where it came from.

That is a description of a working data platform. Banks that build one solve these obligations as a class rather than one at a time, and each subsequent requirement gets cheaper instead of more expensive. Banks that treat every deadline as a discrete compliance project pay full price each time, and arrive at the next one no better prepared than they were for the last.

The deadlines are the visible part. The foundation underneath them is the work.

This article is part of the Kanidata insights library. For the foundations underneath it, start with What is Data Engineering? and Data Platform Evolution: From Paper Ledgers to the Lakehouse.