The Legal Entity Identifier (LEI) is the 20-character code transforming the way we identify legal entities globally. Since LEIs were first issued in 2012, they have become the default connector of reference data for KYC/AML and counterparty identification.

But what about other identifier codes that were already in use, like ISIN and BIC? The ISIN (International Securities Identification Number) is a global standard for unique identification of financial instruments. The BIC code (Bank Identifier Code, aka SWIFT code) is an international standard for identification of both financial and non-financial institutions.

The Global LEI Foundation (GLEIF) supports the mapping of such codes to the LEI. Its Certification of LEI Mapping service is aimed at ensuring authorities which map their own codes (like SWIFT for BIC, and ANNA for ISIN) to the LEI, do so accurately.

To explore this subject further, I spoke with Johan Hol, Founder of – a RegTech service connecting LEIs to ISINs for banks and other financial institutions. is a RapidLEI partner.


F: What do you see as the challenges of managing these different codes – LEIs, ISINs, and BICs?

Johan Hol

Johan Hol

J: The main challenges of all these kinds of identification codes are data accuracy, consistency and data coverage. If you want to get the maximum added value out of these codes, it’s important to follow the same standard around the globe and always have one golden record. The data has to be up-to-date, so changes due to, for example,  mergers, have to be reflected as of, or at least close to, the effective date.

Another challenge is to map these identifiers to each other in a consistent way. For example, ISIN to LEI mappings are made available by GLEIF and ANNA [Association of National Numbering Agencies], but are also provided via the Financial Instruments Reference Data System of ESMA [European Securities and Markets Authority]. Although the vast majority of the mappings is equal, only a minor difference can lead to inconsistent data mappings for, for example,  the investment portfolio of banks, insurance companies or pension funds, which are’s main clients.


F: Why is it important that the codes are mapped to each other?

J: It depends on the contents of the code as to whether mapping adds value or not. For mapping to have value, there has to be a logical relationship between the codes. For example, there is a relationship between zip code and city, but there isn’t any relationship between cell phone numbers and zip codes (at least not here in the Netherlands).

We initially started providing data mappings from a regulatory reporting perspective – for regulations including Solvency II, DNB-FTK, Mifid II and EMIR. Having issuer LEIs mapped to ISINs is important in order to comply to regulatory reporting requirements, but it also helps in determining risk exposures, especially if the so called ‘Level 2′ LEI data (direct and ultimate parent entity/’who owns whom’) are taken into consideration.


F: How does contribute to solving LEI mapping challenges?

J: We use open data as our primary source, but they don’t cover the full scope of the data mapping requirements of our clients. We also map other attributes like NACE and CIC to LEIs and ISINs respectively. Although they don’t fully cover all financial instruments yet, their potential is impressive.

The 60-70% open data cover now improves both data quality and processing time and reduces costs for our clients as they don’t have to buy the data from data vendors.

The remaining instruments are mapped via our search and mapping algorithms, so we can assure a 100% mapping coverage.

Next to these data enrichments we also perform data quality checks so we can assure data accuracy, consistency and provide the highest possible data (mapping) coverage.


Find out more about