Legacy Problem for Payments Revolution: Banks Are Adding AI, Tokens, and Instant Rails Before the Old Stack is Gone

TL;DR

• Banks are modernizing payments faster than they can retire the systems being replaced, creating years in which old and new infrastructure may have to operate together.
• ISO 20022 adoption shows that changing the message format does not automatically fix the quality of the information inside the message. Swift reported in April 2026 that 61.2% of payments still contained unstructured debtor postal addresses and 62.9% contained unstructured creditor information.
• Swift later deferred all payments changes in Standards Release 2026 and extended the structured-address migration timeline after parts of the industry said they were not ready. The Federal Reserve subsequently rescheduled the corresponding Fedwire Funds Service release from November 2026 to November 2027.
• AI agents create a new authorization problem: banks may need to verify not only the customer and the payment, but also the mandate under which software was allowed to act.
• Stablecoins and tokenized deposits could improve settlement and programmability, but banks may have to support both tokenized and conventional money for a long period, adding another layer of infrastructure before any old layer disappears.
• Instant payments make fraud prevention more difficult because a transaction can be technically authorized by a real customer while still being driven by a scam, manipulation or mistaken intent.
• The strategic question is shifting from “How quickly can we add the new technology?” to “Which old complexity can we actually remove once the new technology is live?”

Five Problems Hiding Behind the Payments Boom

Problem One: The New Payment Stack Can Cost More Before It Costs Less

Technology modernization is often explained as a substitution story. An institution replaces old infrastructure with newer infrastructure, gains automation and scalability, then captures the savings.

Payments rarely move that neatly.

Large banks operate systems with decades of accumulated dependencies. A legacy payment engine may interact with customer records, sanctions screening, treasury systems, reconciliation tools, liquidity management, reporting, accounting, regulatory controls and downstream applications that were built at different times for different purposes.

Replacing one component does not necessarily make those dependencies disappear.

That creates a period in which a bank can be paying for the cloud environment, integration layer, migration team, testing program and new security architecture while still funding the data center, software licenses, specialist staff, resilience arrangements and operational controls attached to the legacy stack.

The important metric is therefore not simply how much the new platform costs.

It is how quickly the institution can retire the old cost base after the new platform becomes operational.

This distinction matters because resilience works against aggressive retirement. Payments are mission-critical. A bank cannot simply turn off a proven system because a new environment passed its first production test. Parallel runs, fallback capabilities, duplicated monitoring and extended migration windows can all be rational risk-management choices. They can also leave the institution carrying two worlds at once.

The same pattern is visible elsewhere in digital finance. Crypto systems often promise to remove intermediaries, yet the practical user experience can still depend on exchanges, custodians, banks, identity providers, compliance teams and fiat on-ramps. The Crypto Encounter has previously examined why crypto payments remain operationally complicated for ordinary users even when the underlying transfer technology is fast.

The banking version of the problem is larger because the institution cannot optimize only for speed or cost. It has to preserve availability, regulatory compliance, auditability, recoverability and customer access throughout the transition.

A credible cloud business case should therefore answer a harder question than “What will the target architecture cost?”

It should show which existing costs disappear, which costs merely move, which costs survive, and which new controls are added because the system has become more distributed.

Until those answers are visible, a lower unit cost for computing does not necessarily mean a lower total cost for payments.

Problem Two: ISO 20022 Can Modernize the Message Without Fixing the Data

ISO 20022 illustrates a different version of the same modernization problem.

The global payments industry has made enormous progress toward the richer messaging standard. Swift said in August 2026 that more than 98% of payment instructions were being sent in ISO 20022 format after the transition from the older MT standard.

At first glance, that sounds like the migration is nearly complete.

The data tells a more complicated story.

In April 2026, Swift reported that 61.2% of payments still contained unstructured debtor postal addresses, while 62.9% contained unstructured creditor information. Swift’s target for unstructured addresses was zero.

That gap exposes an important lesson: a modern message container does not guarantee modern data inside it.

