The era of choosing one or the other is over. The real question is which capabilities you own, which you rent, and which you share. In this blog, our senior advisor Guy Moons explains why.
The payment system modernisation debate has occupied banking boardrooms for the better part of a decade. But something has shifted in 2025 and 2026. The question is no longer theoretical: a wave of hard regulatory deadlines, a restructured vendor landscape, and a generation of cloud-native platforms that have now proved themselves at scale have forced tier 1 banks to make concrete architectural decisions they have been deferring for years.
Change has been fundamental over the past years, but banks have not seen the end of the change journey yet with the introduction of the Digital Euro, Swift Scheme Payments and Ledger, PSD3, Rulebook upgrades, one-leg-out instant payments, the roll-out of the UK Payments Forward Plan, and more to come. Bank systems will continue to be affected by industry and regulatory change, which limits their ability to innovate and increases the cost of running their payments business.
The result is a market in genuine tension. A small number of the largest institutions are building proprietary payment stacks from the ground up, betting that full vertical integration is the only path to differentiation at their scale. Most others are selectively buying vendor capabilities for regulatory-mandated infrastructure while building where it matters competitively. And a third cohort is discovering that neither fully answers the question: the real prize lies in how the two are orchestrated.
The Regulatory Pressure That Changed Everything
To understand the current decision landscape, you need to start with the regulatory calendar. 2025 was one of the most consequential years in the history of payments infrastructure, compressing decisions that banks might otherwise have deferred for another five years.
ISO 20022 carries structured data fields, including richer beneficiary information, legal entity identifiers and structured address formats, that legacy payment processing systems were not built to handle. Banks running translation layers as a temporary workaround faced a clear choice: continue accumulating technical debt, or use regulatory compliance as a forcing function to re-platform the underlying infrastructure.
For most tier 1 banks, regulatory deadlines have been the single most important catalyst for modernisation projects that had been stalled in governance for years.
The Build Case: Differentiation at Scale
For the very largest institutions, the build argument has never been stronger. A handful of global banks have made the strategic decision to own their payment infrastructure outright, building proprietary processing platforms, liquidity management engines and commerce infrastructure rather than relying on third-party solutions.
The logic is competitive. By controlling the full stack, these institutions can offer capabilities, such as real-time cash pooling across dozens of currencies, virtual account structures and programmable settlement, that are genuinely difficult to replicate on a shared platform designed to serve multiple institutions. The product roadmap is determined by client need and competitive strategy, not a vendor’s release cycle.
The caveat is that this requires something most banks cannot replicate, engineering investment measured in the billions, tens of thousands of technologists, and the organisational discipline to run a technology company inside a bank. It is not a playbook that translates directly to peers at different scale. Most banks will fix burning issues before executing a payment system transformation programme.
The Buy Case: Regulatory Infrastructure and Speed to Market
At the opposite end of the spectrum, the vendor market has matured considerably, and the case for buying specific payment infrastructure capabilities has strengthened substantially.
Payment hub platforms have emerged as the dominant approach for banks that need ISO 20022 compliance, instant payment scheme connectivity, and multi-rail access without the three-to-five-year build timeline. These platforms absorb the ongoing cost of regulatory change, including scheme updates, format migrations and new reporting obligations, allowing banks to redirect engineering capacity towards differentiation rather than compliance maintenance.
The cloud-native core banking market has similarly matured, with event-driven, API-first architectures now running in production at tier 1 institutions for specific use cases. The distinction that matters most is not cloud-hosted versus on-premise, but whether the architecture was designed for real-time, composable banking from the outset or migrated from legacy infrastructure. The two deliver fundamentally different outcomes.
The composable banking model has changed the buy decision structurally. Banks no longer need to adopt an entire vendor stack. The unit of decision is no longer the platform: it is the capability.
The caveat is that working with vendors creates a lock-in to the roadmap and technology of that vendor. Reducing the number of vendors helps alignment and reduces the effort required from the vendor management team.
The AI Dimension
The applications are established: real-time fraud detection, exception triage, natural language querying of payment operations data, propensity modelling for treasury and deposit products.
The underlying model infrastructure is almost universally sourced externally. The question is whether to build the application layer, the training data curation, and the evaluation infrastructure in-house. The banks getting the best results treat AI as a capability requiring sustained internal investment, not a feature to activate from a vendor dashboard. AI decisions in payment processing must be explainable, auditable, and overridable, and navigating that governance requirement is largely an internal exercise regardless of what the vendor layer provides.
AI-based development redirects the discussion from buy to build, as smaller teams become more productive using AI. However, before banks use AI for production systems, they need to ensure that the entire development process, from business requirements through to delivery of the code, encompasses quality assurance, traceability, auditability and maintenance. This requires a strong AI culture in which AI is supported throughout the organisation.
The Emerging Playbook: Architect for Composability
What is actually happening at most large banks in 2026 is neither pure build nor pure buy. It is a deliberate decomposition of the payment stack into capability categories, with decisions made at the component level according to a consistent set of criteria.
What the Market Is Deciding
The industry conversation has shifted from whether to modernise to how to do it without destabilising systems that support millions of customers every day. Tier 1 banks are not moving slowly because they lack ambition: they are moving deliberately because the risk profile of a failed migration at an institution processing trillions of dollars daily is categorically different from the same project at a challenger bank.
The banks making the most progress are finding ways to move architecturally without betting the institution on a single transformation programme. Progressive capability replacement, such as the payment hub before the core, the analytics layer before the ledger, and the fraud engine before the operations platform, allows ongoing value delivery without the all-or-nothing risk of wholesale replacement. The non-functional requirements governing these decisions have also become more demanding: real-time processing at scale, near-continuous availability, full auditability, and the ability to absorb regulatory change without a re-platforming project every two years.
Except for international payment flows, where processing is still complex, the market has seen the harmonisation of domestic payment schemes into more standardised, uniform processing. At the same time, starting with instant payments, tier 1 banks are exploring their options to take control of their payment systems and are evaluating whether to build instead of buy for these less complex payment engines.
The Verdict
The build versus buy framing has served its purpose, but it is no longer the right question for tier 1 banks. The right question is: which capabilities are genuinely differentiating, which are commodity infrastructure, and does the organisation have the architectural clarity and engineering discipline to keep those categories separate?
The banks that will look back on 2025 and 2026 as a turning point are those that used regulatory deadlines as forcing functions to clean up their underlying data and integration architecture, rather than simply patching compliance onto existing systems. That investment is what makes the intelligence layer actually possible.
The payment system is no longer just operational infrastructure. For the banks that get this right, it is the most valuable data asset they own.
This article reflects publicly available industry research and regulatory developments current to July 2026.
There is also the risk of exacerbating inequality. If open finance frameworks are designed primarily around smartphone-based consent interfaces, urban broadband connectivity, and formal employment records, they may deepen the financial exclusion of the populations they were meant to serve. The design choices made across the continent over the next three to five years will determine whether Africa’s open finance moment is genuinely inclusive or whether it creates a two-tier system that serves the already-served.
