Table of Contents

1 Introduction

The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code based on the ISO 17442 standard. It provides a globally unique identifier for legal entities, such as companies. The Global Legal Entity Identifier Foundation (GLEIF) administers LEI identifiers. The Global Legal Entity Identifier (LEI) Index provides a daily update on all name and address data for companies with Legal Entity Identifiers (LEIs).

LEIs enable uniform and unique identification of legal entities, and provide particular value when used in conjunction with structured, electronic reporting formats such as XBRL. In collaboration with the GLEIF, XBRL International has released the LEI Taxonomy to facilitate the consistent use of LEIs in XBRL reports.

The primary audience for this guidance are taxonomy architects, taxonomy authors and collectors intending to use LEIs in an XBRL reporting framework.

2 Why use the LEI Taxonomy

The LEI taxonomy provides a consistent and tested approach for incorporating LEIs in XBRL reports. The prebuilt validations ensure LEI values adhere to the prescribed format. Adopting a consistent approach to the inclusion of LEIs increases the value of the data to consumers.

3 How LEIs can be reported in XBRL reports using the LEI Taxonomy

This section explains how XBRL reports can use the LEI Taxonomy to incorporate the LEI as a primary, secondary or related entity identifier.

3.1 LEI as a primary identifier

Facts in XBRL reports specify an entity to which they relate, which is referred to as the Primary Identifier. This is done using the XBRL "entity" < >, which combines an identifier for the entity with a URI identifying a scheme from which that identifier is taken.

Where an LEI is used as the Primary Identifier, the recommended scheme value is http://standards.iso.org/iso/17442 and the identifier value would be the LEI. XBRL best practice recommends using the "entity" built-in dimension to identify the "preparer of the XBRL report". XBRL does not constrain the content of the entity built-in dimension to be a taxonomy concept, therefore, to use the LEI as a Primary Identifier, no modelling is required to be done in the taxonomy.

3.2 LEI as a Fact (secondary identifier)

There can be scenarios in which an XBRL reporting framework mandates the preparer to use a local identifier, such as a national company number, as the primary identifier, but allows the preparer to disclose their LEI where available. In such cases the LEI can be included as a secondary identifier in XBRL reports. This can be done using a standardised concept defined in the LEI Taxonomy.

3.3 LEI as a fact (related parties)

Business reports often require disclosure of information about other entities. For example, financial reports often include the identification of subsidiaries or related parties. LEI can be used to unambiguously identify related entities. The LEI concept in combination with a taxonomy-defined explicit or typed dimension that identifies the nature of the relationship with the preparer can be used to report the LEI of related entities.

The LEI taxonomy defines a specific concept, LEI, for capturing LEI values. The datatype used in this concept constrains the value captured according to the 20-character alpha-numeric pattern for LEI.

The LEI Taxonomy also provides a standard XBRL datatype, leiItemType, for representing LEIs. Taxonomy authors can use the datatype to create their own concepts. For example, taxonomies may define concepts such as Subsidiary LEI, Parent LEI etc. which capture the LEI of these specific entities. The LEI datatype can thus be used to model related entities as fact values. Re-using the LEI datatype for custom LEI concepts ensures that built-in taxonomy validations for the LEI format can be leveraged.

3.4 LEI as a typed dimension value

Business reports capturing information about related entities may use a typed dimension in the taxonomy. The LEI can be used as a typed dimension value to differentiate information pertaining to each specific related entity.

The LEI taxonomy defines an XML element for use where LEIs are used as the dimension value for a typed taxonomy-defined dimension. The standard LEI typed domain element is named LEIDomain. The LEI typed domain element ensures that the reported LEI matches the 20-character alpha-numeric pattern, however it does not enforce the checksum validation for the last 2 digits. Implementers should define their own XBRL formula rules using the standard LEI checksum functions to validate the checksum.

Table 1 gives an example of counterparty exposure disclosure in which the counterparties (related entities) are identified by their LEI.

This disclosure could be modelled in the taxonomy as a typed dimension since the number of counterparties is unknown at the time of taxonomy creation. In this case the standard LEI typed domain element can be used to construct a typed dimension (e.g. Counterparty), which can then be included in a cube with concepts to report the direct and indirect exposures for each entity.

A separate guidance document is available with recommendations on incorporating multiple entities in XBRL.

4 Methods of LEI Validation

There are different methods of validation that can be applied to an LEI, ranging from local syntactic verification that it is a 20-character string, all the way up to remote accessing a database of LEIs from an LEI issuer or GLEIF. The LEI taxonomy seeks to provide as much validation as is possible without reference to an external database.

The validations are incorporated in the LEI taxonomy using XML schema data types and XBRL formula rules. The XBRL formula rules in the LEI taxonomy are built in a modular fashion, allowing taxonomy authors to use the components applicable to them. XBRL processors may validate an LEI depending on how the XBRL report uses the LEI. Table 2 gives different modelling approaches and the built-in validations they provide.

4.1 LEI checksum functions

The authoritative way to check if an LEI is valid is to consult the global LEI index maintained by GLEIF. This will check if a given LEI has been issued, and is still current, and will provide information about the entity to which it was issued.

In some situations, it may not be practical or desirable to do an online lookup. In this case, it is possible to check that the LEI is syntactically valid by ensuring that it conforms to the prescribed pattern (18 alphanumeric characters followed by two digits) and that the last two digits are a valid checksum for the preceding 18. Whilst a valid checksum does not guarantee that an identifier is a valid LEI, it provides a useful check against accidental modification of the digits within the LEI.

Due to an ambiguity in the description of the checksum mechanism used by LEIs, there are a small number of valid LEIs in use that do not strictly conform to the checksum calculation. For this reason, the checksum implementation in the taxonomy has been split into two parts. The validate-checksum function should return true for all valid LEIs. The validate-checksum-invalid-digits additionally checks that the last two digits are not "00", "01" or "99". Although these digits are technically prohibited by the checksum process, a small number of valid LEIs do use these digits.

It is recommended that the validate-checksum function, and the corresponding lei-fact-checksum and lei-identifier-checksum assertions are treated as required validation rules, whereas and the validate-checksum-invalid-digits function, and lei-fact-checksum-digits and lei-identifier-checksum-digits assertions are used as warning-level checks. Implementers may wish to consider maintaining a whitelist of LEIs that are valid but which to not conform to this check.

4.2 Report uses LEI identifier scheme

In addition to the format validation, the LEI taxonomy also has an optional validation rule to ensure that all facts in an XBRL report use the identifier scheme http://standards.iso.org/iso/17442. The evaluation of this rule will depend on the entry point chosen (see LEI taxonomy entry points section for details).

5 LEI Taxonomy entry points

The LEI taxonomy provides three taxonomy entry points, allowing taxonomy authors to select which components and validations they wish to re-use. Table 3 explains the LEI taxonomy components available for each entry point.

XBRL International recommends using the lei-required.xsd entry point wherever possible so as to enforce the use of a valid LEI as the primary identifier for all facts in the report.

6 LEI taxonomy Link

The LEI Taxonomy can be found in the XBRL Taxonomy Registry.