When a UAE bank decides to augment rather than replace its core, the project is almost always scoped around the new thing: the digital app, the SME platform, the onboarding journey, the payment capability. The proposal describes what the bank will be able to do that it could not before, and that is what gets priced, planned, and approved. The augmentation then runs into the same wall again and again, and the wall is always in the same place. The project is not decided by the capability being built. It is decided by what the existing core will expose to it, and that boundary is the one thing the scope rarely maps before the bank is committed.
This piece is a perspective on why core banking augmentation projects are governed by the core's exposure surface rather than the capability being added. The argument is opinionated. We are not arguing that augmentation is the wrong choice, in many UAE banks it is the right one, or that delivery teams are weak. We are arguing that an augmentation is only ever as capable as what the core will reliably expose: real-time positions, safe write-back, event notification, a coherent data model, and enforceable entitlements; that scoping the new capability while assuming the exposure surface is the characteristic way these projects overrun; and that the exposure boundary is cheap to map before commitment and expensive to discover after. Augmentation is not building on top of the core. It is building within the limits of what the core hands out.
The audience for this analysis is CIOs, CTOs, heads of digital, and architecture leads at UAE banks choosing or running an augmentation over a core replacement, who have seen a well-scoped capability stall against the core it depends on. The useful diagnostic question is not "what capability are we building" but "have we mapped exactly what the core will expose, in real time, for write, as events, with what data model and entitlements, before we committed the plan and the price".
The Boundary the Project Is Actually Built Against
Below is the augmentation pattern as it actually is: a new capability layer, the existing core as the system of record, and between them the exposure boundary that decides everything. The point is not that augmentation is fragile; it is that the project's real constraints all sit on that dashed line, and scoping the layer above it while assuming the line is what produces the overruns. Tap any boundary point to see why it decides the build, how it fails when assumed, and what mapping it first changes.
The augmentation boundary: what the core will expose
Tap a boundary point for why it decides the build and what mapping it changes
Why the Exposure Surface, Not the Capability, Governs
The reason the exposure surface governs is that an augmentation, by definition, does not own the system of record; the core does. Every meaningful thing the new capability does, show a true balance, let a customer act, react to a change, honour a limit, is ultimately a request to the core to read or write something, and the core answers only within what it exposes. The capability layer can be designed beautifully and still be bounded by a core that returns yesterday's position, accepts no safe write, emits no events, or hides its data model. The ceiling is set by the boundary, not by the ambition of the layer above it, and a project that scopes the layer without measuring the boundary has planned the part it controls and assumed the part that decides it.
The UAE context makes augmentation common and the boundary consequential at the same time. There are 62 licensed banks in the UAE, operating in a market the CBUAE is actively modernising, the CBUAE's FIT programme reached around 85 per cent completion across its nine initiatives as reported for 2024, so banks face real pressure to deliver new digital and payment capability quickly. Augmentation is frequently the rational way to move fast without a multi-year core replacement. But moving fast on top of a core whose exposure surface has not been mapped means the speed is borrowed against a boundary that has not been checked, and the same modernisation pressure that makes augmentation attractive also makes the unmapped boundary more likely, because the scoping time gets compressed.
This is why the failure is structural rather than a delivery shortcoming. A strong team can build the capability exactly as specified and the project still stalls, because the specification assumed an exposure the core does not provide, and no amount of build quality changes what the system of record will hand out. The bank exposed here is not the one that chose augmentation, or chose a weak vendor; it is the one that scoped the new capability and never mapped, in concrete terms, what the core would actually expose to it, so the boundary was discovered in build rather than decided in scope.
The shift in one observation
An augmentation read as building a new capability produces a plan scoped around the capability. Read as building within the core's exposure surface, it produces a boundary map made before commitment. The banks whose augmentations overrun are usually the ones that scoped the layer and assumed the line. The ones whose hold are the ones that mapped the line first and scoped to it.
Where the Capability-First Scope Breaks
Scoping the new capability while assuming the exposure surface breaks in four predictable places.
Real-time assumed, not confirmed
The capability is built to be live while the core only exposes end-of-day positions. It demonstrates perfectly on extract data and produces customer-facing errors and reconciliation breaks in production, where the staleness finally shows.
Write-back over-scoped
The capability promises customer actions the core's write surface cannot safely accept. Teams build indirect or batched posting workarounds, introducing failure modes between the new layer and the system of record that are hard to detect and reconcile.
Events that do not exist
The experience is designed to be reactive over a core that emits no events, forcing constant polling. It looks responsive in testing and degrades under real volume because the core never signals that anything changed.
Controls re-implemented
Entitlements and limits the core does not expose get re-implemented in the new layer, risking divergence from the system of record, or omitted, risking control failure. Both are discovered late and both are serious in a supervised bank.
The Numbers
Two Ways to Scope an Augmentation
The difference between augmentations that hold their plan and those that stall is whether the exposure boundary is mapped before commitment or assumed.
| Dimension | Capability-first scope | Boundary-first scope |
|---|---|---|
| What is scoped | The new capability, in isolation. | The capability within the mapped exposure surface. |
| Real-time data | Assumed available. | Confirmed, or designed around if it is not. |
| Write-back | Scoped to the demo. | Scoped to what can be posted safely. |
| Events | Presumed to exist. | Treated as a scoping input. |
| Entitlements | Re-implemented or omitted late. | Honoured from the core by design. |
An augmentation is only ever as capable as what the core will reliably hand out. A project that scopes the new layer and assumes the exposure boundary has planned the part it controls and guessed the part that decides it, which is why the wall is always in the same place.
What Boundary-First Scoping Looks Like
The pattern in augmentations that hold their plan is recognisable. Before commitment, the exposure surface is mapped in concrete terms: whether the core serves real-time positions or only end-of-day, what can be written back and how safely, whether it emits events or must be polled, how coherent and accessible its data model is, and which entitlements and limits it exposes. The capability is then scoped to that surface, designed around the constraints rather than into a wall, with the augmentation pattern chosen to fit what the core actually provides. The boundary becomes a known input to the plan and the price rather than a discovery during the build, and the new capability is sized to what can be delivered reliably rather than to what a demonstration on convenient data implied.
This does not mean replacing the core; the whole point of augmentation is to avoid that, and it remains the right call in many UAE banks. It means treating the exposure boundary as the first scoping activity, not an implementation detail. Where the core exposes too little for the intended capability, that is itself the most valuable early finding, because it changes the pattern, the price, or the sequencing before money is committed rather than after. What the core will expose, and therefore what the augmentation can be, is specific to the core in place and is established in scoping before any build commitment.
How This Sits Alongside the Bank's Own Responsibilities
The configuration keeps a clear separation. The bank owns its core platform and vendor relationship, its architecture decisions, its risk and control framework, and its own compliance with the CBUAE framework. The software work is the delivery: mapping the exposure boundary and building the augmentation within it.
This is the role BY BANKS is positioned for. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the bank that runs it. We do not make core platform or vendor selections for a bank, own its architecture or risk decisions, act as auditors, or act for or on behalf of the CBUAE or any core vendor, and we are not affiliated with or endorsed by any of them. The bank owns its core, its architecture, its controls, and its own compliance; we map the exposure boundary and build the augmentation to its direction within it. The accountable party leads and owns the obligations; we build to their direction.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: a bank choosing augmentation over replacement and wanting the plan to reflect what the core can actually provide; an architecture lead whose well-scoped capability has stalled against the core it depends on; or a CIO reviewing why digital projects keep hitting the same wall. The honest answer is usually the same: the exposure surface decides the build, the capability scope assumed it, and mapping the boundary before commitment is the cheapest risk reduction the project has.
For broader related work, see our perspective on why UAE banks keep losing money on analytics they already bought and our perspective on why global AML platforms keep needing custom work in the UAE. The applied work sits across our core banking augmentation, digital banking platform, and banking document management capabilities, within the broader banking software practice and our operational platforms work. Get in touch if a 45-minute conversation about a specific core's exposure surface would be useful.
Frequently Asked Questions
No. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the bank that runs it. We do not make core platform or vendor selections for a bank, own its architecture or risk decisions, act as auditors, or act for or on behalf of the CBUAE or any core vendor, and we are not affiliated with or endorsed by any of them. On any engagement, the bank owns its core, its architecture, its controls, and its own compliance. We map the exposure boundary and build the augmentation to the bank's direction; the bank owns the decisions.
No. Augmentation is frequently the right choice and avoids a multi-year replacement. The argument is about scoping it correctly: an augmentation is bounded by what the core exposes, so that boundary should be mapped before commitment rather than discovered in build. Done that way, augmentation is sound. The failure mode is not augmentation itself; it is scoping the new capability while assuming the exposure surface.
No. They are an observational generalisation of the exposure constraints that commonly decide augmentation projects, used to make the scoping point clear. They describe no specific bank, core platform, or vendor. The actual exposure surface differs by core and configuration, and the real boundary is established against the specific core in place, not from this generalisation.
The figures, 62 licensed banks as of 31 December 2024 and the reported FIT programme completion for 2024, are drawn from CBUAE published material and are summarised, not reproduced, and not advice. The authoritative figures and any updates are those issued by the CBUAE. They are used here only as market context; nothing in the architecture argument depends on their precise values, and banks should rely on official sources for current figures.
It still helps. For a project in flight, mapping the exposure boundary that the scope assumed converts hidden risk into a known set of constraints that can be managed through re-scoping, pattern change, and dependency planning rather than discovered as overrun. For one not yet committed, the same mapping done first lets the plan and price reflect what the core actually provides. The order is driven by where the unmapped exposure risk concentrates, which scoping establishes for the specific core.
Core banking augmentation is widely scoped around the new capability and is in practice decided by what the existing core will expose to it: real-time positions, safe write-back, events, a coherent data model, and enforceable entitlements. The capability layer can only ever be as capable as that boundary allows, and scoping the layer while assuming the boundary is the characteristic way these projects overrun, made more likely by the modernisation pressure that makes augmentation attractive in the first place across the UAE's 62 licensed banks. The banks whose augmentations hold their plan are the ones that mapped the exposure surface before commitment and scoped to it. The build is software work; the core, the architecture, the controls, and CBUAE compliance remain entirely the bank's, and the work simply maps the boundary that decides the project and builds the capability within it rather than into it.
References to the UAE banking market and the CBUAE FIT programme are descriptive of publicly available official sources and are summarised, not reproduced. Figures cited (62 licensed banks in the UAE as of 31 December 2024; approximately 85% reported completion of the CBUAE FIT programme across its nine initiatives, as reported for 2024) are drawn from public sources listed on our Sources and Data page; the exposure-boundary model is an observational generalisation rather than a description of any specific core platform, vendor, or bank. BY BANKS is an independent software engineering company; we do not select or replace core banking platforms for a bank, own its architecture or risk decisions, act as auditors, or act for or on behalf of the CBUAE or any core vendor, and we are not affiliated with or endorsed by any of them. On any banking engagement, the bank owns its core, its architecture, its controls, and responsibility for its own regulatory compliance. This article is not architecture, procurement, regulatory, or legal advice; banks should obtain qualified advice for their specific obligations. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation