Frankfurt, .

DATA POINT MODELLING06.06.2017

MAREK WŁODARCZAKPAWEŁ MARTYNIUK

AGENDA

1. Introduction to DPM

2. DPM Dictionary

3. DPM Annotated Templates and Table Layout

4. Upgrading DPM Model and Taxonomy

5. Validation rules

6. Versioning

2

WHAT IS A DATA MODEL?

receiveranalysis and audit

data

Data requirements

/ concepts definitions

sender

Data exchange format

?Data Model

e.g. XBRL taxonomy

data

3

WHAT IS DATA POINT MODELLING?methodology of description of information requirements

process ideal/desired scenario

1. definition of required breakdowns (potentially overlapping with analytical needs) in the dictionary

2. creation of templates (tabular views) based on dictionary breakdowns in order to reflect current analytical needs

actual scenario reversed & iterative

1. analysis and description of templates (published in legal acts) in order to coherently, consistently and explicitly identify each reporting position

2. gathering and ordering of template description information in the dictionary

output dictionary of business terms

templates annotated with dictionary terms

information requirements

dictionary of business

terms (breakdowns)

templates annotated with dictionary terms

legal acts templates (forms)

§

DPM

4

WHAT IS WHAT IN DPM TERMINOLOGY?Metric – business concept describing at least data and period type of a financial, e.g. Carrying amount: monetary value reported at a point in time, Impairment: monetary figure reported for a period of time, Date of purchase: concept in data format reported as of the reporting date,

FINREP: carrying amount, current period, nominal amount, …

COREP: exposure, own funds, …

MIR: NDER, APRD, transactions, …

BSI: assets, liabilities, managed assets, …

Domain – set of concepts or values sharing semantic nature, e.g. geographical areas (political, social/economic, physical, …), currencies, financial instruments, …; divided into:

explicit – list of members defined in the model,

typed – values assigned by reported entities according to the pattern (e.g. codes),

Domain member – each member of an explicit domain, e.g. in case of financial instruments: derivatives, equity instruments, loans, …

Subdomain – hierarchical dependencies between domain member resembling nesting, order and basic arithmetical relations (lower level elements aggregate to a higher level element with indicated weight and comparison operator)

Dimension – context of application of a domain member or value; e.g. Hungary member of geographical areas domain could be used in the context of: location of operations, issuer residence, market of trade, … dimensions refer to explicit as well as typed domains (e.g. codes can be contextualized as ISIN, LEI, …)

Data Point – each single piece of data defined by information requirements, characterised by:

exactly one metric

dimension and domain member/value pairs

data point

explicit domain

subdomain (hierarchy)

metric data type period type

domain member

domain member

domain member

domain member

domain member

domain member

domain member

dimension

dimension

dimension

typed domain

domain type dimension

metric

dimension domain member

dimension typed domain value

5

HOW DOES IT LOOK ON AN EXAMPLE? (1)

DPM properties

6

HOW DOES IT LOOK ON AN EXAMPLE? (2) Domain: Categories

Total (…)

Cash

Loans and credits

Debt securities

Equity instruments

Fixed

Other than (…)

Dimension: Categories of assets

Total (…)

Cash

Loans and credits

Debt securities

Equity instruments

Fixed

Other than (…)

Domain: Sectors

All / Not-applicable

Non-MMFs

Central Administration

Other general government

Non-MFIs other than general government

Monetary Market Funds [MMFs]

MFIs other than Monetary Market Funds

Monetary Financial Institutions [MFIs]

Dimension: Counterparty sector

All / Not-applicable

Monetary Financial Institutions [MFIs]

Monetary Market Funds

MFIs other than Monetary Market Funds

Central Administration

Other general government

Non-MFIs other than general government

Dimension: Counterparty sector (alternative)

All / Not-applicable

Monetary Market Funds

Non-MMFs

MFIs other than Monetary Market Funds

General government

Non-MFIs other than general government

Dimension: Original maturity

All

< 1 year

≥ 1 year < 2 year

≥ 2 years

Domain: Time interval

All

< 1 year

≥ 1 year < 2 year

≥ 2 years

7

HOW DOES IT LOOK ON AN EXAMPLE? (3)

Domain: Geographical areas

All / Not-applicable

