When modernization creates complexity

For four decades, the work of moving money has rested on a single expectation: the payment goes through, every time, without interruption. That expectation still holds. What has changed is the speed at which everything around the payment now moves. Real-time processing is the baseline; data standards are being rewritten, and regulators now expect operational resilience to be demonstrated rather than asserted. 

ACI Worldwide and IBM have worked together since the mid-1980s to keep mission-critical payments running for many of the largest institutions in the world. Together, we have reached a clear view. A decade of modernization has made payments faster and richer, and across many institutions, it has also made them more fragmented. The decisive question for the next decade concerns the platform beneath the engine, and whether it can keep pace with continuous change without forcing a disruptive rewrite, even where the engine itself still processes every transaction, flawlessly.

Over the past decade, banks rebuilt payments for a real-time world. They added rails, channels, data standards, fraud layers, and orchestration. Each addition was rational on its own. Together, they produced an outcome few institutions chose deliberately: a fragmented payments estate, with more systems and more handoffs surrounding a business-critical payments flow. 

ISO 20022 made the cost of that fragmentation visible. The difficult part of the migration was never the message format. It was the work of coordinating ecosystems, validating data models, and testing across the architecture underneath, and that work pushed major schemes to move their own deadlines. The lesson is direct. Modern payment systems generally have the raw capability they need. The harder challenge is complexity; the durability of the platform that has to carry every new mandate, rail, and control at the same time, under supervision, without downtime. 

For a large bank, this reframes the platform decision. Throughput is no longer the heart of the question. What matters is whether the institution is modernizing on a foundation that can keep evolving, or quietly postponing a forced migration it has not yet scheduled. Where an institution already runs core transaction processing on IBM Z, re-platforming a proven payments engine such as BASE24-eps^® onto that same enterprise platform reduces fragmentation and improves long-term viability without rewriting what already works. 

This paper makes the case in three pillars. Platform sustainability is a strategic risk category that most modernization programs underweight. Alignment with the core enterprise platform now matters more than resilience engineered in isolation. And a phased move of a proven engine is more credible than a wholesale rewrite. ACI and IBM appear only at the close, where the requirements set out here describe something that already exists.

Ask most payment leaders to describe a modern platform and the answers converge: real-time and always-on, modular, cloud-ready, secure by design, and open to a wide ecosystem. The description is accurate, and the market has delivered on it. Instant payments have moved into the mainstream, account-to-account transfers carry one of the strongest growth outlooks in the industry, and merchants increasingly expect to route across several processors rather than commit to one.¹ None of that is in dispute. 

What it leaves unanswered is the question that decides whether any of these capabilities will still matter ten years out. Can one platform keep carrying all of them at once, on a single foundation, without buckling? The checklist does not ask. 

Consider how the estate actually grew. Each new demand was met by adding a system, for example, a real-time rail, an open-banking interface, a fraud and financial crime layer, an orchestration layer, a data store, or a cloud service. Every addition was reasonable in isolation. The result, in many banks, is fragmentation; a sprawl of systems and handoffs wrapped around a transaction path that has to stay up. That complexity rarely appears on a single budget line. It surfaces as integration effort, reconciliation overhead, operational fragility, and slower delivery, and it compounds with every new initiative. Fragmentation is the central problem of payments modernization. 

No single vendor, platform, or rail creates it. It is the accumulated byproduct of doing the right thing repeatedly without a foundation built to absorb it, and it raises a question most modernization programs never ask directly: Can the platform underneath keep carrying all of this, indefinitely, or is the institution building toward the day when its only option is a disruptive rewrite of an application the business runs on every second? 

The standard checklist misses the property that decides the outcome: platform sustainability. The test is not whether the engine performs today, but whether the platform beneath it can absorb a constant stream of change, under supervision, without an outage, for years, and remain the foundation the institution has actively chosen rather than one it is stuck with. 

None of this argues against a platform that performs. A payments engine that has run reliably for years is an asset. The argument is narrower and harder; performance is necessary and no longer sufficient, and the platform decision now turns on durability as the demands keep coming. The next section shows where that test was run in public and what it exposed.