A bank may be able to send an ISO 20022 message while the address entered by a corporate client originated in an old enterprise resource planning system, a free-text field, an outdated customer database or a manual workflow that was never designed for structured global payments.

In other words, the industry can modernize the highway while vehicles continue arriving with incomplete paperwork.

Swift acknowledged the readiness problem on August 27, 2026. In an official update, the network said progress toward structured postal addresses remained uneven and that large parts of the industry were still unable to meet the requirement. Swift therefore agreed to a controlled extension and said it would defer all payments changes under Standards Release 2026, with an update on the timing and approach for structured addresses due by December at the latest.

The Federal Reserve followed with a major scheduling change of its own. Federal Reserve Financial Services moved the Fedwire Funds Service release planned for November 2026 to November 2027, citing industry alignment and interoperability with peer market infrastructures.

The delay gives institutions time. It does not solve the data problem by itself.

That distinction is essential.

If the source of the bad data sits inside corporate customer systems, correspondent-bank records, onboarding databases or legacy internal applications, another year only helps if organizations use that year to repair the source, not simply postpone the cutover.

ISO 20022 was designed to make payment information richer and more structured. Better data can improve automation, reconciliation, screening and transparency. But the benefits depend on the quality of the information entering the chain.

A poorly populated structured field is not automatically more useful than a well-maintained legacy record.

This turns ISO 20022 from a messaging project into a data-governance project.

It also changes who owns the problem. Payment operations cannot fix everything alone. Corporate clients, onboarding teams, compliance functions, vendors, treasury platforms and core-banking systems may all contribute data that eventually reaches the payment message.

The institutions that treat the extension as a technical deadline change may arrive at the next deadline with the same underlying weakness. Those that treat it as a data-remediation window have a chance to capture what ISO 20022 was supposed to deliver in the first place.

Problem Three: AI Can Make the Payment, but Who Gave the Machine Permission?

The next shift is more fundamental because it changes who, or what, initiates the transaction.

Consumers are already familiar with software making recommendations. An AI assistant can compare flights, search hotels, monitor prices, shortlist products or organize a trip. The next stage is not difficult to imagine: the software is allowed to complete the purchase.

That transition creates agentic payments.

The technical idea is straightforward. A user gives an AI agent a mandate that defines what the software is allowed to do. The mandate might restrict merchants, categories, payment methods, time periods and spending limits. Tokenized credentials can then allow the agent to transact without exposing the user’s raw payment information.

The governance problem is much harder.

Suppose a customer tells an AI travel assistant:

Book a four-day business trip to Miami. Keep the total under $4,000. Choose a hotel within 20 minutes of the venue and avoid overnight flights.

The software can interpret that instruction in many ways. It may select a more expensive flight to satisfy the schedule. It may pay a hotel deposit. It may change the booking when a cheaper option disappears. It might purchase ground transportation. It could face a merchant that only accepts a particular payment method.

Which of those decisions did the customer actually authorize?

Traditional digital payments generally rely on some combination of identity, authentication, account ownership, device signals and transaction approval. Agentic commerce inserts a decision-making layer between the human and the payment.

That means authorization may need to become hierarchical:

human identity → agent identity → customer mandate → transaction decision → payment credential → bank controls → settlement.

Every arrow is a possible control point.

Banks will need ways to determine whether the agent is genuine, whether the mandate is current, whether the requested payment falls within its boundaries, whether the credential can be used for that merchant, and whether the surrounding behavior looks consistent with the customer’s intent.

The problem becomes even more serious when instant payment rails are involved. A card transaction may offer established dispute processes and network controls. A real-time account-to-account transfer can reduce the time available to detect something wrong before money reaches the recipient.

The Crypto Encounter has already examined the machine-speed risk through research into security weaknesses in AI-agent crypto payments. The important lesson extends beyond crypto: autonomous execution can scale both convenience and mistakes.

AI also changes the attack side of the equation. Criminals can use automation to generate conversations, impersonate trusted people, personalize fraud attempts and maintain interactions at a scale that was previously expensive. That is why our reporting on AI agents and automated crypto fraud matters to mainstream payments as well.

