ISO 20022: 2009 to 2019 Upgrade Considerations

ISO 20022: 2009 to 2019 Upgrade Considerations

Introduction

Here’s the scenario: your company is accepting payment instructions from clients via the channel of choice. It could be file transfer, API, Swift FileAct etc. The key factor is, not so long ago, you upgraded the client payment instruction format to ISO 20022, based on a pain.001.001.03 (payment initiation). That version, from 2009, has been extant for many years, is supported out-of-the-box by most ERP/TMS systems and is CGI-MP compliant. Your interface format is up to date, with a flexible, data-rich ISO 20022 message capability and your clients have all integrated. All is well.

Now here comes the 2019 version, the pain.001.001.09. If you are sending payment messages into certain schemes, such as SEPA Credit Transfer, according to the 2023 rulebook, you will need (at some point) to upgrade to the pain.001.001.09. Interbank messaging is aligned around 2019 (e.g. pacs.008.001.08) and for seamless data interoperability, other groups and practices will now align – CGI-MP is moving to this version and has published their UGs (see CGI-MP on MyStandards).


As interbank is migrating to ISO 20022 to support cross-border payments and cash management businesses from March 2023, CGI-MP message versions and guidelines are also updated [to 2019] to align with the interbank usage.

  • CGI-MP WG1 User Handbook – Feb 2023 Update

Whilst you may have scheme or practice rules dictating this change, do your clients have needs that will be met by the upgrade? Changing the format of a client interface and the data they may need to provide is usually disruptive, not something you want to do often or without a detailed upgrade schedule, test and client communications plan. For the upgrade to 2019, in many use cases the client benefit may not be immediate or obvious, rather this is a foundation upgrade, with the potential for future benefits, such as e-remittance or alias capabilities. So, do you need to update your client payment format to 2019, what are the key considerations and what are some of the challenges and impacts?

Upgrade Approach

Unlike some of the earlier ISO 20022 message versions, 2009 to 2019 is largely backwards compatible, certainly for the pain.001. If contemplating your own upgrade, a practical option would be to follow the proven co-existence approach, via a 2-phase upgrade plan:

  1. Interim Translation: Retain a client facing format based on pain.001.001.03 and map payments internally to 2019 (pain.001.001.09 or pacs.008.001.08 etc) before sending on.
  2. Long-Term Native: In parallel and over time, build the pain.001.001.09 client facing format and migrate clients as and when ready.

The 2019 version is designed to support enhanced data. It is the origination and use of this data which needs careful planning to ensure it can be included in the flow as quickly as possible. A phased migration relies on understanding the enhanced data differences and whether you or your clients will benefit from this data, where the data will be originated and how to build it into your upgrade plan and product roadmap. Generally:

  • If enhanced data is originated by your client, such as a corporate accounts payable department or an intermediary payment services provider, the interim translation approach will continue to limit the acceptance of this data, for example, there is no LEI field in a pain.001.001.03 so if originated by your client, it cannot be received. Other means of accepting the data will be required.
  • Alternatively, if enhanced data can be derived, such as looking up the LEI or structured address from client reference data, the interim translation approach will work. You can derive the enhanced data and insert in into the onward pain.001.001.09 assuming of course, your master reference data has already been updated to support this. By implication, the updating of reference data is a likely a pre-requisite of any upgrade plan and may well be the most complex and time-consuming workstream.

Key Differences

2019 version sees changes to several existing data elements and, most importantly, several new elements. The following pictures, with pain.001.001.03 on the left and pain.001.001.09 on the right, illustrate the major, high-level differences in the base specification.

Supplementary Data

A supplementary data element has been added to the Customer Credit Transfer Initiation level and to each payment (Credit Transfer Transaction Information level). Usage guidelines (UGs) are rules designed to restrict the usage from the base specification. They specify a subset of the available base data and, in certain cases, business rules (cross-field rules) to be adhered to. By contrast, supplementary data is designed to expand the message beyond the base specification. Supplementary data is not widely used in the payments’ domain and beyond the scope of this article. It is unlikely to impact your upgrade and can be ignored. For more information on supplementary data and to see one of the few usages, go to the SCRIPS UG for camt.050.

Supplementary Data addition

Group Header

The only significant changes in the Group Header are those related to the postal address, organisation identification and contact details of the parties or agents. All 3 of these elements have new fields to support enhanced data and will be covered later in this article as they are reusable elements and apply to all parties and agents in the message.

Group Header changes

Payment Information

On the debtor side, payment information element, there are a number of subtle changes, some of which are:

  • Service Level. The service level can now have multiple occurrences rather than the single occurrence permitted in the pain.001.001.03. This allows a client to specify which of the available rules should be applied to the payment, specifically it can be used to select a wider range of payment product options but is more a future enhancement, once those product offerings are available, rather than something which will impact any migration.
  • Requested Execution Date. This changes from only an ISODate to either an ISODate or ISODateTime. This feature aligns with the growing real-time payments and liquidity capabilities across the globe, where a future dated execution date can now be an exact time. For most use cases, there will be no client impact and can remain unchanged as an ISODate in the interim phase. Internally, for the interim solution, a remapping to ../ReqdExctnDt/Dt will be required.
Payment Information changes
  • Proxy. The updated CashAccount38 element has a Proxy element, to cater for an alias/proxy identifier as an alternative assumed name for the account. This is a reusable component so occurs in every instance of an account not just debtor. The use of aliases for sending payments is growing rapidly, particularly in peer-to-peer transactions. India’s UPI and Brazil’s PIX are topical examples and SEPA is planning its own alias capability. If the proxy is something needed as part of the interim upgrade phase, you should consider updating your reference data source to derive alias names to work around the absence of this in the pain.001.001.03.

Credit Transfer Transaction Information

