"OBDX developer" is not one skill, it is four stacked — Java backend, Oracle database, a Knockout.js front end, and the OBDX platform itself. The first two you can hire in any market. The third is a framework almost nobody has learned recently, so a strong React developer is not an OBDX UI developer. The fourth has no public learning path at all, which is the entire reason the role is hard to fill and why postings ask for anything between two and ten years with no consistency.
This is written for whoever has to produce the job description, or decide whether to hire, train or augment. It is deliberately specific, because the generic version of this advertisement — "OBDX developer, 5+ years" — attracts three different kinds of applicant and gives you no way to compare them.
Four layers, and only two of them are ordinary
Current job postings are consistent about what the role requires, and reading several together makes the structure obvious.
The Knockout problem
Postings name Knockout.js specifically for OBDX UI customisation, and this catches banks out more than anything else on the list.
Knockout is not a framework many developers have picked up in the last several years. The consequence is direct: a strong React or Angular engineer is not an OBDX UI developer on day one. The concepts do transfer and a good engineer absorbs the syntax quickly, so it is a closeable gap — but it has to be planned rather than assumed, and it is a common reason a new hire is slower in their first month than the interview suggested.
It also means your framework preferences elsewhere are irrelevant here. A bank standardised on React still needs Knockout for this layer, unless it is building a custom client against the OBDX APIs instead — which is a different architectural decision, and one we covered in remote UI or local UI.
Why the platform layer cannot be hired for
This is the structural problem, and it is worth understanding rather than working around.
A React developer can learn from free documentation, open-source code, courses and an enormous community, so supply responds to demand within a year or two. OBDX has none of that. The documentation is version-specific PDFs and webhelp; much of the genuinely operational material sits behind Oracle support rather than the open web; and there is no open-source ecosystem to read or contribute to. We ran into exactly this writing about OBDX performance — no public tuning guidance exists at all.
So the knowledge is acquired almost exclusively by working on a live implementation, at a bank or an implementation partner. That is a supply constraint recruitment budget does not quickly fix, because the training pipeline is other people's projects.
Why the postings disagree with each other
Read a few advertisements together and the experience requirements make no sense: two to six years in one, seven or more in another, eight to ten in a third. They are not describing the same job.
In practice the role splits three ways. There is UI customisation work, which is Knockout plus the extensibility framework. There is integration work on the adapter layer and the host boundary, which is Java and a strong stomach for someone else's core. And there is the systems analyst variant, which needs deep platform knowledge and relatively little hands-on coding.
A bank advertising generically for an "OBDX developer" receives all three and has no basis for comparison. Naming which one you want is the single highest-leverage edit to the job description.
What to screen for
Four questions that separate real experience from exposure.
Which release? The specifics vary between versions, and someone who knows one may be describing a system you do not run.
What did you change, and at which tier? A UI override and an adapter implementation are different kinds of work requiring different judgement. Vague answers here usually mean the person was adjacent to the work rather than doing it.
What happened at the host boundary? Integration is where the difficulty concentrates, as we set out in connecting OBDX to a core that isn't FLEXCUBE. Someone who has genuinely worked there has stories about error translation.
Tell me about an upgrade you lived through. The gap between someone who customised carefully and someone who did not is nowhere more visible — the themes are in customising OBDX without breaking your next upgrade.
How scarce, really
Scarce enough to shape a project plan rather than merely a salary band. A search of one major Indian job aggregator returned eight OBDX roles in total, which is a small number for a market that size, and those roles cluster among implementation partners and banks rather than spreading across the industry.
We would treat that as an indicator rather than a measurement — it is one snapshot of one site. But it matches what we see: the people exist, there are not many, and most are already on an implementation somewhere.
Which leaves three honest options for a bank with an OBDX roadmap and no OBDX team. Train internally from your Java engineers, accepting that the platform layer takes real time and a live project to acquire. Hire, accepting a long search. Or augment with people who already have the fourth layer, and use the engagement to transfer it. Most banks end up doing some combination, and the mistake is assuming the first option is faster than it is.
Questions we get asked
What skills does the role need?
Four layers: Java/J2EE with Spring or Struts and REST; Oracle SQL and PL/SQL; a front end on Knockout.js, which is what OBDX UI customisation uses; and OBDX platform knowledge itself — extensibility framework, Development Workbench, adapter layer. The first three are ordinary enterprise skills. The fourth makes the role hard to fill.
Why can't you hire this like a React developer?
No public path into the platform layer. React has free docs, open source, courses and a huge community, so supply responds to demand. OBDX has version-specific PDFs, material behind Oracle support, and no open-source ecosystem. Experience comes almost only from a live implementation — a constraint budget doesn't quickly fix.
Is Knockout.js a real constraint?
More than expected. Postings name it specifically, and few developers have learned it recently — so a strong React or Angular engineer isn't an OBDX UI developer on day one. Closeable, since concepts transfer, but plan for it rather than assume it, or your new hire is slower than the interview suggested.
Why do postings disagree on experience?
Because the market has no shared definition. Current listings ask 2–6 years, 7+, and 8–10 — they're describing different jobs: UI customisation, adapter-layer integration, or a systems analyst role needing platform knowledge and little coding. Advertise generically and you get all three with no basis to compare.
What should we screen for?
Which release they worked on; what they changed and at which tier (a UI override and an adapter implementation are different work); what happened at the host boundary, where difficulty concentrates; and an upgrade they lived through, which exposes whether they customised carefully.
How scarce are they?
One major Indian aggregator showed eight OBDX roles in total — small for that market, and clustered among implementation partners and banks. Treat it as an indicator, not a measurement. It matches practice: the people exist, there aren't many, and most are already on an implementation.
We work on OBDX deployments as the mobile and integration layer, which means we spend our time in the two layers the market does not supply. If you are writing the job description, naming which of the three roles you want is worth more than any other edit.