ISO 20022 address compliance: what banks are planning for November 2026

In our previous two articles on ISO 20022 address management, we covered what is changing with the November 2026 deadline and what a global enterprise learned firsthand from their ISO 20022 migration. The picture that emerged was clear: the data gaps are real, the timeline is tight, and the organizational complexity is underestimated.

But there was one voice missing from that conversation: the banks themselves.

What are they actually planning to do when a payment arrives with an unstructured or incomplete address? Will they reject it, correct it, or let it through? How are they handling legacy formats such as MT101 and AFB320? And are the rules the same everywhere, or does it depend on which bank and which corridor?

To find out, we surveyed a group of banks* that we work closely with. What came back confirmed the broad direction of travel and also revealed significant operational divergences that every treasury team needs to understand before November 2026.

The key finding: your data, your responsibility

Let's start with the most important finding.

Banks are broadly aligned that payments containing invalid addresses will face rejection. The general principle is that if an address is present in a payment message, it must be valid. The inclusion of an address that fails the new structural requirements is, in most banks' framing, a blocking issue.

This finding matters because a common assumption among treasury teams is that banks will act as a safety net. They will catch and correct bad data before it causes a problem. For some specific scenarios, that assumption has some basis. But as a general operating principle, it is dangerous.

The devil is in the details, and the details vary significantly.

Non-compliance is still alarmingly high

Before getting into how banks will respond to non-compliant addresses, it is worth setting the scene on where things stand today.

Two of the banks we surveyed report that around 60% of addresses they currently receive are invalid or non-compliant. One bank points to broader market data showing that nearly half of ISO 20022 addresses observed on the Swift network remain unstructured: approximately 46% for debtor addresses and 48% for creditor addresses in some markets as of spring 2026. These findings are consistent with our own data, which shows that 79% of the ISO 20022 XML transactions we process contain at least one invalid address.

The banks are aware. They are communicating. But awareness has not yet translated into remediation at the scale the deadline requires. One bank noted something that stands out: banks are all worried about the low level of feedback from clients. Most corporate treasury teams have not yet confirmed readiness, and many have not responded to outreach at all.

If your bank has sent you communications about the November 2026 deadline and you have not acted, you are in the majority. That is not reassuring.

Banks are communicating, but not equally

All the banks we surveyed confirm they have begun communicating with clients about the new address requirements. The channels are broadly similar: newsletters, information letters, dedicated web pages, practical guides, webinars, and targeted outreach to key clients.

But the intensity varies. Some banks are taking a broad-brush approach, making materials available to all clients without differentiated engagement. Others are planning more targeted actions for high-volume or strategically important clients. Several are ramping up communication in the second half of 2026 with direct outreach and reminders as the deadline approaches.

But the generic communications are a signal, not a plan. You may not receive proactive guidance from your bank that is specific enough to act on. You still need to initiate direct conversations about what your bank will and will not accept in your specific corridors and payment formats.

On payment rejection: the principle is shared, the scope is not

The banks are aligned that invalid addresses will lead to payment rejection. Where they diverge is on which addresses, for which parties, and in which circumstances.

Some banks take a relatively targeted approach. Rejection would primarily apply to the creditor, ultimate creditor, and ultimate debtor addresses. For the debtor, typically the bank's own client, they may substitute compliant address data from their internal client reference database.

Other banks take a broader stance. Any address present in a payment message, for any relevant party, must be compliant. There is no substitution mechanism for third-party data they do not hold.

This distinction matters enormously in practice. If your debtor address is non-compliant but your bank holds your records and can substitute them, you may avoid rejection on that element. But if your creditor address is missing a town name, no bank can fix that for you. They do not have your beneficiaries' data.

The safest assumption is to treat every address in every payment message as your responsibility to get right, before the payment leaves the premises.

On country-only agent address: a specific and underappreciated risk

One question in our survey revealed a divergence that few treasury teams have thought through.

Consider a payment message where an agent, an intermediary bank, has a postal address that contains only the Country tag, with no town name. This pattern is common in legacy data.

Three of the banks we surveyed consider this scenario a rejection case. Under their interpretation, if an address is provided and it does not meet the structural requirements including town name, it does not pass validation, regardless of whether the address is optional.

Other banks take a more contextual view. If the agent is identified by a BIC, a country-only address may not be blocking the transfer. But if the agent is identified by a routing code or clearing code rather than a BIC, then name and address, including at minimum town and country, become required, and a country-only entry would not suffice.