For a real-world test of platform sustainability, the industry does not have to look far. ISO 20022 was meant to be a messaging upgrade; a move from older, data-poor formats to a structured, data-rich standard across high-value and cross-border payments. It looked like a format change. It became one of the most demanding modernization programs the industry has run and this paper provides a clear view of the property. 

The evidence is in the timelines. The Federal Reserve rescheduled the Fedwire Funds Service move to ISO 20022 from March 2025 to July 14, 2025, citing customer readiness rather than any limit o processing capability, and it completed the single-day cutover on that date in a project that affected more than 4,700 financial institutions and vendors.² On the cross-border side, Swift ran a multi-year coexistence period in which legacy and ISO 20022 messages operated in parallel, and it closed that period only in November 2025.³ Neither delay came from a shortage of compute capacity. Each reflected the time it took to align ecosystems, validate data models, upgrade dependent systems, and test end to end across thousands of participants. 

Three observations follow, and each reaches well beyond ISO 20022. 

Coordination, not capability, was the hard part.
The bottleneck was the number of systems and parties that had to change together, which is another way of describing fragmentation. Industry commentary at the time made the same point. Readiness varied widely by institution, and the constraint was preparation across the ecosystem rather than the speed of any one system.⁴ The more fragmented the estate, the more places a single standard must be implemented, and the more fragile the whole becomes during the transition. 

Architecture beneath the message determined the difficulty.
A richer data standard is only as useful as the platforms that carry the richer data through authorization, clearing, settlement, reconciliation, and reporting without losing it. Institutions whose systems could not natively handle the structured data met workarounds, truncation, and added cost long after the format itself was settled. 

Difficulty scaled with dependency.
The migration was hardest where payments were most entangled with other systems and least disruptive where the platform was aligned and the data path was clean. 

ISO 20022 was a rehearsal for what follows. The mandates ahead, continuous regulatory change, new rails, supervised resilience, and richer real-time decisioning will arrive faster and land on the same foundation. An institution that found ISO 20022 painful should read that pain as information rather than history. The program previewed how every future change will feel on a platform that was not built to absorb it.

This paper advances a single, testable proposition.  

Three terms in that statement are often collapsed together and deserve definition. 

Re-platforming means moving a proven application onto a different underlying platform while preserving the application itself. It is not a rewrite, and it is not a replacement of what works. 

Platform longevity means the capacity of the underlying platform to support sustained change, under supervision, over a multi-year horizon, without a forced migration. 

Consolidation means reducing the number of separate systems and dependencies around the payments flow by bringing payments into closer alignment with the core transaction systems an institution already runs.

ISO 20022 showed what a single coordinated mandate costs. The platform question cannot wait because mandates like it are no longer occasional. They are continuous, and several are arriving at once. 

Regulatory change is now continuous and supervised.
ISO 20022 established a richer data model that downstream systems must carry. Operational resilience has become a supervised obligation. In the European Union, the Digital Operational Resilience Act has applied to financial entities since January 2025, with enforceable requirements for technology risk management, incident reporting, resilience testing, and oversight of third-party providers.⁵ Resilience is now demonstrated rather than asserted, and the platform is where the demonstration succeeds or fails. 

Rails keep multiplying.
Real-time schemes, account-to-account services, and open banking are expanding the number of ways value moves at different speeds in different markets.⁶ Every new rail is another integration the platform must absorb without destabilizing the rest, and each integration that lands on a fragmented estate makes the next one harder. 

Workloads are changing in kind, not only in volume.
Real-time fraud and financial crime decisioning increasingly has to run inside the authorization window rather than after the fact. The platform is therefore no longer only a system of record and a processing engine. It is where time-critical decisions are made, which places new demands on latency, as well as on where data is allowed to sit. 

None of these demands would force a platform decision on its own. The difficulty is that they now arrive together, and they keep arriving. A platform has to take on a regulatory mandate, a new rail, a supervised resilience obligation, and a heavier real-time workload in the same period, repeatedly, without an outage. That overlap makes platform durability the decision that governs the others, which is why postponing it is no longer a neutral act.

The first pillar puts it on the risk register, beside credit, market, and operational risk, where most institutions have not. 

Exposure accumulates quietly. A platform performs well for years, the business builds on it, and each new rail, regulation, and integration is added without a second thought. Over time, the institution acquires a dependency it never consciously chose; reliance on a platform whose roadmap, enterprise fit, and supporting skills it does not fully control. Strong performance hides rising exposure, and that exposure has three parts. 

