Meet us at Money20/20 USA
Las Vegas | 18 - 21 October 2026

How Financial Institutions Can Modernize Payment Infrastructure

How Financial Institutions Can Modernize Payment Infrastructure

Table of contents:

Payment infrastructure modernization means upgrading legacy payment systems to support real-time processing, API access, multiple rails, and digital assets. It rarely requires replacing the core, since those capabilities can be separated from it and upgraded one at a time.

Banks spend as much as 70% of their IT budgets keeping existing systems alive, and technology costs have grown roughly four times faster than revenue over the past fifteen years, according to Accenture’s Banking Top Trends 2026 report. That ratio describes the payment modernization problem on its own: most of the budget goes toward standing still.

Where the bank IT budget

Meanwhile, the deadlines have stopped being theoretical:

  • 9 October 2025. Payment service providers in the euro area must send instant credit transfers around the clock and run Verification of Payee checks on euro credit transfers.
  • 22 November 2025. Swift closed the coexistence period for in-scope cross-border payments, and legacy MT payment instructions are no longer accepted in place of their ISO 20022 equivalents.
  • November 2026. Fully unstructured postal addresses drop out of CBPR+ messages.

Client expectations moved at the same time. Around 60% of large Fortune 500 companies are looking at blockchain initiatives of some kind, and corporate treasurers who used to ask about SWIFT coverage now ask about stablecoin settlement.

The reflex response to all of this is a core replacement program. However, it is usually wrong. This article explains why, what modern payment infrastructure actually consists of, and how institutions are getting to market without rebuilding the bank.

What is payment infrastructure?

Payment infrastructure is the stack of systems that moves money between parties and keeps a reliable record of it. That includes:

  • Ledgers that hold balances
  • A processing engine that decides what happens to each instruction
  • Network connections to clearing and settlement schemes
  • Custody or account systems that hold the funds
  • Liquidity arrangements that put the right currency in the right place
  • Compliance controls that screen every transaction along the way

Most institutions treat this as one thing because it arrived as such, usually bundled into a core banking platform bought in a single procurement cycle years ago. Modern payment infrastructure separates those functions so each can be changed independently.

Why legacy payment infrastructure is becoming a bottleneck

Five problems show up repeatedly, and they compound because everything in a legacy stack is wired to everything else.

1. Batch cycles meet real-time mandates

Systems built around overnight processing handle instant payments by bolting a fast lane onto a slow ledger. That holds up until volume rises, or until a regulator requires 24/7 processing with no upper limit on transfer amounts, as the EU’s Instant Payments Regulation now does. Liquidity forecasting, sanctions screening, and fraud controls all have to run at that speed too, and that’s where most retrofits break.

2. Message formats truncate the data

ISO 20022 carries structured remittance information, purpose codes, and full party details; older formats can’t hold them. An institution translating between the two loses exactly the data that automated reconciliation and screening depend on, so investigations a modern message would have closed by itself land on someone’s desk instead.

3. Coupling makes every change expensive

When payment processing logic, account records, and network connectivity live in the same monolith, adding one payment method means regression testing the whole system. Product timelines get measured in quarters because the release process is measured in quarters.

4. Maintenance crowds out everything else

With most of the technology budget committed to keeping the lights on, regulatory change, security work, and anything a customer might notice compete for what’s left. The base grows every year that passes.

5. Digital assets have nowhere to sit

A bank can’t accept a stablecoin deposit through a core designed around correspondent accounts. It needs key management, wallet provisioning, blockchain connectivity, on-chain transaction monitoring, and a liquidity path to convert. This does not exist in legacy banking infrastructure; none of it is a small project.

What modern payment infrastructure looks like

The defining feature of modern payment infrastructure is how the pieces are joined, more than any particular technology within it.

Access: APIs and modular services

Every function is reachable programmatically:

  • Documented endpoints for each capability
  • Webhooks for asynchronous events
  • A sandbox environment to build and test against

Payment APIs are an architectural commitment before they are a feature. If a capability isn’t exposed through an API, it can’t be recombined into a new product without a project. Underneath that, custody, processing, screening, and liquidity run as separate services with defined contracts between them, so one provider can be swapped without rewriting the systems around it.

Rails: blockchain connectivity and automated liquidity

Public networks sit alongside card schemes, SEPA, and correspondent banking as one more route for value to travel. In practice this means managed node infrastructure, address provisioning, transaction broadcasting, and confirmation monitoring, abstracted behind the same kind of interface a bank already uses for fiat rails.

Liquidity follows the same principle. Funds move between accounts, wallets, and currencies on rules rather than on a treasury analyst’s morning checklist, with conversion routed to whichever venue offers the best execution at that moment.

Controls: compliance in the transaction path

Screening, KYT, and sanctions checks run inline as part of processing, as opposed to as a reporting exercise afterward. Approval workflows, limits, and role-based permissions become configuration rather than code. This is also where most of the sector’s automation investment is landing: 81% of financial services firms now report adopting AI, and risk and monitoring functions are consistently among the first places it goes.

Why modernize payment infrastructure?