Keys changes in payment element include:

  • UETR. The Unique End-to-End Transaction Reference is a new addition. This mirrors the inclusion of the UETR in the Swift MT standards release from 2021 (i.e. MT 103 Block 3 Field 121). The UETR is an important identifier in the payment chain and many market infrastructures and messaging services mandate its use (Swift CBPR+, SCRIPS). For both an interim and long-term solution, it can be generated and populated in the pain.001.001.09 if required. The origination of this by the ultimate debtor or debtor, such as a corporate, is not yet common practice given the EndToEndId usually serves their needs (see a previous article on EndToEndId for more details on this) and Swift gpi tracking, if used, can be presented from the point of the debtor agent processing the payment. If a Swift corporate requires full gpi tracking, they will generate the UETR and would need the long-term solution to be in place in order to pass in the pain.001.001.09.
UETR addition
  • Postal Address. One of the most significant changes is the enhancement to the postal address. This applies to every occurrence, whether for a party (such as Ultimate Debtor in the picture below) or agent. The PostalAddress24 complex element has 6 additional fields, allowing a more granular structured address, to ultimately negate the use of unstructured Address Line fields. Certain scheme UGs already restrict or forbid the use of the unstructured Address Line fields. In the interim phase it is important to begin the journey to fully structured addresses – the minimum should be shaping your clients’ use of the pain.001.001.03, ensuring Town Name and Country are populated and avoid the use of Address Lines. See this earlier articleon structured addresses for more information.
Structured address additional fields
  • Legal Entity Identifier (LEI) & BIC. The 2019 version adds the LEI to the data model. The LEI is a unique identifier for an organisation. It does not apply to private individuals, hence is found in the OrganisationIdentification29 complex element. Further details on LEIs can be found at the Global LEI Foundation (GLEIF) questions and answers. Also available from GLEIF is a suite of APIs endpoints supporting functions such as LEI search and lookups. Finally, it is worth noting the subtle change of the BICOrBEI to AnyBIC. See the regular expressions below for the differences to be incorporated into any validation logic.
OrganisationIdentification29 showing new LEI field
AnyBIC change and LEI addition

2019 AnyBIC Format:

<xs:pattern value="[A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}"/>

2009 BICOrBEI Format:

<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>
  • Structured Remittance Information. The repeating Structured Remittance Information complex element is not new. It offers the promise of significant improvement, particularly in B2B use cases, and I have covered this in a previous article. The previous version offered a rich set of data and whilst it is important, in equal measure, it has been unsupported by interbank schemes. The new version (StructuredRemittanceInformation16) includes several new data fields, the most important of which is the repeating complex element, Line Details (DocumentLineInformation1). This permits full granularity of each payment as shown in the 3-level data hierarchy image below: payment -> related document (e.g. invoice) -> line details. For your upgrade, unless your use cases require line details, the existing data fields will likely meet your customer needs and the focus should remain on the expansion of interbank schemes which support structured remittance information.
Structured Remittance Information showing Line Details addition
Indicative 3-level data hierarchy showing new Line Details addition

Usage Guidelines & Market Practice

This article has focussed on the changes to the base specification rather than business rule changes (usage guidelines) for market practice groups or schemes. It is these that will require detailed analysis and upgrade resources, for example, CGI-MP sets out detailed business use of the regulatory reporting data, such as regulatory reporting indicator applied to DEBT or CRDT side, use of purpose of payment codes (see external code sets) under RgltryRptg not Purp, use of Tax ID (TXID) for the party under Othr/Id, etc.

Regarding Structured Remittance Information, the most important development is not the addition of the fields mentioned above, rather the increasing support for accepting this data by interbank schemes. This support, however, remains varied. Swift CBPR+ support up to to 9000 characters (excluding tags), Payments Canada’s Lynx follows this approach whilst the AFT scheme supports up to 100,000 occurrences of StructuredRemittanceInformation16, Nordic Payments Council supports 999 occurrences. Meanwhile, SEPA also support up to 999 occurrences but only via an Additional Optional Service (AOS) which has limited participation. The continued expansion of support for structured remittance information (and making it mandatory for participants) remains a high priority.

Summary

The 2009 to 2019 upgrade is preparation for the use of enhanced data and to realise the benefits this will provide. Backwards compatibility and a co-existence (2 phase) approach allows the upgrade to minimise impact to client interfaces, but the major benefits will only be achieved once the native 2019 enhanced data elements are in place and utilised (and supported by FMIs and scheme rules).


Notes:

  1. This article refers to the base message specifications not any specific usage guideline (UG) adopted by a particular scheme or group.
  2. It focusses on the pain.001 only, agnostic of relay usage, and ignores other messages, such as pain.002.001.10. This is intentionally simplistic; please contact me if you require advice on status or other messages/flows.
  3. ISO 20022 is syntax agnostic. I may refer to xml and xsd but only for examples and to illustrate the data model. Other syntax, such as JSON, are equally valid.

Dominic Digby

Senior Manager with May Business Consulting, product manager with extensive business and technical experience of B2B, interbank and cross-border payments.


ISO 20022 Structured Addresses

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.

Postal address comparison – 2009 and 2019

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.

MT and MX address formats

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.

Dominic Digby

Senior Manager with May Business Consulting, product manager with extensive business and technical experience of B2B, interbank and cross-border payments.


ISO 20022 LEI & BIC Mapping

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.

Example: Multiple LEIs for a single BIC

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.

Example: Enriched multiple LEIs for a single BIC

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.
Setting Excel import encoding to UTF-8
Excel asking to convert LEI to number using scientific notation — DO NOT 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.

Dominic Digby

Senior Manager with May Business Consulting, product manager with extensive business and technical experience of B2B, interbank and cross-border payments.