The Islamic contracts — Murabaha, Ijarah, Mudarabah, Musharakah — are core concerns, administered in FLEXCUBE Islamic Banking. OBDX's job is presentation: relabelled journeys, Islamic retail and corporate finance views, and a consolidated view where Islamic and conventional accounts share one login. That sounds like the easy half, and the scoping error is assuming it is. Relabelling interest as profit is not a string swap, and the consolidated view touches everything that aggregates.
This question arrives from two directions. Banks running an Islamic window ask whether OBDX can serve it alongside conventional accounts. Fully Islamic banks ask what they actually get out of the box. Both answers depend on the same thing: knowing which side of the channel-core line each requirement sits on.
Oracle ships dedicated documentation here — there are OBDX Islamic Banking user manuals for Corporate Islamic Finance and for retail Islamic accounts — and the product material describes coverage across accounts, term deposits and finance, with Islamic and conventional supported from a single platform.
The line that decides your budget
Here is the split that governs everything else. The Islamic contract types are not an OBDX feature. Murabaha and Ijarah account creation, and the profit-sharing structures Mudarabah and Musharakah, are FLEXCUBE Islamic Banking concerns. Oracle's core documentation describes Ijarah, for instance, as a lease where the bank purchases property or capital equipment and leases it to a customer. That is a product definition, and it is administered in the core.
The practical consequence: when someone asks for a product behaviour the bank does not currently offer, that is a core project with a core budget and a core owner. When they ask for it to be presented differently, that is yours. Teams that have not drawn this line spend the first month of delivery arguing about it.
Relabelling is not a string swap
Oracle's manual frames the Islamic treatment partly in terms of labels — they have been "adjusted and rechristened" for Islamic Finance in accordance with Islamic banking requirements. It is an accurate description and it is routinely misread as meaning the work is a translation file.
Replacing interest with profit changes the concept behind the number. The calculation, the disclosure, the supporting explanation and often the surrounding journey have to follow. A screen that says "profit" while showing a figure derived and presented exactly as interest was is wrong in a way no amount of copy editing fixes — and it is wrong in a domain where being wrong is a governance finding, not a bug report.
Treat the labels as the visible surface of a product decision. Someone qualified signs them off, and that someone is not the content designer.
The consolidated view is the underestimated piece
Oracle's retail manual describes Islamic and conventional accounts appearing together for a single customer. For a bank running an Islamic window alongside conventional operations this is exactly right, and it is where the engineering actually concentrates.
The reason is that everything which aggregates has to decide what to do with two kinds of product at once. The dashboard. The total balance. Transaction history. Statements. Search. Export. Notifications. Each of those needs a rule, and "sum them" is sometimes the wrong answer for reasons that are not technical. A view that silently blends Islamic and conventional holdings is a Shariah governance problem, not a display preference.
This is also where the testing load lands, because every aggregate surface now needs three cases: Islamic only, conventional only, and mixed.
Get the Shariah function in early
The sign-off path is different from a conventional programme and it catches teams out. The bank's Shariah board or supervisory function governs terminology, how profit is presented, which disclosures appear and where in a journey they sit, and how an Islamic product may be described alongside a conventional one.
Engineering teams used to clearing copy with marketing and compliance tend to discover this at user acceptance testing, by which point the journey structure may need to change. Putting the review into the sprint cadence costs very little. Finding it late costs a release.
What this means for cost
An Islamic OBDX deployment generally costs more than a conventional one and much less than two deployments — which is the comparison that matters when the alternative is running separate platforms for the window and the conventional bank.
The extra effort concentrates in three places: the consolidated view and its aggregation rules, the terminology and disclosure work with its additional sign-off, and testing, since every journey gains an Islamic variant. The contracts themselves are core work and sit outside the channel budget entirely — which is worth stating plainly in a business case, because otherwise someone will later ask why the channel programme did not deliver a product the channel was never going to deliver.
One honest limit on this article: we could not find OBDX-specific public documentation covering profit-sharing account journeys in detail. The contract types are clearly core-side, but if Mudarabah or Musharakah servicing is central to your roadmap, confirm the channel coverage against the manuals for your release rather than inferring it. The same version caution applies here as everywhere in OBDX.
Questions we get asked
Does OBDX support Islamic banking?
Yes — Oracle ships OBDX Islamic Banking user manuals for Corporate Islamic Finance and retail Islamic accounts, with coverage described across accounts, term deposits and finance, and Islamic plus conventional supported from a single platform. What you get is the servicing experience, not the products.
Where do Murabaha and Ijarah live?
In the core. Murabaha, Ijarah and the profit-sharing structures Mudarabah and Musharakah are FLEXCUBE Islamic Banking concerns — Oracle describes Ijarah as a lease where the bank buys property or equipment and leases it on. A missing contract is a core project with a core budget, not a channel one.
Can Islamic and conventional share one login?
Yes — the retail manual describes them appearing together as a consolidated view. It's the most underestimated requirement in scoping, because everything that aggregates (dashboard, totals, history, statements, search, export) now needs a rule, and silently blending them is a governance problem rather than a display one.
Is it just relabelling?
Oracle's manual does describe labels "adjusted and rechristened" for Islamic Finance — but swapping interest for profit changes the concept, so calculation, disclosure and explanation must follow. A screen saying "profit" over a figure derived as interest is wrong in a way no translation file fixes.
Who signs off the journeys?
The bank's Shariah board or supervisory function — and from the start, not before launch. They govern terminology, how profit is presented, which disclosures appear where, and how Islamic products are described alongside conventional ones. Build the review into sprint cadence.
Does it cost more?
More than a conventional deployment, far less than two. The extra lands in the consolidated view and its aggregation rules, the terminology and disclosure sign-off, and testing — every journey gains an Islamic variant. The contracts are core work and outside the channel budget.
We build the mobile layer on OBDX deployments across the GCC and wider MENA region, where Islamic and conventional frequently sit side by side. If you are scoping one, the channel-core line is the first thing worth drawing — most of the budget argument resolves once it is on paper.