This distinction is subtle but important. It means that the same data, in the same field, could be accepted by one bank and rejected by another depending on how the agent is identified. If your payment templates use agent addresses without BICs, this gap should be an explicit item on your checklist.

On legacy formats: mixed signals on their longevity

For treasury teams still operating on MT101 or AFB/CFONB 320 formats, the question of what happens after November 2026 is critical. The banks' responses here are the most divergent in the survey.

On Swift MT101, the general direction is cautiously favorable to continued acceptance, provided that the addresses are structured in a way that allows the required elements, specifically town and country, to be extracted without ambiguity. Several banks specify that the address must be provided using format F (the structured tag variant), rather than the legacy free-text fields.

On AFB/CFONB 320 in France, the picture is less encouraging. Some banks plan to continue accepting the format if addresses are preformatted according to the expected rules. Others are actively steering clients toward XML migration before November, noting that the address-qualified versions of AFB320 have not been widely implemented in practice. This gap means the format exists but the structured address capability is not operationally established.

Our next article will cover the structured address transition across payment formats in depth.

Not all controls are equal

One more divergence is worth flagging for treasury teams doing technical compliance work.

Most banks confirmed that their controls will focus primarily on the presence of required tags. If TownName and Country exist in the message, the validation passes, regardless of whether the values make geographic sense.

Fewer banks plan to validate both presence and content. The bank’s system will check whether the town name is a real place, whether the country code is valid, and whether the combination is consistent.

This difference sounds like a minor technical distinction. In practice, it has real implications. A payment with the same tags might pass a presence check but fail a content check. A payment where the town name is populated with a postal code might pass at one bank and fail at another.

If your migration strategy relies on populating required fields with placeholder values, be aware that this approach may not work universally. The banks enforcing content validation will not be satisfied with technically present but meaningless data.

There is no universal standard

Finally, and perhaps most importantly for global treasury operations: the controls banks are implementing are not always applied uniformly.

Some banks confirmed that their controls will be generic. Consistent rules will be applied across all payment types and corridors. Others indicated that requirements will vary by country, currency, payment type, or origin-destination combination.

In our previous article about the lessons learned from our customer interview, we saw a concrete example of this divergence. In several Asian countries, TownName in the ISO standard is mapped to a district, while the city itself is captured in Country Subdivision, making both fields mandatory in those corridors, beyond the global minimum.

Banks applying corridor-specific rules will have similar regional variations. A payment that passes your bank's controls for a European corridor may not pass for an Asian or Latin American one. Testing in a single low-risk corridor before global rollout is good practice, and it’s the only way to surface these variations before they cause live payment failures.

What this means for your action plan

The survey findings do not change the November 2026 deadline. But they do sharpen what "compliant" actually means in practice.

The overall picture is consistent with what we have observed across our own client base: the direction is clear, the deadline is firm, and the level of industry-wide readiness is still below where it needs to be.

Banks are aligned that structured addresses are becoming a hard operational requirement. They are actively communicating. They are planning rejection controls. But their implementations differ in ways that matter for businesses.

Here is the summary to take away:

1. Do not rely on your bank to complete your addresses. Banks can substitute data for their own clients in specific scenarios, but they cannot fix your beneficiary data. That is your data, your responsibility.

2. Test with each banking partner in each relevant corridor. Generic compliance is not enough if your banks apply corridor-specific rules or validate content rather than presence only.

3. Contact your banks directly about legacy format acceptance. Do not assume MT101 or AFB320 will continue to work as-is. Get written confirmation of what is acceptable, at what level of address structure, and by when.

4. Avoid placeholder values. If your data quality remediation involves populating town name fields with "N/A" or similar, verify with each bank whether this approach passes their controls. Some will accept it; others will not.

5. Act on the assumption that presence controls will tighten over time. The banks applying content validation today are ahead of the curve. Others will follow. Building clean data now avoids having to remediate again later.

What's next

Recently we have received many questions around how the structured address transition affects payment formats, including EDI 820, MT101, AFB320, and local standards such as DTAZV and CBI. In our next article, we will provide an in-depth look at what changes in each format, what remains the same, and how Kyriba's format parameters handle the conversion.

If you have questions about your specific migration, reach out to us. The time to find the gaps is before November, not after. And we are here to help.

*This article draws on responses to a questionnaire sent to a panel of banks in preparation for the November 2026 ISO 20022 address mandate. Individual bank positions are aggregated and anonymized.