Bank Digital Programmes Don’t Stall on Execution. They Stall Two Levels Above It.
Leonid Goriev
Founder of Alty
July 16, 2026
On the most common failure mode we see in financial services transformation, and why the team that gets blamed is rarely the one that caused it.
Two years into a digital transformation programme, the honest status update is usually quieter than anyone planned for. The budget was approved, the roadmap exists, a team was hired or a vendor brought in — and yet the product looks much as it did at the start.
Nothing failed outright, which is part of the problem. There was no collapse to point at, no single decision to reverse. Progress just thinned out, until it was hard to say when anything last moved.
When this happens, the first explanation people reach for is usually the wrong one — talent, budget, vendor quality, sometimes the technology stack. What actually sits underneath is harder to see, and much harder to name in a steering committee: the decisions that shaped the programme were made two levels above the people who had to execute them, and by people without the technical expertise to see what those decisions would cost. This is not a story about a bad team, but about a decision architecture that put the wrong people in charge of the wrong calls.
The pattern executives keep misdiagnosing
Here is how it usually unfolds. A programme is sanctioned at board level, and the strategic intent is clear: modernise, digitise, remove friction, protect the flanks from the challengers. Somewhere between that intent and the delivery team, a specific set of decisions gets locked in — the technology stack, the delivery framework, the design methodology, the timeline, the budget.
Those decisions are usually made by people who have institutional authority but not delivery experience. They come out of a committee, a consulting recommendation, or a compressed conversation with a vendor who told them what they wanted to hear.
The team that has to execute is handed the outcome and can see the problems immediately. They usually raise them, once, in a language that carries no weight against a signed-off business case. Then the work starts, and reality catches up in three phases.
First, the timeline slips — not because the team is slow, but because the plan was built without them. Second, scope compresses: the original scope was written by people who couldn't see the operational reality, so half of what was promised turns out to be technically dangerous to ship at the pace demanded, and the difficult conversation now happens after the commitment rather than before it. Third comes blame. When the programme misses its milestone, the visible failure is delivery, and the team is told — formally or informally — that it should have flagged the risks earlier, despite having done exactly that at the start. Someone gets restructured, a new vendor is brought in, and the cycle restarts on the same decision architecture that broke the last one.
According to Accenture, banks now spend close to 70% of their IT budgets simply keeping existing systems running. When most of the available capacity goes to holding the foundation steady, the decisions that would change it keep getting deferred to the next programme — which then repeats the same mistake at higher cost.
What a stalled programme looks like from inside the team
The programme could be at a UK Tier-1, a Continental European private bank, or a challenger scaling into new products. The specifics change; the mechanism underneath does not.
Product, design, and engineering each hold part of the picture, and the parts never resolve into one view, because no one senior enough to reconcile them is close enough to the work. A previous agency delivered what was scoped — a redesign, a set of new screens — and the underlying problem sits exactly where it was. Teams have grown wary of touching core systems, not for lack of skill, but because the last time someone tried, the incident report went to the CEO.
The written status is green. The lived status, if you asked anyone on the delivery side, is that no one believes the current plan will land. From the outside, none of this looks like much. From inside the company, it is the difference between intending to modernise and being able to act on it.
Three programmes, the same underlying pattern
The examples below start from very different institutions and reach the same place.
A leading Nigerian bank, a market-defining incumbent
This bank had built its reputation on being first to move in its market. By the early 2020s, architectural decisions made years earlier by leadership without deep technical review meant that even small changes to its mobile platform carried real operational risk.
The engineering team knew what needed to happen, and said so. They also knew that the decisions they were being asked to execute would push a fragile foundation further out of alignment — so, every time, they hesitated.
The work started below the interface. We rebuilt the product architecture and technical foundation so the platform could evolve without threatening stability, then moved ownership of the roadmap back to the bank's own teams, structured so that technical expertise had a seat at the strategic table rather than just a task list.
The app's rating climbed from 3.4 to 4.7 and the platform scaled to millions of active users. The result that mattered most internally was quieter: the bank's own engineers could ship again, because the decisions above them were finally being made with their input in the room.
CBH, a Swiss private bank
CBH came to us with fragmented systems and manual processes. A previous agency engagement, chosen by leadership without a clear ownership plan, had left the bank with polished deliverables and no internal capacity to carry them forward.
The quicker route would have been an interface refresh; instead, the work began by consolidating the digital core and rebuilding the operating model. Regulatory and cybersecurity validation was designed into the architecture from the start rather than added later, at the request of the compliance function that had been treated as a downstream reviewer the first time.
The platform later cleared independent audits. Getting there depended on doing the structural work first, before anything client-facing, and on making the people who knew the regulatory reality co-authors of the plan instead of gatekeepers at the end of it.
Oschadbank, one of Ukraine’s largest banks
Oschadbank was losing deposits slowly and steadily. Customers used it for payroll, then moved their money to other apps for everyday spending.
The strategic explanation from the top was clear: build a better app. The product team that would have to build it knew a better app alone would not close the gap, and had been saying so. Leadership's commercial hypothesis assumed customers were leaving because of the UI, when they were leaving because there was nothing to keep their money in place between paydays.
Once the diagnosis was corrected, the work followed: building the daily-banking layer added more than two million new cards in the first year. The insight had existed inside the team the entire time, and reached the roadmap only after the decision-making structure changed.
What to do instead
Move technical decisions closer to technical expertise. The stack, the delivery framework, the sequencing, the architecture, the design methodology — none of these should be locked in by people who cannot describe the trade-offs. Leadership's job is to set the strategic intent and hold the outcome; the delivery team's job is to shape how that outcome gets built. Programmes stall when those roles get confused, and they usually get confused at the point where the plan is signed off.
Treat the delivery team as a source of intelligence, not a cost centre. The people building the product see the reality of the system every day, and their feedback is the highest-signal information available to leadership — almost always cheaper than the audit that follows a missed milestone. Programmes where that feedback loop is intact recover from setbacks; programmes where it is broken keep repeating the same one.
Deal with the foundation before the surface. A redesign laid over a fragile core takes on the fragility of the core. The unglamorous work — architecture, integration, the operating model — is what lets everything above it hold. If the team is already afraid to touch core systems, adding scope only raises what is at stake.
Plan the handover from the start. A programme isn't finished when the vendor leaves; it is finished when the internal team can carry the product forward on its own. That requires ownership to have been shared from day one rather than transferred at the end.
None of this is modernisation for its own sake. Getting the decision architecture right is what lets a bank move quickly afterwards, on a base it can trust. The three programmes above began from very different starting points and reached the same place: back in control of their own product, and able to keep changing it once we had gone.
Where this leaves us
I have spent fifteen years building digital products for banks and fintechs across the UK, the EU, and CEMEA. The pattern that stalls a programme is almost never a lack of effort or intent, but a decision-making structure that put the wrong people in charge of the wrong calls and left the team that could have prevented it with no way to be heard.
Fix the structure and movement returns; the programme starts to look like the one on paper. So if your current programme is quietly not moving, the question worth asking is not who to replace on the team, but which decisions above it should have been made with it — and whether the structure that produced those decisions is still the one making the next set.
Leonid Goriev is Co-founder of Alty, a digital product partner working with banks, fintechs, and regulated platforms across the UK and CEMEA.
