How to survive the ISO 20022 hybrid address translation

At this point, you’d think everything that could be said about ISO 20022 had already been said. It hasn’t. 

Banks still relying on translation services to convert MT to MX messages face a real problem come November 2026. Especially if planning hasn’t started yet. 

The issue is straightforward: MT messages need the right ingredients to be translatable. Get the mix wrong, and the translation fails. The payment fails with it. 

You can’t bake bread without flour. You can’t translate an unstructured address into a hybrid or fully structured address without meeting a precise set of preconditions. 

So what exactly is changing? And what do you need to do to meet the deadline? 

Lost in translation

Let’s start with some context. 

In March 2023, Swift opened the door to its multi-year migration of CBPR+ (Cross-Border Payments and Reporting Plus) messages. The legacy MT standard began its long farewell, with traffic gradually shifting to ISO 20022 MX messages. 

To avoid forcing every bank to switch overnight, Swift introduced a coexistence period: a window in which MT and MX messages could flow through the network in parallel. 

November 2025 was billed as the end of that window. As it turned out, the window stayed open for exception, investigation, and payment initiation messages. These are the non-instruction message types that weren’t captured by the November 2025 mandate. Coexistence is now officially due to end in November 2026, and MT messages remain permitted until then. 

So you can be forgiven for thinking it was already over. What you won’t be forgiven for is missing the deadline when it finally arrives. 

Are you impacted? 

As the transition has progressed, three distinct types of institution have emerged: 

1. Early movers: banks that have re-platformed their payment engines and now natively send and receive MX messages (pacs.008, pacs.009, and so on)
2. Hybrid players: banks that send MT outbound but can receive MX inbound, or vice versa
3. Legacy senders: banks that, due to the cost, complexity, or risk of overhauling core systems, continue to originate MT messages and rely on translation to meet their ISO 20022 obligations downstream

The third group is large. Because so many banks fall into this category, Swift offers translation services to support them. These can be deployed on-premises, within the bank’s own infrastructure, or consumed as Swift’s billable Transaction Manager and In-flow Translation contingency service. The bank keeps sending MT payments; Swift converts them to MX before they reach the counterparty. 

It is a safety net. Legacy senders stay CBPR+ compliant without overhauling their technology. But that safety net is about to develop some holes.

What’s changing for structured addresses in November 2026?

Fully unstructured postal addresses will no longer be permitted in CBPR+ messages. The new translator rules remove them entirely, leaving only two acceptable forms: 

• Fully structured addresses: each component (street, building number, post code, town, country) in its own ISO 20022 element
• Hybrid addresses: a structured country and town name, with a free-text line for everything else

For banks with fully native ISO 20022 payloads, this is manageable. The problem lands squarely on those still relying on Swift’s translation services to convert legacy MT output. 

The translator can only produce a valid MX address if the upstream MT message gives it the right raw materials. No flour, no bread. And if those ingredients are missing, the translation service returns a STOP Translation error. The payment is rejected. 

Who will be impacted?

Nearly a third of banks are still working with unstructured customer addresses. The problem extends beyond their own records. Corporate clients, ERP systems, and treasury platforms all need to be aligned before November 2026. 

There are two areas of impact: Parties (the debtor and creditor) and Agents (the financial institutions in the payment chain). Both will be affected.

It is up to you, the bank, to prevent it. 

Parties – Fields 50a and 59a

In a payment, a party is the person or organization money moves between: 

• Field 50a — Ordering Customer / Debtor: the party whose account is being debited 
• Field 59a — Beneficiary / Creditor: the party whose account is being credited 

These are typically corporates or individuals, not banks. 

Address quality has historically been the weakest link in cross-border payments. That’s because party address data arrives from multiple sources: sales channels, ERP systems, paper forms, and legacy records. The new rules fix these inconsistencies. 

The new rules for Parties 

To be translatable to a valid MX hybrid address, the MT message must satisfy all of the following criteria: 

