Oracle Banking Digital Experience is built to be extended, and its central promise is that extensions stay separate from core so that most customisations written for one release sit on top of an upgraded one. That promise holds — for work done through the documented extension points. Upgrade pain almost always traces back to a team that could not find the supported route for something and edited a core artefact instead. The useful knowledge is therefore not "how do I change this", it is "which tier is this change supposed to happen in, and what will that tier not let me do".
Search for help with this and you get Oracle's own documentation, a handful of job postings, and very little in between. The documentation is good, but it is organised as reference rather than as guidance, which makes it hard to answer the question a team actually has in week one: where is this change supposed to go?
What follows is that map. It is drawn from Oracle's extensibility and UI extension guides rather than from any one project, so check it against the guide for your specific release — the model has been stable across the 18.x to 25.x line, but details move.
The promise, and its one condition
Oracle's design intent is explicit: extensions are kept separate from core, so a bank can take advantage of core upgrades because most extensions written for a previous release can sit directly on top of the upgraded version. That is the whole reason the extensibility model exists, and it is the reason an OBDX estate can stay current rather than freezing on the version it was customised against.
The condition is the part that gets lost. The guarantee covers work done through the extension points. A change made by editing a shipped artefact is outside it — and will be overwritten, silently, by the next upgrade. Nearly every horror story about OBDX upgrades is a story about a change that went somewhere it was not meant to go, usually because the supported route was not obvious and a deadline was.
UI tier: overrides, and what an override consists of
UI customisation happens under the channel's extensions folder rather than in the shipped component. Overriding an existing component is not a single file — you need a ViewModel, an HTML file and a resource bundle, with a model and a partial optional depending on what you are changing.
Three related places are worth knowing early, because teams otherwise invent their own conventions and then cannot find anything:
- Validation overrides go in the extensions override locale file — from release 18.2 onward,
extensions\override\obdx-locale.js. - Segment and user-type logic is evaluated in
extensions/override/extensions.js. - Menu overrides require a declaration in
extension.json. A menu change that does not work is very often a missing entry here rather than a broken component.
REST tier: add, do not alter
This is the constraint that most often forces a design rethink, and it is worth internalising before scoping: extensibility in the REST tier is limited to writing new services. The out-of-the-box REST services cannot be customised.
So when an existing endpoint nearly does what you need but not quite, you have two supported options and one unsupported one:
- Write a new REST service of your own that composes or replaces it.
- Leave the endpoint alone and change behaviour further down, in the service tier, through hooks.
- Edit the shipped service. This works until the next upgrade, which is the definition of the trap.
The second option is usually right and usually not the first instinct, because the change feels like an API change.
Service tier: pre and post hooks
The application service layer — the app layer — provides pre and post extensions around the out-of-the-box service logic. A pre hook runs before the standard logic and can validate or enrich the request; a post hook runs after and can act on the result.
This is the main supported route for changing behaviour, and the tier where most genuine business customisation belongs. If a requirement is about what happens rather than what it looks like, start here before reaching for anything else.
On validations specifically: out-of-the-box business validations can be overridden through business policies. What cannot be touched is the set of checks OBDX performs mandatorily — more on that below.
Adapter tier: two artefacts, not one
Adapters are the seam between OBDX and whatever sits behind it, which makes them the tier that matters most in a core banking integration.
Changing an existing adapter does not mean editing it. The supported route is to develop a new custom adapter and a corresponding adapter factory, overriding the specific methods you need in the custom adapter class. The factory is what causes OBDX to resolve your implementation rather than the shipped one — which is why this is always a two-artefact job, and why "I wrote the adapter but it isn't being called" is nearly always a missing or unregistered factory.
The floor you cannot move
OBDX performs certain checks unconditionally, and these cannot be overridden or bypassed. Not through business policies, not through hooks.
This sounds obvious written down and is routinely assumed away in early scoping, usually because a business stakeholder has described a flow that quietly requires skipping one. Finding out in build is expensive; finding out in UAT is worse. It is worth an explicit session early in a programme to walk the proposed journeys against the mandatory checks and confirm none of them depends on a check not firing.
How to keep upgrades boring
Five habits, all cheap, that separate estates which upgrade smoothly from those that do not:
- Treat "which tier does this belong in" as a design decision with a named answer, recorded. Not a thing each developer resolves individually under time pressure.
- Keep an inventory of every extension, with the tier and the artefacts involved. At upgrade time this is the test plan; without it, the test plan is the whole application.
- Never edit a core artefact. If there appears to be no supported route, that is a question for Oracle, not a licence to improvise.
- Pin the release you are customising against and read that release's guide. The model has been stable from 18.x through 25.x, but specifics have moved and the guides are versioned for a reason.
- Rehearse the upgrade on a copy before it is scheduled. The inventory tells you what to check; the rehearsal tells you what the inventory missed.
None of this is sophisticated. It is simply the difference between an OBDX estate that takes Oracle's upgrades and one that is quietly frozen three releases back because nobody is confident about what would break.
Questions we get asked
Do OBDX customisations survive an upgrade?
They are designed to. Extensions are kept separate from core, so most extensions written for a previous release sit directly on top of an upgraded one. The qualifier matters: that holds for work done through the documented extension points. Changes made by editing core artefacts are outside the guarantee.
Can you customise the out-of-the-box REST services?
No. Extensibility in the REST tier is limited to writing new services; shipped endpoints cannot be modified. If an existing endpoint is close but not right, write a new service, or change behaviour further down in the service tier through hooks.
What are pre and post hooks?
Extension points in the application service layer that run before and after the out-of-the-box logic. A pre hook validates or enriches the request; a post hook acts on the result. They are the main supported way to change behaviour without touching the shipped service.
How do you change an existing adapter?
You do not edit it. Write a new custom adapter plus a corresponding adapter factory, and override the specific methods you need. The factory is what makes OBDX resolve your implementation — which is why "my adapter isn't being called" is usually a missing factory.
What can you not override?
Mandatory system checks. Out-of-the-box business validations can be overridden through business policies, but certain checks are performed unconditionally and cannot be bypassed. Walk proposed journeys against them early — this assumption tends to surface late.
What does a UI component override need?
A ViewModel, an HTML file and a resource bundle, with a model and partial optional, placed under the channel's extensions folder. Validation overrides go in the extensions override locale file, segment logic in the extensions override script, and menu overrides need an entry in extension.json.
We build customer-facing apps on top of existing OBDX deployments, which means living with this model rather than reading about it. Appsarmy is not an Oracle partner — this is implementation experience, not a reseller relationship.