Reporting Exceptions Format Version 2.1

Documentation last updated: 2021-07-20

Introduction

Following the LEI-ROC policy document, "Collecting data on direct and ultimate parents of legal entities in the Global LEI System - Phase 1" (10 March 2016), the Global Legal Identifier System (GLEIS) requires that legal entities with an LEI provide information on their ultimate and direct accounting consolidating parents.

Audience for this document

The target audience for this standard includes:

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 the LEI ROC's published document entitled "LEI ROC Report on collecting data on direct and ultimate parents of legal entities in the Global LEI System" (10 March 2016; available from www.leiroc.org).

Terminology and Typographical Conventions

The following typographical conventions are used throughout the document:

Cardinalities

Please note:

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.

Release Notes

Version 2.1

  • New enumerated values:
  • Deprecated enumerated values:
  • Version 1.1

    Version 1.0

    The first release.

    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:

    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.

    XML Syntax

    This section specifies the XML schema for an LEI data file conforming to this standard.

    XML Design Rules

    XML Schema

    An XML file conforming to this standard SHALL be valid according to the following XSD 1.0 schema.

    Extension

    The optional Extension section of an Reporting Exception Item 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:

    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: