RR-CDF Version 2.1

Documentation last updated: 2021-03-04

Introduction


This XML schema defines a reporting format for relationship records for Global Legal Entity Identifier System (GLEIS) Local Operating Units (LOUs) to report relationships between two legal entities (one relationship per relationship record).
Types of relationship supported:
  • LEI to LEI relationships.
  • LEI to (GLEIS-internal) Provisional Node Identifier (PNI) for reporting parent entities which do not yet have an LEI.

    • 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 the policy document published by the LEI ROC entitled "Collecting data on direct and ultimate parents of legal entities in the Global LEI System – Phase 1” (10 March 2016; available from www.leiroc.org).

    Terminology and Typographical Conventions

    Within this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in Annex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:
    • SHALL (NOT): Requirement
    • MAY: Permission / Possibility
    When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface, they are intended to have their ordinary English meaning.

    The following typographical conventions are used throughout the document:
    • ALL CAPS type is used for the special terms enumerated above.
    • Monospace type is used to denote programming language, UML, and XML identifiers, as well as for the text of XML documents.

    Cardinalities

    • The cardinality of each element (the number of times it SHALL or MAY appear in an XML data file conforming to this schema) is expressed as a number range in the format {minimum occurrences, maximum occurrences} in the XML examples shown below the notes of its containing element. This notation is equivalent to the following explanations in words:
      • Mandatory, unique: {1,1} - the element SHALL appear, exactly once.
      • Mandatory, repeatable: {1,unbounded} - the element SHALL appear at least once. It may be repeated any number of times.
      • Optional, unique: {0,1} - the element MAY be omitted; it MAY appear once at most.
      • Optional, repeatable: {0,unbounded} - the element MAY be omitted. It MAY be repeated any number of times.
    Please note:
    • The default cardinality is {1,1} (mandatory, unique). This document highlights when an element differs from this either by its minOccurs (minimum occurrences) or maxOccurs (maximum occurrences) value, or both.
    • XML cardinalities apply in the context of any containing elements. This means that a contained element may have a cardinality of one or more even if its containing element may be omitted, because the contained element is mandatory given the presence of the container.
    • XML cardinalities enforce a minimum data quality and standards conformance. Other business rules (as explained below) and data quality checks applied by GLEIF may encourage stricter cardinalities in live implementations.

    Business Rules

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

    XML Syntax

    This section specifies the XML schema for an Relationship 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/rr/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 is valid according to the following XSD 1.0 schema.

Release Notes

Version 2.1

  • New or changed enumerated values:
    • QualifierCategoryTypeEnum
      • Added GOVERNMENT_ACCOUNTING_STANDARD.

Version 2.0

  • New or changed enumerated values:
    • RelationshipType
      • Added IS_FUND-MANAGED_BY.
      • Added IS_SUBFUND_OF.
      • Added IS_FEEDER_TO.
    • RelationshipStatus
      • Added NULL.
  • Documentation notes:
    • Several definitions of elements, attributes or enumerations have been updated and aligned with the State Transition and Validation Rules.

Version 1.1

  • Corrections:
    • Corrected elementFormDefault="unqualified" to elementFormDefault="qualified".

Version 1.0

The first release.

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:
  • A Header.
  • Zero or more Relationship Records.

Relationship Data File Header

The Relationship Data File Header describes the context for the Relationship 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 Relationship Record; each Relationship Record is self-contained.

Relationship Record

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

Relationship

The Relationship container element identifies the two related entities and their relationship.
Related Entities
The ISO 17442-compliant identifiers of the legal entities related by this Relationship Record.
Relationship Attributes
Attributes describing the dates, type, qualitative and quantitative aspects of the relationship itself, as required. The data is supplied by the legal entity, and recorded and published by the LOU.

Registration

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

Extension

