IBM’s Institute for Business Value 2025 analysis of core banking modernization programs documented a finding that most banking technology leaders already suspect but do not like to state plainly: 94% of core banking modernization projects exceed their planned timelines. Fewer than half of the CIOs running these programs report substantial improvements in efficiency, customer experience, or innovation agility as outcomes — despite the investment scale, which Oliver Wyman has characterized as a $20 billion category in the US alone.
This is not evidence that digital banking transformation is impossible. It is evidence that the failure modes are predictable and that most programs repeat them. The banks that have delivered successful core transformations in 2025–2026 — Lloyds Banking Group with Thought Machine Vault, several regional banks with Mambu — share architectural disciplines that most transformation programs skip in the interest of timeline and budget.
The open banking market is valued at $35.72 billion in 2025, growing to $43.22 billion in 2026 (Precedence Research). Open Banking adoption in the UK — the most mature market — passed 50.7% of UK adults in 2025, representing 27.5 million users. This is not a future projection; it is the current state of a market where incumbent banks are competing with neobanks, fintech-embedded services, and each other for the API-accessible customer relationship.
The engineering challenge of digital banking in 2026 is not building a mobile app with a clean UI over a legacy core. It is replacing or wrapping the legacy core in a way that does not break the 20-year-old business logic embedded in it, while simultaneously meeting the cybersecurity requirements of DORA, the interoperability requirements of open banking, and the speed-to-market requirements of competitive banking.
What “Core Banking” Actually Is and Why It’s Hard to Replace
A core banking system is the software that maintains the authoritative record of account balances, processes transactions, calculates interest, manages product configuration, and interfaces with payment networks. Everything else in a bank’s technology stack — mobile apps, online banking, relationship management tools, risk systems — reads from or writes to the core.
Legacy core banking systems — primarily COBOL mainframe applications at US and European banks — were built incrementally over 30–50 years. The COBOL codebase of a large US bank may exceed 100 million lines of code. The business logic embedded in that code — the rules for fee calculation, overdraft handling, accrual timing, regulatory reporting — is the institutional knowledge of the bank, encoded over decades of regulatory changes, product launches, and merger integrations. Almost none of it is documented. Most of the engineers who wrote it are retired.
This is why replacement is hard. It is not a technology problem. It is an institutional knowledge extraction problem: understanding what the legacy system does, encoding that knowledge in the new system, and validating that the outputs are equivalent. The validation is comprehensive: every account type, every transaction scenario, every month-end and quarter-end reconciliation, every regulatory report must produce identical outputs on both systems in parallel. This parallel run — typically 6–18 months — is the most expensive and difficult phase of any core banking replacement.
The “strangler fig” approach — gradually routing transaction types from the legacy core to the new core while keeping both systems running in parallel — sounds conceptually elegant. In practice, the integration complexity between two systems with different data models, different event timing, and different reconciliation approaches creates overhead that compounds with every transaction type added to the migration scope. 94% of projects exceeding timelines is largely explained by strangler fig complexity that was not scoped correctly at the outset.
Cloud-Native Core Banking: What Thought Machine, Mambu, and 10x Actually Do Differently
The cloud-native core banking vendors that have won tier-1 bank programs share an architectural approach that differs fundamentally from legacy core banking:
Immutable ledger with smart contracts (Thought Machine Vault). Rather than storing account balances as mutable database records, Vault stores accounts as a sequence of immutable posting instructions (“post credit of $100 to account X at time T”). The current balance is always computed by replaying the posting history — which is never modified, only extended. This event-sourced architecture is how financial systems actually work conceptually: a bank account balance is the net of all transactions against it, not a number that gets overwritten. The result is a system where historical data is always accurate, regulatory audit trails are inherent rather than constructed, and dispute resolution is trivially supported.
Composable product configuration (Mambu). Rather than hardcoding product rules in application code, Mambu’s architecture separates product configuration (interest rates, fee schedules, eligibility rules, repayment logic) from the platform code that executes it. New products are configuration, not code deployments. This is the capability that allows banks running Mambu to launch new loan or deposit products in days rather than months — because the core can interpret the product configuration without a code change.
API-first architecture. Legacy cores expose functionality through batch files, proprietary messaging protocols, and screen-scraping COBOL interfaces. Cloud-native cores expose everything through RESTful APIs with OpenAPI specifications. This means a bank’s digital channels, partner integrations, and regulatory reporting feeds can all be built on standard HTTP APIs — without the custom integration middleware that represents a significant operational cost in legacy core environments.
The caveat: cloud-native cores require a different data migration strategy. Migrating 20 years of customer account history from a mutable-balance legacy system to an immutable-ledger new system requires reconstructing the transaction history for every account — which requires that the legacy system’s transaction history is complete, correctly ordered, and interpretable by the migration tooling. Missing or corrupted historical data is one of the most common migration blockers.
DORA: The Engineering Requirements That Took Effect January 2025
The EU Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — took effect January 17, 2025. It applies to approximately 22,000 EU financial institutions: banks, investment firms, insurance companies, payment institutions, and crypto asset service providers. 19 cloud providers (AWS, Azure, Google Cloud, and others) were designated as Critical Third-Party Providers (CTPPs) under direct EU supervisory oversight in November 2025.
DORA has five pillars, each with direct engineering consequences:
1. ICT risk management. Banks must maintain an ICT risk management framework with documented risk assessments, an asset register for all ICT systems, defined recovery time objectives (RTO) and recovery point objectives (RPO) for critical functions, and regular testing of recovery procedures. This is not a security audit checkbox — it requires engineering teams to maintain accurate system inventories, implement automated failover for critical systems, and validate RTO/RPO targets through actual recovery testing.
2. Incident management and reporting. Major ICT incidents must be reported to the relevant national competent authority within 15 hours of initial notification, with a more detailed report within 72 hours and a final report within one month. This reporting requirement necessitates incident detection systems that can distinguish between operational degradation and major incidents within regulatory timeframes — which requires instrumented systems, clear incident severity criteria, and automated alerting that reaches the right people within minutes, not hours.
3. Digital operational resilience testing. Financial institutions must conduct annual resilience testing, including penetration testing. Significant institutions (criteria include size, interconnectedness, and systemic importance) must conduct Threat-Led Penetration Testing (TLPT) — a structured penetration test methodology that simulates realistic threat actor techniques against production systems in a controlled environment. TLPT is more demanding than standard penetration testing and requires specialist red team engagement.
4. ICT third-party risk management. Every ICT vendor contract must include specific provisions: the right to audit the supplier, defined service levels with remediation obligations, data portability and exit assistance requirements, and sub-outsourcing notifications. For banks using cloud services that touch client data or transaction processing, this requires either renegotiating contracts to include DORA provisions or replacing vendors who will not agree to them.
5. Cyber threat information sharing. DORA encourages (and for significant institutions, may require) participation in threat intelligence sharing arrangements with other financial institutions and with ENISA (the EU cybersecurity agency). This is primarily an operational and legal process — establishing information sharing agreements and participating in sector threat intelligence exchanges.
The penalties: Up to 10% of annual global turnover for serious breaches. Senior management personal liability up to €1 million in some member states. Banks that treated DORA as a compliance checkbox rather than a systems engineering program are under National Competent Authority scrutiny.
Open Banking Engineering: What FAPI 2.0 Requires
Open banking mandates API access to customer account data and payment initiation for authorized third parties. The security standard that EU and UK open banking implementations target is FAPI (Financial-grade API) — an OAuth 2.0 profile with stronger security requirements than standard OAuth because of the sensitivity of financial data.
FAPI 1.0 Advanced is the current EU PSD2 and UK Open Banking implementation baseline. It requires:
- mTLS (mutual TLS): Both the client (third-party provider) and the server (bank API) authenticate with certificates. Standard TLS only authenticates the server — mTLS ensures the bank knows which registered TPP is calling its API.
- PAR (Pushed Authorization Requests): The authorization request is pushed server-to-server before the user is redirected, preventing request tampering.
- PKCE (Proof Key for Code Exchange): Prevents authorization code interception attacks.
- Signed JWT request objects: The authorization request is signed with the client’s private key, providing non-repudiation.
FAPI 2.0 is the next generation, currently in early adoption. It simplifies some of the FAPI 1.0 complexity while adding stronger protection for payment initiation flows. Banks planning open banking API platforms should evaluate FAPI 2.0 as the target architecture for new implementations.
The UK Open Banking Standard mandates specific consent management UX — the screens a customer sees when authorizing a third-party application are regulated, including the data scopes displayed, the authorization duration, and the revocation mechanism. Banks must implement the consent management flows to the standard’s specifications, not their own UX preferences.
AI in Core Banking: What’s Actually Working
McKinsey’s December 2025 analysis of AI in banking is direct: banks with clean, governed data foundations are scaling AI for credit decisioning, deposit pricing optimization, and customer lifetime value modeling, and generating measurable competitive advantages in speed-to-decision and loss rate performance. Banks without the data foundation are still in pilot hell.
The specific applications that have moved from pilot to production:
ML-based credit scoring. Machine learning models trained on application data, bureau data, and (for existing customers) behavioral account data are outperforming traditional scorecard models in both accuracy (lower loss rates) and speed (decisions in seconds rather than minutes for thin-file applicants). The engineering requirement: a feature store that makes model features consistent between training and inference, model versioning with A/B testing infrastructure to validate new models before full deployment, and monitoring for model drift as the credit environment changes.
Deposit pricing optimization. Banks with granular customer transaction data can model price sensitivity for deposit products — identifying which customer segments are most likely to move deposits in response to rate changes, and pricing accordingly. This is a revenue optimization application that requires ML engineering but does not require the credit risk regulatory framework, making it a faster path to deployment.
Fraud detection at payment initiation. Real-time fraud scoring for payment instructions — using graph models that identify unusual payee relationships, transaction velocity models, and device fingerprinting — has moved from rule-based to ML-based at most large banks. The latency requirement is strict: fraud scoring must complete within the authorization window (100–500ms for card transactions), which requires inference infrastructure designed for low latency, not throughput.
How we approach this at Insoftex
Core banking modernization is the most technically and organizationally complex class of software project in financial services. The technical complexity (data migration, parallel run validation, legacy code archaeology) combines with the organizational complexity (change management for operations staff, vendor negotiations, regulatory notification requirements) in ways that make scope definition exceptionally difficult.
For clients evaluating core banking modernization options — full replacement, strangler fig wrapping, or ledger decoupling — we scope the migration complexity first: the quality and completeness of historical transaction data, the undocumented business logic that will need to be identified and replicated, and the parallel run validation approach. These determine the realistic timeline and cost more accurately than vendor proposals.
For clients building fintech products that integrate with banks — open banking platforms, payment initiation services, embedded finance layers — we design the FAPI-compliant API integration from the first architecture session, because retrofitting FAPI security requirements onto a standard OAuth implementation requires more than configuration changes.
Digital banking engineering is specialized. The standards, the regulatory environment, and the data architecture requirements are specific enough that teams without prior exposure consistently underestimate project complexity. The banks that deliver successful digital transformations are those that match engineering expertise to the actual requirements of the work.
Evaluating core banking modernization options, building open banking API platforms, or designing DORA-compliant infrastructure? Our Product Pilot includes a technical scope assessment and architecture review — identifying the migration complexity, regulatory requirements, and architectural decisions that determine whether a digital banking program succeeds or joins the 94% that exceed their timelines.