The future payment system may therefore need something stronger than authentication.

It may need machine-readable evidence of intent.

Authorization Is Becoming a Living Contract

A useful way to think about an AI-payment mandate is as a contract that can be evaluated by machines.

Instead of giving software unlimited access to an account, the user could specify boundaries such as:

• maximum value per transaction;
• maximum cumulative value over a day, week or trip;
• approved merchant categories;
• approved geographic areas;
• allowed payment rails;
• expiry time;
• transactions requiring human reapproval;
• conditions under which the mandate can be revoked;
• whether substitutions are allowed;
• whether the agent can create recurring commitments.

That sounds manageable until real-world ambiguity appears.

A user might permit a hotel purchase but not a resort fee. They may authorize a subscription but not its renewal. They may allow an AI procurement agent to buy office supplies while excluding gift cards. They may permit payments to an established supplier but not to a new bank account presented in an email.

Fraudsters will inevitably search for the spaces between the rules.

The payments industry therefore faces a design challenge that resembles smart-contract security. The system must translate natural-language intention into machine-executable boundaries without creating loopholes the user never anticipated.

Crypto has already shown why this distinction matters. A blockchain can process a valid signed instruction exactly as designed even when the human signing it has been deceived. Our explainer on why technical security does not always produce user safety makes the same point from the consumer side.

Agentic payments bring that problem directly into banking.

Problem Four: Stablecoins and Tokenized Deposits Could Create a Second Financial Stack

Digital money introduces another layer of coexistence.

Stablecoins already move value across public and permissioned blockchain networks. Banks and central banks are exploring tokenized deposits, tokenized reserves and programmable settlement. The attraction is easy to understand: faster settlement, automation, conditional transactions, potentially lower reconciliation overhead and the ability to combine money with other tokenized assets on shared infrastructure.

The Bank for International Settlements has moved the discussion beyond theory. In May 2026, BIS announced that Project Agorá had demonstrated atomic multi-currency settlement using tokenized central-bank reserves and tokenized commercial-bank deposits. The project involved seven central banks and more than 40 regulated financial institutions, and BIS said work would advance toward real-value testing.

That is important progress.

It does not answer the transition question.

If a bank offers tokenized deposits, those tokens still have to relate to the bank’s balance sheet, customer records, liquidity management, compliance obligations and conventional deposit systems. A tokenized representation of money may sit on a programmable ledger, but the institution cannot ignore the accounting and regulatory infrastructure surrounding the liability.

Stablecoins create a different set of dependencies. A stablecoin may travel on a blockchain, while the assets supporting it sit in bank deposits, Treasury securities, money-market instruments or custodial arrangements inside traditional finance. The Crypto Encounter’s analysis of who actually holds the dollars behind stablecoins shows how deeply digital tokens can remain connected to old financial infrastructure.

This creates a paradox.

The visible payment may be tokenized while the invisible support system remains conventional.

Banks considering stablecoin services or tokenized deposits therefore face a choice that is less binary than the public debate suggests. They may not be deciding between “traditional banking” and “blockchain banking.” They may have to operate both.

The Expensive Middle: When Both Money Systems Have to Work

Imagine a commercial bank five years from now serving three types of corporate customer.

One wants conventional account-to-account payments. Another wants tokenized commercial-bank deposits for programmable settlement. A third wants to pay international suppliers using regulated stablecoins.

The institution may need to support:

• traditional deposit accounts;
• real-time payment rails;
• wire infrastructure;
• blockchain connectivity;
• wallet management;
• token issuance or redemption processes;
• digital-asset compliance controls;
• sanctions and transaction monitoring across different rails;
• liquidity between tokenized and conventional money;
• reconciliation between ledger environments;
• customer support for systems with very different failure modes.

None of those requirements is inherently an argument against tokenization. They are an argument for measuring the transition honestly.

The efficiency case becomes strongest when new infrastructure eliminates an old process. It becomes weaker when new infrastructure merely sits beside the old one.