The optional Extension section of a Relationship Record may be used to include additional data not defined in this standard. This may include data specific to an LOU, data specific to a publisher of LEI data, and so on.
For example, an LOU may use Extension to publish additional data elements it collects as part of registration.
The following rules SHALL be observed:
  • Each XML element included in the content of the Extension element SHALL be in an XML namespace that is not null and not equal to the XML namespace of the Relationship Data File as specified in this standard.
  • The XML namespace for an Extension element SHALL be a namespace which the creator of the extension element exclusively or jointly controls, or from which the creator re-uses existing elements and their definitions, e.g. a namespace derived from the Internet Domain Name of the creator, a namespace agreed upon by a group of trading partners, etc.
  • An Extension element SHALL NOT be defined in such a way as to require the recipient of the file to recognize the Extension element in order to interpret the data elements specified in this standard. A recipient of the file SHALL be able to ignore all Extension elements and still interpret the standard content correctly.
  • A recipient of a data file conforming to this standard SHALL NOT reject a file solely because it contains extensions not understood by the recipient. A recipient SHALL be prepared to accept a file containing extensions and ignore any it does not understand, provided that the file complies to this standard.
 Contains the file structure for the whole relationship records file as specified in the XML datatypes below. Contains the file upload information for this RelationshipData file. Container for all of the RelationshipRecord container 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 relationship record file. The date and time of the baseline relative to which this file contains new or changed Relationship Records. The number of relationship records in this 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 Extension element may contain any additional elements required to extend the Header container element. 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 relationship records created for internal use by an LOU (all internal relationship records for which the LOU is the ManagingLOU) as of the date/time the file is created. The file contains those relationship records created by an LOU for internal use (all internal relationship records for which the LOU is the ManagingLOU) which are new or changed since the DeltaStart specified in the Header, as of the date/time the file is created. The file contains all relationship records published by an LOU (all relationship records for which the LOU is the ManagingLOU) as of the date/time the file is created. The file contains those relationship records published by an LOU (all relationship records for which the LOU is the ManagingLOU) which are new or changed since the DeltaStart specified in the Header, as of the date/time the file is created The file contains all relationship records GLEIF manages internally to the GLEIS (including all internal relationship records from all LOUs) as of the date/time the file is created. The file contains those relationship records GLEIF manages internally to the GLEIS (including all internal relationship records from all LOUs) 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 relationship records published by GLEIF (including all relationship records from all LOUs) as of the date/time the file is created. The file contains those relationship records published by GLEIF (including all relationship records from all LOUs) 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 records matching criteria specified in a query. 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. 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. The Registration container element contains information specifying the LOU's administration of the relationship report. 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. This Extension element may contain any additional elements required to extend the RelationshipRecord. An LEI or ISO 17442-compatible ID for the entity at the "start" of a directional relationship. An LEI or ISO 17442-compatible ID for the entity at the "end" of a directional relationship. A unique code designating the specific category of a directional relationship between two legal entities. 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. The status of the legal entities' relationship itself: ACTIVE, INACTIVE or NULL. Any additional qualitative attributes that help to categorize the relationship. Any additional quantitative attributes that help to categorize the relationship. 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. This Extension element may contain any additional elements required to extend the Relationship container element. The identifier for the entity designated by this node. The type of identifier used to designate this node's entity. An LEI code taken from the LEI issuing prefix namespace of a GLEIS LOU. An ISO 17442-compatible code, not taken from the LEI issuing prefix namespace of a GLEIS LOU. StartNode is directly consolidated by EndNode. The StartNode "child" entity has its accounts fully consolidated by the EndNode "parent" entity, in the sense given by the accounting standard(s) specified in RelationshipQualifiers; the EndNode entity is the closest fully consolidating parent to the StartNode entity in any applicable hierarchical ownership structure. StartNode is ultimately consolidated by EndNode. The StartNode "child" entity has its accounts fully consolidated by the EndNode "parent" entity, in the sense given by the accounting standard(s) specified in RelationshipQualifiers; the EndNode entity is the most distant fully consolidating parent from the StartNode entity in any applicable hierarchical ownership structure. StartNode is an international branch of the legal entity designated by EndNode (in jurisdiction country of StartNode). The EndNode is the Head Office and SHALL be an LEI. StartNode is a fund managed by a main management entity. The EndNode is legally responsible for the constitution and operation of the fund. StartNode is a sub-fund to an umbrella fund. The EndNode is a legal entity with one or more than one sub-funds/compartments where each sub-fund/compartment has its own investment objectives, separate investment policies and strategies, segregation of assets, separate investors and which has segregated liability between sub-funds/compartments. StartNode is a Feeder Fund, that is (almost) exclusively invested in a single other fund. The EndNode is the Master Fund that has identical investment strategies. 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.
 The start date for a particular period relevant to the relationship. The end date for a particular period relevant to the relationship. 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. The dates in this instance of RelationshipPeriod indicate the accounting period covered by the most recent validation documents for this relationship. The dates in this instance of RelationshipPeriod indicate the duration of validity of the relationship itself, as distinct from any administrative or reporting aspects. The dates in this instance of RelationshipPeriod indicate the validity period of a regulatory filing, accounting document, or other document demonstrating the relationship's validity. As of the last report or update, the reporting legal entity reported that it is legally registered and/or operating, AND that the relationship detailed in this RelationshipRecord is still valid. It has been determined that the relationship ended, e.g. because entity that reported this relationship is no longer legally registered and/or operating; or the relationship is no longer valid for other reasons. The relationship status is not applicable. Container for all sets of relationship qualifier information. Designates the optional list of additional qualitative attributes that help to categorize the relationship. Specifies the additional qualitative attributes that help to categorize the relationship. The accounting standard applied to determine the definition of e.g. ultimate or direct accounting consolidating parent for the relationship detailed in this RelationshipRecord. The relevant accounting standard is that applicable to the EndNode (the "parent" entity). United States-Generally Accepted Accounting Principles. International Financial Reporting Standard (developed by the International Accounting Standards Board – IASB see http://www.ifrs.org). A financial reporting (accounting) standard not otherwise listed in the latest version of the relationship data file format. Used for entities consolidated under the International Public Sector Accounting Standard (IPSAS 35) or National Government or Federal Government accounting standards specifically developed for Government entities in their state or local jurisdiction. Specifies one additional quantitative attribute of the relationship, according to a particular measurement method. Specifies the method of measurement (or set of rules) used to quantitatively categorize the relationship. 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. ,). Specifies the units, where applicable, of a measurement made on a relationship. Accounting consolidation holds when "[in the] financial statements of a group [...] the assets, liabilities, equity, income, expenses and cash flows of the parent and its subsidiaries are presented as those of a single economic entity (please see http://www.iasplus.com/en/standards/ias/ias27-2011). The date at which the relationship information was first collected by the ManagingLOU. The date at which the information was most recently updated by the ManagingLOU. The status of the legal entity's relationship record registration with the ManagingLOU. The next date by which the relationship information SHALL be renewed and re-certified by the legal entity. The LEI of the LOU that is responsible for administering this relationship record. Level of relationship validation. Type of source document(s) used for validating the relationship. A reference to a specific document or other source used as the basis of relationship validation for this relationship record. 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. This Extension element may contain any additional elements required to extend the Registration container element. A relationship data report that has been submitted to the LOU and which is being processed and validated, prior to publication. A relationship data report that has been validated and published, and which is reported by an entity that was an operating legal entity as of the last update. A relationship data report that has been determined to be a duplicate registration of the same relationship. In many cases this will mean more than one report with e.g. the same 2 entity IDs, the same relationship type, certain status values and the same relationship date(s), but this determination will depend on the relationship type in question. A relationship data report that has not been renewed by the NextRenewalDate. The relationship is considered to have ended, but the relationship report is kept in publication for historical audit trail purposes. A relationship data report that was marked as erroneous or invalid after it was published. The relationship report is kept in publication for historical audit trail purposes only (so that data recipients can correct their local data). A relationship data report that has been transferred to a different LOU as the ManagingLOU. A record in this state is not published, but may be used internally by the prior LOU for audit trail purposes. A relationship data report for which a transfer to another LOU has been requested. The request is being processed at the sending LOU. When the receiving LOU is ready, the status will be changed to PENDING_ARCHIVAL by the sending LOU prior to completion of the transfer. This relationship data report is about to be transferred to a different LOU, after which its registration status will revert to a non-pending status. The PENDING_ARCHIVAL status serves to inform recipients of LOU-provided data files that a relationship record will be removed from that LOU’s published file after the transfer is complete A consolidated financial (accounting) statement, prepared and submitted to the relevant authority. A regulatory filing providing public information on legal entities and/or their relationships. Other documents supporting the validation of legal entities and/or their relationships. Contract(s) attesting to the validity of legal entities and/or their relationships. Other official document(s) attesting to the validity of legal entities and/or their relationships. The validation of the relationship data provided by the registrant has not yet occurred. Records with this ValidationSources value SHALL NOT be published. 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 submitter can be partially corroborated by supporting sources (e.g. financial statements with other definitions of the relevant relationship type; quarterly or annual regulatory filings, contracts and other documents used in preparing financial statements). The relationship data provided by the registrant has been validated against an explicit relationship statement found in key sources (e.g. consolidated financial statements).
  • Elements of base data type rr:LEIDateTimeProfile use this datatype to 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 SHALL 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) SHALL 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).