There are four shapes: on-premise, and IaaS, PaaS or SaaS on Oracle Cloud Infrastructure. The sales conversation runs on cost; the actual decision usually runs on data residency, which a supervisor hands you rather than you choosing. The second deciding factor is how much you intend to customise — and the public material does not clearly say what extensibility survives under SaaS, which makes it the thing to get answered in writing before you sign anything.
Oracle Banking Digital Experience has been available on Oracle Cloud Infrastructure for a while now, and the deployment question has quietly become the first architectural decision on most OBDX programmes — made before anyone has looked at a journey or an adapter. It deserves more care than it usually gets, partly because the comparison most banks are shown is a cost slide.
What you actually operate in each model
Oracle's own description is useful here: the infrastructure tier works the same way across the three cloud models, the implementation differs somewhat between IaaS and PaaS, and under SaaS implementation is not required at all. The part that catches people is IaaS — it is cloud, but the bank still handles network, compute, storage and database setup itself, which means the project needs genuine OCI capability on the team or from a partner.
Residency decides it before cost does
Oracle's own OBDX material acknowledges that some regulations restrict where data can be stored or processed, and that this can push banks toward on-premise or private cloud. For a regulated bank that is not a preference to weigh against savings. It is a constraint handed down by a supervisor, and it removes options before the commercial conversation starts.
Where the rules permit cloud but require data to remain in-country, Oracle positions OCI Dedicated Region as the sovereignty answer — a full OCI region placed inside the customer's own data centre. That is a genuine middle path and worth understanding properly, but it is a substantial commitment rather than a configuration option.
This is the same force we see shaping AI deployments in banks, for much the same reasons, and we wrote about how it plays out there in on-prem versus cloud inference.
The cost claim, handled honestly
Oracle publishes figures putting OCI at roughly half the total cost of ownership of on-premise, with bring-your-own-license available for database services and spending shifted to operating expense. Those are the vendor's numbers. They are not independent benchmarks and they are not wrong for that reason — but they describe a generic comparison, and your bank is not generic.
The model that should decide this includes your existing Oracle licence position, what your data centre actually costs you today including the share of staff you would not shed, and the people you would need under each option. An IaaS deployment does not remove the need for infrastructure skills; it changes which ones. Teams that model cloud as "the same work, cheaper" are usually disappointed in year two.
The question the public material does not answer
Here is the gap worth knowing about before you walk into a vendor meeting. Oracle describes the on-premise model as letting banks build custom APIs, widgets and screens using low-code tooling, including an API toolkit and a drag-and-drop UX toolkit. Separately, it says the SaaS model requires no implementation.
Those two statements do not combine into a clear picture of what extensibility survives under SaaS. We could not find a published side-by-side comparison of the managed service against a self-managed deployment, and we are not going to guess at one — the honest position is that it is unclear from public material.
That matters more than it sounds, because for a lot of banks the extensibility is the reason to pick OBDX. If your value comes from the adapter layer reaching a particular core, from custom journeys, or from a mobile client you control, then a model described as requiring no implementation is a materially different product and needs to be understood as one.
Four things to get in writing
Which extensibility mechanisms exist in each model — name them: the adapter layer, custom services, UI customisation. Where data resides and is processed, by named region, in each model. Upgrade cadence and control, because a managed model generally means upgrades happen on the provider's schedule, which has consequences for a bank with its own change freeze calendar. And the exit path — what travels if you move between models later.
No datasheet answers these. They come from the account team, in writing, before signature. A vendor confident in the answers will not mind the questions.
Questions we get asked
What are the deployment options?
On-premise, plus IaaS, PaaS and SaaS on OCI. Oracle notes the infrastructure tier works the same across the three cloud models, implementation differs between IaaS and PaaS, and SaaS requires no implementation. Under IaaS the bank still handles network, compute, storage and database setup.
Is cloud cheaper?
Oracle publishes roughly 50% lower TCO on OCI with bring-your-own-license for database, shifting spend to opex. Those are vendor figures, not independent benchmarks — a starting position for negotiation. Model it against your own licence position, data centre costs and the people you'd need either way.
What usually decides it?
Data residency, before cost. Oracle's own material acknowledges regulations restricting where data is stored or processed can push banks to on-premise or private cloud. That's a supervisor's constraint, not a preference. Where cloud is allowed but data must stay in-country, OCI Dedicated Region is positioned as the answer.
Does SaaS limit customisation?
We won't assert either way from public material — and that's the point. Oracle describes on-premise as supporting custom APIs, widgets and screens via low-code tooling, and separately says SaaS needs no implementation. Those don't combine into a clear answer. Since extensibility is often the whole reason to pick OBDX, get this in writing.
What should we ask Oracle?
Which extensibility mechanisms exist per model, named. Where data resides and is processed, by region. Upgrade cadence and how much timing control you keep. And the exit path — what's portable if you move models later. No datasheet covers these.
Can we start on one model and move?
It's the same product, so the question is how much of your deployment travels. Documented extension points tend to move; operational things tend not to — integration endpoints, network paths, monitoring, pipelines, and assumptions your adapters make about reaching the core. Plan the first choice as durable.
We work on the mobile layer of OBDX deployments across all of these models. If you are choosing between them, the extensibility question is the one we would push hardest on — it is the one that determines whether the rest of your roadmap is possible.