Roadmap dependency.
A platform that is not aligned with the institution’s broader technology direction drifts to the margin of the estate. Investment concentrates elsewhere, and the platform becomes a special case served by a narrowing set of tools. None of this shows up in a throughput metric, yet it sets the cost and risk of every future change. 

Skills sustainability.
This is the part the industry discusses least and should discuss most. Mission-critical payment platforms run on people who understand them deeply, and the deepest of that expertise sits with a long-tenured group of specialists now reaching retirement, while newer technologists are trained largely on other languages and tools. The strain is already measurable. In one 2025 industry survey, most IT leaders called expanding mainframe capacity a priority, while a clear majority highlighted the need for greater specialized expertise.⁷ ISO 20022 previewed the consequence, with programs slowed as much by the availability of people who understood the systems as by the systems themselves. The institutions most exposed are often those running the most stable platforms, because stability is what lets the knowledge concentrate in a small group to begin with. As that knowledge retires, the constraint on change shifts from the technology to the people who can safely change it. 

Forced-migration risk.
Every platform that drifts to the edge of the estate eventually meets a decision the institution does not control: a support change, an enterprise consolidation, an architectural mandate. At that point, a migration that could have been planned becomes urgent and compressed. A migration forced onto an external deadline costs more and carries more risk than one the institution schedules for itself. 

Naming platform sustainability as a risk category changes the question leadership asks. The question becomes whether the institution is accumulating a forced migration it has not scheduled and what it would cost to convert that into a planned one. The two are not equivalent. A planned re-platforming preserves the proven application, runs in parallel with existing operations, and moves on the institution’s timetable. A forced one does none of that. 

This is not a claim that every bank should move. It is a claim that sustainability should be assessed deliberately rather than discovered late. A bank that has run a proven engine reliably for years has every reason to keep it. The strategic question is whether the platform beneath that engine is one the bank has chosen to depend on for the next decade or one it depends on by default.

The second pillar concerns where resilience comes from. A payments platform can be made resilient on its own. More durable resilience comes from alignment with the enterprise platform an institution already trusts with its most critical workloads. 

Most large banks already run core transaction processing on a platform engineered for continuous availability, security, and very high volumes. When payments run on a separate, dedicated platform, the institution carries two operating models, two resilience postures, two security perimeters, and the integration layer between them. That separation was once a reasonable design choice. As the rate of change rises, it becomes a source of fragmentation and a multiplier of effort. Bringing payments into alignment with the core addresses several pressures at once. 

Alignment reduces fragmentation directly.
Fewer separate systems mean fewer handoffs, fewer reconciliation points, and fewer places where a change in one system forces a change in another. The payments flow moves closer to the data and the systems it depends on, which is exactly what would have made a mandate like ISO 20022 less painful. 

Resilience can be governed once.
Rather than demonstrate operational resilience separately for payments, the institution can extend the model it already operates and supervises for its core. IBM Z systems are engineered for continuous availability, with quantum-safe encryption and enterprise-grade security as platform properties rather than features added afterward.⁸ The point for a payments leader is not a single availability number, which depends on configuration and is measured under defined conditions. It is that resilience, security, and recovery can be governed once, at the platform level, for both core and payments. 

Time-critical intelligence runs where the transaction runs.
As real-time fraud and financial crime decisioning moves inside the authorization window, running it on the same platform that processes the payment lets the decision be made without moving sensitive data off platform, which removes both latency and a category of risk. This is where artificial intelligence in payments actually lands, as a workload with strict latency and data-locality demands. IBM Z addresses it directly, with on-chip inferencing designed to score transactions for fraud in real time, on-platform, at approximately a one-millisecond response.⁹ The platform either meets those demands or forces the workload somewhere it cannot run well. 

Future demands fit the same foundation.
BASE24-eps on IBM Z is designed to run high-volume, low-latency processing while aligning with IBM Z and Db2 workloads, and it supports partitioning so that test, development, and production environments can be managed together with less disruption when moving to a new release.¹⁰ The same alignment opens a path toward containerized operation. ACI Connetic^®, ACI’s next-generation card processing cloud-native platform, is delivered in container-based form on IBM Z and IBM LinuxONE with Red Hat OpenShift.¹¹ 