• Option F* must be used if an address is provided. Option F is the structured “Party Identifier + Name and Address” variant that uses line tags 1/, 2/, 3/. 
• Option K must not be used when an address is present. Option K only allows a single line of up to 35 characters — a name only, no address. 
• The “No Letter” option (i.e., plain Field 59 without a letter suffix) must not carry an address either — same restriction as Option K. 
• In Option F, the Name and Address subfield must contain a 3/ line formatted as 3/CC/TOWN NAME, where CC is a valid ISO country code, and TOWN NAME is present. 

If any of these are missing, the translator stops with errors: 

•  T20356 (country or town name missing) 
•  T20359 (malformed 3/CC/ line) 
•  T20367 (address present in 50K or 59 No Letter)

(*A refresher on Options in Swift MT messages is available at the end of this article, should you need it.)

How a Party address translates

how this might look in practice:

For the MX output, the two 2/ lines are in a single address line. The 3/ line gives the translator both the country and the town it needs. 

What happens to create a STOP Translation

The following examples illustrate how messages that appear perfectly readable to a human can still fail translation. The translator operates on structure, not meaning. 

This looks like a perfectly readable address to a human, but Field 50K is name-only under the new rules. The translator cannot extract a structured country or town from free-text lines, so it stops. 

This creates an: Error T20367. 

Likewise, this would happen with an Option F that omits the town — note the field is 50F, as Option F line tags (1/, 2/, 3/) are being used: 

This fails with T20356 because TOWN NAME is missing after the country code. 

Agents — Fields 52a, 53a, 54a, 55a, 56a, 57a, 58a 

Agents are financial institutions that handle the payment along the chain:

• 52a — Ordering Institution (debtor’s bank, when different from the sender) 
• 53a — Sender’s Correspondent 
• 54a — Receiver’s Correspondent 
• 55a — Third Reimbursement Institution 
• 56a — Intermediary Institution 
• 57a — Account With Institution (creditor’s bank) 
• 58a — Beneficiary Institution (in cover and financial-institution transfers) 

These are the banks moving the money. Each of them needs to be unambiguously identified. Either by BIC (the easy path) or by name and address (the path with the new rules). 

The new rules for Agents

• If you provide a BIC (Bank Identifier Code), you do not need a postal address. This is the simplest path; use Option A (BIC), and you are done. Translators identify the institution from its BIC, and the address question goes away. 
• If you do not provide a BIC, Option D must be used. Option D is the “Party Identifier + Name and Address” variant for agents. 
• In Option D, the second, third, or fourth line of the Name and Address subfield must be formatted as 3/CC/TOWN NAME, where CC is a valid ISO country code, and TOWN NAME is present. The country code and town name belong to the agent, not to anyone else in the chain. 
• Option B and Option C must not be used for the address. The single exception is Field 53B, which remains permitted. 
• The first line cannot be 3/CC/TOWN NAME. It must be the agent’s name. 

If these conditions fail, the translator stops with errors: 

• T20364 (Option B used) 
• T20365 (Option C used) 
• T20374 (Name, Country, and Town all required) 
• T20356 (Country or Town Name missing) 
• T20359 (malformed 3/CC/ line) 
• T20360 (no postal address information at all)

(A refresher on agent field options — A, B, C, and D — is available at the end of this article, should you need it) 

how this might look in practice:

Worked examples – Stop Tranlsation

Using Option B

Option B is no longer permitted for agent fields under the new translator rules, regardless of what the field contains, the format itself is disallowed. A bank that identifies its Receiver’s Correspondent using Field 54B will trigger an immediate translation stop, even if the content looks reasonable to a human reader: 

:54B:/12345678
North Industrial Park 

STOP Translation, error T20364. 

Using Option C

Option C carries only an account number; no name, no address. It is also disallowed under the new rules. A bank using Option C for an Intermediary Institution will hit the same wall: 

:56C:/SC202542 

STOP Translation, error T20365. 

Right option, wrong structure

Option D is the correct choice when no BIC is provided. But the structure must be exact. The first line must always be the agent’s name. A bank that puts the 3/CC/TOWN NAME line first, before the institution’s name, will fail: 

