1. XBRL, Solvency II approach
15th Eurofiling workshop
Madrid,

2. Agenda Introduction Reporting frameworks in EU
Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

3. Nov. 2009: Solvency II Directive Implementing measures
Solvency II Timeline
Nov. 2009: Solvency II Directive
Omnibus II
Implementing measures
2001
In force
1/1/2011
Technical preparation (advices)
Technical standards
TODAY

4. XBRL issues Main issues to solve for a successful implementation
Scarcity of available skilled XBRL resources
Short timeframe before the go-live date

5. EIOPA current work Mutualized development
An EIOPA effort instead of 30 national efforts
A taxonomy project, to be delivered as soon as possible after the availability of the stable reporting package (target: this autumn)
Outcome of the technical consultation: cross sector consistency desirable.
Experience sharing with the others ESAs (EBA, ESMA) and ESRB
Data Point Modelling project launched (EBA used methodology)

6. Tight deadlines and resources scarcity
Stable reporting requirements in June, DPM in September, supporting stable taxonomy this autumn
A tool for undertakings project launched
To provide a (non mandatory) possibility for undertakings to produce valid XBRL instances from the start
EIOPA need to be able to validate, extract, store and then use data
Mutualization/sharing possibilities currently examined (e.g. providing a benchmarking validation service)

7. Agenda Reporting frameworks in EU Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

8. Overall reporting framework in EU
Countries
Europe
Reporters
NSAs
ESAs
Logotypes … …

9. Agenda Reporting frameworks in EU Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modeling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

10. Path to XBRL Solvency II is a complex reporting
Structured XML, first chosen, is not adequate
Choice of XBRL, over an EIOPA-specific flat XML language: YARL (Yet Another Reporting Language)

11. Commonalities with EBA taxonomies
Reasons for alignment considerations
Certain firms are required to send reports to both banking and insurance regulators
Certain software vendors offer products or solutions for both, banks and insurance companies
Commonalities between EBA and EIOPA taxonomies under consideration:
Common dimensions
Data Point Modelling
Common data types
Taxonomy architecture
Base primary items
Label construction rules
Tools
etc

12. Agenda Reporting frameworks in EU Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

13. Taxonomy generated from templates
Types
Dimension Domain, value or list of values
Header dimension(s)
Abstract primary items
(label or alias)
Column dimension(s)
Primary items
(label or alias)
Line dimension(s)
Pop-up window
showing P.Item + Characteristics + Dim. combinaison(s)

14. Use of codes for concepts
Codes are used as tag names for concepts
To get usable names (not too log)
To be language-agnostic
The codes used are those that are defined by the business people in the Quantitative Reporting Templates (regulatory document)
They are not Excel cell coordinates !

15. A real template (extract)

16. Additional information needed in annotated templates

17. Expression of validations
Generation of XBRL assertions with code, label, messages, using patterns

18. Agenda Reporting frameworks in EU Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

19. Dimensions in data models
only base items
few base items, many breakdowns
each data point defined as a base item in a combination of members of breakdowns
lower number of items in total (Cartesian product is multiplication)
distinguishing between base items and breakdowns not always easy
supports maintenance: relation concept- breakdown is stable but components of breakdowns tend to change
each data point defined as a base item
high total number of items
easy to define, difficult to maintain
significant consequences of little changes to data model
which is a base item, what is a breakdown?
alignment with design of analytical models

20. Almost everything is a perspective
portfolios
Portfolio breakdown (purpose and measurement)
e.g. held for trading - „acquired or incurred principally for the purpose of selling or repurchasing it in the near term”; includes different instruments: Derivatives, Loans, Debt securities, Equity instruments, …
Instruments breakdown:
e.g. debt instrument - „contractual or written assurance to repay a debt”; can fall into different portfolios: Held-for-trading, Designated at fair value, Available for sale, …
held-for-trading
instruments
designated at fair value
loans
derivatives
available-for-sale
debt securities
income/expense
natures
assets
liabilities
assets: property, resources, goods, etc that a company possesses and controls, e.g. financial instruments owned by a reporting entity that shall generate economic benefits in the future
liabilities: sources of funding for company’s assets and operations, e.g. financial instruments that have been issued by a reporting entity, thus represents an obligation that needs to be settled in the future by a transfer of some assets (such as cash) from the entity
income/gains or expenses/losses:
economic benefits that occurred during the period and originated from increase/decrease in value or result on sales/purchase of a given financial instrument

21. DATA POINT: Net carrying amount of not yet unimpaired 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).
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
Original maturity:
All
< 1 year
≥ 1 year < 2 year
≥ 2 years
Category:
Debt securities
Categories:
Total (…)
Cash
Loans
Debt securities
Equity instruments
Tangible and intangible
Other than (…)
Portfolio:
Amortised cost
Amount type:
Carrying amount
Impairment status:
Unimpaired
Counterparty sectors:
All / Not-applicable
MFIs
MMFs
MFIs other than MMFs
Central Administration
Other general government
Non-MFIs other than government
Past due period:
≥ 180 days
Original currency:
EUR
Original maturity:
< 1 year
Counterparty sector:
MFIs
Amount types:
Carrying amount
Gross carrying amount
(Specific allowances)
(Collective allowances)
Counterparty residence:
EMU
Location of activity:
Spain
Counterparty residences:
All / Not-applicable
EMU (…)
Spain
Other than Spain in EMU (…)
Other than EMU (…)
Original currencies:
All / Not-applicable
EUR
Other than EUR
Locations of activities:
All / Not-applicable
Spain
Other than Spain (…)

