By: Parth Desai
Between December 2025 and May 2026, Swift‘s Payments Market Practice Group (PMPG) published several documents that shifted responsibility for the migration from unstructured postal addresses in ISO 20022 payment messages further upstream.
Until last week, those changes faced a November 2026 deadline. That deadline has now moved.
On 27 August, after acknowledging that the industry was not ready, Swift announced that it would defer all payments changes under Standards Release 2026. An updated timetable for the amends will now be reconsidered, with the decision makers planning consultations with industry stakeholders including banks, central banks, payment market infrastructures, market practice groups and corporates. A further update is expected by December at the latest. The non-payments elements of Standards Release 2026 – the securities and trade changes – have been decoupled from the deferral and will go live in Q1 2027.
This extension, while changing the timetable and surely prompting a few relieved exhales across the industry, does not fundamentally change the problem that needs to be solved. November 2026 was never simply a compliance date; it was a milestone on the G20-backed path to a more efficient and transparent global payments ecosystem, in which structured data cuts sanctions false positives and the cost of payment repairs and investigations. The deferral confirms that restructuring address data is not trivial, and that LLMs or unsupported community tools – without explainability, guaranteed accuracy and deterministic behaviour – have no place in a regulated environment. The time bought should be spent solving that problem holistically, not tactically.
The working group published PMPG-020 (Hybrid Postal Address – Grace Period for Banks), followed by a joint call to action by PMPG and High Value Payment Systems Plus (HVPS+) for corporates in early 2026. The PMPG-050 (PMPG Payment Insights April 2026) moved validation to the point of entry, eliminating the ability to repair address data downstream, while PMPG-060 (PMPG Payment Insights May 2026) reframed residual cutover risk as a data quality problem.
Effectively, the target audience expanded from bank operations only to both bank and corporate operations, the operating model has shifted from “downstream repair” to “point-of-entry validation”, and the residual risk has been reframed from format compliance to data quality.
The new metric is inter-field consistency, such as whether town name (<TwnNm>), post code (<PstCd>), and country (<Ctry>) are geographically coherent. During a recent diagnostic, a Tier-2 bank found that 92% of its <TwnNm>s were populated but only 64% passed the test for inter-field consistency. Therefore, roughly one in three payments with structured postal addresses were geographically incoherent despite passing format validation.
The fix is situated upstream. The master data sits in the corporate’s ERP, not the bank’s payments engine. Banks can validate, but only corporates can fix the data, so it’s now a joint problem for banks and corporates. That’s the industry update most haven’t yet pieced together.
Banks should use the extra time to widen the lens beyond addresses to remittance information, payment purpose and regulatory reporting – the same data quality problem in adjacent fields. Structured addresses also pay back directly in sanctions, AML, KYC, and FATF checks such as the travel rule, which belongs in the business case. And banks should give corporate and SME customers the tools to fix the data before a payment is ever submitted.
Checklist for success
Corporates cannot simply outsource the cutover to their bank. There are five concrete actions that corporates should take to ensure they are ready to meet the extended deadline when it is set:
- Audit how their ERP or TMS captures <TwnNm> and <Ctry> today. On first audit, a surprising number of corporates discover that these data points live coupled inside one or two free-text address strings – this needs to be addressed.
- Capture <TwnNm> and <Ctry> as discrete fields in their master data. These data points should be in named, validated fields with their own data-type constraints, not as part of a larger address string.
- Migrate from the MT101 message format to pain.001 SCORE, where their bank supports the latter format. Keeping MT101 with address information will result in the address being lost. Pain.001, on the other hand, natively carries the structured fields.
- Push the requirement a step further along the chain. If the corporate uses a payment factory or service bureau, their <TwnNm> and <Ctry> discipline must be used by these service providers, as they are the corporate’s channel for compliance purposes.
- Ask their house bank for a written channel ingestion specification – then tackle the gap. If the bank doesn’t have one, then ask when they will, as the gap between their spec and the corporate’s data is the work to do before the new date, whenever it falls.
Data quality is key
Format compliance is no longer the constraint; the ISO 20022 structured address data quality is.
Those corporates running joint corporate-bank data-quality dashboards before the new timetable is published will cut over cleanly when the time comes. The ones that are still optimising format – and treating PMPG-050 as “validation news” rather than as the end of downstream repair – will not.
Structured addresses are more than a compliance requirement – they create trusted, standardised data that improves enterprise data quality, and operational efficiency. They also provide the foundation for AI. Unstructured addresses are a key stumbling block in master data management and in the golden record behind any 360-degree view of customers, suppliers and employees – so resolving them properly, starting with payment addresses, pays back well beyond accounts payable. Structured data is also the foundation for AI and agentic solutions, enabling smarter automation, better insights, and long-term business value from a single strategic investment.
