The use of enhanced data is the next phase of the ISO 20022 migration across the payments domain. The major benefits will be realised once the entire end-to-end chain supports the enhanced data that ISO 20022 messages offer. This will take time as the data will only be as rich as dictated by the entity in the payment chain with the greatest data constraint. It is important for the key financial market infrastructures (FMI) to take the lead by adopting enhanced data in their own scheme rules and standards, gradually propagating through the payments network. This adoption has begun, with Swift, CHAPS, SEPA and others all setting out timelines and plans to move to enhanced data. For example, the SEPA 2023 rulebook updates the ISO 20022 messages to the 2019 version, which includes the latest version of the structured address element (Postal Address 24). Using this version of the ISO 20022 messages (or later) is the foundation step. Swift and other FMIs have already implemented this version and in the corporate space, CGI-MP are planning to upgrade.
What is enhanced data?
Enhanced data is the overloading of data in a message, made possible by the use of the more structured data model afforded by ISO 20022, permitting more precise data processing, whether for KYC, screening, monitoring, reconciliation or linking and matching related workflows and offering better targeted value add services.
Key aspects of enhanced data are structured addresses, legal entity identifiers (LEIs) and structured remittance information. I’ve covered structured remittance information previously in the context of B2B use cases, see this link for further information. I’ll cover LEIs in a separate paper, but both LEIs and structured addresses will aid the identification of parties and agents in the chain, increasing transparency, speed and ultimately increasing automated onboarding, straight-through processing and cost reduction. Both will also need careful consideration to implement correctly and efficiently.
You may have heard of enhanced data, structured addresses and even hybrid addresses. This article aims to explain the basics, point out some key resources and highlight some of the challenges.
What are structured addresses?
The ISO 20022 data model builds complex data items from their component, structured parts allowing a precise and granular drill down into the lowest level of the data item.
A fully structured address is an address which is composed of the component parts (fields) as defined in the 2019 version of the ISO 20022 messages. This is a PostalAddress24 complex element used in the various ISO 20022 messages. The widely used 2009 version of these messages used an earlier and less detailed address structure, PostalAddress6.
The two version are show below with the 2009 version having 9 fields comprising the address (counting 7 iterations of Address Line as one field), whereas the 2019 version expands these to 15 fields.
A fully structured address should have strict and consistent separation of the address parts into these PostalAddress24 fields and, importantly, the use of the repeating Address Line fields (<AdrLine>) is not permitted. For example, using “The White House, 1600 Pennsylvania Avenue, Washington DC, USA”:
Unstructured:
<AdrLine>The White House, 1600 Pennsylvania Avenue</AdrLine>
<AdrLine>Washington DC</AdrLine>
<AdrLine>USA</AdrLine>Or Unstructured (or any other variation of AdrLine):
<AdrLine>The White House</AdrLine>
<AdrLine>1600 Pennsylvania Avenue</AdrLine>
<AdrLine>Washington DC, USA</AdrLine>Structured:
<StrtNm>Pennsylvania Avenue</StrtNm>
<BldgNb>1600</BldgNb>
<BldgNm>The White House</BldgNm>
<TwnNm>Washington, DC</TwnNm>
<Ctry>US</Ctry>Typically, the data in repeating address line fields (address line 1, 2, 3 etc) is inconsistent, usually any single or multiple address elements. This makes processing these data fields difficult with extensive fuzzy logic and often many false positives. As you can see from this simple example, using a structured format is less ambiguous and allows more precise processing, reducing the need for data transformation/parsing, fuzzy logic and false positives.
When considering migration from MT to MX, it is worth noting that the use of a “structured” address is available in MT formats, but this is not to be confused with an MX / ISO 20022 structured address. The MT “structured” address format, such as in field 59 option F in an MT 103, should be regarded as unstructured in the context of MX. This is demonstrated in the table below.
Implementation challenges
Implementing fully structured addresses poses many significant challenges. FMIs and market practices need to adopt the 2019 version of the ISO 20022 messages, which use PostalAddress24. This is happening. Swift CBPR+ already uses it, the SEPA 2023 rulebook mandates the change and CGI-MP has also defined and planned to upgrade to 2019, using the pain.001.001.09 rather than pain.001.001.03. However, all other stakeholders in the payment and cash management chains need to follow suit, including banks, corporates and their software vendors. Service bureaux, ERP and TMS systems all need to handle 2019 version messages and the underlying data model.
Internal reference data repositories will need upgrading to store native structured addresses. This will require the data migration of existing records, which even for modestly sized organisations, could involve many millions of address records. Importantly, many governmental and non-governmental agencies need to upgrade their reference data sources. Currently, sanctions lists, bank almanacs, BIC repositories, country-based company registers etc are all storing address data in differing, unstructured formats.
Ironically, given Legal Entity Identifiers (LEIs) are being introduced and their use more widely advocated through the same ISO 20022 2019 message versions, this is a pertinent example of a reference data source that provides addresses in an unstructured format. The benefits of using LEIs for better party identification could be undermined if you intend to use the LEI address data which, given that is not compliant with ISO 20022, would need transforming to a structured format. To assist with your own research, LEI formats including the address formats and examples are provided at the following links:
LEI xml schema:
https://www.gleif.org/en/lei-data/gleif-data-quality-management/xml-schema
LEI xml data, including address, for Alphabet Inc:
https://search.gleif.org/#/record/5493006MHB84DD0ZWV18/show_xml
I have produced a summary of the mapping from LEI address to ISO 20022 PostalAddress24, available in a Google Sheet here:
https://docs.google.com/spreadsheets/d/13my6mwxqRmCXfAZd-5A5xUXCGGJgTQeUkaw8k9yXwKY/edit?usp=sharing
Clearly, the wide implementation of native structured addresses will be lengthy and challenging and will therefore require a phased approach. This is why a hybrid approach is being adopted by many FMI and for most participants and parties in the payment chain, will require a long-term plan for transforming data between structured and unstructured formats, including hybrid formats.
The phased introduction of structured addresses has begun and in many FMIs, will end in November 2026 when unstructured addresses will no longer be permitted. The European Payments Council (EPC) has, for instance, published guidance on the use of structured addresses from November 2025 for all four of the SEPA payment scheme rulebooks (EPC 153-22).
Afternote: since writing, the EPC have an open consultation on the introduction of stuctured addresses. It is likely, that they will align with CBPR+ and HVPS+ on a November 2026 end of unstructured addresses and a November 2025 introduction of hybrid addresses. The lifespan of hybrid addressess is not yet determined.
Use of hybrid address format
Intended as an interim format in the migration from unstructured to fully structured, certain FMIs have created UGs allowing a hybrid of both structured elements along with unstructured elements (address lines).
A hybrid address format allows stakeholders to use the data elements from PostalAddress24 but not as strictly defined as in the structured format. This could be by keeping the building number in the street name or allowing some use of address lines in addition to the town name and country. You’ll note that the base specification of PostalAddress24 has all elements as optional, allowing significant flexibility, enabling a hybrid approach – the usage guidelines (UG) may mandate certain elements, such as town and country whilst permitting the optional use of address lines. UGs, which dictate the specific hybrid format rules, will vary by the publishing authority. Again, referring to the EPC guidance for SEPA, it states, “…the current input of addresses with 2 occurrences of the unstructured address element “Address Line” associated with the structured address element “Country” will still be accepted.” However, from November 2025, it states, “The provision of structured addresses for SEPA payments must comply with following requirements: Data element “Address Line” cannot be used, Data elements “Country” <Ctry> and “Town Name” <TwnNm> must be used, All other 12 data elements may be used depending on the components of the address.”
Using The White House example, a hybrid address could look like:
Hybrid Example 1:
<StrtNm>1600 Pennsylvania Avenue</StrtNm>
<BldgNm>The White House</BldgNm>
<TwnNm>Washington, DC</TwnNm>
<Ctry>US</Ctry>This first example, which some may contend is not a hybrid address[i], would be valid in a SR 2023 CBPR+ pacs.008.001.08 for the Debtor, Creditor, Ultimate Debtor and Ultimate Creditor addresses.
Hybrid Example 2:
<TwnNm>Washington, DC</TwnNm>
<Ctry>US</Ctry>
<AdrLine>1600 Pennsylvania Avenue</AdrLine>
<AdrLine>The White House</AdrLine>This second example would not be valid for the Debtor, Creditor, Ultimate Debtor or Ultimate Creditor as CBPR+ has a formal rule preventing this hybrid option (CBPR_Structured_vs_Unstructured_FormalRule). In the EPC SEPA hybrid UGs, 2 instances of <AdrLine> in combination with <Ctry> would be valid (but not with <TwnNm>).
Afternote: the introduution of usage guidelines in November 2025 will permit this hybrid address.
Payments Market Practice Group and Swift guidance
The Payments Market Practice Group (PMPG) has published guidance on structured addresses. This is essential reading and includes extensive examples of structured addresses for 32 countries. https://www.swift.com/about-us/community/swift-advisory-groups/payments-market-practice-group/disclaimer/swift-payments-market-practice-group-document-centre
Once you have downloaded the PMPG excel file, navigate to the last worksheet, called Samples. This worksheet holds another embedded excel which provides sample structured addresses for these countries and is extremely useful for training your Large Language Model (LLM) if trying AI models.
Swift has also published guidance on structured addresses and their phased approach for FINPlus and Standards MX, including beyond 2026.
Swift CBPR+: Structure of postal addresses in CBPRPlus messages (21 August 2023, as at the time of writing): https://www2.swift.com/knowledgecentre/kb_articles/5026188
Use of artificial intelligence
We cannot finish without mention of AI. Given the need for transformation from unstructured to structured formats, this is something likely to benefit from a suitable LLM which, given sufficient detailed instructions and sample data (both for training and testing), may reduce the effort. I have experimented with Claude 2, ChatGPT (only 3.5) and Bard. I’ve included in this article a set of sample instructions for an AI chat bot and a source and target excel file. The source file containing 10 LEI addresses for the model to convert to the target format/file. I’ll leave the rest to you. Enjoy!
Note: all errors and omissions are my own.
[i] I contend this is a hybrid address as it does not fully comply with the structured, separate data elements of street name and building number.
