LEI-CDF Version 3.1

Documentation last updated: 2021-03-04

Introduction

As the Global LEI System (GLEIS) High Level Principles stipulate, the GLEIS should uniquely and unambiguously identify participants to financial transactions. The ISO 17442 Legal Entity Identifier (LEI) standard defines the following set of attributes as the most essential elements of identification:

The name of the legal entity as recorded in an official register, or otherwise in the entity's constituting documents.
Where applicable, the name of the official register in which the legal entity is registered and its identifier in that registry.
The legal form of the entity as represented in ISO 20275.
The address of legal formation, and the country in which it is located as represented in the ISO 3166 series.
The entity creation date, being the date on which the entity was first established, as represented in ISO 8601.
The address of the headquarters of the legal entity or the international branch.
The status of the legal entity regarding whether or not the entity is legally registered or otherwise constituted, and operating.
The status of the validation, publication and updating of the LEI and its supporting data record.
The date of the first LEI assignment, being the date of publication of the identifier and its supporting data record as represented in ISO 8601.
The date of last update of the LEI data record as represented in ISO 8601, and the reason for the update.
The effective date of a legal entity event, being the date on which the event was effective in the legal jurisdiction in which the entity is formed, as represented in ISO 8601.

The LEI Common Data File format (LEI-CDF) was proposed by the Legal Entity Identifier Regulatory Oversight Committee (LEI ROC) as the additional standard necessary to support the GLEIS in maintaining exclusive assignment of LEIs (one LEI per entity) and identifying, remediating data quality issues, and supporting use of the data. It is maintained and developed as a technical standard by the Global LEI Foundation (GLEIF) with the collaboration and oversight of the LEI ROC. The LEI-CDF specifies in more detail:

The semantic content (definitions) of the ISO 17442 attributes.
Some additional elements, such an indication of the status of the information, necessary for effective use of the data.
The form the information takes at any given LOU, such that it can be made to conform to a common standard.

All LOUs use this file format to publish LEIs and their reference data.

Audience for this document

The target audience for this standard includes:

All Local Operating Units (as well as candidate LOUs) of the GLEIS.
All users or potential users of LEI data.
All financial regulators who consume LEI data.

Status of this document

This section describes the status of this document at the time of its publication. Later versions may supersede this document. The most up to date version will always be available from www.gleif.org.

The file format references and honors previous completed work published by the LEI ROC in a document entitled "LEI Data File Format 1.0" (19 June 2014; available from www.leiroc.org).

Terminology and Typographical Conventions

Within this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in Annex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:

SHALL (NOT): Requirement
MAY: Permission / Possibility

When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface, they are intended to have their ordinary English meaning.

The following typographical conventions are used throughout the document:

ALL CAPS type is used for the special terms enumerated above.
Monospace type is used to denote programming language, UML, and XML identifiers, as well as for the text of XML documents.

Cardinalities

The cardinality of each element (the number of times it SHALL or MAY appear in an XML data file conforming to this schema) is expressed as a number range in the format {minimum occurrences, maximum occurrences} in the XML examples shown below the notes of its containing element. This notation is equivalent to the following explanations in words:

Mandatory, unique: {1,1} - the element SHALL appear, exactly once.
Mandatory, repeatable: {1,unbounded} - the element SHALL appear at least once. It may be repeated any number of times.
Optional, unique: {0,1} - the element MAY be omitted; it MAY appear once at most.
Optional, repeatable: {0,unbounded} - the element MAY be omitted. It MAY be repeated any number of times.

Please note:

The default cardinality is {1,1} (mandatory, unique). This document highlights when an element differs from this either by its minOccurs (minimum occurrences) or maxOccurs (maximum occurrences) value, or both.
XML cardinalities apply in the context of any containing elements. This means that a contained element may have a cardinality of one or more even if its containing element may be omitted, because the contained element is mandatory given the presence of the container.
XML cardinalities enforce a minimum data quality and standards conformance. Other business rules (as explained below) and data quality checks applied by GLEIF may encourage stricter cardinalities in live implementations.

Business Rules

The accompanying documentation in addition to this Technical Specification specifies business rules where applicable for each element. These are rules that are not enforced by validating against the XML schema, but are still mandatory for all Common Data File (CDF) format files.

XML Syntax

This section specifies the XML schema for an LEI data file conforming to this standard.

XML Design Rules

The XSD schema conforms to W3C's XML Schema specification, version 1.0.
The XML namespace is "http://www.gleif.org/data/schema/leidata/2016".
All interior XML elements are namespace-qualified (element form = qualified).
All XML attributes are in the null namespace (attribute form = unqualified), with the exception of xml:lang.
Element names are upper camel case.
Attribute name are lower camel case.
XSD type names are upper camel case.
Enumeration code list values are all caps with underscores.
Elements are used in preference to attributes except for language and type qualifiers.
For a data element specified as having unbounded cardinality, the XML includes a single container element whose subelements are one or more instances of the data element whose cardinality is unbounded. The name of the container element is formed as the plural of the name of the contained elements.

