ISO 20022 Enhanced Data — Structured Addresses
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 and most data-rich version of the structured address element (PostalAddress24). Using this version (or later) is the foundation step. Swift and other FMIs are already there 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, regulatory 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 article, but both LEIs and structured addresses will aid the identification of parties and agents in the chain, supporting automated onboarding, straight-through processing, increasing transparency, speed 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 the PostalAddress24 complex element used in this version. The widely used 2009 version of the ISO 20022 messages use an earlier and less detailed address structure, PostalAddress6.
The two versions 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 free text, inconsistent and usually combines multiple address elements. Processing these unstructured data fields is 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 version, 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, natively.
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 — not a trivial undertaking. 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.
LEIs are a good example of an external reference data source that uses unstructured address formats. This is ironic given the use of LEIs is being introduced as part of the enhanced data improvements in the same scheme rules that advocate the use of structured addresses. Let’s hope the benefits of using LEIs, for clearer party identification, are not undermined by the difficulty of reconciling their unstructured address format to your internal structured address respository. To assist with your own research on this specific point, 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 also 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, necessitating a phased approach between now and 2026. This is also why a hybrid address format is being adopted by many FMIs. For most participants and parties in the payment chain, they will require a medium-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 late 2025 when unstructured and hybrid 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). Between November 2023 and November 2025, a phased, hybrid address format is permitted.
Use of hybrid address format
What is the hybrid format exactly?
Intended as an interim format in the migration from unstructured to fully structured, certain FMIs have created usage guidelines (UG) allowing a hybrid address format mixing structured elements and unstructured elements (i.e. 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 this hybrid format — UGs 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. Referring again 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, it states that from November 2025:
“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>).
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 in an excel file available here:
IMPORTANT: 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) — I presume you will be applying ML supervised learning.
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 machine learning
We cannot end without mention of ML. Given the need for transformation from unstructured to structured formats, this is something likely to benefit from generative AI and a suitable LLM which, when fed sufficient detailed instructions, parameters and sample data (both for training and testing), may reduce the effort. I have experimented with Claude 2, ChatGPT (only 3.5) and Bard with mixed results. Included in this article are links to a set of sample instructions for an AI chat bot and a source and target Google Sheets 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. Let me know in the comments how you get on. Enjoy!
Bard Address Transformation Instructions: https://docs.google.com/document/d/1jICOsQE1qAPskrwm_S_rtOQT6_foxkDdz22D2D0uT4o/edit?usp=sharing
Source File: https://docs.google.com/spreadsheets/d/1wK0IqwgAF1RcAzbrMG8PVSPG_YrRIB2D8iDOv-j4oPc/edit?usp=sharing
Target File: https://docs.google.com/spreadsheets/d/1KuOTmJ4ep2O3gD_yED6H4stZcFmuy34edwCYfEB6KKU/edit?usp=sharing
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.
Originally published at https://www.linkedin.com.