EMU (…)

Spain

Other than Spain in EMU (…)

Other than EMU (…)

Dimension: Counterparty residence

All / Not-applicable

EMU (…)

Spain

Other than Spain in EMU (…)

Other than EMU (…)

Dimension: Instrument currency

All / Not-applicable

EUR

Other than EUR

Domain: Currencies

All / Not-applicable

EUR

Other than EUR

8

HOW DOES IT LOOK ON AN EXAMPLE? (4)

Location of activity: Spain

Amount type: Outstanding

Basic concept: Assets

Category of assets: Debt securitiesCounterparty sector: Monetary Financial Institutions

Original maturity: ≥ 1 year < 2 year

Counterparty residence: Spain

Instrument original currency: EUR

9

WHAT IS A DOMAIN AND WHAT IS A DIMENSION?

Original maturity: > 1 year

Remaining maturity: ≤ 1 yearOriginal maturity: > 1 year

Remaining maturity: > 1 year

Revision of interest rate: ≤ 1 year

Domain: Time interval

≤ 1 year

> 1 year

Dimensions:

Original maturity

Remaining maturity

Revision of interest rates

Dimension: Categories of assets

Total (…)

(…)

Loans and credits

Dimension: Counterparty sector

All / Not-applicable

(…)

Non-MFIs other than general government

Non-financial corporations

Households and NPISHs

10

WHAT IS A SUBDOMAIN?

Domain: Geographical and political areas- All- EMU (…)- Spain- Other than Spain- Other than Spain in EMU (...)- Other than EMU (…)

Subdomain 1:All (…)

SpainOther than Spain

Subdomain 2:All

EMUSpainOther than Spain in EMU

(…)Other than EMU (…)Dimensions:

Location of activity

Securitization partner residence

Counterparty residence

Other than EMU

EMUSpain

?

Other than Spain

Spain

11

HOW DOES A DATA POINT LOOK LIKE?Net carrying amount of not yet impaired but already past due (over 180 days) debt securities held, issued in EUR by MFIs located in EMU with original maturity under one year, measured at amortised cost and relating only to business activities conduced in Spain (local business)?

Categories:

Total (…)

Cash

Loans

Debt securities

Equity instruments

Tangible and intangible

Other than (…)

Counterparty sectors:

All / Not-applicable

MFIs

MMFs

MFIs other than MMFs

Central Administration

Other general government

Non-MFIs other than government

Original maturity:

All

< 1 year

≥ 1 year < 2 year

≥ 2 years

Counterparty residences:

All / Not-applicable

EMU

Other than EMU (…)Original currencies:

All / Not-applicable

EUR

Other than EUR

Locations of activities:

All / Not-applicable

Spain

Other than Spain (…)

Amount types:

Carrying amount

Gross carrying amount

(Specific allowances)

(Collective allowances)

Base terms:

Assets

Liabilities

Equity

Off-balance sheet

Exposures

Portfolios:

Total (…)

Fair value through profit or loss

Amortised cost

Impairment status:

All / Not-applicable

Impaired

Unimpaired

Past due periods:

All

0 days

< 180 days

≥ 180 days

Base term: Assets

Category: Debt securities

Portfolio: Amortised cost

Amount type: Carrying amount

Impairment status: Unimpaired

Past due period: ≥ 180 days

Original currency: EUR

Original maturity: < 1 year

Counterparty sector: MFIs

Counterparty residence: EMU

Location of activity: Spain

Measure (metric):

Monetary

Text

Date

Time reference:

Current period end

Previous period end

Current period

Measure (metric): Monetary

Time reference: Current period end

12

each data point defined as a separate item with no or few breakdowns

high total number of items

easy to define, difficult to maintain

significant consequences of little changes to data model

WHICH IS BETTER – ITEMS (MEASURES) OR BREAKDOWNS?

which becomes an item or a breakdown (consistency in modelling)?

alignment with design of analytical models (model used for data exchange may but does not have to be used in analytical systems and vice versa)

only items (measures) few items, many breakdowns

each data point defined as an item in a combination of members of breakdowns

lower number of items in total (Cartesian product is multiplication)

distinguishing between items and breakdowns and consistent application of such classification is not always easy

supports maintenance: relation concept-breakdown is stable but components of breakdowns tend to change