There are three reasons for this, in rough order of urgency.

  • Regulatory. Instant payment mandates and ISO 20022 aren’t optional, and the compliance work is easier on architecture designed for it.
  • Commercial. New revenue lines, whether stablecoin settlement, embedded finance, or merchant services, need capabilities that don’t exist in the legacy stack.
  • Cost. Every year of deferral raises the maintenance base and shrinks the discretionary budget.

The commercial case is the one that tends to move budgets, and the market data behind it is hard to argue with. Digital payments revenue is projected to reach $2.4 trillion by 2029, and digital payment transaction value already represents 17.7% of global GDP. On the client side, 88% of financial professionals consider direct bank connectivity very or extremely beneficial, 82% say it would increase their loyalty to their provider, and 75% of executives report direct revenue uplift from open banking initiatives. These are integration capabilities, available only to institutions whose systems can be integrated with.

The four layers of modern payment infrastructure

One payment instruction

Separating the stack into layers makes the modernization decision tractable, because it lets an institution replace, keep, or outsource each layer on its own schedule.

Core processing

This is the layer that receives every instruction, decides what has to happen, and routes work to the right component. It holds the transaction state machine, the fee logic, the retry rules, and the audit record, and it doesn’t talk to networks directly.

This is usually the layer institutions are most reluctant to touch, and often the one they should leave alone longest. A ledger that reconciles correctly is worth a great deal.

Custody and account infrastructure

This layer usually holds the value. In fiat, that’s accounts at the central bank or a correspondent. In digital assets, it’s wallets and the cryptographic keys that control them, which introduces requirements the fiat side never had:

  • Key generation and storage
  • Signing policy and approval thresholds
  • Address whitelisting
  • Segregation of client funds across balance pools

The security model here differs in kind from the rest of the stack. A processing bug can be reversed, but a key compromise usually cannot.

Liquidity

Making sure the right asset is in the right place at the right time. For cross-border and digital asset flows, this covers conversion, routing across venues and providers, consolidation of funds scattered across wallets or accounts, and rebalancing to keep operational floats topped up.

Manual treasury work scales linearly with volume, which is why this layer tends to start hurting first once a new product succeeds.

Compliance

Transaction screening, sanctions checks, KYT for on-chain flows, travel rule data, approval workflows, and the audit trail behind all of it. In a modern stack this layer is invoked by core processing before an instruction executes, which is the only way to satisfy real-time mandates without slowing settlement to the speed of a manual review.

Modernization strategies: three paths

Where the bank IT budget goes

Full replacement

Rip out the core, migrate everything, run in parallel, and cut over.

Pros

  • One architecture across the estate
  • No permanent integration debt
  • A clean answer to the question of where the truth lives

Cons

  • Cost and schedule risk that have repeatedly killed programs at large institutions. Commonwealth Bank of Australia budgeted A$580 million over four years in 2008 and declared the program complete in 2012 having spent over $1 billion across five years
  • Product development effectively stops while the migration runs, which is a hard thing to explain to a board watching competitors ship
  • Institutions elsewhere have written off entire programs after years of work

Hybrid coexistence

Keep the legacy core for existing products, run a modern payment platform alongside it for new ones, and migrate customers or product lines gradually.

Pros

  • New capabilities ship on modern architecture within months
  • The legacy system keeps doing what it already does well
  • Each migration step is small enough to reverse

Cons

  • Two systems to operate and reconcile against each other
  • “Temporary” coexistence can quietly become permanent
  • Governance has to be explicit about what migrates when, or nothing does

Infrastructure layer

Keep the core, and integrate specialized infrastructure for the capabilities it doesn’t have. The institution keeps its ledger, its license, its customer relationships, and its brand, and connects through APIs to external systems for custody, blockchain connectivity, liquidity, and screening.

Pros

  • The fastest path to a live product
  • The smallest blast radius when something goes wrong
  • Providers can be changed later without another core program

Cons

  • Dependency on external providers
  • Vendor due diligence and exit planning become part of the project
  • Operational resilience requirements (DORA, in the EU) apply to the provider relationship

Most institutions end up combining the second and third. IDC expects that by 2028, 30% of new bank payment system deployments will process payments across card, interbank, and cross-border rails from a single platform, which describes a modular design rather than a monolithic one.

Why financial institutions are choosing modular infrastructure

The strategic argument is that competitive advantage has moved. Finch Capital’s 2026 State of European Fintech finds that a firm’s defensibility increasingly rests on embedded workflows, proprietary data, and regulatory intensity. None of those live in the underlying structure. An institution’s license, client relationships, underwriting data, and compliance posture are the assets. Node operations and key management are not, which is why so much fintech infrastructure is now bought rather than built.

The practical argument, however, is timing. Tokenized payments illustrate it:

That 38-point gap closed in a year because banks integrated capabilities rather than built them. An institution planning an eighteen-month build for stablecoin settlement is planning to arrive after the market has been served.

Which points to the underlying test. Infrastructure earns its keep by disappearing.

The best infrastructure is the kind businesses don't have to think about. It simply works

Misha Kaplin
Misha Kaplin

Head of Business Development

Build vs. buy

