LEI-CDF Version 2.1

Documentation last updated: 2017-02-23

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 official name of the legal entity as recorded in the business registry, or with the fund manager for collective investment vehicles, or otherwise in the entity’s constituting documents.
  • Where applicable, the name of the business registry in which the entity was formed.
  • The identifier of the entity in the business registry.
  • The address of the headquarters of the legal entity or the address of the fund manager.
  • The address and the country of legal formation as represented in ISO 3166.
  • The date of the first LEI assignment.
  • The date of last update of the LEI set of information.
  • The date of expiry, where applicable.
  • The reason for expiry, if applicable.
  • For entities with a date of expiry, where applicable, the LEI of the entity or entities that acquired the expired entity.
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

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 MUST 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 MUST appear, exactly once.
    • Mandatory, repeatable: {1,unbounded} - the element MUST appear at least once. It may be repeated any number of times.
    • Optional, unique: {0,1} - the element NEED NOT appear; it MAY appear once at most.
    • Optional, repeatable: {0,unbounded} - the element NEED NOT appear. 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 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

Change Management

Changes to this standard that affect the data schema SHALL be made by approval and publication of a new version of this document. A new version SHALL be one of the following:

Errata Version An errata version makes corrections to the normative content of the standard (excluding corrections which would change the data schema) and/or makes changes to non-normative content such as explanatory material. An errata version does not change the XML schema definitions, only the documentation parts, and so does not affect the interoperability of systems implementing the standard. An errata version is indicated by incrementing the third version number; e.g., 1.0 to 1.0.1, or 1.0.1 to 1.0.2.

Minor Version

A minor version may include all changes permitted in an errata version, and in addition adds one or more data elements and/or adds one or more codes to a code list (“enum” data type). A minor version changes the XML schema. Minor version changes to schema MUST provide for forward and backward compatibility. This allows existing implementations to continue to interoperate even if they are using different minor versions. A minor version is indicated by incrementing the second version number; e.g., 1.0 to 1.1 or 1.1.3 to 1.2.

Major Version

A major version may make any change at all, including incompatible changes to the XML schema. Major version changes to schema require that the new version uses a different XML namespace. This requires existing implementations to separately understand both the old and new versions during a period of transition. A major version is indicated by incrementing the first version number; e.g., 1.1 to 2.0.

The release of a new minor or major version shall always be accompanied by a transition plan for LOUs and GLEIF, to ensure a smooth and time-bounded migration to the new version.

Minor Version Changes to the XML Schema

A minor version may introduce new XML elements and/or adds one or more codes to a code list (“enum” data type). Minor version changes to schema SHALL be made as specified below, in order to achieve forward and backward compatibility.

Forward compatibility means that an LEI Data File which is valid according to the older version’s schema is also valid according to the newer version’s schema.

Backward compatibility means that an LEI Data File which is valid according to the newer version’s schema is also valid according to the older version’s schema.

New data elements may be added at pre-defined extension points within the schema, each with an optional XML element NextVersion. New data elements are always added within a NextVersion element. When a minor version adds a new data element to a NextVersion element, a new NextVersion element is also added inside the previously added NextVersion element, to accommodate additional data elements in subsequent minor versions. Each successive NextVersion element set is contained directly within the previous minor version's NextVersion set.

As can be seen from the full XML schema presented here, the following rules SHALL be observed to ensure forward and backward compatibility:
  • The initial XSD declaration for a NextVersion element SHALL use the element name "NextVersion", XML data type "lei:NextVersion1Type" and cardinality optional, unique {0,1}. The XML data type allows a sequence of any elements, each of cardinality optional, repeatable (unbounded) and with lax content processing, but in the target namespace.
  • The minOccurs declaration on the NextVersion element allows it to be omitted in files conforming to the first minor version. The schema wildcard xsd:any allows for forward compatibility: a file conforming to a new minor version still validates in the old version because the wildcard matches any new elements introduced in the new minor version.
  • New elements SHALL be introduced in a subsequent minor version by modifying the declaration for the above type declaration as follows:
    • A sequence of the new elements introduced in the previous version.
    • A subsequent NextVersionN element where N is an index number starting at 1 and incremented by 1 with each minor version.
  • Each new element SHALL be declared minOccurs=”0”, to ensure backward compatibility: a file conforming to the old version still validates in the new version because the new schema does not require the presence of elements not defined in the old version. If a new element is mandatory for conformance to the new version, this MUST be enforced outside schema validation.
  • The new definition of the NextVersion element SHALL include a declaration of an inner NextVersion element, as illustrated above, to provide for additional elements in subsequent minor versions. The nesting of NextVersion elements is required to satisfy the “unique particle attribution” constraint of XSDÂ 1.0.
  • Each code list (Enum types) is implemented in the XML schema simply as the XSD string data type. This provides for forward compatibility because the schema for an older minor version will validate any string, including codes defined in newer minor versions. The schema for each minor version includes the list of valid codes for that minor version as a documentation annotation to the type declaration for each Enum type.

