Think of Level 2 Data as of “parenthood” data, that provides an answer to “Who owns Whom” question. However, it must be clear that the definition of the parenthood adopted by LEI ROC is strictly based on the accounting definition of the relationships.
For any given entity, the Level 2 information describes its ‘direct accounting consolidating parent’ and its ‘ultimate accounting consolidating parent’. Please note that the classical notion of “ownership” is not used in Level 2 Data. Instead, the “direct accounting consolidating parent” of a legal entity is defined as the lowest level legal entity that prepares consolidated financial statements that consolidate the entity in question. Similarly, the “ultimate accounting consolidating parent” of a legal entity is the highest level legal entity preparing consolidated financial statements that consolidate the entity in question. Both parents are based on the existing accounting definitions of consolidation applying to a given parent.
The reasons for such seemingly counter-intuitive definitions lie in the fundamental difficulty of precisely defining and verifying (by the registering authority) parenthood information that is not grounded in well-established accounting standards. LEI ROC is aware that the definition is not an exhaustive representation of “Who owns Whom” types of relations, yet at the beginning of the Global LEI System’s implementation, it is the only definition that could be implemented without imposing high costs on LEI issuers. As the LEI System advances into the future, we can expect more refined definitions of a relation: “Eventually, organizational relationships may be described in the GLEIS at a granular level that would allow users with different purposes to obtain the exact types of organizational information relevant for their purposes. Such an approach has long-run appeal, but raises the possibility of significant costs and complexity at the start. For that reason, the ROC is determined to initiate the collection of relationship data by focusing on direct and ultimate parents, based on existing accounting definitions” [1].
LEI ROC has also recommended the approach of reporting information about entity parents by the ‘child’. This decision was motivated by the anticipated difficulties related to reporting by the parents, e.g. if the parent entity does not yet possess and LEI.
The project to build Level 2 Data started in May of 2017, so currently only a small subset of legal entities identified within the LEI system have information about their parents. The process of adding in the information for already issued LEIs is executed following the annual renewal; so it is expected that by the end of the first term of 2018, all LEIs should have their associated parental information.
There is another important policy that initially limits the number of entities which will have parental information published: when the information about the parent is present but the parent entity does not yet have an LEI, such information is not published until that parent obtains their LEI number. This policy is motivated by the resolve to provide high-quality data and the reputation of the Global LEI System.
[1] “Collecting data on direct and ultimate parents of legal entities in the Global LEI System – Phase 1”
Level 2 Data Model
For the representation of “Who owns Whom” information, a new data model and corresponding data format have been used. The Level 2 data model is not an extension of the model used for Level 1 (“Who is Who”). Instead, a new model has been proposed that reflects the nature of relations existing in the business world, as seen from the accounting standards perspective. This model has three fundamental purposes:
- To identify the legal entities involved in a relationship.
- To specify the type and other aspects of the relationship.
- To expose the validation and reporting information obtained by the LEI-issuing organization responsible for the creation and management of the relationship record.
The reality that the model attempts to reflect can be illustrated in the following diagram:
The relations are encoded by each set of relationship records. Each record specifies the StartNode of the Relation and the EndNode of the Relation. According to the “reporting by a child” rule, the StartNode is the entity that is a “child” in that relation and the EndNode is the “parent” in the relation.
The identification of both the StartNode and the EndNode in the data model are identified by the NodeID (with a corresponding NodeIDType). While the specification allows for the LEI code to be used as both the NodeID and other identifiers compatible with the ISO 17442 standard [1], it is currently assumed that relations that do not have LEIs for the parent are not published (in accordance with the aforementioned policy).
Moreover, the data model is extensible, as there remains a possibility to express (using the Relationship Qualifier) various forms of relations – in the current version of the date there is only “ACCOUNTING STANDARD” assumed for the ‘dimension’ of the qualifier. There is also the possibility to specify the Category of the qualifiers (IFRS and US_GAAP being used today).
[1] ISO_17442_COMPATIBLE (see page 40 of “Relationship Record Common Data File format V1.1”)
Level 2 Data Format
The Data Format that implements the Data Model for relationships, called RR-CDF (Relationship Record Common Data Format) was first announced on November 16th 2016, as a 1.0 version for information only. The current format, RR-CDF version 1.1 was published in May 2017, along with the first RR-CDF concatenated files becoming available. Alongside the format described in the documentation [1] and XML Schema [2], GLEIF published an important document describing the transition and validation rules for the RR-CDF Format [3].
[1] “Relationship Record Common Data File (RR-CDF) Format (Version 1.1)”
[2] “XSD Schema for Relationship record”
[3] “State Transition Rules for the Relationship Record Common Data File Format (Including Validation Rules)”
The RR-CDF format version 1.1 is the current and most up-to-date file format for the encoding of relationship records. It can be visualized in the following form:
In the following example you can see the relationship XML record in the RR-CDF Data File Format 1.1. This example shows that the company “Bloomberg Finance L.P.” (http://lei.info/5493001KJTIIGC8Y1R12) is “directly consolidated” (is a child in the accounting sense) of the company “Bloomberg L.P.” (http://lei.info/549300B56MD0ZC402L06):
<?xml version="1.0" encoding="UTF-8"?> <rr:RelationshipRecord> <rr:Relationship> <rr:StartNode> <rr:NodeID>5493001KJTIIGC8Y1R12</rr:NodeID> <rr:NodeIDType>LEI</rr:NodeIDType> </rr:StartNode> <rr:EndNode> <rr:NodeID>549300B56MD0ZC402L06</rr:NodeID> <rr:NodeIDType>LEI</rr:NodeIDType> </rr:EndNode> <rr:RelationshipType>IS_DIRECTLY_CONSOLIDATED_BY</rr:RelationshipType> <rr:RelationshipPeriods> <rr:RelationshipPeriod> <rr:StartDate>2007-01-01T00:00:00.000Z</rr:StartDate> <rr:PeriodType>RELATIONSHIP_PERIOD</rr:PeriodType> </rr:RelationshipPeriod> </rr:RelationshipPeriods> <rr:RelationshipStatus>ACTIVE</rr:RelationshipStatus> <rr:RelationshipQualifiers> <rr:RelationshipQualifier> <rr:QualifierDimension>ACCOUNTING_STANDARD</rr:QualifierDimension> <rr:QualifierCategory>US_GAAP</rr:QualifierCategory> </rr:RelationshipQualifier> </rr:RelationshipQualifiers> </rr:Relationship> <rr:Registration> <rr:InitialRegistrationDate>2017-05-17T15:44:28.472Z</rr:InitialRegistrationDate> <rr:LastUpdateDate>2017-05-17T15:44:28.472Z</rr:LastUpdateDate> <rr:RegistrationStatus>PUBLISHED</rr:RegistrationStatus> <rr:NextRenewalDate>2017-10-13T22:30:37.371Z</rr:NextRenewalDate> <rr:ManagingLOU>5493001KJTIIGC8Y1R12</rr:ManagingLOU> <rr:ValidationSources>ENTITY_SUPPLIED_ONLY</rr:ValidationSources> <rr:ValidationDocuments>OTHER_OFFICIAL_DOCUMENTS</rr:ValidationDocuments> </rr:Registration> </rr:RelationshipRecord>
There is also another record showing that the entity is also “ultimately consolidated” by the same parent.
It is interesting to note that GLEIF has used the Extension element of the file Header to specify the sources of the information currently available. So, in the currently available concatenated RR-CDF files we can see the information about the Relationship Record “originators” (the LEI issuers) with the counts of the RR records they provided:
(...)
<gleif:Source>
<gleif:ContentDate>2017-10-13T22:30:00.000+02:00</gleif:ContentDate>
<gleif:Originator>969500Q2MA9VBQ8BG884</gleif:Originator>
<gleif:RecordCount>407</gleif:RecordCount>
</gleif:Source>
<gleif:Source>
<gleif:ContentDate>2017-10-14T23:59:59Z</gleif:ContentDate>
<gleif:Originator>9884008RRMX1X5HV6625</gleif:Originator>
<gleif:RecordCount>11</gleif:RecordCount>
</gleif:Source>
<gleif:Source>
<gleif:ContentDate>2017-10-14T02:32:15.362Z</gleif:ContentDate>
<gleif:Originator>EVK05KS7XY1DEII3R011</gleif:Originator>
<gleif:RecordCount>19118</gleif:RecordCount>
</gleif:Source>
</gleif:Sources>
(...)
Level 2 Reporting Exceptions
In the realm of the accounting definition for parenthood, it must be assumed that there will be many cases when a parenthood cannot be properly reported. Following the LEI ROC recommendations, the documentation of the Level 2 Exception Format allows for limited lists of exceptions, resulting from an entity that has declined to report its parenthood information:
- There is no parent that meets the requirements of the accounting definition of parenthood. This includes cases of the entity being controlled by natural persons, its parents not preparing consolidated statements, or when the entity has diversified shareholdings (e.g. in the case of public companies)
- There are legal or regulatory restrictions prohibiting the entity to report information about its parents.
- The disclosure of the parenthood information could be detrimental to the entity or the parent.
Currently, the information about a parent is also not reported in the case of when it does not have an LEI identifier.
These exceptions, expressed in the Level 2 Exception Format, map out the nine acceptable reasons[1].
[1] The “Reporting Exceptions Format V1.1” contains the following enumeration that defines the reasons: NO_LEI, NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON, LEGAL_OBSTACLES, CONSENT_NOT_OBTAINED, BINDING_LEGAL_COMMITMENTS, DETRIMENT_NOT_EXCLUDED, DISCLOSURE_DETRIMENTAL
The following example illustrates the structure of the Level 2 Exception Format:
<?xml version='1.0' encoding='UTF-8'?>
<repex:ReportingExceptionData xmlns:gleif="http://www.gleif.org/concatenated-file/header-extension/2.0" xmlns:repex="http://www.gleif.org/data/schema/repex/2016">
(...)
<repex:ReportingExceptions>
<repex:Exception>
<repex:LEI>213800LJ8A7JKEBMAF74</repex:LEI>
<repex:ExceptionCategory>ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>NO_KNOWN_PERSON</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>213800Z6C3293M8HD766</repex:LEI>
<repex:ExceptionCategory>DIRECT_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>NON_CONSOLIDATING</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>213800Z6C3293M8HD766</repex:LEI>
<repex:ExceptionCategory>ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>NON_CONSOLIDATING</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>2138004VOKEQWSNH9U53</repex:LEI>
<repex:ExceptionCategory>DIRECT_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>BINDING_LEGAL_COMMITMENTS</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>2138004VOKEQWSNH9U53</repex:LEI>
<repex:ExceptionCategory>ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>BINDING_LEGAL_COMMITMENTS</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>213800XJMQ3PQ54P5C17</repex:LEI>
<repex:ExceptionCategory>ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>BINDING_LEGAL_COMMITMENTS</repex:ExceptionReason>
</repex:Exception>
<repex:Exception>
<repex:LEI>213800XJMQ3PQ54P5C17</repex:LEI>
<repex:ExceptionCategory>DIRECT_ACCOUNTING_CONSOLIDATION_PARENT</repex:ExceptionCategory>
<repex:ExceptionReason>BINDING_LEGAL_COMMITMENTS</repex:ExceptionReason>
</repex:Exception>
(...)
</repex:ReportingExceptions>
</repex:ReportingExceptionData>
As for February 10, 2018 there were about 113,000 records in the Relationship Record files and about 1,368,000 exceptions being reported in the Level 2 Exception files.The fact that valid relationship records form only a small fraction of all Level 2 records reflects both the initial stage of LEI Level 2 data handling and the inherent difficulties in the precise reporting of parenthood relations.