The build case rests on control, unit economics at very high volume, and the ability to shape the product precisely. The buy case rests on time, risk, and the fact that most of what has to be built is table stakes rather than differentiation.

Build in-house Integrate a platform
Time to first transaction 12–24+ months for custody, connectivity, and compliance tooling Weeks to a few months, depending on integration scope
Upfront cost Engineering, security review, audits, node infrastructure Integration effort plus commercial terms
Ongoing cost Node operations, network fees, on-call, upgrades for every chain Predictable, shifted to the provider
Team required Blockchain engineers, security engineers, compliance engineers Existing integration and product teams
Control over keys and funds Complete Depends on model: fully retained in a self-custody setup, delegated in a managed one
Adding a network or asset A new project each time Provider-side, usually configuration
Compliance tooling Built from zero, then maintained against changing rules Built in, maintained by the provider
Key risk Schedule and security risk sit with you Vendor concentration, exit planning, resilience requirements

For most institutions, a split version is best:

  • Build the things customers see and the logic that reflects your commercial model
  • Integrate the things that are hard, undifferentiated, and expensive to keep current

The crucial question is: if the project shipped exactly on time, what would customers notice? If the answer is “nothing, but we’d be able to offer X,” then X is the product, and the infrastructure underneath it is a means to get there.

How Coinspaid Enterprise fits into modern payment infrastructure

Coinspaid builds at the layers described above, which makes it a useful illustration of where an external platform sits in relation to a bank’s existing systems.

Coinspaid Enterprise is aimed at licensed institutions, EMIs, PSPs, and regulated fintechs that want to offer digital asset payments under their own license and brand. It covers:

  • Core processing for digital asset operations
  • Custody and blockchain connectivity, the digital asset infrastructure layer
  • Liquidity routing through connected providers
  • Compliance execution, including transaction screening and audit trails

The institution keeps its license, treasury relationships, and merchant relationships. Merchant onboarding, settlement configuration, balance monitoring, and accounting run through portals the institution’s own team operates. The platform supports third-party custodians and external liquidity providers rather than requiring a single arrangement.

Coinspaid Core answers a different control question. It’s infrastructure rather than a custodial service: key management, wallet provisioning, a payments engine, liquidity automation, policy controls, and managed blockchain connectivity, with keys and transaction signing remaining in the client’s own environment. Businesses that want to own their blockchain infrastructure without operating nodes tend to land here.

The distinction between the two comes down to how much of the operating model an institution wants to run itself. Neither replaces a core banking system, and neither is meant to.

The takeaway

Modernization has a reputation for being all-or-nothing. That reputation was earned by a generation of core replacement programs that ran long, cost more than planned, and froze product development while they were underway. The architecture that has emerged since, however, enables a different approach. Because custody, liquidity, compliance, and processing can now be separated and connected through APIs, an institution can add a capability without touching a ledger that has been reconciling correctly for fifteen years.

That reframes the whole question. Instead of figuring out how to replace the core, ask which layer is actually blocking the product you want to ship, and what is the shortest path to unblocking. For most institutions, the answer involves keeping considerably more of the existing estate than they expected, and integrating a well-defined piece of infrastructure at the point where the gap is.

Speed here comes from scope discipline more than from an early start.

Frequently asked questions

It depends entirely on scope. A full core replacement runs three to five years and sometimes longer. A hybrid program that stands up a modern platform alongside the legacy core typically shows a live product in six to twelve months. Integrating an existing infrastructure layer for a specific capability, digital asset payouts for example, is usually measured in weeks to a few months, most of which is compliance sign-off and testing rather than engineering.

Yes, and that’s the normal pattern. Blockchain capability is added as a separate service that the core calls through an API. The core continues to hold customer records and fiat balances; the external layer handles wallets, keys, on-chain transactions, and network connectivity, then reports back settled positions. The integration surface is a few endpoints and a webhook stream.

  • API-based access with webhooks and a sandbox
  • ISO 20022 message handling
  • A real-time processing engine that doesn’t depend on batch windows
  • Modular services with defined interfaces
  • Automated compliance screening in the transaction path
  • Key management and wallet infrastructure, if digital assets are in scope
  • Observability across the whole flow, since you can’t operate what you can’t see

API-based access with webhooks and a sandbox; ISO 20022 message handling; a real-time processing engine that doesn’t depend on batch windows; modular services with defined interfaces; automated compliance screening in the transaction path; key management and wallet infrastructure if digital assets are in scope; and observability across the whole flow, since you can’t operate what you can’t see.

It works as a settlement rail with different properties from the existing ones: 24/7 availability, near-final settlement in minutes, and programmability. Instead of replacing card schemes or SEPA, it sits alongside them as another route, chosen when its properties fit the payment. Most institutional use today is stablecoin settlement, where those properties matter for cross-border flows and out-of-hours movement.

Build what your customers experience and what encodes your commercial logic. Integrate custody, blockchain connectivity, liquidity routing, and screening unless you have a specific reason to own them, such as extreme volume economics or a regulatory constraint that requires it. The test is whether the capability is a source of advantage or a cost of entry.