:56D:/12345678
3/GB/Newcastle 

STOP Translation. The translator cannot confirm a name is present and stops. 

Right option, incomplete content 

Option D is used correctly here, and the structure looks reasonable. There is a name, an address line, and a 3/ line. But the 3/ line contains only the country code, with no town name after it. The translator needs both. Half the ingredients are there but the bread still won’t bake: 

:56D:/12345678
1/A. Jansen
2/Prinses Beatrixlaan 23
3/NL 

STOP Translation, error T20356. 

What banks should do now

If your institution is a legacy sender and depends on Swift translation services, you must act now. November 2026 will be painful otherwise. 

Here is the work to start now:

1. Run an inventory of what you actually send

Sample your outbound MT103, MT202, MT202COV, and related traffic over a representative period. For every party and agent field, classify the option used (A/B/C/D/F/K/No Letter) and check whether the address content meets the new pre-conditions. This tells you the scale of the problem. 

2. Identify the upstream sources of address data

Addresses do not appear in MT messages by accident. They come from customer master data. Trace each non-compliant pattern back to its source system, and you’ll find where the fix is needed. 

3. Push BICs for agents wherever possible

The simplest agent path is Option A with a BIC. Every agent leg expressed as a BIC is one less address to worry about. To clean your data, the best approach is to validate your correspondent and beneficiary-bank reference data against the BIC directory. 

4. Restructure party address capture

For 50a and 59a, the front-end systems that capture customer addresses must produce content that maps cleanly to Option F with 1/, 2/, and a 3/CC/TOWN NAME line. This often means changes to onboarding screens, ERP exports, and the parsing of remittance instructions. Town and country must be discrete, validated fields — not “everything in one box.” 

5. Test against SR2025 and SR2026 CBPR+ collections

Swift’s testing readiness portals on MyStandards expose both the SR2025 (transition) and SR2026 (post-November) CBPR+ collections. Run your translated traffic through both; the SR2025 collection still permits unstructured addresses, SR2026 does not. Use the gap to find what will break. 

6. Decide your strategic direction

Translation was always meant to be a temporary solution. Banks that have not yet started the move to native ISO 20022 origination should treat the November 2026 changes as the moment to revisit the business case. The rules will keep tightening; translation will keep getting more conditional. At some point, the cost of platform modernization will be lower than the operational risks of failed translations and rejected payments. 

7. Engage your operations and reconciliation teams

When translations start failing, the symptoms appear as investigation cases, NACKs (negative acknowledgments), and reconciliation breaks downstream. Operations teams need to know what the new error codes (T20356, T20359, T20360, T20364, T20365, T20367, T20374) mean and how to triage them quickly. 

It’s time to move on from coexistence

The CBPR+ coexistence period was generous. It gave the industry nearly four years to move at its own pace. November 2026 is the point where the network finally insists that addresses be machine-readable — for sanctions screening, for fraud detection, for straight-through processing. And for the simple reason that ISO 20022 was always supposed to deliver structured, high-quality data. 

If your institution is still leaning on translation, the message from Swift is now explicit: translation will keep working, but only for messages that come in clean enough to translate. The window is open. It won’t be for much longer. 

Download our report to prepare. 

*What are “Options” in Swift messages?

In Swift MT messages, many fields support multiple variants called “options,” each identified by a letter suffix appended to the field number. The option letter defines the structure and permitted content of that field. Different options allow different combinations of identifiers, names, and address formats. 

Party field options (Fields 50a and 59a)

Option F uses a tagged line structure that makes it machine-readable:

This tagged structure is what separates Option F from the others. A translator can reliably extract country and town from a 3/ line. It cannot do the same from the free-text block in Option K or a plain Field 59 — which is precisely why those options are no longer permitted when an address is present. 

Agent field options (Fields 52a–58a) 

In Option D for agents, there are no mandatory line tags equivalent to the 1/, 2/, 3/ structure used in party Option F. However, the rules are equally strict: the first line must be the agent’s name, and the 3/CC/TOWN NAME line must appear on line 2, 3, or 4.