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.
- Relationship reporting according to the Relationship Record Common Data File
(RR-CDF) format V1.0 is mandatory. The only opt-out reasons allowed are taken
from the LEI-ROC policy document, pages 16-17. A further general exception
case, also based on the LEI-ROC policy document (p. 18) is also provided to
cover situations where the opt-out reasons may not be precisely applicable:
- No LEI - "the parent does not consent to have an LEI" (LEI-ROC policy,
p. 18).
- This format provides a simple record structure linking, per
record:
- One LEI from the LOU's current LEI data file;
- One relationship type (reporting category) that must be reported;
- One reason for declining to report that relationship type for the legal
entity referenced by this LEI, plus an optional reference e.g. to a legal or
regulatory provision.
All LOUs use this file format to record and submit Reporting Exceptions to
GLEIF.
Audience for this document
The target audience for this standard includes:
- All Local Operating Units (as well as candidate LOUs) of the GLEIS
- All users or potential users of LEI data
- All financial regulators who consume LEI data
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:
- 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 MUST 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 MUST appear, exactly
once.
- Mandatory, repeatable:
{1,unbounded}
- the element MUST appear
at least once. It may be repeated any number of times.
- Optional, unique:
{0,1}
- the element NEED NOT appear; it MAY
appear once at most.
- Optional, repeatable:
{0,unbounded}
- the element NEED NOT
appear. 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.
Release Notes
Version 2.1
New enumerated values:
Deprecated enumerated values:
-
ExceptionReasonEnum
- Deprecated
LEGAL_OBSTACLES
.
- Deprecated
CONSENT_NOT_OBTAINED
.
- Deprecated
BINDING_LEGAL_COMMITMENTS
.
- Deprecated
DETRIMENT_NOT_EXCLUDED
.
- Deprecated
DISCLOSURE_DETRIMENTAL
.
Version 1.1
- Corrections:
-
Extension element in Header corrected to minOccurs="0".
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:
- The initial XSD declaration for a NextVersion element SHALL use the element name
"NextVersion", XML data type "lei:NextVersion1Type" and cardinality optional,
unique {0,1}. The XML data type allows a sequence of any elements, each of
cardinality optional, repeatable (unbounded) and with lax content processing,
but in the target namespace.
- The minOccurs declaration on the NextVersion element allows it to be omitted in
files conforming to the first minor version. The schema wildcard xsd:any allows
for forward compatibility: a file conforming to a new minor version still
validates in the old version because the wildcard matches any new elements
introduced in the new minor version.
- New elements SHALL be introduced in a subsequent minor version by modifying the
declaration for the above type declaration as follows:
- A sequence of the new elements introduced in the previous version
- A subsequent NextVersionN element where N is an index number starting at
1 and incremented by 1 with each minor version
- Each new element SHALL be declared minOccurs=�0�, to ensure backward
compatibility: a file conforming to the old version still validates in the
new version because the new schema does not require the presence of elements
not defined in the old version. If a new element is mandatory for
conformance to the new version, this MUST be enforced outside schema
validation.
- The new definition of the NextVersion element SHALL include a declaration of
an inner NextVersion element, as illustrated above, to provide for
additional elements in subsequent minor versions. The nesting of NextVersion
elements is required to satisfy the �unique particle attribution� constraint
of XSD 1.0.
- Each code list (Enum types) is implemented in the XML schema simply as the
XSD string data type. This provides for forward compatibility because the
schema for an older minor version will validate any string, including codes
defined in newer minor versions. The schema for each minor version includes
the list of valid codes for that minor version as a documentation annotation
to the type declaration for each Enum type.
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
- The XSD schema conforms to W3C's XML Schema specification, version 1.0.
- The XML namespace is "http://www.gleif.org/data/schema/repex/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 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:
- 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 LEI
Data File as specified in this standard.
- The XML namespace for an extension element SHALL be a namespace to which the
creator of the extension element is entitled to use; 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 MUST 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 MUST be prepared to accept a file containing extensions and ignore any
it does not understand, provided that the file complies to this standard.
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 Reporting Exception Items.