22. Annotated templates using generic base items
Data can be analysed from multiple perspectives
Most changes in the model do not affect primary items

23. Pro and cons for HD taxonomies
Pros
Quality check for the model (via DPM)
Explicit dependencies between concepts
Change management with stable base items
Use of breakdowns for internal purposes (databases, BI…)
Potential bridge with other reporting frameworks
No need for arbitrary decisions (base vs dimensions)
Data centric model (template independent)
Cons
Less readability of taxonomies
Bigger instances and lower performances (more breakdowns used)
More time and resources required for preparation
More complex formulas / assertions with need of dimension filters

24. Agenda Reporting frameworks in EU Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

25. EIOPA XBRL Approach: Two Layers
Non-DPM Eurofiling XBRL architecture
Annotated templates (limited DPM)
MDA taxonomy layer
Mapping layer
Solvency II templates
DPM XBRL architecture
DPM-based annotated templates
Data Point Model
HDA taxonomy layer

26. Highly dimensional approach Moderate dimensional approach
Benefits of two layers
Highly dimensional approach
Moderate dimensional approach
Derivatives, Investments other than held for index-linked or unit-linked funds
BS_C1:A10A
Assets
Types of assets
Total
Debt instruments
Solo or Group
Solo or Group
Solo or Group
Solo or Group
Derivatives
Solo …
Solo
Group
Investment or own use …
Group
Investment
Periodicity
Own use
Periodicity
Linking
Annually
Annually
Unit-linked or index-linked
Quarterly
Not unit-linked, not index-linked
Quarterly
Line of business
Monthly
Monthly
Total
Ad hoc …
Non-life, non SLT health
Ad hoc
SLT health
Valuation method
Non-SLT health
Valuation method
Life
Solvency II
Country of custody
Solvency II
Total
Too be redesigned
Marked to market …
Marked to market
Marked to model
Issuer or residence country
Marked to model
Total
CRD …
CRD
Statutory
Type of amount
Statutory
Carrying amount …
Original currency
Total … …

27. Mapping layer considerations
Mapping approach:
Equivalence linkbase
Formula linkbase
Instance mapping
Resource mapping
XSLT style-sheets
Rendering linkbase
Criteria for evaluation of mapping solutions
Standard specifications compliance
Maintenance of solution
Performance of processing (mapping)
Resources required for development
Support by software vendors

28. Agenda Introduction Reporting frameworks in EU
Choice of XBRL and architecture
Initial taxonomy development: moderately dimensional
Introduction of Data Point Modelling and highly dimensional approach
EIOPA approach: MD and HD
Tool for undertakings

29. Why are we going to provide a XBRL Tool for Undertakings?
Solvency II will be applied to all European countries, XBRL is not well known in all of them
Tight timeline for the implementation
Some small and medium undertakings may have difficulties to adapt their system for the first submissions
Principle of proportionality 
Providing a Tool for Undertakings

30. Contributing to XBRL community and open source community
What are we looking for?
Helping the undertakings without XBRL knowledge, providing a tool to easily create complete and valid XBRL instances of the Solvency II harmonized quantitative reporting
Designing the XBRL tool to be reusable for other projects and specifically extensible for NSA local requirements
Contributing to XBRL community and open source community

31. How and when are we going to develop it?
1st Phase
2nd Phase
21/09/2012
29/03/2012
1.-Project Setup
Establish the members of the project, general goals, software methodology, calendar, etc.
2.- Create the first draft of the analysis of requirements
Identify the scope of the project, analyse the alternatives, create the draft of the analysis of requirements.
3.- The open tender
Write and publish a public tender request for an offer which includes the requirements established on the analysis.
The interested companies will have 2 months to submit their offers.
Timeline
3rd Phase
4.- Evaluation Process
Analyse the received offers and choose one of them.
5 .- Design, implementation, test and integration
Refine the analysis with the selected contractor, Implementing phase, testing phase, integration and NSA test.
6 .- Publication
Publish a release for public test.
7 .- Production, configuration and change management
Adaptive maintenance of the project.
11/04/2012
4/7/2012
23/7/2012
26/10/2012
01/01/2013
01/01/2014
01/05/2014

32. Requirements Use of XBRL label, rendering, reference, formulas, etc.
Distribution license for all Europe. Preferable EUPLA license
Internationalization: Languages, data formats, currencies, etc.
Using the input forms in a similar layout as the public reference templates.
Easy to use for administrative staff with limited IT knowledge
Allowing reusing or extension of the tool for national extensions
Easy to deploy
Use of XBRL label, rendering, reference, formulas, etc.
XBRL syntax and formula validation at client side
2nd level support
Easy to update when the taxonomy changes
Open source,
reusable
Good performance with large amounts of data
Multiplatform
Note that these requirements are under discussion and not final

33. Thank you
Any questions?