Guidelines for Data Point Modeling

From XBRLWiki

(Difference between revisions)

Revision as of 05:22, 8 October 2013

Introduction

General

The purpose of this document is to support supervisory experts in the creation of a Data Point Model (DPM). By definition of the European Banking Authority (EBA) a DPM “is a structured formal representation of the data [...] identifying all the business concepts and its relations, as well as validation rules, oriented to all kind of implementers.”1 The underlying rules for the creation of such methods were initially introduced by the Eurofiling Initiative and developed further by the European Insurance and Occupational Pensions Authority (EIOPA). The main objective of data point modelling, the process of creating a DPM; “[it] should help to produce a better understanding of the legal background to the prudential reporting data and make data analysis much easier for both the institutions and regulators”2. Further goals are to prevent redundancies, lower maintenance efforts and, in general, to facilitate working with national extensions on the European agreed upon data set to facilitate the descriptions of requirements that are sharable across national legislations. It is a requirement to have all the information collected by the national supervisory agencies, particularly in Europe, transformed into the same data structure with the same quality in order to be able to carry out standardized analysis of the data across Europe. The current implementations are not able to meet these European requirements for supervision “to achieve higher quality and better comparability of data”3. The main reasons for this are the differences between the data definitions and the data formats of the various national supervisory agencies, making comparison of reported data virtually impossible.

Objective

The aim to harmonise the European supervisory reporting is to be able to carry out more comprehensive analysis and an increase of comparability of data. The supervisory agencies are already acquainted with the representation of regulations specified in laws, this document is going to introduce the reader to the concept of Data Point modelling methodology as well as to its main terms and definitions that will enable you to create Data Point Models that contain “all the relevant technical specifications necessary for developing an IT reporting format” on your own.

Target audience

In general you as banking supervisor are responsible to communicate with Information Technology (IT) experts in order to support the transfer of the essence of regulatory reporting to IT systems. In 2009 the Eurofiling Initiative has published the concept of Data Point modelling. Structures of data represented in supervisory tables as well as underlying laws and guidelines were defined in order to enable the interpretation of the reporting information by IT applications. IT specialists are responsible for the development of software, however most of the time they do not have the special business knowledge needed to gather reporting requirements from various sources such as legal texts like Solvency Regulations and National Banking Acts for building a faultless system. Therefore the task of creating a DPM is assigned to you. This document introduces basic principles deemed necessary in the modelling process. On the basis of the explanations given in this document you will be able to provide prerequisites for deriving data formats on the basis of a DPM as well as setting up a powerful data warehouse. This implies that the model is issued in a format that is understood by both parties, involved in transforming legislation into a model: business experts and IT specialists. The topics regarding supervisory reporting are kept short and limited to the content relevant for this paper. The idea is to convey the creation of the Data Point Model to you, as you are a supervisor with analytical capabilities and personal interest in this topic. No special IT knowledge is expected. The first sections will give you an overview on the required IT knowledge. National banking supervisors have a mandate to evaluate the financial situation of financial institutions in their country. To be able to perform the necessary analytics, financial data is required from these institutions. The requirements are described in the form of texts and tables of data. To make a comprehensive model from these texts and tables a model is being created to enable IT support in communicating and storing the necessary data. A common problem with the NSA's is that IT staff has little financial background and financial specialists have little IT background. This makes data modelling a problematic area as both specialities are needed. This document is aimed at providing the tools and knowledge of creating a DPM by the financial specialists. The result, a model, can later in the process be perfected by IT staff.

Scope

This paper is a handbook for supervising experts. The main body consists of four sections. The interrogative form helps in choosing which section promises most answers to your problem. After this first introductory section the main part starts to provide basic knowledge about different types of data models and data modelling approaches. The second and third section provide an overview of data models in general in contrast to the fourth section that highlights the necessity of data modelling for supervisory data. This fourth section derives the objectives based on the background information of the preceding sections. Furthermore one paragraph classifies the Data Point Model introduced by the Eurofiling Initiative and elaborated by EIOPA and EBA where many new terms related to DPM are introduced. A paragraph, which explains the areas of application for the DPM follows. The fourth section concludes with a paragraph introducing a subset of the technical constrains that need to be considered in the creation process of the DPM. The fifth section gives step by step instructions to create a DPM. The paper concludes with remarks on the progress achieved so far and provides an outlook on the software that is being developed at the moment to support you during the creation process. The last section also evaluates the DPM process to more traditional approaches. New terms are introduced throughout the text when they come up for the first time and can additionally be looked up in the glossary, which can be found in the appendix at the end of the paper.

Terms and definitions

For the purposes of this document, the following terms and definitions apply.

NOTE The terms definitions used in connection with Data Point modelling are inspired by vocabulary already known through their use for describing multidimensional databases and data warehouses. IT specialists originally introduced these terms. However, for an understanding and creation of Data Point Models they are now established in the language of business specialists as well.

data point

a Data Point can be compared to a cell in a table that holds reportable information and the row- and columnheaders characterising the Data Point can be regarded as the dimension and member combinations that apply to the Data Point

default member

a member in an enumerable dimension that will represent the dimension-member combination on a Data Point when that dimension is not explicitly associated

dictionary element

an abstract term for dimensioned elements, dimensions, domains and members

dimension

a dimension represents the “by” condition of a Data Point

Note 1 to entry: Dimensions literally describe the dimensioned element in order to limit the range of interpretation and thereby qualify the dimensioned element. One dimension either has a definite (i.e. countable) number of members, which is called an explicit dimension, or an infinite number of members represented as values, that follow a specific typing pattern, which is known as a typed dimension.

dimensioned element

a dimensioned element shows the nature of the data by typing it. It holds information about the underlying structure of the cell that is specified. In IT contexts a dimensioned element is referred to as metadata

domain

a domain is a classification system to categorize items that share a common semantic identity

Note 1 to entry: A Domain provides therefore an unambiguous collection of items in a value range. The items of a Domain can have a definite, and therefore countable, number of items, or an infinite number of elements that follow a specific (syntax) pattern.

domain member

each element that is part of a domain is called a domain member

Note 1 to entry: It is also possible to have members that do not belong to a domain; they can refer to a dimension directly.

Note 2 to entry: Domain members can either be explicitly named or defined by a type.

enumerable dimension

an enumerable dimension is a dimension that “specifies a finite number of members

fact

a fact describes the quantitative aspects of data reported EXAMPLE An amount, a number, a string of text, a date.

hierarchy

a non-enumerable dimension “specifies an undefined number of [members] [...] [it] defines syntactic constraints on the values of the members, i.e. a data type or a specific pattern

non enumerable dimension

a non-enumerable dimension “specifies an undefined number of [members] [...] [it] defines syntactic constraints on the values of the members, i.e. a data type or a specific pattern

sub-domain

a sub-domain is a subset of the members of a domain

taxonomy

a taxonomy describes a valid Data Point Model

templates

graphical representation of a set of supervisory data

Bibliography

Retrieved from "http://xbrlwiki.info/index.php?title=Guidelines_for_Data_Point_Modeling"