13

Template 3

FINREP ver 1: 51 data points

FINREP rev 2: 45 data points

Identical cells: 0! due to:

different classification of instruments

addition of economic hedges as a new portfolio

introduction of breakdown by markets

How to present this change?

HOW DOES DATA MODELLING SUPPORT CHANGE COMMUNICATION?PART 1 OF 4

Financial Assets Held for Trading, Trading Derivatives, Equity Option

Financial Assets Held for Trading, Trading Derivatives, Equity Option, OTC

Financial Assets Held for Trading, Trading Derivatives, Equity Option,

Organized market

14

HOW DOES DATA MODELLING SUPPORT CHANGE COMMUNICATION?PART 2 OF 4

Instruments

Option

Cross swap

Forward

FRA

Future

IRSWarrant

Option/Cap/Floor/Collar/Swaption

Other than Option, Cross swap, Forward and Future

Other than Option, Warrant, Forward and Future

Other than Option/Cap/Floor/Collar/Swaption, IRS, FRA, Forward and Future

Risk Type

Currency (FX)

Equity

Interest rate

Portfolio

Held for trading

Base item

Assets

Liabilities

Assets and/or Liabilities

Amount type

Carrying amount

Notional amount

Category

Derivatives

15

HOW DOES DATA MODELLING SUPPORT CHANGE COMMUNICATION?PART 3 OF 4

Instruments

Option

Other than options

Risk Type

Currency (FX)

Equity

Interest rate

Portfolio

Held for trading

Held for trading, economic hedges

Base item

Assets

Liabilities

Assets and/or Liabilities

Amount type

Carrying amount

Notional amount

Category

Derivatives

Market

Organized market

OTC

16

HOW DOES DATA MODELLING SUPPORT CHANGE COMMUNICATION?PART 4 OF 4

Market

Organized market

OTC

=

+

+

Instruments

Option

Other than options

Portfolio

Held for trading

Held for trading, economic hedges

Instruments

Option

Cross swap

Forward

FRA

Future

IRSWarrant

Option/Cap/Floor/Collar/Swaption

Other than Option, Cross swap, Forward and Future

Other than Option, Warrant, Forward and Future

Other than Option/Cap/Floor/Collar/Swaption, IRS, FRA, Forward and Future

Portfolio

Held for trading

FINREP ver 1 vs FINREP rev 2

17

DPM is template-independent

(data centric) - all information

about data point is explicit

It is easy to trace the difference

between every two data points across

entire reporting framework

DPM could be a guideline on how

to organize the data on the

reporting entity side (storage and

BI systems)

The quality of reporting

requirements/templates is

improving (consistent labeling,

hierarchical structures)

Model is very stable but possible to

extend if required (reusing of concepts is

priority, adding/extending of

concepts/hierarchies is possible as long

as it doesn’t break the logic of model)

BENEFITS OF DPM

18

WHAT IS THE NATURE OF DATA MODELLING?

data modelling it’s not a science!

it’s a (subjective) result of discussion

and agreement

19

What DPM is?

•Methodology to organize the data

•Subjective result of discussion and agreement

•Must include:

•Dictionary (consistent, well structured, no overlaps, etc.)

•Mechanism to describe data model (tables) with concepts

from the dictionary (unique, explicit, etc.)

What DPM is not?

•Technical format

•Tables

•Science

•„Something” to be prepared by IT experts…

DPM - SUMMARY

• Data Point Model (DPM) is a structured representation of the data, identifying all the business concepts and its relations, as well as validation

rules. DPM contains all the relevant technical specifications necessary for developing an IT reporting solution (independent from the technical

format)

(EIOPA definition)

20

DPM DICTIONARY

•Metrics

•Domain members

•Hierarchies

•Validity periods

•Other differences

EBA vs EIOPA comparison

31

METRICS

EBA

Metrics are stored in a single sheet together with domain members

EIOPA

Metrics are split into HD and MD and stored in

separate sheets

32

DOMAIN MEMBERS

EBA

Domain members are stored in a single sheet

EIOPA

Domain members are stored in separate

sheet for each domain

33

HIERARCHIES

EBA

Hierarchies are stored in a single sheet

EIOPA

