Client: Large Commercial Bank, Vietnam
Industry: Banking / Fintech
Engagement model: ODC / Dedicated Team
Team: 20 experts (Java, QC, Business Analysis), built around 1 technical architect and 3 senior backend developers
The Problem
Core banking modernization sits at an uncomfortable intersection. The business wants to move fast. Compliance and regulatory obligations don’t move fast, by design. Most teams end up picking one and quietly sacrificing the other.
This bank was living that tradeoff directly. Their T24 core banking system had stretched feature delivery past six months per cycle. Backbase expertise, the specific skill set needed to modernize the digital layer on top of T24, was hard to find and harder to hire for quickly. Every month spent training existing engineers on Backbase was a month not spent shipping.
The bank needed to accelerate development and shrink time to market. What made this harder than a typical modernization project: none of that could come at the cost of compliance. In core banking, a fast feature that creates a compliance gap isn’t a fast feature. It’s a liability with a deadline attached.
What We Built
The engagement ran as an ODC model: a dedicated team embedded directly into the bank’s delivery process, client-interviewed and approved before a single engineer was assigned.
Team structure
Twenty experts across Java engineering, QC, and business analysis, anchored by one technical architect and three senior backend developers. The architect role mattered specifically here: core banking integration work needs someone who can hold the full system’s compliance and architectural constraints in view while a larger team executes against it.
Core banking modernization: Backbase + T24
The team built complete architecture across eKYC, onboarding, credit card, deposit, savings, and lending, the core functional surface of a modern digital banking experience layered onto the bank’s existing T24 system. This wasn’t a bolt-on integration. It required deep, specific knowledge of how T24 and Backbase actually interact, which is exactly the expertise gap the bank was trying to close.
Module integrations within agreed SLAs
Beyond the core banking build, the team delivered integrations across insurance and retail modules, all within delivery SLAs agreed upfront with the client, not renegotiated as the engagement went on.
Tech stack: T24, Backbase, Java, Python.
The Outcomes
6x faster feature delivery
The headline number, and the one that mattered most to the bank’s roadmap. What had been a months-long cycle per feature compressed to weeks. In core banking, where every feature also needs to clear compliance review, that kind of speed only works if the underlying architecture was built correctly from the start. It wasn’t speed that cut corners. It was speed that came from getting the architecture right the first time.
20 additional engineers requested
The clearest signal of client confidence in this kind of engagement isn’t a satisfaction score. It’s what the client does next. This bank came back and added 20 more engineers to the engagement, effectively doubling the team’s size after seeing the first phase of delivery.
2 to 3 week resource turnaround
Once the engagement was running, adding capacity didn’t require restarting a hiring or vetting process from scratch. New resources could be turned around in 2 to 3 weeks, which matters enormously for a bank whose roadmap doesn’t pause while a new engineer is being sourced and onboarded.
Why the ODC Model Fit
Two things about this project made a dedicated team the right structural choice over a project-based or managed service engagement.
The skill gap was specific and ongoing, not a one-time need. Backbase and T24 integration expertise isn’t something the bank could quickly build in-house, and it wasn’t a need that would disappear after one project. An embedded team that could scale with the bank’s roadmap, rather than a fixed-scope project that ended and left the same skill gap behind, was the right fit.
The compliance context required continuity. Core banking work benefits enormously from a team that accumulates institutional knowledge of the bank’s specific compliance requirements over time, rather than a team that’s replaced or rotated between engagements. The ODC model’s continuity is what let the architecture stay coherent as the engagement scaled from the original team to double its size.
The Broader Lesson
“Move fast without compromising compliance” sounds like a tradeoff until you look closely at where the actual bottleneck was. It wasn’t compliance review slowing the team down. It was a skill gap, specific Backbase and T24 expertise, that made every feature take longer to build correctly the first time.
Solve the actual bottleneck, and speed and compliance stop being opposites.
Frequently Asked Questions
What does core banking modernization with Backbase and T24 actually involve? It typically involves building or modernizing the digital layer (onboarding, eKYC, lending, deposits) on top of an existing T24 core banking system, requiring specific expertise in how the two systems integrate, not just general banking software development experience.
Why did this engagement use an ODC model instead of a project-based contract? The skill gap was ongoing rather than one-time, and the compliance context benefited from a team that retained institutional knowledge over time. An embedded dedicated team fit that need better than a fixed-scope engagement that would end and leave the same gap behind.
How fast can a dedicated offshore team scale once an engagement is running? In this case, additional resources were turned around in 2 to 3 weeks once the engagement was established, since the vetting and onboarding process was already in motion rather than starting from scratch.
Related Reading
If your team is navigating a similar tradeoff between delivery speed and compliance, that’s worth a direct conversation. We’ll give you an honest read on where the actual bottleneck is.
