Swift Delays ISO 20022 Address Mandate as Legacy Bank Data Slows Payment Migration
Oct. 20, 2026 • Deep Dive • Banking & Payments
Swift has postponed the mandatory removal of unstructured postal addresses from payment messages, previously scheduled for November 14, 2026. It has also deferred cross-border payments changes to Standards Release 2027 or later, with an updated scope expected by December 2026. The European Payments Council and Federal Reserve Financial Services have postponed their structured address timelines in response.
The delay exposes a data problem beneath the messaging change. Swift monitoring found that roughly 61% to 65% of global payment messages still used unstructured addresses shortly before the decision. Many core banking and ERP systems store addresses as free text rather than the separate fields specified by ISO 20022. Swift’s interim hybrid format requires a structured town name and country code while allowing limited free-text detail. Separately, the non-payments portion of Standards Release 2026 is now scheduled for June 12, 2027, to avoid a conflict with Europe’s T+1 settlement migration.
Swift has postponed the mandatory removal of unstructured postal addresses from payment messages, a change that had been scheduled for November 14, 2026, under Standards Release 2026. The August 27 decision reflects a practical obstacle to the ISO 20022 migration: many institutions still hold payment-party addresses as free text, rather than in the separate fields needed for structured messages.
The postponement has since become part of a wider schedule change. On September 21, Swift said all cross-border payments changes covering MT Category 1, CBPR+, SCORE+ and SwiftGo would move to Standards Release 2027 or later. It expects to provide scope updates by December 2026. Swift has not set a replacement enforcement date for the structured address requirement in the verified information available here.
The data problem behind the deadline
Swift network monitoring showed that roughly 61% to 65% of global payment messages still used unstructured postal addresses shortly before the postponement. The figure points to the scale of the transition: a messaging standard can specify where address components belong, but the information must first be available in a form that can populate those fields.
ISO 20022’s PostalAddress schema provides up to 14 discrete structured fields, including StreetName, BuildingNumber, PostCode, TownName and Country. By contrast, legacy core banking and enterprise resource planning, or ERP, systems have often stored addresses as multiple lines of free text designed for MT delivery tags. Moving from one format to the other therefore involves more than changing the outgoing message: it requires institutions to address how the underlying records are stored and supplied.
Other readiness indicators reinforced the concern. A RedCompass Labs study found that 44% of global banks were not on track for the original November 2026 deadline. Among banks with assets exceeding $250 billion, 20% considered the mandate unrealistic. Belgium’s Isabel clearing network reported that approximately 85% of payment files routed through its system failed to meet structured address criteria. Those measures cover different populations, but each documents a gap between the required format and the data being submitted or held.
An interim format, not a permanent exemption
Swift established a hybrid address format to ease the transition. It requires a structured Town Name and Country Code while permitting up to two 70-character free-text lines for other address details. The arrangement allows some address information to remain in its existing form without abandoning structured fields altogether.
The longer-term objective remains tied to Financial Action Task Force Recommendation 16 and G20 cross-border payments roadmaps. The structured address requirement is intended to reduce false-positive sanctions screening hits and support straight-through processing, in which payments can move through systems without manual intervention. The postponement changes the timetable for enforcement; it does not remove the underlying reason for improving address data.
That distinction matters for banks and their customers. Where an address exists only as free text in a core system or ERP record, adopting a new payment message alone cannot reliably provide every discrete address component. The reported failure rates and Swift’s network monitoring help explain why enforcing the original deadline would have affected more than a small group of late adopters.
A wider release rescheduling
The European Payments Council followed Swift on September 9, postponing structured address enforcement across all five of its SEPA scheme rulebooks. Federal Reserve Financial Services also postponed its structured address migration timeline for US payment rails to align with Swift’s revised schedule. These changes show that the address deadline was not confined to one set of cross-border messages.
The revised schedule also affects other planned changes. Deferring Standards Release 2026 delayed the mandatory decommissioning of MT 101 messages in favor of pain.001 instructions and cancelled the planned October 3, 2026, Relationship Management Application bootstrap.
Swift separated the non-payments portion of the release—including MT non-payments, securities, funds and tracker messages—and scheduled it for June 12, 2027. It chose that date to avoid conflicts with Europe’s migration to T+1 settlement. Although some initial post-delay reports placed this portion of the release in the first quarter of 2027, Swift subsequently clarified the June date. It should not be confused with a new deadline for structured addresses or the broader cross-border payments changes.
For institutions planning the migration, the next stated milestone is Swift’s expected scope update by December 2026. The revised timetable provides more time to work on address records, but the readiness figures identify the central task: making payment data usable in structured fields, not merely changing the message that carries it.
Revolut’s expansion into UK consumer lending is facing closer regulatory scrutiny. The Financial Times reported on October 27, 2026, that the Bank of England’s Prudential Regulation Authority had ordered a Section 166 skilled-person review of the bank’s product approval processes and internal risk governance. The review comes as Revolut offers unsecured personal loans and prepares to introduce a domestic credit card, with mortgages planned later. Revolut UK CEO Francesca Carlesi has said the bank intends to package and sell loans through securitisation rather than retain substantial long-term credit exposure. Revolut is targeting a loan-to-deposit ratio of roughly 6%, far below the roughly 100% typical of incumbent British high-street banks. The strategy could support lending growth while limiting loans held on its balance sheet, but it does not eliminate credit risk. S&P Global has cited the possibility of higher credit losses as Revolut expands lending across multiple jurisdictions.
Sumitomo Mitsui Banking Corporation (SMBC) and Ant International signed a memorandum of understanding on October 26, 2026, to explore cross-border payments and digital treasury services. Their initial focus is Japan, Singapore and wider Southeast Asia. Engineering teams will examine whether Ant International’s Whale RTP platform can be integrated with SMBC’s institutional transaction banking and digital asset platforms. The agreement is exploratory, not the launch of a live settlement service. SMBC’s multi-market transaction banking rails are expected to support operations involving Ant International’s Alipay+, Antom and WorldFirst businesses. Ant International says its Whale platform processed more than US$600 billion in global treasury flows in 2025, with over 95% of transactions settling on the same day. Those figures describe the existing platform, not activity under the SMBC agreement. The MoU follows separate tokenized-deposit work involving Ant International and other banks, including a live OCBC solution and an HSBC pilot.
Tech Mahindra and Finastra announced on October 23, 2026, that Tech Mahindra had completed its acquisition of Finastra’s cash management products and related intellectual property. The deal moves Tech Mahindra beyond implementing banking software for clients and into owning transaction banking products. Financial terms were not disclosed. The acquired portfolio includes Fusion Cash Management, Fusion Virtual Accounts and Fusion Liquidity Management, along with CashPlus, Global CashPlus and associated transaction banking APIs. Finastra product engineering and customer success personnel are being moved into Tech Mahindra’s banking, financial services and insurance division. Tech Mahindra plans to integrate the products into its existing Finastra Centre of Excellence to maintain service continuity for banking clients. The acquisition follows Tech Mahindra’s earlier purchase of an 85% stake in Canadian fintech Avant Techno Solutions and comes as Finastra divests businesses to concentrate on lending and payments software.
The European Payments Council implemented Version 1.1 of its Verification of Payee scheme rulebook on September 20, 2026, clarifying operations, API specifications and security after feedback from live deployment. Its directory service, operated with SWIFT, has also completed a live transition supporting provider reachability and routing. The changes come as non-eurozone EU payment providers work toward a July 9, 2027, compliance deadline. Required under the EU Instant Payments Regulation for both instant and standard SEPA credit transfers, Verification of Payee checks recipient details before authorization and must be offered free to users. The inter-provider exchange has a five-second operational maximum and can return a match, close match, no match or verification-not-possible result. A close match supplies the verified recipient name for the payer to review. A warning does not necessarily prevent a transfer: liability depends on whether a payer proceeds despite it or a provider fails to perform a required check.
Fireblocks has rejected an Axios report that Visa was in advanced talks to acquire the digital-asset infrastructure company for about $2.5 billion. Fireblocks said the reported discussions were not taking place at present. Visa declined to comment on the claim, while Coinbase separately denied reports that it was considering a bid. None of the companies has confirmed an acquisition process. The reported price would be about 69% below Fireblocks’ $8 billion valuation from its January 2022 Series E funding round. The company generated $124 million in revenue in 2024 but remained unprofitable, and it has initiated plans to cut 60 to 70 jobs amid the rumors. Visa already uses Fireblocks as an institutional client and works with it on an interoperability initiative. Those existing links provide context for the speculation, but do not establish that a transaction is under discussion.
TerraPay and J.P. Morgan have connected TerraPay Verify with Kinexys Liink so participating financial institutions can check recipient details before sending cross-border payments to mobile money wallets or bank accounts. Announced on October 22, 2026, the integration allows Liink participants to configure bi-directional API queries with TerraPay Verify. It extends a validation network that already covers account details in more than 70 countries to wallet-related checks. The partnership targets a source of payment failures: a 2026 LexisNexis Risk Solutions study cited during the rollout attributed 10% to 15% of cross-border payment failures to incorrect recipient or beneficiary details. Wallet identifiers can differ from conventional bank-account formats, making early checks useful but not a guarantee that a payment will complete. The companies have not publicly disclosed commercial terms, query pricing or country-by-country rollout plans, and the available information does not establish how much the integration will reduce failures in practice.