This is why stablecoin adoption should not be reduced to transaction speed. The Crypto Encounter has explored both sides of that question in our analysis of whether stablecoins can genuinely replace bank transfers. They may outperform traditional rails for specific cross-border jobs without yet replicating every feature of regulated bank money.

The banking-economics question goes further. If stablecoins draw meaningful balances away from deposits, institutions may also have to rethink funding. Our examination of whether stablecoins could make banks more expensive considered what happens when payment innovation starts changing the liability side of the bank rather than merely the front-end experience.

Tokenized deposits offer a different model because they remain commercial-bank liabilities. Yet they still require interoperability, common standards and credible settlement arrangements if they are to move efficiently across institutions.

The future may therefore be neither a stablecoin victory nor a bank-token victory.

It may be a prolonged contest between architectures, with institutions paying to connect them.

Stablecoins Reveal Why “Digital” Does Not Mean Independent

The stablecoin market also provides a warning against treating new rails as self-contained financial systems.

A token can settle on-chain in seconds while depending on off-chain reserves, redemption banks, market makers and custodians. When confidence in those supporting institutions changes, the token can feel the impact.

The March 2023 USDC episode demonstrated this clearly when reserve exposure to Silicon Valley Bank temporarily pulled USDC below its dollar target. That event remains useful because it showed how a blockchain-native asset can inherit risk from conventional banking infrastructure.

Our detailed guide to what actually happens when a stablecoin loses its peg separates reserve shocks, algorithmic failures and collateral contagion because the mechanism matters more than the label.

For banks building digital-money strategies, the wider lesson is that tokenization relocates some risks, reduces others and creates new dependencies. It does not remove the need to understand the full chain behind the payment.

Problem Five: The Customer Approved the Payment. That Does Not Mean the Bank Should Ignore the Risk.

Modern fraud prevention has historically relied heavily on a question that sounds simple: did the customer authorize the transaction?

Scams make that question inadequate.

A victim of an investment scam may log into a genuine banking app, pass multifactor authentication, add the beneficiary, enter the exact amount, review the payment and press the final confirmation button personally.

The bank can authenticate the user perfectly.

The payment can still be disastrous.

This is the core problem created by authorized push-payment scams and similar forms of social engineering. The criminal does not necessarily need to break the payment system. The criminal persuades the legitimate customer to use the system correctly for the wrong purpose.

Instant payments intensify the challenge because speed is both the product feature and the risk condition. A payment that settles within seconds gives institutions less time to investigate suspicious behavior and less opportunity to recover funds once the recipient moves them onward.

Federal Reserve Financial Services has been adding tools around this problem. In April 2026, its FedNow Service launched a network intelligence API that gives sending institutions receiver-account information observed across the service before an instant payment is made. The Federal Reserve has also described fraud mitigation as increasingly dependent on understanding customer behavior and intent, not merely whether credentials were valid.

This is the same conceptual divide crypto users already know. A network can confirm authorization. It cannot necessarily confirm understanding.

That is why The Crypto Encounter’s crypto safety checklist emphasizes transaction context, destination verification and human behavior rather than assuming cryptographic approval equals a safe outcome.

Banking is moving toward the same realization.

Fraud Detection Is Becoming Intent Detection

The next generation of payment controls may need to ask several questions simultaneously:

• Is this really the customer?
• Is this really the customer’s device?
• Is the beneficiary who the customer thinks it is?
• Does the transaction match previous behavior?
• Does the beneficiary account exhibit risk signals?
• Has the customer recently changed contact details, credentials or devices?
• Is there evidence of coercion, remote access or social engineering?
• If an AI agent initiated the payment, does the transaction remain inside its mandate?
• Should the transaction be delayed or escalated even though the user has approved it?

Those questions create tension with customer experience.

A payment system that challenges every unusual transaction is frustrating. A payment system that never challenges an authenticated customer can become a highly efficient delivery mechanism for scammers.

The correct intervention threshold will vary by institution, rail, customer and transaction type. That is why payment intelligence is moving toward contextual risk rather than a single yes-or-no authentication event.

The implications for AI are significant.

