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 linkfor 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:

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) – I presume you will be 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 end 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, 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!

[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.

Legal Entity Identifier and Business Identifier Code Mapping

Aim

This article explains why the GLEIF published LEI/BIC relationship mapping csv file cannot always easily be used to derive the correct LEI related to a given BIC. It shows how to enrich the csv file with additional LEI fields, to better differentiate and select the correct LEI when more than one is related to a single BIC.

Background

In the various ISO 20022 adoptions across the payments domain, specifically the planned introduction of enhanced data, the mandated use of Legal Entity Identifiers (LEI) should be part any implementation project for banks and PSPs.

In this article we’ll be looking at the use-case where, for the given organisation (whether an agent or party), the Business Identifier Code (BIC) is available and from this, we need to get the relevant LEI to populate the ISO 20022 message.

LEI / BIC Mapping

Helpfully, Swift and GLEIF have produced an open-source csv relationship file which maps a BIC assigned to an organisation to its LEI. This is updated each month and can be downloaded from the GLEIF website.

This file could therefore be imported each month to a reference data store and used to lookup the correct LEI for a given BIC.

Many to Many Relationships

If it were that straightforward, this article would be redundant, so here’s the (small) complication…a single BIC can be related to multiple LEIs; likewise, a single LEI can be related to multiple BICs.

At the time of writing, the November 2023 mapping csv file has 22447 mapped items. Of these, 98.4% (22084) are BICs which only map to a single LEI. However, there are a minority of BICs which map to multiple LEIs. For example the BIC “INGCITM1XXX” maps to 6 LEIs as shown in the picture below. With only the LEI field itself, it is not easy to differentiate between them and ensure the correct organisation is selected.

Enriching with Additional LEI Data

To solve this we can enrich the csv file with additional LEI fields thereby, the correct selection should be easier. The enriched file with 6 additional fields is shown below.

How to Enrich

The GLEIF APIs provide everything needed to get the additional organisation data fields, specifically using the lei-records > Level 1 Information (LEI Records) > GET LEI Record By ID (LEI).

Using this API endpoint with the page[size] parameter and the filter[lei], where the latter is a comma separated string of the LEIs to enrich. A snippet of this Python code is below.

# URL of the GLEIF API endpoint
url = f"https://api.gleif.org/api/v1/lei-records?page[size]={batch_size}&filter[lei]={lei_csv_param}"

# Make the API call to GLEIF
response = requests.get(url)

# Check if the API call was successful
if response.status_code == 200:
  # Parse the JSON response
  data = response.json()
  # Extract the data from the response
  if not data['data'][0]:
    return 'No LEI data found'

  else:
    for item in data['data']:
      # Get the LEI
      if 'attributes' in item:
        lei = item['attributes'].get('lei')
        legal_name = item['attributes']['entity']['legalName']['name']
        legal_adr_city = item['attributes']['entity']['legalAddress']['city']
        legal_adr_ctry = item['attributes']['entity']['legalAddress']['country']
        legal_adr_postalcode = item['attributes']['entity']['legalAddress']['postalCode']
        status = item['attributes']['entity']['status']
        lei_enriched_data.append([lei, legal_name, legal_adr_city, legal_adr_ctry,
                                  legal_adr_postalcode, status])

return lei_enriched_data

GitHub Repository

The full Python code can be cloned from my GitHub repo here:

GitHub domdigby/GLEIF

I’m a hobbyist coder, just learning Python, therefore you have my apologies for the parlous state of this code, however, it works and doesn’t exceed the GLEI API rate limits. It also includes other methods calling on the GLEIF API endpoints and a method to validate the format and checksum of an LEI.

I hope these are useful. Enjoy!

GLEIF API Health Warning

A health warning about the GLEI APIs: read the terms and conditions (below). They are rate limited and exceeding the rates will likely result in 429 status codes (too many requests).

Terms & Conditions

There is no charge for the use of GLEIF’s LEI data.

GLEIF does not enter into individual contractual relationships with specific users of the LEI data.

Rate limiting is currently set at 60 requests, per minute, per user, for all users.

Please refer instead to the LEI Data Terms of Use available here: https://www.gleif.org/en/meta/lei-data-terms-of-use/

Using Excel?

In case you are using excel to open or view the original and enriched csv files, please note that due to the accented and non-Latin characters supported by LEI fields, such as those found in legal name, the python code uses UTF-16 encoding when writing the data to the enriched csv file. If you try to open this using Excel (double clicking the csv file), it may not work. Instead, follow these steps to import the csv file into Excel:

1. Open Excel, then open a blank workbook.
2. From the ribbon select File then Open.
3. Browse to the location of the csv file, select it then choose Open.
4. At the Text Import Wizard, ensure you select Unicode (UTF-8) as the File origin. This is very important — see picture below.
5. If asked to convert the data, select Don’t Convert.

Finally, If you must use Excel, I’d advise using a Power Query import. For large csv files this is more efficient. Certainly, don’t try to import the ISIN / LEI mapping file unless using a data model in Power Query. The ISIN / LEI csv has over 2 million records and is >240Mb.

Having started to look at the practicalities of getting the correct LEI from a given BIC, to populate an ISO 20022 message and comply with the pending LEI requirements (CHAPS, CBPR+, SEPA etc), I thought I’d share some initial thoughts and tool which may help others. Please reach out if you need any further information.