The global core banking software market was valued at $19.67 billion in 2025 and is projected to reach $83.78 billion by 2034. The modernization sub-segment specifically — the portion of that spend dedicated to replacing or re-architecting legacy core systems — generated $1.9 billion in 2025 and is growing at a 24.4% CAGR, on track for $16.8 billion by 2035.
Behind these numbers sits a structural problem that has compounded for decades: banks spend 60–80% of their IT budgets maintaining systems that were never designed for real-time, always-on, ISO 20022-native operation. McKinsey estimates only 5–10 cents of every technology dollar in banking delivers new business value; the remainder is maintenance, patching, and the operational overhead of coaxing 30-year-old COBOL cores to interact with modern API layers. Global financial institutions spent $36.7 billion on legacy payment system maintenance in 2025, a number expected to reach $57 billion by 2028. The modernization case is straightforward. The execution is not.
The Payment Rail Engineering Landscape: Three Deadlines, One Year
2025 was a landmark year for payment infrastructure — not because of new technology, but because multiple regulatory and industry deadlines converged simultaneously, forcing engineering teams to deliver hard migrations in compressed timeframes.
ISO 20022 / Swift CBPR+ — November 22, 2025
Swift ended the MT/MX coexistence period on November 22, 2025. Legacy MT payment messages — the format that has governed correspondent banking for decades — are no longer valid on the Swift network. This was the culmination of a 20-year standardization initiative and the Swift Board re-confirmed the hard cutover in March 2024 with no further extensions.
Every Swift BIC member is required to be compliant, and the compliance responsibility for both inbound and outbound transactions rests with the originating bank. Some institutions missed the deadline — J.P. Morgan began receiving CBPR+ pain.001 v9 messages in November 2025 but targeted their outbound sending capability for Q4 2026, illustrating that even tier-1 banks operate on phased timelines.
The engineering impact extends well beyond message format. ISO 20022 MX messages carry structured, richer remittance data — LEI codes, purpose codes, full debtor/creditor addresses — that MT messages could not encode. This forces schema changes across core banking, sanctions screening, AML systems, and reconciliation engines. A bank that can receive MX messages but cannot route the enriched data fields downstream has technically complied with Swift requirements while leaving the value of ISO 20022 on the floor.
FedNow (US Federal Reserve) — Ongoing Expansion
The Federal Reserve’s FedNow Service crossed 1,600 participating financial institutions by late 2025, adding 500 institutions over the prior year and more than 100 in Q4 alone. Community banks and credit unions make up more than 95% of all participants.
The volume numbers are large: average daily transactions reached nearly 30,000 in 2025; total transaction volume grew 460% year-over-year; Q2 2025 alone saw $245 billion processed — a 49,000% increase from the $492 million processed in Q2 2024. Total dollar value for 2025 reached $853.4 billion. The transaction limit was raised from $1 million to $10 million in November 2025, responding to growing commercial demand from payroll, real estate escrow, and marketplace payout use cases.
The engineering architecture of FedNow is relevant: it uses ISO 20022 natively (pacs.008, pacs.002, pacs.004 message types) and settles via each institution’s Federal Reserve Master Account. This provides more flexible liquidity management than the Clearing House RTP network’s pre-funded joint account model, which has been a friction point for smaller institutions evaluating real-time payment participation.
SEPA Instant — October 9, 2025 (EU)
Across the EU, SEPA Instant Credit Transfers became mandatory on October 9, 2025 for receiving payments. Every eurozone PSP is now required to process euro transfers within 10 seconds, 24 hours a day, 365 days a year, with a maximum amount of €100,000. Verification of Payee (VoP) became mandatory at the same date: PSPs must confirm that the payee name and account number match before executing any SEPA credit transfer.
The engineering complexity is concentrated in compliance infrastructure. Legacy AML and sanctions screening systems were built around batch processing windows — nightly runs, end-of-day reports. A 10-second payment window does not accommodate overnight batch cycles. Banks had to re-architect their compliance stacks for real-time, streaming operation, or their SEPA Instant participation would represent a regulatory violation at each transaction. Nearly half of European banks admitted difficulty meeting earlier January compliance phases, though 85% reported confidence in the October milestone.
How Banks Build Between Core and Channel
The three-layer API model has become the dominant architectural pattern for banks trying to decouple the pace of digital innovation from the pace of core system change:
System APIs expose core banking capabilities — account balance, transaction history, loan status — behind a stable, versioned interface. These insulate digital channels from core system changes and create a stable contract for downstream consumers.
Process APIs orchestrate multi-step business workflows: customer onboarding, cross-border payment initiation, KYC workflows. They compose multiple System API calls with business logic, providing a process-level abstraction that neither the core system nor the digital channel needs to know about.
Experience APIs are channel-specific adapters that shape data for mobile apps, web portals, ATMs, contact centers, and fintech partner integrations. A mobile app and a contact center agent need very different representations of the same underlying account data.
Banks building this middleware layer in-house typically use API gateways (Kong, Apigee, AWS API Gateway), event brokers (Apache Kafka), and integration platforms (MuleSoft, WSO2, Azure APIM). The critical engineering decision is how much business logic lives in the middleware versus the core. Middleware that accumulates business logic becomes a second core — equally difficult to change and without the institutional knowledge that maintains the original.
Open Banking Standards: FDX and FAPI 2.0
The US open banking infrastructure is consolidating around the Financial Data Exchange (FDX) standard. As of early 2026, 130 million consumer accounts are connected via FDX API, up from 114 million in mid-2025. FDX membership has grown to over 250 organizations, including JPMorgan Chase, Bank of America, Wells Fargo, Capital One, Plaid, Yodlee, and MX.
The regulatory context matters: the CFPB recognized FDX as an official standard-setting body under the Personal Financial Data Rights rule (Section 1033) in October 2024. This rule requires financial institutions to unlock individual financial data and transfer it to third parties at consumer request, without charge.
On the security standards layer, FDX has migrated away from legacy OAuth patterns toward the OpenID Foundation’s FAPI (Financial-grade API) security profile. FAPI 1.0 became a certification requirement by 2026, and the ecosystem is actively migrating to FAPI 2.0 — which strengthens authorization code flow with PKCE, Pushed Authorization Requests (PAR), and Rich Authorization Requests (RAR). This eliminates the redirect-based credential scraping and screen-scraping that created both security risk and user friction in first-generation open banking implementations.
Cloud Migration in Banking: Proof Points and Real Numbers
Cloud adoption in banking is no longer a future-state discussion.
JPMorgan Chase migrated 75% of its data and 70% of its production applications to cloud (public or private) by 2024, with total technology spend reaching $17 billion — up $1.5 billion year-over-year. Private cloud compute and storage costs fell approximately 5% while volumes grew approximately 50% from 2021 to 2023.
Lloyds Banking Group moved 50% of its applications to cloud, reduced its data center footprint by 40%, and cut legacy technology applications by 17.5%. The technology transformation program delivered $1.5 billion in savings in 2024. Lloyds migrated to Google Cloud’s Vertex AI in 2024, with 300+ data scientists and AI developers on the platform.
Globally, bank cloud spending was forecast to reach $85 billion in 2025 — more than double the $32.1 billion spent in 2020. The Big 6 cloud providers in banking are IBM, Microsoft Azure, AWS, Google Cloud, Alibaba Cloud, and Oracle Cloud. Fewer than one in five major financial institutions is currently multi-cloud, though 88% report planning multi-cloud adoption within the year — the concentration risk implications of single-provider dependency are increasingly on regulators’ radar.
Ledger Engineering: The Patterns That Financial Systems Depend On
Two architectural patterns underpin every financial system at scale, regardless of whether the core is legacy COBOL or a cloud-native platform:
Double-entry ledger: Every transaction must be recorded in at least two accounts — a debit and a credit — such that the sum of all debits equals the sum of all credits. This is not an accounting convention; it is a consistency constraint that makes financial data auditable and self-verifying. Modern implementations enforce this at the database layer or application layer with explicit transaction validation before commit.
Event sourcing: Rather than storing only the current state of an account, event-sourced ledgers store the immutable log of every state-changing event. The current balance is a projection computed from the event log. This enables point-in-time reconstruction (what was the account balance at 2:47pm last Thursday?), auditability, and the ability to replay events to correct errors — capabilities that batch-update ledgers cannot provide without significant additional infrastructure.
Banks modernizing to real-time payment rails discover quickly that batch-based ledger architectures cannot deliver the consistency guarantees that instant payment settlement requires. Reconciliation at scale — matching outgoing payment instructions to confirmations, handling reversals and corrections in real-time — becomes a core engineering problem that shapes database selection, message broker design, and operational tooling.
The Vendor Landscape in 2025
The core banking vendor market is bifurcated between established platforms with large installed bases and cloud-native challengers targeting net-new banks and digital transformations:
Temenos and Finastra (formed from the merger of Misys and D+H) serve large institutional clients globally, with deep functionality in corporate banking, payments, and treasury.
FIS (Fidelity National Information Services) and Fiserv are the dominant US processors, powering the majority of community banks and credit unions on processing infrastructure rather than full core replacement.
Thought Machine and Mambu represent the cloud-native tier: API-first, configurable via metadata rather than code changes, and designed for the multi-tenancy and regulatory flexibility that greenfield digital banks and bank-as-a-service platforms require. Both use event-sourced ledger architectures natively.
The vendor selection decision is consequential: core banking replacements run 3–7 years, cost hundreds of millions at large institutions, and carry significant organizational risk. The trend toward cloud-native cores is real, but adoption is concentrated in digital challenger banks, embedded finance platforms, and credit unions rather than incumbent tier-1 banks pursuing full core replacement.
What This Means for Engineering Teams
The pressure on banking engineering teams in 2025–2026 is structural, not cyclical. ISO 20022 compliance is mandatory and no longer optional. FedNow and SEPA Instant participation creates competitive pressure from faster-moving peers. Open banking regulation under Section 1033 and the EU’s PSD2/3 framework extends the obligation to share data in real time.
The engineering work that separates institutions that adapt from those that fall behind is not glamorous: data model migration, middleware API design, AML/sanctions screening re-architecture for streaming operation, event-sourced ledger implementation, and cloud infrastructure that meets OCC and ECB operational resilience standards. This work is harder than it looks and more consequential than it is given credit for.
Insoftex works with financial technology companies and banking infrastructure teams on the engineering layer behind these transitions — API architecture, data pipeline engineering, compliance system design, and cloud-native platform development. See how we approach fintech engineering for the systems we build most often, or book a 30-min technical call to discuss your specific architecture.