ISO/PRF 5116-3

Improving transparency in financial and business reporting -- Harmonization topics

Titre manque

General Information

• Status: Published
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• Technical Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Drafting Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 08-Jun-2021
• Completion Date: 08-Jun-2021

Standards Content (sample)

FINAL
INTERNATIONAL ISO/FDIS
DRAFT
STANDARD 5116-3
ISO/TC 68/SC 9
Improving transparency in
Secretariat: AFNOR
financial and business reporting —
Voting begins on:
2021-06-08 Harmonization topics —
Voting terminates on:
Part 3:
2021-08-03
Mapping between DPM and MDM
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/FDIS 5116-3:2021(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS. ISO 2021
---------------------- Page: 1 ----------------------
ISO/FDIS 5116-3:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2021

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may

be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting

on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address

below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/FDIS 5116-3:2021(E)
Contents Page

Foreword ........................................................................................................................................................................................................................................iv

Introduction ..................................................................................................................................................................................................................................v

1 Scope ................................................................................................................................................................................................................................. 1

2 Normative references ...................................................................................................................................................................................... 1

3 Terms and definitions ..................................................................................................................................................................................... 1

4 Introduction to the Multidimensional Data Model ........................................................................................................... 1

5 Preconditions on mapping ......................................................................................................................................................................... 2

5.1 Types of Database Management Sytems (DBMSs) ................................................................................................... 2

5.2 Fundamental choices ......................................................................................................................................................................... 3

5.3 Fact definitions: presentation vs DPM ................................................................................................................................ 5

5.4 Storing native XBRL facts ............................................................................................................................................................... 6

5.5 Dimension/defaultMember ......................................................................................................................................................... 7

5.6 Options ........................................................................................................................................................................................................... 8

5.7 Versioning.................................................................................................................................................................................................... 8

5.8 Changes on fact values...................................................................................................................................................................... 8

6 Definitions ................................................................................................................................................................................................................... 8

7 Mapping from Data Point Model to Multidimensional Data Model .................................................................9

7.1 General ........................................................................................................................................................................................................10

7.2 Framework ..............................................................................................................................................................................................11

7.3 Taxonomy .................................................................................................................................................................................................12

7.4 Dimensions ..............................................................................................................................................................................................14

7.5 Context ........................................................................................................................................................................................................19

7.6 Primary Items .......................................................................................................................................................................................21

7.7 Fact table or Data points ..............................................................................................................................................................23

7.8 Summary ...................................................................................................................................................................................................24

8 Metamodel defined by the EBA (FINREP and COREP) mapped to MDM ..................................................26

8.1 General ........................................................................................................................................................................................................26

8.2 Creation of the structure and load of the DPM from the EBA in a RDBMS .......................................27

8.3 Loading DPM_ROLAP from DPM_EBA ..............................................................................................................................27

9 Implementation of the DPM in the MDM using the design ROLAP ................................................................34

9.1 General ........................................................................................................................................................................................................34

9.2 Structure ROLAP .................................................................................................................................................................................34

9.3 Creation of the infrastructure through MS SQL Server .....................................................................................34

10 DPM of FINREP 2012 in the MDM using the design ROLAP ...................................................................................38

10.1 General ........................................................................................................................................................................................................38

10.2 DPM of FINREP 2012 ......................................................................................................................................................................39

11 DPM of the first prototype of Solvency II in the MDM using the design ROLAP ...............................47

11.1 General ........................................................................................................................................................................................................47

11.2 DPM of the prototype .....................................................................................................................................................................47

Bibliography .............................................................................................................................................................................................................................51

© ISO 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/FDIS 5116-3:2021(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards

bodies (ISO member bodies). The work of preparing International Standards is normally carried out

through ISO technical committees. Each member body interested in a subject for which a technical

committee has been established has the right to be represented on that committee. International

organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.

ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of

electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the

different types of ISO documents should be noted. This document was drafted in accordance with the

editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of

any patent rights identified during the development of the document will be in the Introduction and/or

on the ISO list of patent declarations received (see www .iso .org/ patents).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and

expressions related to conformity assessment, as well as information about ISO's adherence to the

World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/

iso/ foreword .html.

This document was prepared by the European Committee for Standardization (CEN) (as CWA

XBRL 005) and was adopted with the following modifications by Technical Committee ISO/TC 68,

Financial services, Subcommittee SC 9, Information exchange for financial services.

— Clause 2, Normative references, added;
— minor editorial changes.
A list of all parts in the ISO 5116 series can be found on the ISO website.

This document uses different verbal forms from those listed in the ISO/IEC Directives, Part 2.

Any feedback or questions on this document should be directed to the user’s national standards body. A

complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/FDIS 5116-3:2021(E)
Introduction
0.1 General

This document aims to provide an introduction to the topic of creating a conceptual model for storing

multidimensional data which is received as XBRL instances that follow the rules defined by European

taxonomies published by the European Banking Authority (EBA) or by the European Insurance and

Occupational Pensions Authority (EIOPA).

Disclaimer: The Multidimensional Data Model (MDM) presented in this document is intended to be a

starting point for a subsequent modelling process to be adjusted and extended to specific analytical

or transactional needs. It solely refers to the concepts of Data Point Model (DPM) and European XBRL

Taxonomy Architecture (EXTA), which build the basis of European supervisory reporting.

The structure of the data model is based on meta classes, introduced in part 1 and 4 of the CWA1

[26]

document . The data model represents a relational model using Relational Online Analytical

Processing (ROLAP). In this document UML data structures of a DPM are used because its comprehension

will be easier. With the UML class model representing the description of the European filing rules, this

document visualizes the mapping between UML meta classes and their correspondence in the form of

database tables in the MDM.

This document consists of eight sections, save the bibliography. Section one explains working with

a Multidimensional Data Model as a step towards working with the Relational Data Model. Section

two makes a study of the architecture of XBRL, the databases and their aims, requirements and

preconditions in catering for XBRL. Section three defines the conditions used for mapping from DPM to

MDM. Section four is detailing point by point the mapping. Section five shows the metamodel defined by

the European Banking Authority (EBA) through the FINREP (Financial Report) and COREP (Common

Solvency Report) taxonomies and its mapping into MDM. Section six displays the MDM implemented in

a relational database. Sections seven and eight show two implementation examples.

0.2 Objective

The objective of this sample MDM is to provide a starting point into the topic of mapping DPM and XBRL

instance structures into a multidimensional database. Based on an easily comprehensible example,

more complex issues are addressed that would need to be taken into account by defining an MDM for

production use.
0.3 Target audience

This document is aimed at users of European supervisory taxonomies that have the need to store

reporting data based on these data definitions and to retrieve them for analytical or transactional

purposes. Database experts should get detailed information about the specifics to be taken into account

when modelling multidimensional database structures for storing supervisory data based on XBRL.

Therefore, the audience of this document might be financial or economic institutions, agencies or

universities with the intention to provide micro or macro prudential analysis on supervisory data.

0.4 Relationship to other work

The reader of this document is expected to be familiar with the principles of data modelling, having

a thorough understanding of the concept of DPM as well as basic knowledge of XBRL. The reader is

also expected to have knowledge in creating conceptual models for relational and multidimensional

databases.
© ISO 2021 – All rights reserved v
---------------------- Page: 5 ----------------------
FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 5116-3:2021(E)
Improving transparency in financial and business
reporting — Harmonization topics —
Part 3:
Mapping between DPM and MDM
1 Scope

This document aims to provide an introduction to the topic of creating a conceptual model for storing

multidimensional data which is received as XBRL instances that follow the rules defined by European

taxonomies published by the European Banking Authority (EBA) or by the European Insurance and

Occupational Pensions Authority (EIOPA).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/

NOTE The terms and definitions used in the mapping with Data Point Model are inspired by vocabulary

already known from their use for describing multidimensional databases and Data Warehouses.

4 Introduction to the Multidimensional Data Model

The multidimensional database is primarily used to create OLAP (Online Analytical Process)

applications and their databases using a fact table and set of dimensions. A multidimensional structure

stores multidimensional data, that is to say, cubes. A cell or fact is an intersection consisting of elements

that form the dimension(s) which in turn form a cube. A cell can have zero or more measures, but in this

document only one measure is taken into account.

The Multidimensional Data Model (MDM) is used instead of the Relational Model, because the

European architecture of economic-financial reports is relying on dimensions heavily, which makes

implementation in MDM the logical choice. Moreover, the performance of queries is better in this type

of database.

The goal of this document is to store the Data Point Model in a database, in an efficient, easy way.

© ISO 2021 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/FDIS 5116-3:2021(E)
5 Preconditions on mapping
5.1 Types of Database Management Sytems (DBMSs)

In this section some types of DBMS's are analysed that appear suitable for storing DPM and XBRL

documents. Only those databases are considered where, in a previous study, it seemed possible to store

the DPM and to extend XML or XBRL documents.
Figure 1 — Different types of DBMS's
The typical solutions are (Figure 1):
― Hierarchical databases;
― Multidimensional databases;
― Relational databases;
― Mixtures, where, normally, the relational database is the base.

Hierarchical databases (e.g. Tamino by Software AG, GT.M, IBM Information Management System (IMS)),

which rely on the hierarchical model, that is to say, databases organized into a tree-like structure. In this

structure, data uses relationships among their leaves. Each leaf on a superior level has 0..* relationship

with leaves on the inferior level. A leaf on an inferior level only has a 0..1 relationship with a leaf on the

superior level.

Multidimensional databases, not being based on relational databases, have the data is stored in an

optimized multi-dimensional storage array, and not in a relational format. However, it is necessary

to organize the information in a cube beforehand. These databases have very fast response times in

queries. Examples of Multidimensional databases are: Essbase, icCube, Infor BI OLAP Server.

In relational databases the information is stored in relational format. But, moreover, in these databases

it is possible to store cubes, but in a relational format, changing their internal structures.

2 © ISO 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/FDIS 5116-3:2021(E)

In all these solutions, it is necessary to verify that database transactions are processed reliably. For

this, a database must fulfil ACID (Atomicity, Consistency, Isolation, and Durability) properties. Not all

databases fulfil the ACID requirements, this depends on the vendor. These properties are:

― Atomicity: each transaction is “all or nothing”;

― Consistency: it ensures that any transaction will bring the database from one valid state to another

valid state;

― Isolation: it ensures that the concurrent transactions result in a system state that would be obtained

if transactions were executed serially;

― Durability: once a transaction is committed, it will remain so even in the event of power loss, crashes,

or errors.

― This document will not analyse whether databases carry out the ACID properties. However,

the majority of commercial Relational Database Management Systems (RDBMS) achieve these

properties. These databases are very common in the Information Systems Departments of this

environment. Examples of these RDBMS's, are Oracle, DB2 or MS SQL Server, amongst others.

5.2 Fundamental choices

This section will discuss, if the XBRL document instance is stored directly in the database in part or in

a relational model.

There are two mainstream solutions for storing XBRL instances and their facts into a relational

database system. The question is, when Information Systems (IS) receive a XBRL taxonomy or an

instance document, how these XML documents can be stored with the lowest cost in resources in the

database. As relational databases can only store relational data and XML documents are not relational,

the mapping is not a direct process.
The topic to analyse is:
― Mapping the XBRL instance document to the relational model;
― Storing the XBRL instance document as a blob, or PDF document in the database;
― Storing the XBRL instance as a XML document or as a XBRL document.

Not all XML documents can be mapped into the relational model. However, XBRL instance documents

can be mapped to the relational database, as they show many references. The XBRL specification

contains a very important aspect: validation by formulae. Formulae are based on XPath 2.0 (XML

Path Language), which is based on XML. When the XBRL instance document is transformed into the

relational model, the instance document cannot be validated by formulae anymore. Moreover, as these

validations are based on the XBRL Formulae and Calculation specifications, the mapping to a RDBMS is

[19]

not easy nor immediate . As XBRL validation requires the use of XML enabled tools, this cannot be

done in the RDBMS. There are many validators, both commercial and open source (Openfiling) in XML.

On the other hand, the mapping of instance documents into a relational database is available through

different commercial or open source vendors (Openfiling).

An XBRL instance document can be stored in a relational database as an XML document or in a relational

format. Analysing the queries in both solutions resulted in:
― In XML, these queries use XQuery and XPath.

― The end user has difficulties accessing the language of the queries directly or through tools;

― The query language is very specific. Experts in this language are necessaries;
© ISO 2021 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/FDIS 5116-3:2021(E)
― The tuning of XML documents is complex.
― Relational Database use standard SQL.

― The end user can obtain the data in an easy way through spread sheets, linked tables or other

tools;
― The query language is a standard, and is part of university IT curricula;

― The performance and tuning of a relational database has been extensively analysed.

― If the XBRL instance document is stored directly in the database (as a blob), the problems are the

same but the RDBMS is an inferior level. Cases are:
― Storing as a photo (Blog or Clog);
― Storing as a XML document.

In the first case the database is only used as a storehouse. In the second case, storing as an XML

document, with functions embedded in the engine of the database. This means that the database

manager has embedded these functions in the engine. Today there are vendors that add the type XML

as Oracle, MS SQL Server or DB2. Depending on the vendors the main features are:
― Generating XML Instances;
― Methods or procedures on the XML data type;
― Queries on XML instances;
― Processing namespaces;
― Indexes;
― Navigation through the document;
― …

XBRL is an extension of XML, but it is not XML, the cost of implementation therefore has to be evaluated,

and the performance of the database must be re-tuned for optimization.

MS SQL Server has also utilities for working with XBRL that is necessary to analyse, in the same way.

Oracle 11g release 2 (as from version 11.2.0.3.0) works with XBRL instance documents Oracle 11g with

XBRL(https:// docs .oracle .com/ cd/ E20212 _01/ doc/ doc .11/ e17070/ intro .htm):

― Manages XBRL content;

― Can create multiple XBRL repositories and project XBRL data relationally or query it in various

ways;

― Operations of aggregated business and financial reports such as extraction, transformation, and

loading (ETL); business intelligence (BI); and online analytical processing (OLAP);

― The validation is outside to the database Out oracle (https:// www .xbrl .org/ xbrl -solutions -oracle).

Both the Microsoft and Oracle solutions have to be evaluated in terms of costs, resources, tuning and

performance in the engine of the database.

In summary; this document is not considering storing the XML document (instance) as a whole, as it

is storing the instance in a native XML database. Only storing the content of the XML document in a

RDBMS is discussed. One can either:
― Store almost native facts and their aspects, or
4 © ISO 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/FDIS 5116-3:2021(E)

― Convert the facts and the required aspects into a proprietary set of data before storage.

― For both scenarios all relevant aspects on the facts will need to be determined from the analyst

point of view.

Another consideration for the importance of aspects is to decide if the database will also be the

source to generate (the same or new) XBRL instances (more information on Openfiling). More XBRL-

specific requirements need to be considered to create a valid instance. When the target is to (re)create

instances, special consideration has to be given to any merge processes on fact values. Merged fact

values will cause problems for instance creation unless there is a possibility of an ‘undo’ (split) routine

or a structure more complex in the relational model. This can be created as easily as storing both the

original fact values and the merged value. However, different instances can coexist because, as it is

explained below, each fact is defined in a time period and it belongs to an entity.

Table 1 below shows a summary of the possible advantages and disadvantages of both methods.

Table 1 — Pros and cons of alternatives
Proposals Native store Convert before
store
Quantity of aspects to store (direct from instance) (+)(-) (+)(-)
Quantity of aspects to store (indirect from Discoverable Taxonomy (-) (+)
Set (DTS))
Speed of storage process (+) (-)
Maintenance (mapping table, mapping software) (+) (-)
Analyst queries, degree of difficulty (-) (+)
Analyst queries, speed (-) (+)
Easy handling of new DTS versions (+) (-)
Extensibility towards proprietary XBRL reports (+) (-)
Extensibility towards proprietary non-XBRL reports (-) (+)
5.3 Fact definitions: presentation vs DPM

XBRL Taxonomies created with DPM contain two definitions of individual reportable facts:

― Primaries, dimensions and members have readable labels and optional references to external

documentation;

― Tables, axes headers and table footers have generic (text) labels and indicators pointing towards an

'RC' (row-column) value that identifies a cell in the templates that form the basis of the DPM.

Since there is no guarantee that both definitions will match, a reported fact can rely on either definition.

It depends on whether the reporter used a form, based on the table linkbase, or a mapping based on

the primaries/dimensions/members combinations. From a theoretical point of view the templates are

transformed to DPM and then the DPM into XBRL concepts, i.e. the concepts are leading. This has not

been stated explicitly by EBA. In order to stay independent from EBA modelling it is best to store both

definitions as relevant aspects. The definition texts as such are the only means for a business analyst to

create a query and understand its outcome. Definitions that rely on documentation outside the DTS and

is referred to by XLink references, is only available for concepts, not on the presentation of the table.

Linking this information into the database (and query) is outside the scope of this document. In theory

such external reference pointers could be created on the presentation, EBA has however not used this

feature; it would be used in accordance with XBRL specifications.

When using the instance transformation option, the definitions have to be manually mapped to the

internal definitions. This only needs to be done once. The maintenance task is to check every new

release of the DTS for changes in definitions regardless where they are being used. Every change needs

to be re-evaluated and again manually mapped into the internal definitions. Analyst queries work with

© ISO 2021 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/FDIS 5116-3:2021(E)

internal definitions, their meaning should be clear to the users. Another point of consideration is that

there is no guarantee that what is dimensionally valid in the DTS will be presented as a cell in any table.

The other way around, what is in a table is always dimensionally valid, is guaranteed. There needs to

be a process to detect such anomalies, either upon loading a new version of the DTS or upon storage

of the facts. There may even be a need for a disclaimer that facts reported without a proper 'cell' in a

table are being disregarded. In this sense the table linkbase is forming a third validation mechanism of

reportable facts (XSD and XDT being the others).

Lastly the introduction by EBA of a new mechanism called 'filing indicators', needs to be thought

through. If instance creation from the database is in order, these XML nodes need to be stored too.

They are used to ea
...