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? (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
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