Digital Transformation Horror Stories: Financial Services
Financial services digital transformation fails in recognisable patterns. A core banking migration scoped at eighteen months that ran for four years, consuming a budget that could have funded three separate capability builds. A compliance platform that processed data correctly but could not connect to the reporting layer that the regulator actually required. A robo-advisory that impressed the product team and confused the clients. Three failure patterns — and the better approach each time.
Financial services organisations spend more on technology than almost any other industry. Global banking technology spend exceeded $650 billion in 2025. The outcomes relative to that spend are, to put it charitably, variable.
Core banking migrations that take twice as long as scoped and cost three times the original budget. Regulatory technology implementations that solve the data problem but not the reporting problem. Customer-facing digital innovations that win awards at FinTech conferences and generate modest adoption among actual customers.
These patterns are well-known to anyone who has worked in financial services technology. They are rarely discussed publicly because the organisations involved have reputations to protect and regulatory relationships to maintain. They are discussed extensively in private — in the conversations between CTOs and CFOs who are trying to understand why the last programme went wrong before they commit to the next one.
This article describes three of those conversations. Not to assign blame, but because the failure patterns are predictable, the causes are identifiable, and the better approach — for each one — is available to mid-market financial services organisations that understand what went wrong before they begin.
Horror Story One: The Core Banking Migration That Took Four Years
A regional bank with £800M in assets decided to migrate from its legacy core banking system — a platform that had been in place for nineteen years and was increasingly difficult to integrate with modern digital channels — to a modern cloud-native core. The business case was sound: the legacy system's API limitations were preventing the bank from offering the digital account management and instant payment capabilities that challenger banks were providing as standard.
The vendor's implementation timeline: eighteen months. The actual timeline: four years and three months. The original budget: £4.2M. The final cost: £11.8M. The outcome: a functioning modern core — but the digital channel integrations that had justified the migration were still incomplete at go-live because the integration specifications had been deprioritised during the extended delivery period to reduce scope and hit a deadline.
The bank's CTO described the project in a conversation with peers: "We kept changing the scope to fit the timeline, and then changing the timeline to fit the scope. By year three, neither the scope nor the timeline had any relationship to what we'd agreed in the business case."
What went wrong: The migration was scoped as a single programme rather than as a staged delivery of independent capabilities. When the programme ran into difficulty — data migration complexity that had been underestimated, integration challenges with the existing products system, staff changes mid-programme — the entire scope moved rather than individual components. The digital channel integrations that justified the investment were in scope for the full four years without delivering any value.
The better approach: Core banking migration should be approached as a capability release programme, not a monolithic project. Identify the specific capabilities the migration must deliver — instant payments, open banking APIs, real-time account management — and scope the migration as the sequence of releases that enables those capabilities, each of which can be delivered and tested independently. The first release delivers value. The second release adds value. The migration is a programme of incremental improvements rather than a four-year commitment with a single go-live.
Horror Story Two: The Compliance Platform That Didn't Connect to Reporting
A specialist asset manager with regulatory reporting obligations to the FCA implemented a compliance data management platform to address a known weakness: their compliance team was spending 35 hours per week manually reconciling position data from the portfolio management system into the regulatory reporting templates. The platform they selected — a well-regarded enterprise compliance tool — processed their data correctly and maintained the audit trail the regulator required.
It did not connect to the FCA's reporting portal.
Not because the connection was technically impossible. Because the integration between the compliance platform and the specific regulatory submission system the FCA used had been listed in the contract as "Phase 2 scope" — a detail that had not been surfaced clearly enough in the evaluation process for the compliance team to understand that the core reporting function they were buying the platform to achieve would not be delivered in the initial implementation.
Twelve months after go-live: the compliance team was processing data in the compliance platform, then manually exporting it and reformatting it for FCA submission. They were spending 28 hours per week instead of 35 — a modest improvement at a cost of £380,000.
What went wrong: The evaluation assessed whether the platform could manage the data. It did not assess whether the platform's regulatory reporting outputs were compatible with the specific submission format the FCA portal required. "Regulatory reporting capability" as a feature in a vendor's product description does not mean "produces the specific XML schema that FCA Gabriel accepts." The integration requirement was specific, testable, and should have been verified before contract signature.
The better approach: For any compliance technology investment, the end-to-end reporting chain must be validated before selection — from data source through the platform to the specific regulatory submission format. The question is not "does the platform support regulatory reporting?" but "does the platform produce the exact output format that our specific regulator's submission system accepts?" These are different questions with different answers, and only one of them determines whether the investment delivers the outcome it was purchased to achieve.
Horror Story Three: The Robo-Advisory That Confused More Clients Than It Helped
A mid-market wealth manager launched an AI-powered robo-advisory capability — a digital investment recommendation system that would make portfolio recommendations to retail clients based on their stated risk profile, investment goals, and time horizon. The product team was genuinely excited about it. The technology worked. The recommendations were algorithmically sound.
Eighteen months after launch: 340 registered users out of a client base of 4,200. Of those, 180 had made at least one investment decision based on the recommendation. Seventeen had complained — not about the recommendations themselves, but about the explanations. The system explained its recommendations in terms of Sharpe ratios, standard deviation of returns, and efficient frontier positioning. The clients it was designed to serve were small business owners and professionals who understood investment as "growing their money" and risk as "losing their money."
The robo-advisory did not speak their language. It spoke the language of the product team that built it.
The compliance team had also required that every recommendation include a full regulatory disclosure — several screens of small-print disclosure that preceded the recommendation itself. Most users who reached the recommendation screen had clicked through the disclosure without reading it. A small number had been genuinely confused by it and called the firm's client services team to ask whether the AI was actually authorised to give them advice.
What went wrong: The product was designed from the inside out — from the technical capability and the compliance requirement toward the client, rather than from the client's understanding and expectations toward the technical capability. The client research that should have preceded the design phase — understanding how the target clients thought about investment decisions, what language resonated with them, what would make a recommendation credible rather than confusing — was not conducted. The compliance disclosure requirement was met by inserting the standard disclosure at the start of the recommendation flow, rather than by designing a disclosure experience that was both compliant and comprehensible.
The better approach: Client-facing financial services AI requires user research before specification, not after launch. The questions to answer before the design phase: What does this client already understand about investing? What language do they use when they describe their financial goals? What would make a recommendation from an AI system feel trustworthy rather than opaque? The compliance disclosure is a design constraint, not an afterthought — and there is almost always a way to meet the regulatory requirement through a disclosure experience that is both compliant and appropriately understood by the target audience.
The Pattern
Three different failures. Three different financial services sub-sectors. One consistent root cause: the decision to commit budget and timeline was made before the critical questions were answered.
The core banking migration committed before the integration complexity was mapped. The compliance platform committed before the specific regulatory submission format was validated. The robo-advisory launched before the target clients were observed attempting to use it.
The better approach in each case required the same discipline: do the specific validation work before committing — not as a delaying tactic, but as the fastest path to an investment that delivers its intended outcome.
For mid-market financial services organisations, the lesson is not caution. It is specificity. The organisations that avoid these failure patterns are not slower. They are more precise about what they need to know before they begin.
Related reading: AI Strategy for Financial Services: Where Mid-Market Firms Should Start → What Is Spec-First Software Development? Why It Changes Everything → How to Brief an AI-Native Software Factory →