A dedicated platform can certainly be made resilient. Resilience built in isolation simply costs more to sustain, and it is harder to extend, compared to resilience inherited from the enterprise platform the institution already trusts. For a bank anchored on IBM Z in the core, the most durable resilience strategy for payments may be the platform it already operates for its core.

The third pillar addresses execution, because the strongest strategic argument fails if the path to reach it is not credible. The credible path is a phased move of a proven engine rather than a wholesale rewrite. A rewrite replaces a working application with a new one and accepts the risk that the new application will not match the proven behavior of the old. A phased re-platforming keeps the application and changes the platform beneath it, in stages, with the existing system still running. The first approach protects the business from the largest category of payments project risk, the loss of behavior validated over years of production. 

Rabobank’s modernization offers a worked example of the discipline involved, even though its starting point differs from the case considered here. The bank’s transaction processing renewal program began in 2014. Rather than cut over in a single step, Rabobank built a new transaction processing environment alongside the existing one, ran the two in parallel, and migrated transaction flows gradually. The first transactions moved in 2016, and by 2017, all flows were running through the new system, with BASE24-eps handling switching, authorization, and real-time transaction processing.¹² The bank then extended the same platform in further phases, first into credit card issuing and then into debit, replacing an in-house solution and reducing processing costs as it went.¹³ 

Several principles carry from that example to the re-platforming case. Parallel operation contains risk, because running the new and existing environments side by side lets an institution migrate on evidence rather than faith and fall back if needed. Phasing separates the foundation move from later modernization, so the platform change becomes a foundation step that enables feature work rather than a single high-risk program. And modernization compounds once the foundation is right, because each phase builds on the same modern base and makes the next one easier. 

No single path fits every institution. The transferable point from Rabobank is the method: Keep the proven application, run in parallel, phase the move, and treat the platform as the foundation for modernization rather than as the modernization itself.

A serious argument states where it does not hold and answers the objections it invites. 

Migration carries real risk.
Any change to a mission-critical payments platform introduces the possibility of disruption. That is precisely why the phased, parallel-run approach matters, and why a re-platforming that preserves the proven application carries a different risk profile from a rewrite that does not. The objection holds against big-bang cutovers. It is far weaker against a disciplined, staged move. 

Re-platforming has a cost.
Moving a platform is an investment, and it competes with other demands on a finite budget. The right comparison is not against zero, but against the cost and risk of the forced migration that platform drift eventually produces, discounted for the fact that a forced migration runs on someone else’s schedule. A planned move rarely costs less in the current year, though it usually costs less when measured across the decade. 

Organizational inertia is real.
Platforms that work are difficult to reconsider, and the people who run them hold deep, legitimate expertise. The response is not to override that expertise but to reframe the question. The performance of the engine is not the issue, which may be excellent, but the sustainability of the platform around it. 

The thesis does not hold everywhere.
For an institution whose payments platform is well aligned with its enterprise estate, whose support roadmap is secure, and whose skills base is stable, the case for moving is weak, and the right answer may be to continue and modernize in place. The argument applies most directly to institutions that already run core transaction processing on IBM Z, that carry meaningful fragmentation between payments and core, and that face the dual burden of running and modernizing the same systems at once. For these institutions, the question is not whether to modernize, but what to modernize on.

Each leader who must act on the thesis meets it from a different angle. 

The chief information officer faces a portfolio decision. The right first move is a platform-sustainability assessment of the foundation beneath payments, judged against the rest of the estate and the decade ahead, rather than a feature-by-feature review of the application. 

Heads of payments find that new capabilities create value only when the platform can carry them, which makes architecture a payments-growth decision rather than simply an operations decision. 

Chief architects rarely face a single-system problem. The difficulty is the number of systems and dependencies around a payments flow the institution cannot take offline, and the question worth asking is whether payments should sit closer to the core transaction systems the institution already runs. 

Infrastructure leaders now see platform choice govern resilience, security, recovery, and operational load as much as throughput, so the business case should be operations-led rather than licensing-led, and payments should be treated as an enterprise infrastructure decision. 