Major Version Changes to the XML Schema

A major version may make any change to the XML schema whatsoever, including incompatible changes.

A schema introduced in a new major version SHALL use an XML namespace URI that is different from the XML namespace URI defined in any other major version of this standard. The namespace URI for a new major version SHOULD be the same as the namespace URI specified in this standard, with the year at the end changed to the year in which the new major version is introduced. If more than one major version is introduced in the same year, a letter “a”, “b”, “c”, etc., may be appended to the year as needed.

A new major version MUST be accompanied by an implementation plan which explains how implementations will make the transition from the old major version to the new major version. Generally speaking, such a plan typically provides for a period of transition in which an implementation capable of receiving the new major version is required to also receive the old major version.

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 MUST 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 MUST 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 MUST be prepared to accept a file containing extensions and ignore any it does not understand, provided that the file complies to this standard.
 Contains the file structure for the whole LEI data records file as specified in the XML datatypes below. Contains the file upload information for this LEI data file. Container for all of the LEIRecord elements submitted with this file. The date and time as of which the data contained in the file is valid. The LEI of the entity that created the content of this file. A code describing the content of this LEI data file. The date and time of the baseline relative to which this file contains new or changed LEI data records. The number of LEI data records in the file. Can be a positive whole (integer) number, or zero (0). A structure for adding further elements in to the LEI data file header in anticipation of a new version, by nesting a series of XML elements with this content model within the NextVersion element, one for each new minor version of the schema, postpending a serial number (1,2,3...) to the element name upon each iteration. This lei:Extension element may contain any additional elements required to extend the LEIHeader. Contains all LEI reference data including details of the LEI's registration with the ManagingLOU. This lei:Extension element may contain any additional elements required to extend the LEIRecords container. The ISO 17442 compatible identifier for the legal entity described in the Entity section. The Entity container element contains the legal entity's reference data, enabling identification. The Registration container element contains all information on the legal entity's LEI registration with the ManagingLOU. A structure for adding further elements in to the LEI Data Record in anticipation of a new version, by nesting a series of XML elements with this content model within the NextVersion element, one for each new minor version of the schema, postpending a serial number (1,2,3...) to the element name upon each iteration. This lei:Extension element may contain any additional elements required to extend the LEIRecord. The legal name of the entity. An optional list of other names (excluding transliterations) for the legal entity. An optional list of ASCII-transliterated (i.e. Latin- or Romanized) representations of names for the legal entity. The address of the entity as recorded in the registration of the entity in its legal jurisdiction. The address of the headquarters of the Entity. An optional list of other addresses for the legal entity, excluding transliterations. An optional list of transliterated addresses for the legal entity. An identifier for the legal entity in a business registry in the jurisdiction of legal registration, or in the appropriate registration authority. The jurisdiction of legal formation and registration of the entity (and upon which the LegalForm data element is also dependent). Please note that the XML schema validates the format of LegalJurisdiction codes but not the specific codes conforming to the ISO standards it reequires. Indicates (where applicable) the category of entity identified by this LEI data record, as a more specific category within the broad definition given in ISO 17442. These categories are based on use cases specified in LEI-ROC policies, found at http://www.leiroc.org/list/leiroc_gls/index.htm The legal form of the entity, taken from the ISO Entity Legal Form (ELF) code list maintained by GLEIF. Please note that the XML schema validates the format of LegalForm codes but not the specific codes conforming to the ISO standard it reequires.
 Another entity associated with this entity if needed to fully identify this entity or to place it in an appropriate context. The operational and/or legal registration status of the entity (may be ACTIVE or INACTIVE). The date that the legal entity ceased to operate, whether due to dissolution, merger or acquisition. The reason that a legal entity ceased to exist and/or operate. The surviving/new legal entity which continues/replaces this registration. A structure for adding further elements in to the Entity section of the LEI data record in anticipation of a new version, by nesting a series of XML elements with this content model within the NextVersion element, one for each new minor version of the schema, postpending a serial number (1,2,3...) to the element name upon each iteration. Date/time the LEI record was created. Date/time the LEI record was most recently updated. The status of the legal entity's LEI registration with the ManagingLOU. The next date by which the LEI registration should be renewed and re-certified by the legal entity. The LEI of the LOU that is responsible for administering this LEI registration. The level of validation of the reference data provided by the registrant. The (primary) registration authority used by the LOU to validate the entity data. An optional list of additional registration authorities used by the LEI Issuer to validate the entity data. A structure for adding further elements in to the Registration section of the LEI Data Record in anticipation of a new version, by nesting a series of XML elements with this content model within the NextVersion element, one for each new minor version of the schema, postpending a serial number (1,2,3...) to the element name upon each iteration. The mandatory first address line element. Optional, additional structured version of an external house number, or range of numbers, contained in one of the address line elements. This could be a numeral, a letter or code made up of mixed characters (e.g. 221B).
 Optional, additional structured version of an internal location number, or range of numbers, contained in one of the address line elements.This could be a numeral, a letter or code made up of mixed characters (e.g. 13) of a floor, suite or apartment within a building identified e.g. by an AddressNumber element.
 Optional free text address line to hold content from other address lines containing explicit routing information (this element's presence indicates that this address is a routing / "care of" address. One to three optional additional address line elements. The mandatory name of the city. The (optional) 4- to 6-character ISO 3166-2 region code of the region. The 2-character ISO 3166-1 country code of the country. The (optional) postal code of this address as specified by the local postal service. The language in which all of the string- valued components of this address are expressed.An IETF Language Code conforming to the latest RFC from IETF BCP 47. Note that the first characters of an IETF Language Code, up to the hyphen (if any), are all lowercase, and those following the hyphen (if any) are all uppercase. The mandatory first address line element. Optional, additional structured version of an external house number, or range of numbers, contained in one of the address line elements. Optional, additional structured version of an internal location number, or range of numbers, contained in one of the address line elements. Optional free text address line to hold content from other address lines containing explicit routing information (this element's presence indicates that this address is a routing / "care of" address. Optional additional address line elements. The mandatory name of the city. The (optional) 4- to 6-character ISO 3166-2 region code of the region. The 2-character ISO 3166-1 country code of the country. The (optional) postal code of this address as specified by the local postal service. The language in which all of the string- valued components of this address are expressed.An IETF Language Code conforming to the latest RFC from IETF BCP 47. Note that the first characters of an IETF Language Code, up to the hyphen (if any), are all lowercase, and those following the hyphen (if any) are all uppercase. The LEI of an entity associated with the LEI of this registration. The name of an entity associated with the LEI of this registration. The type of association represented by this AssociatedEntity instance. The reference code of the registration authority, taken from the Registration Authorities Code List maintained by GLEIF. A legacy / historical reference code of a registration authority which is not yet entered in the Registration Authorities Code List (RAL) maintained by GLEIF, or the designation of an interim register until such time as an entry from RAL can be delivered. The identifier of the entity at the indicated registration authority. Typically, the identifier of the legal entity as maintained by a business registry in the jurisdiction of legal registration, or if the entity is one that is not recorded in a business registry (e.g. one of the varieties of funds registered instead with financial regulators), the identifier of the entity in the appropriate registration authority. An additional registration authority used by the LOU to validate the entity data. The reference code of the registration authority, taken from the Registration Authorities Code List (RAL) maintained by GLEIF. A legacy / historical reference code of a registration authority which is not yet entered in the Registration Authorities Code List (RAL) maintained by GLEIF, or the designation of an interim register until such time as an entry from RAL can be delivered. The identifier of the entity at the indicated registration authority. Typically, the identifier of the legal entity as maintained by a business registry in the jurisdiction of legal registration, or if the entity is one that is not recorded in a business registry (e.g. one of the varieties of funds registered instead with financial regulators), the identifier of the entity in the appropriate registration authority. The type of address represented by this OtherAddress instance. An alternative address for the legal entity excluding transliterations. A transliterated version of one of the addresses for the legal entity. Type of alternative name for the legal entity. An alternative name or representation of a name for the legal entity, excluding transliterations. Type of alternative name for the legal entity. The LEI of the successor entity. The name of the successor entity. A 2-character country code conforming to ISO 3166-1 alpha-2. Please note that the XML schema validates for all CountryCode values consisting of 2 upper-case Latin letters; some possible combinations may not be valid ISO 3166 entries. A current code from the ISO-approved list must be used used. See http://www.iso.org/iso/home/standards/country_codes.htm for more details. A 4- to 6-character ISO 3166-2 region code of the region. Please note that the XML schema validates for all CountryCode values consisting of 2 upper-case Latin letters; some possible combinations may not be valid ISO 3166 entries. An element of this type 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. The file contains all LEI Data Records published by an LOU (all LEI Data Records for which the LOU is the ManagingLOU) as of the date/time the file is created. The file contains those LEI Data Records published by an LOU (all LEI Data Records for which the LOU is the ManagingLOU) which are new or changed since the DeltaStart date specified in the header, as of the date/time the file is created. The file contains all LEI Data Records published by GLEIF (including all LEI Data Records from all LOUs) as of the date/time the file is created. The file contains those LEI Data Records published by GLEIF (including all LEI Data Records from all LOUs) which are new or changed since the DeltaStart specified in the header, as of the date/time the file is created. The file contains records matching criteria specified in a query. Please note that the XML schema validates for all RegistrationAuthority values consisting of the upper-case Latin letters "RA" followed by 6 digits; some possible combinations may not be valid Registration Authority Code List (RAL) entries. A current code from the GLEIF-maintained list MUST be used used. Values of the RegistrationAuthorityEnum code list are maintained by GLEIF through the Registration Authorities Code List (RAL), available at www.gleif.org. The legal entity is a branch of another legal entity. The legal entity is a fund managed by another legal entity. The legal entity is an individual acting in a business capacity. A current code from the GLEIF-maintained list MUST be used. Values of the LegalFormEnum code list are maintained by ISO / GLEIF through the Entity Legal Form (ELF), available from http://www.gleif.org. A legacy code or textual description for the legal entity's legal form, used until a current code from the GLEIF-maintained list can be used. Please note that the XML schema validates for all LegalForm values conforming to the ISO 20275 standard (section "Code Structure"); four uppercase alphanumeric characters in any combination except for purely numeric codes. Some possible combinations may not be valid Entity Legal Form (ELF) entries. Registered name of the entity in an alternative language in the legal jurisdiction in which the entity is registered. A primary legal name previously used by this entity. A "trading as", "brand name" or "operating under" name currently used by this entity in addition to, but not replacing, the (primary) legal, official registered name. Registered address of the entity in the legal jurisdiction, in an alternative language used in the legal jurisdiction. Address of the headquarters of the entity, in an alternative language used in the legal jurisdiction. Registered address of the entity in the legal jurisdiction, transliterated to ASCII characters, auto-transliterated by the managing LOU. Address of the headquarters of the entity, transliterated to ASCII characters, auto-transliterated by the managing LOU. Registered address of the entity in the legal jurisdiction, transliterated to ASCII characters, provided by the entity for this purpose. Address of the headquarters of the entity, transliterated to ASCII characters, provided by the entity for this purpose. The legal entity is a fund, and the associated entity is the manager of the fund. As of the last report or update, the legal entity reported that it was legally registered and operating. It has been determined that the entity that was assigned the LEI is no longer legally registered and/or operating, whether as a result of business closure, acquisition by or merger with another (or new) entity, or determination of illegitimacy. The entity ceased to operate. The entity was acquired or merged with another entity. The reason for expiry is neither of DISSOLVED nor CORPORATE_ACTION An application for an LEI that has been submitted and which is being processed and validated. An LEI Registration that has been validated and issued, and which identifies an entity that was an operating legal entity as of the last update. An LEI Registration that has been determined to be a duplicate registration of the same legal entity as another LEI Registration; the DUPLICATE status is assigned to the non-surviving registration (i.e. the LEI that should no longer be used). An LEI registration that has not been renewed by the NextRenewalDate and is not known by public sources to have ceased operation. An LEI registration for an entity that has been merged into another legal entity, such that this legal entity no longer exists as an operating entity. An LEI registration for an entity that has ceased operation, without having been merged into another entity. An LEI registration that was marked as erroneous or invalid after it was issued An LEI registration that was abandoned prior to issuance of an LEI An LEI registration that has been transferred to a different LOU as the managing LOU. An LEI registration that has been requested to be transferred to another LOU. The request is being processed at the sending LOU An LEI registration is about to be transferred to a different LOU, after which its registration status will revert to a non-pending status. The validation of the reference data provided by the registrant has not yet occurred. Based on the validation procedures in use by the LOU responsible for the record, the information associated with this record has significant reliance on the information that a submitter provided due to the unavailability of corroborating information. Based on the validation procedures in use by the LOU responsible for the record, the information supplied by the registrant can be partially corroborated by public authoritative sources, while some of the record is dependent upon the information that the registrant submitted, either due to conflicts with authoritative information, or due to data unavailability. Based on the validation procedures in use by the LOU responsible for the record, there is sufficient information contained in authoritative public sources to corroborate the information that the submitter has provided for the record. The language of this element's text content. An IETF Language Code conforming to the latest RFC from IETF BCP 47. Note that the first characters of an IETF Language Code, up to the hyphen (if any), are all lowercase, and those following the hyphen (if any) are all uppercase.

Character Codes Allowed in ASCII Transliterated Names

A TransliteratedOtherEntityName instance of type PREFERRED_ASCII_TRANSLITERATED_LEGAL_NAME or AUTO_ASCII_TRANSLITERATED_LEGAL_NAME, can only contain non-control characters drawn from the “invariant subset” of ISO 646. These characters are enumerated below. The “Hex Value” column indicates the code point value (expressed in hexadecimal) for each character in both ISO 646 and ISO 10646. This is enforced by the XML schema.

Graphic Symbol Name Hex Value Graphic Symbol Name Hex Value
! Exclamation Mark 21 M Capital Letter M 4D
" Quotation Mark 22 N Capital Letter N 4E
% Percent Sign 25 O Capital Letter O 4F
& Ampersand 26 P Capital Letter P 50
' Apostrophe 27 Q Capital Letter Q 51
( Left Parenthesis 28 R Capital Letter R 52
) Right Parenthesis 29 S Capital Letter S 53
* Asterisk 2A T Capital Letter T 54
+ Plus sign 2B U Capital Letter U 55
, Comma 2C V Capital Letter V 56
- Hyphen/ Minus 2D W Capital Letter W 57
. Full Stop 2E X Capital Letter X 58
/ Solidus 2F Y Capital Letter Y 59
0 Digit Zero 30 Z Capital Letter Z 5A
1 Digit One 31 _ Low Line 5F
2 Digit Two 32 a Small Letter a 61
3 Digit Three 33 b Small Letter b 62
4 Digit Four 34 c Small Letter c 63
5 Digit Five 35 d Small Letter d 64
6 Digit Six 36 e Small Letter e 65
7 Digit Seven 37 f Small Letter f 66
8 Digit Eight 38 g Small Letter g 67
9 Digit Nine 39 h Small Letter h 68
: Colon 3A i Small Letter i 69
; Semicolon 3B j Small Letter j 6A
< Less-than Sign 3C k Small Letter k 6B
= Equals Sign 3D l Small Letter l 6C
> Greater-than Sign 3E m Small Letter m 6D
? Question Mark 3F n Small Letter n 6E
A Capital Letter A 41 o Small Letter o 6F
B Capital Letter B 42 p Small Letter p 70
C Capital Letter C 43 q Small Letter q 71
D Capital Letter D 44 r Small Letter r 72
E Capital Letter E 45 s Small Letter s 73
F Capital Letter F 46 t Small Letter t 74
G Capital Letter G 47 u Small Letter u 75
H Capital Letter H 48 v Small Letter v 76
I Capital Letter I 49 w Small Letter w 77
J Capital Letter J 4A x Small Letter x 78
K Capital Letter K 4B y Small Letter y 79
L Capital Letter L 4C z Small Letter z 7A
Space 20
Type of alternative name for the legal entity. Legal name of the entity transliterated to ASCII characters, provided by the entity for this purpose. Legal name of the entity transliterated to ASCII characters, auto-transliterated by the managing LOU. The language of this element's text content. An IETF Language Code conforming to the latest RFC from IETF BCP 47. Note that the first characters of an IETF Language Code, up to the hyphen (if any), are all lowercase, and those following the hyphen (if any) are all uppercase.
  • Elements of base data type xs:dateTime further restrict the ISO 8601 range of date and time format to the single format:

    YYYY-MM-DDThh:mm:ss.sssTZ

    where the components of the above string are as follows:
    • YYYY is the year
    • MM is the month (01 = January, …, 12 = December)
    • DD is the day of the month (01 = first day of the month)
    • T is the single character ‘T’
    • hh is the hour (00 – 23)
    • mm is the minute
    • ss.sss is the second and milliseconds. Two digits must be used for the seconds. From one to three digits may be used for milliseconds, or omitted entirely along with the decimal point.
    • TZ is the time zone specifier, which can be one of:
      • Z the single character ‘Z’, denoting Coordinated Universal Time (UTC); or
      • +hh:mm denoting a positive offset from UTC; or
      • -hh:mm denoting a negative offset from UTC
    This pattern therefore adds the restrictions, beyond the ISO 8601 specification:
    • Only the specified pattern of digits, indicators and separators may be used (no spaces or other white space characters).
    • The time zone (TZ) MUST be present, although it may be zero (Z) if all dates and times are expressed as UTC+00:00.
    • Only 3 decimal places maximum are allowed in the seconds section (ss.sss).