@’ rotattng ol st
Common Data File Formats — Questions and Answers FINAL
Table of Contents ) C =T 1Y - I o] 11 o1 PRPPPRPORRPRR. 1.1 What are the GLEIF data formats? .....ccccccvvieeriiiiiiiiie et csiieeee e siane D 1.2 How are the GLEIF data formats applied? .......cccoveeiiiiiiiiiieieniiieece e D 1.3 How are the GLEIF data formats updated?........cccccceeiviviiiiieniiiiiieece e, 6 1.4 How can my organization store and manage CDF data locally? .........ccccceviiinnnnnn. 6 1.5 Whatis a CDF-formatted data file?.......cccouveeiiiiiiiiiii e, © 1.6 Whatis a CDF-formatted data file?........cccvuveeriiiiiiiiii i, © 1.7 How does GLEIF process the CDF data it receives?.......cccccveevvvcivieeeeisinineeneensncnns 7 1.8 How do the CDF formats handle international languages and scripts?........c........ 7 1.9 Which special characters, string lengths and character encoding can be expected when working with LEI-CDF formatted data? ........ccccceeeiiiiiieeeriiiniie i 8 2 LEI-CDF TOPICS cetuueruneeneranrennrenrennsenceossascrnssassensesnssnsssnssnsssassesssassesssascennens O 2.1 Whatisan LEI data file? ...ccovuiiieiiieiiieie et ee e sinnne e D 2.2 What information is found in the LEIl data file header?.........cccccevviveeiinniiieennnn. 9 2.3 What are LEI data reCOords? ......civiiiiiieeiiiiieeie e essiiie e es s sniveeeesssnneeee s e s snnnneessenes 9 2.4 Whatis the structure of the LEI-CDF?......ccccviiiiiiiiiiieece e sineneee s 9 2.4.1 LEIHEAUEITYPE. ceiiiiciiieeeeieciieee s eestteeeesestrieeesssstreeesssstreeesssssssesssssssseesssssssneessnssseeessnans L0 2.4.2 LEIRECOIASTYPE wieiiervieeeiieitieeeeeeitieeeseettteesseetteeessseeeaessnsnseessnsnsesssssnssensssssssenasssnens L1 2.4.3 LEIRECOIATYPE cuiiiiiciiieeeiieitieee s sectieeessettteessestteaesssveeaesssnsaeeessnnseeasssnssenessssnsenasssnnns L1 W Ny W) AV Y oSO OO OO PP PP PP PPPP P RPRPPPPPPRPR . 2.5 Whatisa valid LEI COU@? .......uiiiiiiiiiiiiie e ciiiieeee e cssitie e e svvveeeessssinneeesessssnnneesees 19 2.6 Whatisthe LEl code prefiX?..... et siiieeeessssiieeee s esssineneeeees 19 2.7 How isthe LEI code generated?........ccccceeevviiieeiiiiiniiiiiece s siiieeeeesssiieeeesessineneeenss 19 2.8 How are the LEI code’s check digits calculated and checked?............................. 19 2.9 What information about a legal entity is required by the LEI-CDF?..................... 20 2.10 What additional information can be provided in LEIl data records? .................... 20 2.11 Which status fields are used in an LEl data record?........cccccccevevvinieeeennnicineeennn. 20 2.12 Which o
ther codes and standards are included in the LEI-CDF? ...........cccccuee..... 21 2.13 How do LEl Issuers deal with changes, corrections and updates to the LEI-CDF data they deliver t0 GLEIF? .......oiiviiiiiie e ssieeee s e sinnaeeeees 22 3 RR-CDF TOPICS ceuteuirerenerenrennrenrennsencransencrnssessensssnssasssnssssssassesssssssnssancensss 3 3.1 What are RR-CDF Fil@S?...cciiiiiiiiiiie ettt seete e srae e e s ssvveeee s s s siiinneees 23 3.2 Whatis the structure of the RR-CDF? ......ccccoviiiiiiiiiiiiieeeeeciiieee s eniieeee s sineeens 23 3.2.1 RelationshipDataTyPe ...ccccvieei ittt eerre e errae e e s srae e e s sree e e e eeee 23 3.2.2 RRHEAUEITYPE . ceiiiiciiiiiecitieie s eestteeeesestrieeessstteee s setreeessssssseesssnssseessnssssneessnssseeeesnnns 200 3.2.3 RelationshipRECOIASTYPE ..uuiieiieciiiieeccriieeecctrie e eeree e e eeevee e ssreae e e s sree s e s ssneeaaeseeee 2D G Common Data File Formats — Questions and Answers Page 2 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
2.4.2 LEIRecordsType LEIRecord lei:LEIRecordType {0,unbounded} Contains all LEI reference data including details of the LEl's registration with the ManagingLOU. Extension lei:ExtensionType {0,1} This lei:Extension element 2.4.3 LEIRecordType ) The ISO 17442 compatible identifier for the legal entity described in the Entity LEI lei:LEIType {1,1} . section. ) L The Entity container element contains the legal entity's reference data, Entity lei:EntityType {1,1} L e . enabling identification. ) ) ) ) ) The Registration container element contains all information on the legal entity's Registration lei:RegistrationType {1,1} ) . . . LEI registration with the ManagingLOU. Common Data File Formats — Questions and Answers Page 11 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
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 NextVersion lei:LEIRecordNextVersionType {0,1} 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 Extension lei:ExtensionType {0,1} extend the LEIRecord. 2.4.4 EntityType LegalName lei:NameType {1,1} The legal name of the entity. OtherEntityNames lei:OtherEntityNamesType {0,1} An optional list of other names (excluding transliterations) for the legal entity. TransliteratedOtherEntityNames lei:TransliteratedOtherEntityNamesType {0,1} An optional list of ASClI-transliterated (i.e., Latin- or Romanized) representations of names for the legal entity. Common Data File Formats — Questions and Answers Page 12 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
LegalAddress lei:AddressType {1,1} The address of the entity as recorded in the registration of the entity in its legal jurisdiction.
HeadquartersAddress lei:AddressType {1,1} The address of the headquarters of the Entity.
OtherAddresses lei:OtherAddressesType {0,1} An optional list of other addresses for the legal entity, excluding transliterations.
TransliteratedOtherAddresses lei:TransliteratedOtherAddressesType {0,1} An optional list of transliterated addresses for the legal entity.
RegistrationAuthority lei:RegistrationAuthorityType {0,1} An identifier for the legal entity in a business registry in the jurisdiction of legal registration, or in the appropriate registration authority.
Legallurisdiction lei:JurisdictionCodeType {0,1} 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 Legallurisdiction codes but not the specific codes conforming to the ISO standards it requires.
Common Data File Formats — Questions and Answers Page 13 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
EntityCategory lei:EntityCategoryTypeEnum {0,1} 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
EntitySubCategory lei:EntitySubCategoryTypeEnum {0,1} Indicates and specifies further (where applicable) the sub-category (sub-sector) of Legal Entity identified by this LEI Record and already categorized by the EntityCategory.
LegalForm lei:LegalFormType {0,1} 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 requires.
Common Data File Formats — Questions and Answers Page 14 of 35 GLEIF Public Version 2.4 @ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
AssociatedEntity lei:AssociatedEntityType {0,1} Another entity associated with this entity if needed to fully identify this entity or to place it in an appropriate context.
Note: This is a deprecated field and is maintained for technical backward compatibility.
EntityStatus lei:EntityStatusEnum {1,1} The operational and/or legal registration status of the entity (may be ACTIVE, INACTIVE, or NULL).
EntityCreationDate lei:LEIDateTimeProfileGeYear0001 {0,1} The date on which the legal entity was first established as defined in ISO 17442.
EntityExpirationDate lei:LEIDateTimeProfile {0,1} The date that the legal entity ceased to operate, whether due to dissolution, merger or acquisition.
Note: This is a deprecated field and is maintained for technical backward compatibility.
EntityExpirationReason lei:EntityExpirationReasonEnum {0,1} The reason that a legal entity ceased to exist and/or operate.
Common Data File Formats — Questions and Answers Page 15 of 35 GLEIF Public Version 2.4 @ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
Note: This is a deprecated field and is maintained for technical backward compatibility. SuccessorEntity lei:SuccessorEntityType {0,unbounded} The surviving/new legal entity which continues/replaces this registration. LegalEntityEvents lei:LegalEntityEventsType {0,1} Container for a finite number of events specified by the LEI ROC in the life of a legal entity that would impact the Reference Data in the Global LEI System. NextVersion lei:EntityNextVersionType {0,1} A structure for adding further elements into the Entity section of the LEl 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. Common Data File Formats — Questions and Answers Page 16 of 35 GLEIF Public Version 2.4 @ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
InitialRegistrationDate lei:LEIDateTimeProfile {1,1} Date/time the LEI record was created. LastUpdateDate lei:LEIDateTimeProfile {1,1} Date/time the LEI record was most recently updated. RegistrationStatus lei:RegistrationStatusEnum {1,1} The status of the legal entity's LEI registration with the ManagingLOU. NextRenewalDate lei:LEIDateTimeProfile {1,1} The next date by which the LEI registration should be renewed and re-certified by the legal entity. ManagingLOU lei:LEIType {1,1} The LEI of the LOU that is responsible for administering this LEI registration. ValidationSources lei:ValidationSourcesEnum {0,1} The level of validation of the reference data provided by the registrant. ValidationAuthority lei:ValidationAuthorityType {0,1} The (primary) registration authority used by the LOU to validate the entity data. OtherValidationAuthorities lei:OtherValidationAuthoritiesType {0,1} An optional list of additional registration authorities used by the LEl Issuer to validate the entity data. Common Data File Formats — Questions and Answers Page 17 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
NextVersion lei:RegistrationNextVersionType {0,1} A structure for adding further elements into 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
Common Data File Formats — Questions and Answers Page 18 of 35 GLEIF Public Version 2.4 @ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
2.5 What is a valid LEI code?
All LEI codes must contain only combinations of the digits 0 to 9 and the upper-case letters A to Z. Lower case letters are not allowed. The final 2 digits (the check digits) must be numeric only.
This is required by the LEI standard, 1ISO 17442, and the LEIl code character set is enforced by the Common Data File formats.
A valid LEI code must also have correct check digits.
2.6 What is the LEI code prefix?
The first 4 digits of an LEI (its “prefix”) are reserved to an LEl Issuer to ensure that LEl codes are unique at the point of issuance; this is an additional operational principle which is not explicitly required by ISO 17442. This is not checked automatically by the CDF XML schemas.
Please note that the prefix of any LEI code is added at the initial registration of a legal entity, solely to prevent duplication of codes across two or more LEl Issuers. It has no intrinsic meaning and no other use.
Some LEI codes were issued before the LEI ROC's operational standards came into effect. These codes may have prefixes that do not match any LEl Issuer.
2.7 How is the LEI code generated?
Characters 5-18 of the LEI code are the entity-specific section, generated and assigned by LOUs according to transparent, sound and robust allocation policies. As required by ISO 17442, it contains no embedded intelligence.
2.8 How are the LEI code’s check digits calculated and checked?
The 2 check digits of an LEI are calculated from the first 18 characters of the LEI, according to the I1SO Standard 17442, which itself refers to ISO Standard 7064. Both standards are available from WWW.iso.org at a cost.
Please note that the check digits are only a technical, statistical protection against manual transcription errors (e.g., character transposition during data entry or automated character recognition).
Incorrect check digits indicate the probable presence of an error in the other 18 characters. Correct digits indicate the absence of such errors. The check digits are no indication of any other type of defect beyond this probability, and they do not relate in any way to the LEI reference data.
2.9 What information about a legal entity is required by the LEI- CDF? The minimum reference data for an LEl data record as defined by ISO 17442 and enforced by the LEI- CDF is as follows: ¢ 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: o The name of the business registry in which the entity was formed. ¢ The identifier of the entity in the business registry. o 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 LEl assignment; the date on which the legal entity first established. ¢ The date of last update of the LEIl set of information. ¢ The date of expiry, where applicable. o The reason for expiry, if applicable. o For entities with a date of expiry, where applicable, the LEI of the entity or entities that acquired the expired entity. In addition to LEI-CDF information, a legal entity must report its relationship information, per current LEI-ROC policy, to keep its LEIl in good standing (issued). This is reported to GLEIF by the LEl Issuer, using the RR-CDF format (and the Reporting Exceptions format, where applicable). 2.10 What additional information can be provided in LEI data records? o The legal form of the entity. e Other names or representations of names for the legal entity. o Alegal or headquarters address in different languages. Custom fields may (optionally) also be added; please see below. 2.11 Which status fields are used in an LEI data record? The Legal Entity Reference Data (LE-RD) provided with each LEI code, contains two status fields: e EntityStatus - The status of the legal entity (active, inactive, or null). e RegistrationStatus -The status of the LEl registration with the LEI Issuer. G Common Data File Formats — Questions and Answers Page 20 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.2.4 RelationshipRECOIATYPE. . .uuiiiiieciiiiie ittt ceie e eerre e esrrae e e s sree e e e sreeaaeeeeee 2D
3.2.5 RelationshipContainerTYPe ..ccccccieeeiieciiieee it cetiee e sssrrre e sssrrreeesssreeeesssssseeeesenns 20
3.2.6 NOUETYPE cooiiiieeit ettt ettt ee s eestte e ee st reesse st be e e ssstbeeeesssereeesssateessnnsaeeessnnssseessnns 28
3.2.7 RelationshipPeriodsTyPe . .uueiiiccieeee ittt esrreeesessrrreee s ssraeeesssrreeeesnees 28
3.2.8 RelationshipPeriodTYPe ...cveeeiecciiiiiiieiiieie ettt e s sssrare e s ssraeeeessraeeeeseees 28
3.2.9 RelationshipQUAlIfIErSTYPE .....uvevciiiecieecce et sree e e sree e ssneeeneeeeeees 29 3.2.10RelationshipQUAlIfIErTYPE ..cccvvveeeeie et e sree e esneesneeeeeees 29 3.2.11RelationshipQuUantifiersTYPe .....ccccveeceeiisiee et ceesrcree e e ste e eseee e seeeesseaeeseeeeenes 30 3.2.12RelationshipQuUantifierTyPe......ccccueecciiesececeee e esecreeeceeeste e eseee e sreeessseaeseneeeenes 30 3.2.13RegistrationCoNtaiNerTYPe. .. ..uuuiriiiiieieeieeirciieeiete e e ee e s siererreeeeseessessssnnneeseneess 31
3.3 What information is found in the relationship data file header? ........................ 33
3.4 What are relationship records? ........cccviieiiiiiiiin e eeeees 33
3.5 Do relationship records have a unique ID? ........cccccvviiiieeiiiiiiieeee s esrieeee e essieeees 33
3.6 What information about a relationship is required by the RR-CDF? ................... 33
3.7 What if relationship information is not available for a legal entity?.................... 33
3.8 What are the status fields used in a relationship record? .........ccceccvvvvvvviiinnnee... 34
4 Where can | find further information?.......cc.cccevvviiiiiiinciiiiiinncciniieeennnn. 35 4.1 GLEIF FIlES oottt ettt e e e eeeeeeee e e e e e es s s nnsanssesaesaesseeaaanaaees 3D
4.2 LELISSUET fIllES coiuiiiiieiei ittt sttt e e s saanae s e s s svaae e e s snnnnnees 3D
4.3 Whom should | contact for further questions?.........cccccceevevvvciieeinvcciieeeeeiiineen. 35 G Common Data File Formats — Questions and Answers Page 3 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
For afull list of EntityStatus and RegistrationStatus values, including descriptions, please see the detailed specification of the LEl Common Data File format XML Schema Definitions. 2.12 Which other codes and standards are included in the LEI-CDF? The following code lists are managed by GLEIF: LegalForm Entity Legal Form (ELF) Code; Resolves variant names for ISO Standard 20275 each valid legal form within a jurisdiction to a single code per legal form, per jurisdiction. RegistrationAuthority Registration Authority List (RAL) Identifies a business registry in the jurisdiction of legal registration, or appropriate registration authority (e.g., one of the varieties of funds registered instead with financial regulators). Other codes managed by third parties included in the LEI-CDF are used to ensure data quality: Country The 2-character I1SO 3166-1 country code of the country. Region The 4- to 6-character ISO 3166-2 region code of the region. Legal Jurisdiction Either an ISO 3166-1 country code or an ISO 3166-2 region code. xml:lang An IETF Language Code conforming to RFC 4646. Common Data File Formats — Questions and Answers Page 21 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
ContentDate, DeltaStart, A subset of the ISO 8601-compliant XML Schema dateTime format EntityExpirationDate, EntityCreationDate, InitialRegistrationDate, LastUpdateDate, NextRenewalDate IETF standards can be found on the World Wide Web for free. ISO standards can be obtained from WWW.iso.org at a cost. 2.13 How do LEI Issuers deal with changes, corrections and updates to the LEI-CDF data they deliver to GLEIF? LEI Issuers are responsible for the contents of their LEI data records. GLEIF simply passes on the LEI data records we receive from the LEl Issuer, without changes. Please address any specific queries about the LEI Issuers' data to the LEI Issuers themselves. GLEIF provides contact details for all LEI Issuers at www.gleif.org. An LEI data record may also be challenged directly: e Gotothe page for your LEl using the URL pattern below. https://www.gleif.org/lei/<your LEI> Example: https://www.gleif.org/lei/549300Q82NZ9NYNMZT63 o Click the “Challenge” button at the foot of the page to send a proposed update directly to the LEI Issuer through GLEIF’s central Challenge Service. Common Data File Formats — Questions and Answers Page 22 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3 RR-CDF Topics
3.1 What are RR-CDF Files?
The XML format defines a container that holds a file header and a series of relationship data records.
3.2 What is the structure of the RR-CDF?
Please see the tables below for an overview of the RR-CDF elements.
Some “Type” column values refer to later tables; these refer to data elements that are contained within the referring element.
Further details can be found in the technical specification document PDF and corresponding XML Schema Definition (XSD), available at www.gleif.org.
3.2.1 RelationshipDataType Header rr:RRHeaderType {11} Contains the file upload information for this RelationshipData file. RelationshipRecords rr:RelationshipRecordsType {1,1} Container for all of the RelationshipRecord container elements
submitted with this file.
3.2.2 RRHeaderType
ContentDate rr:LEIDateTimeProfile {1,1} The date and time as of which the data contained in the file is valid.
Originator rr:LEIType {0,1} The LEI of the entity that created the content of this file.
FileContent rr:FileContentEnum {1,1} A code describing the content of this relationship record file.
DeltaStart rr:LEIDateTimeProfile {0,1} The date and time of the baseline relative to which this file contains new or changed Relationship Records.
RecordCount xs:nonNegativelnteger {1,1} The number of relationship records in the file.
NextVersion rr:HeaderNextVersionType {0,1} A structure for adding further elements into 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.
Extension rr:ExtensionType {0,1} This Extension element may contain any additional elements required to extend the Header container element.
Common Data File Formats — Questions and Answers Page 24 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.2.3 RelationshipRecordsType RelationshipRecord rr:RelationshipRecordType {0,unbounded} Contains all relationship information including identifiers referring to the related entities, the specific type and other attributes of the relationship itself, and details of the relationship's registration with the ManagingLOU. 3.2.4 RelationshipRecordType Relationship rr:RelationshipContainerType {1,1} The Relationship container element contains the identifiers of the two entities related by the reported relationship, as well as the type of relationship, dates related to the relationship and other relationship quantifiers and qualifiers. Registration rr:RegistrationContainerType {1,1} The Registration container element contains information specifying the LOU's administration of the relationship report. Common Data File Formats — Questions and Answers Page 25 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
NextVersion rr:RelationshipRecordNextVersionType {0,1} A structure for adding further elements into the Registration section of the Relationship 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.
Extension rr:ExtensionType {0,1} This Extension element may contain any additional elements required to extend the RelationshipRecord.
3.2.5 RelationshipContainerType StartNode rr:NodeType {1,1} An LEl or ISO 17442-compatible ID for the entity at the "start" of a directional relationship. EndNode rr:NodeType {1,1} An LEl or ISO 17442-compatible ID for the entity at the "end" of a directional relationship. RelationshipType rr:RelationshipTypeEnum {1,1} A unique code designating the specific category of a directional relationship between two legal entities. Common Data File Formats — Questions and Answers Page 26 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
RelationshipPeriods rr:RelationshipPeriodsType {0,1} A collection of paired beginning and end dates relating to: the relationship itself, periods (e.g. accounting cycles) covered by documents demonstrating the relationship, or the filing date(s) of those documents.
RelationshipStatus rr:RelationshipStatusEnum {1,1} The status of the legal entities' relationship itself: ACTIVE, INACTIVE, or NULL.
RelationshipQualifiers rr:RelationshipQualifiersType {O,unbounded} Any additional qualitative attributes that help to categorize the relationship.
RelationshipQuantifiers rr:RelationshipQuantifiersType {0,unbounded} Any additional quantitative attributes that help to categorize the relationship.
NextVersion rr:RelationshipNextVersionType {0,1} A structure for adding further elements in to the Registration section of the Relationship 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.
Extension rr:ExtensionType {0,1} This Extension element may contain any additional elements required to extend the Relationship container element.
Common Data File Formats — Questions and Answers Page 27 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.2.6 NodeType NodelD rr:LEIType {1,1} The identifier for the entity designated by this node. NodelDType rr:NodelDTypeEnum {1,1} The type of identifier used to designate this node's entity. 3.2.7 RelationshipPeriodsType RelationshipPeriod rr:RelationshipPeriodType {1,unbounded} Contains one set of start and end dates for a particular type of period, for example, the duration of the relationship itself, the filing or validity period of any documents demonstrating the relationship, or the accounting period they refer to. 3.2.8 RelationshipPeriodType StartDate rr:LEIDateTimeProfile {0,1} The start date for a particular period relevant to the relationship. EndDate rr:LEIDateTimeProfile {0,1} The end date for a particular period relevant to the relationship. Common Data File Formats — Questions and Answers Page 28 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
PeriodType rr:PeriodTypeEnum {1,1} The particular type of period, for example, the duration of the relationship itself, the filing or validity period of any documents demonstrating the relationship, or the accounting period they refer to.
3.2.9 RelationshipQualifiersType RelationshipQualifier rr:RelationshipQualifierType {0,unbounded} Container for all sets of relationship qualifier information. 3.2.10 RelationshipQualifierType
QualifierDimension rr:QualifierDimensionEnum {1,1} Designates the optional list of additional qualitative attributes
that help to categorize the relationship.
QualifierCategory rr:QualifierCategoryTypeEnum {0,1} Specifies the additional qualitative attributes that help to
categorize the relationship.
RelationshipQuantifier rr:RelationshipQuantifierType {0,unbounded} Specifies one additional quantitative attribute of the
relationship, according to a particular measurement method. Common Data File Formats — Questions and Answers Page 29 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.2.11 RelationshipQuantifiersType RelationshipQuantifier rr:RelationshipQuantifierType {0,unbounded} Specifies one additional quantitative attribute of the relationship, according to a particular measurement method. 3.2.12 RelationshipQuantifierType
MeasurementMethod rr:MeasurementMethodTypeEnum {1,1} Specifies the method of measurement (or set of rules) used to guantitatively categorize the relationship.
QuantifierAmount xs:decimal {1,1} Specifies the quantity measured as a decimal (positive or negative) number, using a ‘.” as the decimal point, with no spaces, and without thousand delimiters (e.g. ,).
QuantifierUnits rr:QuantifierUnitsTypeEnum {0,1} Specifies the units, where applicable, of a measurement made on a relationship.
Common Data File Formats — Questions and Answers Page 30 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
_ GLEIF Head of IT Operations & Development About this Document This document provides answers to common questions on the Common Data File formats developed by the Legal Entity Identifier Regulatory Oversight Committee (LEI ROC) and further developed and maintained by GLEIF. Change History This section records the history of all changes to this document. 2022-02-22 Final, 2.4 Updated the document to reflect the | GLEIF latest version of LEI- CDF V3.1, RR- CDF V2.1, and Reporting Exceptions format v2.1 2017-11-06 WORK, 2.3 Minor updates, alignment with GLEIF Golden Copy 2017-05-04 FINAL, 2.2 New Level 2 version, major updates: GLEIF LEI-CDF V2.1, RR-CDF 2016-11-11 FINAL, 1.0 Final version GLEIF Common Data File Formats — Questions and Answers Page 4 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.2.13 RegistrationContainerType InitialRegistrationDate rr:LEIDateTimeProfile {1,1} The date at which the relationship information was first collected by the ManagingLOU. LastUpdateDate rr:LEIDateTimeProfile {1,1} The date at which the information was most recently updated by the ManagingLOU. RegistrationStatus rr:RegistrationStatusEnum {1,1} The status of the legal entity's relationship record registration with the ManagingLOU. NextRenewalDate rr:LEIDateTimeProfile {0,1} The next date by which the relationship information must be renewed and re-certified by the legal entity. ManagingLOU rr:LEIType {1,1} The LEI of the LOU that is responsible for administering this relationship record. ValidationSources rr:ValidationSourcesTypeEnum {1,1} Level of relationship validation. ValidationDocuments rr:ValidationDocumentsTypeEnum {1,1} Type of source document(s) used for validating the relationship. ValidationReference rr:Tokenized500Type {0,1} A reference to a specific document or other source used as the basis of relationship validation for this relationship record. Common Data File Formats — Questions and Answers Page 31 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
NextVersion rr:RegistrationNextVersionType {0,1} A structure for adding further elements into the Registration section of the Relationship 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.
Extension rr:ExtensionType {0,1} This Extension element may contain any additional elements required to extend the Registration container element.
Common Data File Formats — Questions and Answers Page 32 of 35 GLEIF Public Version 2.4 @ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
3.3 What information is found in the relationship data file header?
The header contains the file upload information for a relationship data file.
3.4 What are relationship records?
A relationship record contains all mandatory and additional information on one relationship between
two legal entities.
3.5 Do relationship records have a unique ID?
Relationship records themselves do not have an ID code, as, although they are reported in a
technically separate way from LEI-CDF files, they function as part of the LEl reference data and
always contain at least one LEl. Some types of relationship, such as ultimate accounting
consolidation, may be unique, while others may be repeatable for a given legal entity.
3.6 What information about a relationship is required by the RR-
CDF?
All mandatory relationship types must be reported by entities with an LEI. Each relationship type has
its own set of requirements for valid reporting.
Other optional relationship types may be reported, but the LEI Issuer is not obliged to provide them.
Further, some data fields pertaining to specific relationship types may be optional, supplemental
information.
Please see the State Transition Rules and Validation Rules v2.5 document for further details,
available at www.gleif.org.
3.7 What if relationship information is not available for a legal
entity?
To receive and keep an LEl in good standing, legal entities must provide and update all the
relationship information required by LEI-ROC policy. The latest LEI-ROC requirements can be found at
Any acceptable reasons, per LEI-ROC policy, for non-reporting of relationship information are
supplied to GLEIF using the Reporting Exceptions format. These might include, for example:
¢ Non-consolidating, whenever the accounting consolidation definition for parent relationship does not apply. This category includes cases where the entity is controlled by a natural person(s) without any intermediate legal entity (“Natural Person(s)”); the entity is controlled by legal entities not subject to consolidation (“Non-Consolidating”); and where there is no known person(s) controlling the entity (“No Known Person” e.g., the entity is controlled by diverse shareholders).
¢ Non-Public, whenever the relationship information is non-public and therefore creates obstacles to releasing this information. This category includes cases where there are obstacles in the laws or regulations of a jurisdiction restricting the reporting (“Binding Legal Constraint”); the existence of other legal constraints such as articles governing the legal entity or a contract (“Legal Obstacles”); where disclosure of the information would be detrimental to the legal entity or the relevant parent (“Disclosure Detrimental” and “Detriment Not Excluded”); and where the consent to disclose the parent LEI was not obtained (“Consent Not Obtained”) An entity is not required to provide non-public relationship information in order to register or renew an LEI. ¢ No LEl, when the parent does not consent to obtain an LEI or to authorize its “child entity” to obtain an LEI on its behalf. Details of the Reporting Exceptions format can be found at www.gleif.org, although the reported data in these formats is shared only with the LEI-ROC for evaluation purposes. 3.8 What are the status fields used in a relationship record? The relationship data provided in a relationship record contains two status fields: RelationshipStatus - The status of the relationship itself (active or inactive). RegistrationStatus - The status of the relationship reporting data record maintained by the LEI Issuer. For a full list of RelationshipStatus and RegistrationStatus values, including descriptions, please see the detailed specification of the Relationship Record Common Data File format, found at www.gleif.org. Common Data File Formats — Questions and Answers Page 34 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
4 Where can | find further information? 4.1 GLEIF Files For a description of the GLEIF Concatenated Files and instructions on how to obtain and use them, please see the GLEIF Concatenated Files (and, separately, the Golden Copy Files) Specification and User Manual documents, available from www.gleif.org. 4.2 LEl Issuer files If you have any questions regarding the original source files, please contact the respective LEI Issuer via its website. Contact details for all LEl Issuers can be found at www.gleif.org. 4.3 Whom should I contact for further questions? Please address any further questions or feedback on the LEI-CDF and RR-CDF formats to info@gleif.org. Common Data File Formats — Questions and Answers Page 35 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
1 General topics 1.1 What are the GLEIF data formats? The GLEIF data formats include o LEI-CDF o RR-CDF o Reporting Exceptions They are technical specifications supporting the 1ISO 17442 Legal Entity Identifier (LEI) standard. The GLEIF standards are proposed and developed by the Legal Entity Identifier Regulatory Oversight Committee (LEI-ROC), and further developed and maintained by GLEIF as the operational arm of the Global LEI System, always under LEI-ROC oversight. 1.2 How are the GLEIF data formats applied? The LEI-CDF, RR-CDF, Reporting Exceptions format, and code lists such as the RAL, specify data elements and values that can be checked (“validated”) automatically. GLEIF applies this validation to all the LEl and relationship data that LEI Issuers submit to GLEIF, so that a basic level of data quality is enforced across all the data. Although this validation is automated, GLEIF monitors the LEI Issuers’ data uploads and data quality reports on a daily basis. In addition, the data formats are flexible enough for LEI Issuers to include additional value-added information in a reliable way, and changes or corrections to the data structures can be proposed to GLEIF at any time. The primary access point to the Global LEI Index, the full set of GLEIF Concatenated Files, is in XML format and is also CDF schema compliant. Please address any further questions or feedback on the LEI- and RR-CDF formats to info@gleif.org. Please note that XML schema validation enforces a minimum data quality and standards conformance. Data files in CDF XML format are not accepted if they do not validate against the XML schema found in the CDF format specification, but other business rules and data quality checks applied by GLEIF also encourages stricter conformance in live implementations. Common Data File Formats — Questions and Answers Page 5 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
1.3 How are the GLEIF data formats updated? Any update requiring significant changes will be accompanied by an appropriate transition plan. All updates are notified via the website, www.gleif.org. 1.4 How can my organization store and manage CDF data locally? Many CDF data file users might wish to use the Golden Copy and Golden Copy Delta Files as the basis of their local LEl and relationships database, as they are optimized for this use case. Updates to specific LEI Records can be quickly obtained via the GLEIF API. The GLEIF Concatenated Files are also maintained to provide a permanent audit trail of all original data as received from LEI Issuers. A local database can also be populated from these files but this may require extra effort to process the data. A secure, scheduled transfer can be set up using HTTPS, as described in the following documents available at www.gleif.org: ¢ GLEIF Golden Copy and Delta Files Specification and User Manual o GLEIF Concatenated File Specification and User Manual Another option is to download a complete or partial set of records in Excel, CSV or JSON format from the LEI Search tool. 1.5 What is a CDF-formatted data file? The GLEIF CDF file downloads are not a database and so there is no documentation detailing tables, relationships between tables or database validation rules. The GLEIF CDF file downloads and the LEI CDF formats are also not intended as database design guidance, though they could be used to inform such a process 1.6 What is a CDF-formatted data file? LEl and RR data files, such as those produced by the LEI Issuers, or the GLEIF Concatenated Files, are text files containing LEI data and relationship records, structured using XML. They cannot be directly opened with a spreadsheet or database application, e.g., Excel or Access, although data in these formats is available through GLEIF’s LEI Search tool, available at www.gleif.org. Common Data File Formats — Questions and Answers Page 6 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
The XML files can be viewed with any simple text editor, but for large numbers of LEI records this is impractical, and a specialized tool is needed. GLEIF does not provide tool support; instead, we recommend consulting your IT team for any complex tasks.
The XML format defines a container that holds a file header and a series of data records.
1.7 How does GLEIF process the CDF data it receives?
GLEIF receives one daily data file per format, per LEI Issuer (also known as a Local Operating Unit or
LOU), directly from the LEI Issuer.
If an invalid LEl Issuer file is found, i.e., one that does not meet technical validation criteria against
the relevant Common Data File (CDF) format, then the most recent valid data file from that LEI Issuer
is substituted for it in that day's Concatenated File.
However, information about the original LEI Issuer file will still be available, even if the file is not CDF
valid.
1.8 How do the CDF formats handle international languages and
scripts?
An LEI data record can contain:
e Other names or representations of names for the legal entity.
o Alegal or headquarters address in different languages.
The OtherEntityName and OtherAddress fields, may have xml:lang language codes:
o FEach OtherEntityName elementincludes an optional language code, permitting OtherEntityName to be repeated as many times as necessary to express the same name type in multiple languages.
- When the type attribute’s value begins with PREFERRED ASCIT TRANSLITERATED LEGAL or AUTO ASCII TRANSLITERATED LEGAL, thelanguage codeinits xml:lang attribute specifies the language of the name prior to transliteration.
For transliterated name and address elements, the value of the free text fields must consist only of
non-control characters drawn from the “invariant subset” of ISO 646 (ASCII).
Relationship records can also contain some free-text fields which are handled in a similar way.
Common Data File Formats — Questions and Answers Page 7 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
1.9 Which special characters, string lengths and character encoding can be expected when working with LEI-CDF formatted data? Any UTF-8 character can be found in an LEI data file. Most free-text fields are limited to a maximum of 500 characters. For full technical details please refer to the LEI-CDF XML schema available at www.gleif.org. Common Data File Formats — Questions and Answers Page 8 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
2 LEI-CDF Topics 2.1 What is an LEIl data file? LEI data files are compliant with the latest LEI-CDF format. They normally contain a full set of LEI records; either o All LEIs managed by one LEl Issuer, or o All LEIs globally, as compiled by GLEIF from the LEI Issuer files. Each LEI data file contains a mandatory header with file information, and zero or more LEl records as follows. 2.2 What information is found in the LEI data file header? The header contains the file upload information for an LEI data file. The GLEIF Concatenated File header contains additional Extension fields supplying information on the LEI Issuers that supplied the LEI data records the file contains. 2.3 What are LEI data records? An LEI data record contains all LEI reference data for one legal entity including the essential minimum reference data needed to tell one legal entity apart from another, supplemental information, and details of the LEI's registration with the LEI Issuer who manages the legal entity’s LEI registration. Through the LEI code, they can be referred to relationships between legal entities, reported using the RR-CDF format. 2.4 What is the structure of the LEI-CDF? Please see the tables below for an overview of the LEI-CDF elements. Some “Type” column values refer to later tables; these refer to data elements that are contained within the referring element. Further details can be found in the LEIl Common Data File Format specification PDF document and corresponding XML Schema Definition (XSD) available at www.gleif.org. Common Data File Formats — Questions and Answers Page 9 of 35 @ Public Version 2.4 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22
2.4.1 LEIHeaderType
ContentDate lei:LEIDateTimeProfile {1,1} The date and time as of which the data contained in the file is valid.
Originator lei:LEIType {0,1} The LEI of the entity that created the content of this file.
FileContent lei:FileContentEnum {1,1} A code describing the content of this LEI data file.
DeltaStart lei:LEIDateTimeProfile {0,1} The date and time of the baseline relative to which this file contains new or changed LEI data records.
RecordCount xs:nonNegativelnteger {1,1} The number of LEI data records in the file. Can be a positive whole (integer) number, or zero (0).
NextVersion lei:HeaderNextVersionType {0,1} A structure for adding further elements into 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.
Extension lei:ExtensionType {0,1} This lei:Extension element may contain any additional elements required to extend the LEIHeader.