XML Schema

An XML file conforming to this standard SHALL be valid according to the following XSD 1.0 schema.

Release Notes

Version 3.1

New or changed elements:

Added EntitySubCategory.

New or changed enumerated values:

EntityCategoryTypeEnum
- Added RESIDENT_GOVERNMENT_ENTITY.
- Added INTERNATIONAL_ORGANIZATION.
EntitySubCategoryTypeEnum
- Added CENTRAL_GOVERNMENT.
- Added STATE_GOVERNMENT.
- Added LOCAL_GOVERNMENT.
- Added SOCIAL_SECURITY.

Version 3.0

New or changed elements:

Added EntityCreationDate.
Added LegalEntityEvents.
Added LegalEntityEvent.

Added LegalEntityEventType.
Added LegalEntityEventEffectiveDate.
Added LegalEntityEventRecordedDate.
Added ValidationDocuments.
Added ValidationReference.
Added AffectedFields.

Added AffectedField.

Deprecated elements:

Deprecated AssociatedEntity.
Deprecated EntityExpirationDate.
Deprecated EntityExpirationReason.

New or changed attributes:

LegalEntityEvent

Added group_type.
Added event_status.
Added group_id.
Added group_sequence_no.

AffectedField

Added field_xpath.

New or changed enumerated values:

EntityCategoryTypeEnum

Added GENERAL.

EntityStatusEnum

Added NULL.

Added LegalEntityEventTypeEnum.

Added CHANGE_LEGAL_NAME.
Added CHANGE_OTHER_NAMES.
Added CHANGE_LEGAL_ADDRESS.
Added CHANGE_HQ_ADDRESS.
Added CHANGE_LEGAL_FORM.
Added DEMERGER.
Added SPINOFF.
Added ABSORPTION.
Added ACQUISITION_BRANCH.
Added TRANSFORMATION_BRANCH_TO_SUBSIDIARY.
Added TRANSFORMATION_SUBSIDIARY_TO_BRANCH.
Added TRANSFORMATION_UMBRELLA_TO_STANDALONE.
Added BREAKUP.
Added MERGERS_AND_ACQUISITIONS.
Added BANKRUPTCY.
Added LIQUIDATION.
Added VOLUNTARY_ARRANGEMENT.
Added INSOLVENCY.
Added DISSOLUTION.

Added ValidationDocumentsTypeEnum

Added ACCOUNTS_FILING.
Added REGULATORY_FILING.
Added SUPPORTING_DOCUMENTS.
Added CONTRACTS.
Added OTHER_OFFICIAL_DOCUMENTS.

Added LegalEntityEventGroupTypeEnum

Added REVERSE_TAKEOVER.
Added STANDALONE.
Added CHANGE_LEGAL_FORM_AND_NAME.
Added COMPLEX_CHANGE_LEGAL_FORM.

Added LegalEntityEventStatusEnum

Added IN_PROGRESS.
Added WITHDRAWN_CANCELLED.
Added COMPLETED.

Deprecated enumerated values:

RegistrationStatusEnum

Deprecated MERGED.

Cardinality changes:

SuccessorEntity was {0,1} and is now {0,unbounded}.

Documentation notes:

Several definitions of elements, attributes or enumerations have been updated and aligned with the State Transition and Validation Rules.

Version 2.1

Cardinality changes:

OtherValidationAuthority was {0,1} and is now {1,1}.

Corrections / Bug fixes:

Missing Extension added (back) to LEIHeader.

New or changed elements:

Additional Extension added to LEIRecords.

Documentation notes:

Documentation notes:
Replaced "RAL" by "RAL" in documentation.
Replaced "Registration Authorities Code List" by "Registration Authorities List" in documentation.

Version 2.0

Cardinality changes:

LEIHeader was {0,1} and is now {1,1}.
ContentDate was {0,1} and is now {1,1}.
FileContent was {0,1} and is now {1,1}.
RecordCount was {0,1} and is now {1,1}.

New or changed elements:

Added OtherRegistrationAuthorityID element to capture interim free-text registration authority information in the process of transition to a RAL entry.
Added OtherLegalForm element to capture interim free-text legal form information in the process of transition to an ELF standard code.
Added TransliteratedOtherEntityNames and TransliteratedOtherAddresses. These contain the name and address types dealing with transliteration, and their character content is now validated by the XML schema.
Added EntityCategory.
Added ValidationAuthority.
Added OtherValidationAuthorities.
BusinessRegisterEntityID replaced by RegistrationAuthority.
Token500Type replaced by Tokenized500Type, has minimum length of one character and may not contain any of: the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, shall not begin or end with a space (#x20) character, or a sequence of two or more adjacent space characters.
All elements in the lei: namespace with base datatype xs:dateTime now strictly validate according to the LEIDateTimeProfile datatype. This enforces the restrictions specified in the LEI-CDF V1.0 documentation.
Added optional AddressNumber.
Added optional AddressNumberWithinBuilding.
Added optional MailRouting address field; an optional free text address line to hold content from other address lines containing explicit routing information (presence indicates that this address is a routing / "care of" address).
Replaced Line1 by FirstAddressLine and Line2 etc. by AdditionalAddressLine. The order of the content of these elements follows the order specified by the XML representation.
The value of RecordCount can now only be equal to or greater than zero.

New or changed attributes:

Updated xml:lang to specify use of the latest RFC from IETF BCP 47 (previously RFC 4646; now RFC 5646 at last schema update).

New or changed enumerated values:

Following enumerations now validate strongly (only the specified values are allowed at a schema validation level; one element with a non-standard value cause the whole LEI data to fail validation):

FileContentEnum.
EntityStatusEnum.
EntityExpirationReasonEnum.
RegistrationStatusEnum.
EntityNameTypeEnum.
AddressTypeEnum.
AssociatedEntityTypeEnum.
ValidationSourcesEnum.

Following enumeration elements now validate by format (only values with the correct pattern of characters are accepted; conversely, however, some schema-valid character combinations may not be registered allowed values):

RegistrationAuthority.
LegalForm.

BusinessRegisterEnum replaced by RegistrationAuthorityEnum.
COU_DELTA_PUBLISHED replaced by GLEIF_DELTA_PUBLISHED.
COU_FULL_PUBLISHED replaced by GLEIF_FULL_PUBLISHED.
OTHER_LEGAL replaced by ALTERNATIVE_LANGUAGE_LEGAL_NAME.
Added PREVIOUS_LEGAL_NAME OtherEntityName type.
Added TRADING_OR_OPERATING_NAME OtherEntityName type.
Added TransliteratedOtherEntityNames types: PREFERRED_ASCII_TRANSLITERATED_LEGAL_NAME, AUTO_ASCII_TRANSLITERATED_LEGAL_NAME.
Added TransliteratedOtherAddress types:AUTO_ASCII_TRANSLITERATED_LEGAL_ADDRESS, AUTO_ASCII_TRANSLITERATED_HEADQUARTERS_ADDRESS, PREFERRED_ASCII_TRANSLITERATED_LEGAL_ADDRESS, PREFERRED_ASCII_TRANSLITERATED_HEADQUARTERS_ADDRESS.

Documentation notes:

Replaced "pre-LOU" by "LOU" in documentation.
Renamed all enumeration elements, updating suffix "Enum1.0" to "Enum", indicating that these are the definitive enumerated values.

Version 1.0

The first release. Please find the published specification of LEI-CDF V1.0 at https://www.gleif.org/content/2-about-lei/5-common-data-file-format/lou-20140620.pdf

Abstract Data Content

This section specifies the abstract data content of a data file conforming to this standard. A data file conforming to this standard SHALL consist of:

An LEIHeader.
Zero or more LEI Data Records.

LEI File Header

The LEI File Header describes the context for the LEI Data Records contained in the main body of the file. The header exists to answer such questions as where the data came from, when it was collected into this file, etc. The content of the header SHALL NOT be required to interpret the data content of any LEI Data Record; each LEI Data Record is self contained.

LEI Data Record

An LEI Data Record describes a single LEI registration. Each LEI Data record in a file conforming to this standard SHALL include data elements as described below:

LEI

The ISO 17442-compliant LEI of the legal entity described by this LEI Data Record. The LEI is assigned by the LOU.
A value of type LEIType in a file conforming to this standard SHALL be a 20-character Legal Entity Identifier conforming to ISO 17422. Conformance to ISO17442 includes having correct check digits.

Entity

Attributes describing the legal entity itself. The Entity data is supplied by the legal entity, and recorded and published by the LOU.

Registration

Attributes describing the registration of this LEI with an LOU. The Registration data is maintained by the LOU.

Extension

The optional Extension section of an LEI record may be used to include additional data not defined in this standard. This may include data specific to an LOU, data specific to a publisher of LEI data, and so on.
For example, an LOU may use Extension to publish additional data elements it collects as part of registration.
The following rules SHALL be observed:

Each XML element included in the content of the Extension element SHALL be in an XML namespace that is not null and not equal to the XML namespace of the LEI Data File as specified in this standard.
The XML namespace for an Extension element SHALL be a namespace which the creator of the extension element exclusively or jointly controls, or from which the creator re-uses existing elements and their definitions, e.g. a namespace derived from the Internet Domain Name of the creator, a namespace agreed upon by a group of trading partners, etc.
An Extension element SHALL NOT be defined in such a way as to require the recipient of the file to recognize the Extension element in order to interpret the data elements specified in this standard. A recipient of the file SHALL be able to ignore all Extension elements and still interpret the standard content correctly.
A recipient of a data file conforming to this standard SHALL NOT reject a file solely because it contains extensions not understood by the recipient. A recipient SHALL be prepared to accept a file containing extensions and ignore any it does not understand, provided that the file complies to this standard.