Once autonomous agents start executing transactions, fraud systems may need to distinguish between human intent, machine interpretation and attacker manipulation.

A legitimate customer may authorize a legitimate AI agent using a legitimate credential, yet the agent may act on poisoned information, a malicious merchant page or an instruction that technically falls inside the mandate while violating the user’s real objective.

At that point, the financial system is no longer simply authenticating payments.

It is evaluating chains of decision-making.

The Five Problems Are Really One Problem

Cloud cost, ISO 20022 data, agentic authorization, tokenized money and payment fraud appear to belong to different technology conversations.

They are increasingly connected by the same structural issue.

The financial system is adding new capability faster than it can remove old dependency.

Cloud platforms arrive before legacy systems retire.

ISO 20022 arrives before source data is fully structured.

AI agents arrive before authorization models are fully defined.

Tokenized money arrives before conventional money infrastructure becomes unnecessary.

Instant payments arrive before institutions can always distinguish a genuine instruction from a manipulated decision.

This pattern explains why technological progress in finance can feel slower and more expensive than the technology itself suggests.

Payments are not a greenfield software problem. They are a trust infrastructure built over decades of legal rules, operating procedures, customer expectations, risk controls and institutional dependencies.

Every meaningful innovation has to enter that environment without breaking it.

The Payment Modernization Stress Test

For banks, payment providers, fintechs and digital-asset firms, the following checklist provides a more useful way to evaluate modernization than asking whether a new technology has been deployed.

• ☐ Retirement test: Which legacy system or process will be shut down because of this investment, and on what date?
• ☐ Duplicate-cost test: How long will old and new systems operate simultaneously?
• ☐ Data-origin test: Where does the information entering the payment message originate, and is the source structured?
• ☐ Resilience test: What additional infrastructure is required to maintain fallback and continuity?
• ☐ Authorization test: Can the institution explain exactly what a human authorized an AI agent to do?
• ☐ Revocation test: Can that authority be withdrawn immediately across every connected payment method?
• ☐ Intent test: Can fraud controls identify signs that an authenticated customer may be acting under deception?
• ☐ Interoperability test: Can tokenized money move into and out of conventional systems without expensive manual intervention?
• ☐ Liquidity test: Does the new rail create trapped liquidity or additional prefunding requirements?
• ☐ Accounting test: Can transactions be reconciled consistently across traditional and tokenized ledgers?
• ☐ Failure-mode test: Who is responsible when the payment is technically valid but economically wrong?
• ☐ Customer-support test: Can frontline teams explain what happened when a transaction crosses several infrastructures?

If a project adds capability but cannot answer the retirement, authorization and failure-mode questions, the institution may be modernizing its surface while increasing complexity underneath.

What This Means for Crypto and Traditional Finance

The boundary between crypto payments and banking infrastructure is becoming less useful as an analytical dividing line.

Stablecoin issuers hold conventional reserves. Banks experiment with tokenized deposits. Blockchain networks connect to fiat payment providers. AI agents may eventually choose between cards, instant bank transfers and digital tokens according to price, speed and merchant acceptance.

Ripple’s push to connect RLUSD and blockchain-based payment infrastructure with companies such as Flutterwave is one example of the overlap. The Crypto Encounter’s coverage of Ripple’s move into African payments through Flutterwave showed how stablecoin infrastructure is increasingly being positioned alongside established cross-border payment networks rather than in a separate crypto universe.

This convergence means the most important future payment infrastructure may be orchestration.

The winning system may not be the rail that replaces everything else. It may be the layer that decides which rail to use, applies the correct compliance and fraud controls, manages liquidity, carries the necessary data and gives the customer a consistent experience regardless of what settles underneath.

That would also explain why interoperability is becoming as strategically important as raw transaction speed.

The Next Payments Race Is About Subtraction

For most of the digital era, financial innovation has been measured by addition.

More APIs. More rails. More data. More automation. More digital assets. More real-time capability.

The next phase may require a different measure.

What can be removed?

Can the cloud platform actually eliminate a legacy environment?

Can structured ISO 20022 data remove manual repair and investigation?