Transformation executives make the larger modernization fundable by separating the foundation move from later feature work and delivering it in phases alongside existing operations. 

Across all five roles, the platform decision sits upstream of everything else each leader is trying to do, and it sets how affordable and how safe the rest will be.

A decision this consequential is best approached as a sequence rather than a single choice. Five stages convert the thesis into action, and the first two cost little and can begin now. 

1. Assess.
   Begin with a platform-sustainability assessment rather than a feature review, and make it measurable. Useful indicators include the age and concentration of platform-specific expertise, the number of integration points and handoffs surrounding the payments flow, the supported roadmap horizon of the underlying platform, and the share of routine changes that require scarce specialists. Read together, these reveal whether the institution is accumulating a forced migration, and on what timeline. 
2. Rationalize.
   Map the payments estate against the core transaction platform the institution already runs. Identify where payments and core duplicate operating models, resilience postures, and integration effort. The aim is to quantify the cost of fragmentation, the recurring tax of complexity that rarely appears on a single budget line, so the case for consolidation rests on operating reality rather than assertion. 
3. Prove.
   Before any production move, validate the target with a contained proof of concept. Re-platform a bounded workload, run it in parallel with existing operations, and measure resilience, performance, and operational fit against defined criteria. A proof that runs alongside production, with a clear fallback, converts a strategic argument into an evidenced decision. 
4. Migrate.
   Move in phases, with the proven application preserved and the existing system running throughout. Sequence the work so the platform foundation is established first and each subsequent phase builds on a validated base. Parallel operation and the ability to fall back are the controls that keep a mission-critical migration within tolerance. 
5. Modernize.
   Treat the platform move as the foundation, not the finish.  Once payments run on an aligned, durable platform, sequence the modernization it enables, adding richer real-time decisioning, faster onboarding of new rails, and a path toward containerized operation where it adds value. The return on the platform decision shows up in the lower cost and risk of every change that follows it.

Every requirement in this paper points in the same direction: a platform durable enough to absorb ongoing change; resilience and security governed once, at the enterprise level; payments aligned with the core rather than fragmented away from it; and a phased path that preserves a proven engine. These requirements are demanding, and they already describe a working combination of proven software and a proven platform. 

ACI Worldwide provides real-time payments software that runs mission-critical transaction processing, fraud and financial crime prevention, and payments orchestration for banks, billers, and merchants worldwide. BASE24-eps is a proven payments engine with a long production record across Tier 1 institutions. IBM Z is the enterprise platform that many of those institutions already trust with their core transaction processing, engineered for continuous availability, enterprise-grade and quantum-safe security, and very high transaction volumes, with on-chip capability for running intelligence close to the data. ACI and IBM have worked together since the mid-1980s, delivering transaction processing, settlement, and card management for major banks across Europe, North America, and Asia Pacific. The current expression of that work maps directly onto the argument above: 64-bit BASE24-eps on IBM z17, designed to reduce data-center cost while strengthening resilience and security, with a defined path from that foundation toward ACI Connetic, delivered in container-based form on IBM Z and IBM LinuxONE with Red Hat OpenShift.¹⁴ 

This is not the only way to meet the standard, but it shows the standard is achievable, with proven software on a proven platform, on a path that preserves what already works. An institution that runs its core on IBM Z and its payments somewhere else is carrying the fragmentation this paper describes. Bringing the two into alignment is the most direct answer to the question the next decade will keep asking.

ACI Worldwide, an original innovator in global payments technology, delivers transformative software solutions that power intelligent payments orchestration in real time so banks, billers, and merchants can drive growth, while continuously modernizing their payment infrastructures, simply and securely. With 50 years of trusted payments expertise, we combine our global footprint with a local presence to offer enhanced payment experiences to stay ahead of constantly changing payment challenges and opportunities. 

IBM provides enterprise hardware, software, and services to many of the world’s leading financial institutions. IBM Z is the company’s enterprise platform for mission-critical transaction processing, engineered for continuous availability, enterprise-grade and quantum-safe security, and high-volume workloads, with on-chip capability for running artificial intelligence close to the data. 

The ACI and IBM collaboration dates to the mid-1980s and spans transaction processing, settlement, and card management for Tier 1 clients across Europe, North America, and Asia Pacific.