GLEIF mapping to BODS version 0.2 - data use guide

Last updated:  8th August 2024

Issues with or suggestions for improvements to this data transformation can be logged on the GitHub repository

Scope

Data includes GLEIF level 1 data and level 2 data.

Data starts from the 06/06/2024 GLEIF golden copy and is updated at intervals of 31 days using GLEIF delta files.

Change over time

replacesStatements is used to represent changes in the data. In this case, replacesStatements only references the most recent, outdated, statement for that entity, person or relationship.

e.g. if a statement 100 is replaced by statement 101, statement 101 will have replacesStatements: [“100”]. If statement 101 is then replaced with statement 102, statement 102 will have replacesStatements: [“101”] (even though it has now replaced statements 100 and 101.

Updated LEI record

When an LEI record is updated (not retired) a new entity statement is generated with an annotation including the updated status. replacesStatements lists the most recent entity statement for that entity.

If the LEI record being updated is a subject of any current ownershipOrControl (OOC) statements,  the ownershipOrControl statements themselves are also replaced with new statements, referencing the previous ownershipOrControl statementID in replacesStatements. The new OOC statement retains the statementDate of the previous statement.

In some cases, the LEI record and relationship record will be updated simultaneously. In this case, the new relationship record will have an updated statementDate.

Relationship ends

(Example record - https://search.gleif.org/#/record/549300CHB5Q2591H4S21 ULTIMATE_CONSOLIDATING_PARENT changes 2024-01-09)

When a new relationship is reported, ending the previous relationship, a new relationship statement is issued. The previous relationship statement is not referenced in the replacesStatements for the new relationship.

Relationship updated

A new ownershipOrControl statement is generated with replacesStatements referencing the most recent ownershipOrControl statement for that relationship.

Voiding of statements

Retired LEI record

When an LEI registration status is set to RETIRED a new voiding statement is generated with an annotation including the updated status. replacesStatements lists the most recent entity statement for that entity. The voiding statement does not include the identifiers array but the LEI is still referenced in the annotations

Relationship records associated with the LEI are not replaced or updated.

(Note - Where an LEI was already retired before April 202 it will be included in the data set as an entity statement and not voided. An annotation will list the LEI as being retired.)

Reporting Exception Ends

When a relationship or different reporting exception is reported, ending a reporting exception, any statements created due to the original reporting exception are voided by the creation of voiding statements with replacesStatements referencing the statement they are voiding.

Voiding statements for ownershipOrControl statements have "subject": {"describedByEntityStatement": ""} and "interestedParty": {"describedByEntityStatement": ""}

All voiding statements will have an annotation explaining the reason for voiding
“Statement retired due to change in a NON_PUBLIC GLEIF Reporting Exception for 549300DPXT2I07WEQM14”

Specific fields

Addresses

Headquarters addresses are listed with address.type “business” and Legal addresses are listed with address.type “registered”

Corroboration level

Where an LEI record is FULLY_CORROBORATED the tag “verified” is added to the source.type array in the associated entity record.

LEI records with Corroboration Levels PARTIALLY_CORROBORATED, PENDING and ENTITY_SUPPLIED_ONLY do not have a “verified” tag and are not distinguished from one another in the mapping.

Dates

statementDate is Last Updated Date for statements generated from LEI Records and Relationship Records.

statementDate is the date a file is produced for statements generated from a reporting exception, as reporting exceptions don’t include dates. As we are using monthly delta files, this will be the first day of the month.

publicationDate and annotations’ creationDate is the date the mapping was generated

Entity type

For entities with an LEI entityType is “registered”. For entities without an LEI (generated due to a reporting exception) entityType is “unknown”

Exceptions

Annotations in all types of statement include annotations when they are created due to a reporting exception.

"This statement was created due to a NATURAL_PERSONS GLEIF Reporting Exception for 815600AD7DBAE9628915"

Interests

All interests are listed with interest.type “otherInterestOrControl”, beneficialOwnershipOrControl “false” and interest.details referring to the GLEIF relationship type.

Person type

Person statements are only generated due to reporting exceptions and always have personType “unknownPerson”

Registration status

Annotations in entity statements where the entity has an LEI include the registrations status.

“GLEIF data for this entity - LEI: '81560060283ED69A8132; Registration Status: ISSUED”

Start node/ End node

Annotations in ownershipOrControl statements where the interestedParty has an LEI show which LEIs are being linked

"Describes GLEIF relationship: 549300P2OO0GKTSE4509 is subject, 549300OJKCH3ZGMOME81 is interested party"

Edge Cases

Last updated date

In a small minority of LEI records data is added to delta files but the “Last Updated Date” is not updated and remains the same as the previous update. Updates are only mapped when “Last Updated Date” is updated.

Liquidation in progress

Liquidations are not represented until the liquidation is complete