Can an AI-payment mandate replace repeated authentication without weakening customer control?

Can tokenized deposits reduce reconciliation rather than create another ledger to reconcile?

Can stablecoin settlement eliminate meaningful friction instead of simply adding another asset, wallet and compliance workflow?

Can smarter fraud controls prevent scams without turning instant payments back into slow payments?

Those questions are less glamorous than launching new infrastructure. They are also closer to the economic reality.

The financial system is unlikely to wake up one morning and discover that the old payments world has vanished. Mainframes, core banking platforms, correspondent relationships, card networks, instant rails, blockchains, tokenized deposits and AI agents may coexist for years.

The institutions that manage that overlap well will not necessarily be the ones with the longest list of technologies.

They will be the ones that understand precisely why each layer exists, what risk it controls, what cost it creates and when it can finally be removed.

That is the harder version of payments modernization.

It may also be the one that determines whether the next generation of financial infrastructure becomes genuinely cheaper, safer and more useful, or simply more complicated.

Frequently Asked Questions

Why are banks still running legacy payment systems after moving to the cloud?

Payments systems are deeply connected to core banking, compliance, treasury, reconciliation, customer records and regulatory processes. Banks commonly need parallel operations, fallback arrangements and extensive testing before older infrastructure can be retired. Cloud migration can therefore create a period in which both environments must be funded.

What is the main ISO 20022 problem in 2026?

Format adoption is very high, but structured data remains incomplete. Swift said in April 2026 that 61.2% of payments included unstructured debtor postal addresses and 62.9% included unstructured creditor information. In August 2026, Swift deferred all payments changes in Standards Release 2026 and extended the structured-address migration timeline after industry readiness concerns.

Why did the Federal Reserve delay the Fedwire Funds Service release?

Federal Reserve Financial Services moved the planned November 2026 Fedwire Funds Service release to November 2027 after Swift extended its own timeline. The Federal Reserve said the decision supported alignment and interoperability across major payment market infrastructures.

What is an agentic payment?

An agentic payment occurs when an AI agent executes a payment on behalf of a user under a defined mandate. The challenge is ensuring that the agent’s identity, credentials, transaction and decision remain within the limits the customer actually authorized.

Are tokenized deposits the same as stablecoins?

No. A tokenized deposit represents a commercial-bank deposit on a programmable or tokenized ledger and remains a liability of the issuing bank. Stablecoins are digital tokens issued under different structures, typically backed by reserves or other assets depending on the model. Both can use tokenized infrastructure, but their legal, monetary and risk characteristics differ.

Could stablecoins replace bank transfers?

Stablecoins can already offer speed and around-the-clock transferability for certain use cases, particularly cross-border transactions. However, they do not automatically replicate every feature of regulated bank transfers, including consumer protection, deposit treatment, legal certainty, interoperability and established dispute processes.

Why are instant payments harder to protect from scams?

Instant payments reduce the time between authorization and settlement. A legitimate customer can also be manipulated into approving a payment to a criminal. Fraud prevention therefore has to consider beneficiary risk, behavioral signals and customer intent rather than relying only on identity and authentication.

What connects cloud migration, AI payments, ISO 20022 and tokenization?

All four can add a new layer of capability before the system they are expected to improve or replace disappears. That overlap creates duplicate cost, operational complexity, new control requirements and interoperability problems. The economic value of modernization ultimately depends on how much old complexity the new infrastructure can remove.

Editorial Note

This analysis was developed from current primary-source material on payment messaging, Fedwire modernization, instant-payment risk controls and tokenized money, alongside The Crypto Encounter’s existing reporting on stablecoins, crypto payments, AI agents and digital-asset security. Product or industry references are included for context and do not constitute endorsements.

Disclaimer

This article is for informational and educational purposes only. It does not constitute financial, investment, legal, regulatory, accounting, cybersecurity or technology advice. Payment systems, digital assets, stablecoins, tokenized deposits and artificial-intelligence technologies involve operational, legal, financial and security risks. Institutions and individuals should conduct their own due diligence and consult qualified professionals where appropriate.