Hierarchies are stored in separate sheet for

each domain

34

VALIDITY PERIODS

EBA: FromReportingDate, ToReportingDate

EIOPA: Creation date, Validity date, Last modified date

35

OTHER DIFFERENCES

Aspect EBA EIOPA

Details of domains and dimensions

Domains and dimensions have description

Definition of domains and dimensions based on label

Typed domains Datatype of typed domain is not defined

Datatype of typed domain is defined

Default Not specified in excel dictionary Domains have default member

IDs Elements have additional ID from database

Elements have single ID

Dimension code Dimension code has 3 letters Dimension code has 2 letters

Owner Single owner in DPM model DPM model has three owners

36

DPM TABLE LAYOUT AND ANNOTATED TEMPLATES

•Tables organization

•DPM Table Layout

•DPM Annotated templates

37

TABLES ORGANIZATION

EBA

Separate layout file for each framework

List of templates

EIOPA

All templates in single file

Entry point matrix

38

DPM TABLE LAYOUT

•Domains and dimensions used in table are listed

•Data point has dimensional characteristic in the comment

•Identification of domain member based on code and label

39

DPM ANNOTATED TEMPLATES

•Metrics MD (blue)

•Named ranges

•Identification of domain member based on label

40

UPGRADING DPM MODEL AND TAXONOMY

Solvency II 2.0.1

Solvency II 2.1.0

41

SOLVENCY II 2.0.1

42

SOLVENCY II 2.1.0

43

VALIDATION RULES

•Validations organization

•Validations syntax

•EIOPA Validation file – additional information

44

VALIDATION RULES

•Validations based on max 7 tables

•Sheets

•Validations based on max 6 tables

•Filter

•Reason for deactivation

•Comments to amendment or deactivation

45

VALIDATION SYNTAX COMPARISON

Type Owner Validation ID Validation

Data type constrains EIOPA BV2 {C0390} - data type constrains [ISO 8601: (yyyy-mm-dd)]

Dictionary element reference

EBA v0831_m if $AccountingStandard = 'IFRS' then {F 08.01.a, r010, c010} = {F 10.00, r290, c020}

EBA v4007_a [ei50] ∈ {[eba_AP:x27], [eba_AP:x42], [eba_AP:x45]}

EIOPA BV339 If{S.01.02, r0190,c0010} = [s2c_AP:x9] then {S.01.01, r0370,c0010}=[s2c_CN:x1]

String pattern EIOPA BV237 If {c0290} like '##75' or {c0290} like '##95' then {c0280} = empty

not(isfallback) EIOPA BV445 If not(isfallback({S.15.02, c0060})) then not(isfallback({S.15.01, c0090}))

Has to be reported EIOPA BV337 If {S.01.02, r0150,c0010}=[s2c_PU:x4] or {S.01.02, r0170,c0010}=[s2c_PU:x51] then {SR.01.01} has to be reported

xsum EBA v1019_m xsum({F 30.02, (r050-060, c010-030)}) = {F 30.01, r010, c020}

46

EIOPA VALIDATION FILE – ADDITIONAL INFORMATION

Technical validations

XBRL Tax Assertions

List of identical data points

47

ADDITIONAL PUBLICLY AVAILABLE DOCUMENTS

Description EBA EIOPA

General information about release Release notes Release Notes

Summary of differences between releases Summary differences The detailed change log between versions

Tables visualization with marked changes Table layout changes -

Abstract description of the model represented in taxonomies following the DPM approach

Description of DPM formal model

The DPM Documentation

Representation in XBRL of the Data Point Model EBA Architecture for XBRL representation of DPM

XBRL Taxonomy Documentation

Syntax of validations Validation Formula.grammar Syntax documentation

List of known issues - The list of known issues

48

DPM VERSIONING ASPECTS COVERED

Aspect EBA EIOPA

Domains, dimensions, domain members

Yes Yes

Hierarchies Yes Yes

Validations Yes(replace)

Yes

Datapoints Yes

(DataPointVID)

No

Tables Yes(TableVID)

No

Frameworks Yes(package contains all previous versions of

taxonomy)

Yes(package contains only last version of

taxonomy)

49

THANK YOU!

MAREK WŁODARCZAKPAWEŁ MARTYNIUK

50