European Regulatory Roll-out Package guide

From XBRLWiki

(Difference between revisions)

Jump to: navigation, search

Current revision

CEN Workshop Agreement

Status: Approval Final Draft - Formal Vote

CEN WS CWA3 Convenor: Aitor Azcoaga (EIOPA)

CEN WS XBRL Experts: Pieter Maillard (Aguilonius), Pablo Navarro (Atos)

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Foreword

This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.

CWA XBRL 003 consists of the following parts, under the general title Improving transparency in financial and business reporting — Standard regulatory roll-out package for better adoption
— Part 1: XBRL Supervisory Roll-out Guide
— Part 2: XBRL Handbook for Declarers

This CWA is one of a series of related deliverables. The other deliverables are:

CWA XBRL 001 which consists of the following parts, under the general title Improving transparency in financial and business reporting — Harmonisation topics:
— Part 1: European data point methodology for supervisory reporting.
— Part 2: Guidelines for data point modelling
— Part 3: European XBRL Taxonomy Architecture
— Part 4: European Filing Rules
— Part 5: Mapping between DPM and MDM

CWA XBRL 002 Improving transparency in financial and business reporting — Metadata container

Introduction

This document is intended to provide guidelines to European regulators in the implementation and roll out of the reporting standard using XBRL across Europe.

The set of recommendations included in this document aim to facilitate the implementation of European National Supervisors to adopt XBRL in any of the reporting frameworks. The following sections will provide guidance on the use, understanding, preparation, and extension of their filings in eXtensible Business Reporting Language (XBRL).

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “should” (recommendation), “may” (allowance) and “can” (possibility). Organizations wishing to implement this CWA would be expected to consider all recommendations where the term "should" is used.

COREP, FINREP (and Solvency II or other future) XBRL taxonomies are offered to European regulators for national implementation. The first releases (2006) of the COREP and FINREP XBRL frameworks have proven that a standardized technical roll-out package is needed to increase the adoption rate and avoid implementation variances, which have a detrimental effect on the overall cross-border effectiveness of using one reporting standard. As well this roll-out guide tries to promote the economies of scale for a better adoption.

1 Scope
2 How to start with XBRL. Supervisory Perspective
3 How to implement and extend XBRL taxonomies
4 Architecture, Methodology and Best Practices
5 Management and maintainability
6 Annex A (informative)
- 6.1 Terms and Definitions
- 6.2 Bibliography

 <span style="font-size:18pt">'''CEN Workshop Agreement'''</span>
-'''Status''': Working Group Working Draft
+'''Status''': Approval Final Draft - Formal Vote
+'''CEN WS CWA3 Convenor''': Aitor Azcoaga (EIOPA)
+'''CEN WS XBRL Experts''': Pieter Maillard (Aguilonius), Pablo Navarro (Atos)
 '''Editing rules'''
 '''Foreword'''
-<span style="background-color:#A9D0F5">This document is a working document.</span><br />
 This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.<br />
-This document is a working document.<br />
+CWA XBRL 003 consists of the following parts, under the general title Improving transparency in financial and
+business reporting — Standard regulatory roll-out package for better adoption<br />
+— Part 1: XBRL Supervisory Roll-out Guide<br />
+— Part 2: XBRL Handbook for Declarers<br />
+This CWA is one of a series of related deliverables. The other deliverables are:<br />
+CWA XBRL 001 which consists of the following parts, under the general title Improving transparency in
+financial and business reporting — Harmonisation topics:<br />
+— Part 1: European data point methodology for supervisory reporting.<br />
+— Part 2: Guidelines for data point modelling<br />
+— Part 3: European XBRL Taxonomy Architecture<br />
+— Part 4: European Filing Rules<br />
+— Part 5: Mapping between DPM and MDM<br />
+CWA XBRL 002 Improving transparency in financial and business reporting — Metadata container<br />
 '''Introduction'''
-The set of recommendations included in this document aim to facilitate the implementation of European National Supervisors to adopt XBRL in any of the reporting frameworks.  The following chapters will provide guidance on the use, understanding, preparation, and extension of their filings in eXtensible Business Reporting Language (XBRL).
-This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “should” (recommendation), “may” (allowance) and “can” (possibility). Organizations wishing to
+This document is intended to provide guidelines to European regulators in the implementation and roll out of
-implement this CWA would be expected to consider all recommendations where the term “should” is used.
+the reporting standard using XBRL across Europe.<br />
-=Scope=
+The set of recommendations included in this document aim to facilitate the implementation of European
-COREP, FINREP (and Solvency II or other future) XBRL taxonomies are offered to European regulators for national implementation. The first releases (2006) of the COREP and FINREP XBRL frameworks have proven that a standardized technical roll-out package is needed to increase the adoption rate and avoid implementation variances, which have a detrimental effect on the overall cross-border effectiveness of using one reporting standard. As well this roll-out guide try to promote the economies of scale for a better adoption.
+National Supervisors to adopt XBRL in any of the reporting frameworks. The following sections will provide
+guidance on the use, understanding, preparation, and extension of their filings in eXtensible Business
+Reporting Language (XBRL).<br />
-This CWA have divided the work/deliveries in two difference parts:
+This guidance is in the form of notes in association with the pertaining requirements clause and uses the
+terms “should” (recommendation), “may” (allowance) and “can” (possibility). Organizations wishing to
+implement this CWA would be expected to consider all recommendations where the term "should" is used.<br />
-::i)	An '''XBRL supervisory roll-out guide''': this is oriented towards national regulators on how to implement, extend and manage XBRL taxonomies<br />
+COREP, FINREP (and Solvency II or other future) XBRL taxonomies are offered to European regulators for
-::ii)	An '''XBRL handbook for declarers''': this is a roll-out guide or reference handbook would give a general introduction to XBRL and serve as a help to preparers of XBRL (reporting entities) <br />
+national implementation. The first releases (2006) of the COREP and FINREP XBRL frameworks have proven
+that a standardized technical roll-out package is needed to increase the adoption rate and avoid
+implementation variances, which have a detrimental effect on the overall cross-border effectiveness of using
+one reporting standard. As well this roll-out guide tries to promote the economies of scale for a better
+adoption.<br />
-The scope of the current document is the first part of the CWA; the XBRL supervisory roll-out guide. In this general guide to XBRL, the following subjects will be addressed.
-The guidance and recommendations included in this document have been created for regulatory filings in the context of European supervisory reporting.
+=Scope=
+This CWA is a general guide to XBRL oriented towards national regulators on how to implement, extend and
+manage XBRL taxonomies. The guidance and recommendations included in this CWA have been created for
+regulatory filings in the context of European supervisory reporting.<br />
-In this document, “regulatory filings” encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).
+In this document, “regulatory filings” encompasses authoritative financial reporting standards and generally
+accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily
+financial position and performance and related explanatory disclosures, and data sets used in the collection of
+financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example,
+internal controls assessments) and non-financial quantitative reports (for example, air pollution
+measurements).
-=Normative references=
+=How to start with XBRL. Supervisory Perspective=
-<span style="background-color:#A9D0F5">Some text</span>
+This section describes how the XBRL standard can be implemented from the regulator's perspective.
-The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
+First, we present different levels of XBRL adoption, to help define the supervisor's strategy.
-EN xyz:199x, Title of the european standard.
+This is followed by a description of the minimum steps required to facilitate initial understanding of the XBRL
+standard, and guidelines describing the review and the likely impact on existing infrastructure and internal
+information systems.
-EN ab c:199x, General title of series of parts — Part c: Title of part.
+Finally, we suggest additional considerations which should be taken into consideration during preparation and
+planning, to help regulators establish which services they need to implement to enable reporting entities to
+adhere to the XBRL standard. Figure 1 presents an overview of the activities described in the section.
-=Terms and definitions=
-For the purposes of this document, the following terms and definitions apply:
+<center>
+[[Image:BusinessOverview.jpg]]<br>'''Figure 1 —The Business Overview to Rollout XBRL reporting'''
+</center>
-; Eurofiling : Eurofiling project is an open joint initiative of the European Banking Authority (EBA) and the European Insurance and Occupational Pensions Authority (EIOPA) in in collaboration with XBRL Europe, as well as stakeholders as banks, solutions providers, academy and individuals. The deliverables are Data Models, XBRL taxonomies, know-how and materials for Supervisory Frameworks: COREP, FINREP and Solvency II.<br />
+[SOURCE: 24th XBRL International Conference: Academic Track 6]
-; ESFS European System of Financial Supervisors : Before and during the financial crisis in 2007 and 2008, the European Parliament has called for a move towards more integrated European supervision in order to ensure a true level playing field for all actors at the level of the European Union and to reflect the increasing integration of financial markets in the Union. As a result, the supervisory framework was strengthened to reduce risk and severity of future financial crises. European System of Financial Supervisors that comprises three European Supervisory Authorities, one for the banking sector (EBA), one for the securities sector (ESMA) and one for the insurance and occupational pensions sector (EIOPA), as well as the European Systemic Risk Board.<br />
-; EBA : The European Banking Authority was established by Regulation (EC) No. 1093/2010 of the European Parliament and of the Council of 24 November 2010.<br />
+===Determine the level of XBRL adoption===
-:The EBA has officially come into being as of 1 January 2011 and has taken over all existing and ongoing tasks and responsibilities from the Committee of European Banking Supervisors (CEBS).<br />
-:The EBA acts as a hub and spoke network of EU and national bodies safeguarding public values such as the stability of the financial system, the transparency of markets and financial products and the protection of depositors and investors.<br />
-:The EBA has some quite broad competences, including preventing regulatory arbitrage, guaranteeing a level playing field, strengthening international supervisory coordination, promoting supervisory convergence and providing advice to the EU institutions in the areas of banking, payments and e-money regulation as well as on issues related to corporate governance, auditing and financial reporting.<br />
-; COREP and FINREP : To achieve a high level of harmonization and strong convergence in regular supervisory reporting requirements, EBA has been developing guidelines on supervisory reporting with the aim of setting up a supervisory reporting model with common data definitions. The Guidelines on Financial Reporting cover consolidated and sub-consolidated financial reporting for supervisory purposes based on IAS/IFRS as endorsed by the European Union.The original Guidelines on FINREP were issued by the Committee of European Banking Supervisors in December 2005. Agreed changes in IFRS were incorporated into the latest FINREP published in December 2009.<br />
+Widespread adoption of XBRL as a business information exchange format has revealed a number of implementation alternatives.
-: Further major changes to the accounting standards which will impact FINREP are expected. The revised FINREP will be reviewed in due course to take account of the changes in accounting standards.<br />
+Selection of a specific adoption strategy by the regulator establishes the roadmap for implementation from the regulator's current reporting framework to a framework which supports the new legislation. This step is probably the most important step in XBRL adoption.
-; EIOPA : The European Insurance and Occupational Pensions Authority (EIOPA) was established in consequence of the reforms to the structure of supervision of the financial sector in the European Union. The reform was initiated by the European Commission, following the recommendations of a Committee of Wise Men, chaired by Mr. de Larosière, and supported by the European Council and Parliament. <br />
+Attending to the level of penetration (or permeability) of XBRL between the Regulator and the Filing entities
-: EIOPA’s main goals are: <br />
+the adoption can be classified in the following:
-:*Better protecting consumers, rebuilding trust in the financial system.
+:* Use of XBRL solely for the electronic exchange of data between the national regulator and European Authority to comply with legislation.
-:*Ensuring a high, effective and consistent level of regulation and supervision taking account of the varying interests of all Member States and the different nature of financial institutions.
+:* Adaptation of existing reporting channels to receive XBRL reports from reporting entities as well as using XBRL for the electronic exchange of data between the national regulator and the European Authority. In this scenario, regulators could make use of automated business rules to validate data received from reporting entities.
-:*Greater harmonisation and coherent application of rules for financial institutions & markets across the European Union.
+:* Full exploitation of XBRL for internal reporting models (multidimensional data analysis) in addition to the use of XBRL for receiving data from reporting entities and electronic exchange between the national regulator and the European Authority as described above.
-:*Strengthening oversight of cross-border groups.
-:*Promote coordinated European Union supervisory response.
-: EIOPA’s core responsibilities are to support the stability of the financial system, transparency of markets and financial products as well as the protection of policyholders, pension scheme members and beneficiaries. EIOPA is commissioned to monitor and identify trends, potential risks and vulnerabilities stemming from the micro-prudential level, across borders and across sectors.<br />
-:EIOPA is an independent advisory body to the European Parliament, the Council of the European Union and the European Commission.<br />
-; SOLVENCY II : The Solvency II Directive 2009/138/EC is an EU Directive that codifies and harmonises the EU insurance regulation. Primarily this concerns the amount of capital that EU insurance companies must hold to reduce the risk of insolvency.<br />
+Depending on the strategy selected, the regulator must also determine which XBRL enabled software applications should be made available to their internal departments and also to reporting entities under their jurisdiction.
-:Once the Omnibus II directive is approved by the European Parliament, Solvency II will be scheduled to come into effect. [https://eiopa.europa.eu/activities/insurance/solvency-ii/index.html] [http://europa.eu/rapid/press-release_MEMO-07-286_en.htm?locale=en]<br />
+To name a few examples for consideration: XBRL validation, report visualization, conversion from existing data formats, filing forms, monitoring, security enforcement and versioning that will facilitate the analysis and supervision of reported information.
-=How to start with XBRL. Supervisory Perspective=
+===Plan and prepare the new reporting models===
+From the regulator's perspective there are two main key drivers in favour of XBRL adoption: compliance with new regulation directives and ensuring the accuracy of data reported by reporting entities.
-This chapter describes how the XBRL standard can be implemented from the regulator's perspective.
+Compliance with new regulation directives implies the adequacy of the reporting business models and rules to the XBRL language and semantics to be implemented.
-First is presented the different levels of XBRL adoption, defining the supervisor's strategy.
+The most important requirement for financial supervision reporting is data accuracy. Reported data, for legal reasons, is expected to be:
+:* accurate for arithmetic purposes;
+:* calculated accurately based on the required definition;
+:* preserved during the data transfer process.
-This is followed by elaborating the minimum amount of steps needed to facilitate a proper introduction of the XBRL standard.
+It is also a good idea to plan and prepare the adaptation of all data requirements. For this, the regulator needs
+to learn and understand the following topics:
+:* XBRL basics – terminology, syntax and structure;
+:* how the data models correspond to the business model and semantic rules into XBRL syntactic schemas and filers forms that define reporting data. Consider information requirements which could have causes additional issues to be solved in the modelling architecture.
-Then it is presented the adaptation and review of the reception infrastructures and the internal information systems that could be impacted by the use of XBRL in the reporting process.
+Many are approaching as compliance requirements driven by a new reporting directive. An alternative approach is considering XBRL adoption as a technology evolution of current reporting systems to take advantage of this standard and reap the benefits of a standardised electronic exchange format.
-Finally it will be described additional considerations to prepare and plan in order to establish the proper circuits and services to enable the standard with the reporting entities.
+In general, successful XBRL implementations usually do not change the business models, just the report format resulting in a transparent use of XBRL to the end users.
-The following picture give an overview on the activities described in the chapter
+It is specially recommended to apply a structured methodology for data modelling. On this topic the Eurofiling architecture approach is proposing a methodology on normalization called Data Point Modelling. This will be introduced later in Section 5, but mainly consists of defining a method to model dictionary data, their aspects and relationships in terms of domains and hierarchies, business validation rules and the corresponding classifications of the data in different tables and forms for filing and visualization (figure 2).
-<center>
-[[Image:BusinessOverview.jpg]]<br>Figure 1 —The Business Overview to Rollout XBRL reporting
+<center> [[Image: CEN_DPM-clarificationDiagram.jpg]]<br />
+'''Figure 2: DPM   process   and   XBRL    relationship'''
 </center>
-===Determine the level of XBRL adoption===
+<br />
-Since the XBRL Standard has been adopted several years ago, a different amount of alternatives on the exchange of XBRL between regulators and reporting entities have emerged.
+[SOURCE: Abstract description of the model represented in taxonomies following the DPM approach] <br />
-The choice of a specific adoption strategy by the regulator is probably the first important step. The adoption strategy establishes the roadmap from the regulator's current reporting requirements towards the new rules.
-Attending to the level of penetration (or permeability) of XBRL between the Regulator and the Filing entities the adoption can be classified in the following:
+How this data inherited from the European frameworks fits into the national reporting model. Study if the current information models for reporting entities have more disclosures or information. In case more detailed information is required, knowledge on the extension of European taxonomies is needed. This will be detailed
-:* Using XBRL only as the electronic format of interchange.
+in Section 4.<br />
-:* Adapting software applications in reception and submission to use XBRL as well as interchange format, for example relying in the business rules for formula validation.
-:* Exploit for internal reporting models (multi dimensional) as well as for external reporting the XBRL standard.
-According to the previous approach the regulator must also decide how many facilities in the form of XBRL enabled software application for their internal departments and for external entities is going to provide.
-To mention a few examples there is a range from validation, visualization, monitoring, versioning that will facilitate the analysis and supervision of reported information.
+In order to select the most appropriate XBRL strategy, the regulator should consider the relevant answers to the questions below that will help to address reporting decisions:
+:* How many different reporting templates do we need to receive from reporting entities?
+:* What is the frequency of this reporting information? Quarterly, semi-annually, annually?
+:* What is the minimum reporting unit of information expected to receive (one template, one module, one table, one fact, other)?
+:* What is the profile of reports (minimum and maximum size expected) to be received keeping a margin of security for processing?
+:* What response time is needed to process received reporting information?
+:* Will it be allowed partial submissions? Or will all data need to be reported in full?
+:* What is the minimum precision accepted for data?
+:* Will it be allowed for reports to be re-submitted if the reporting entity wishes to submit an amendment? Will It be placed any deadlines for receipt of any amendments?
-===Plan and prepare the new reporting models===
+===Review existing reception infrastructure===
-On the regulator's perspective there are two main key drivers in the XBRL adoption: compliance with new regulation directives and data accuracy reported by reporting entities.
+From an IT perspective, regulators will have the opportunity to review their current receipt and transmission infrastructure with their reporting entities to incorporate the new reporting standard to their channels:
-Compliance with new regulation directives implies the adequacy of the reporting business models and rules to the XBRL language and semantics to be implemented.
+If regulator has well established data collection mechanisms in place, it will be necessary to adapt these mechanisms to accept XBRL instance documents, including additional workflows (submit and feedback loops) for the validation of header information and XBRL validation (following recommendations documented in “CEN WS XBRL CWA2 as valuable initiatives to take into consideration).
-The most important requirement for financial supervision reporting is data accuracy. Reported data, for legal reasons, is expected to be:
+Specific items likely to require IT review:
-:* accurate for arithmetic purposes
+:* Select a new system or adapt if necessary an existing system for receiving reports from reporting entities and sending acknowledge messages and validation report results from regulator (transmission channel):  web secure portal upload, email secure SMTP, web service secure integration submission, cloud portal, etc.,
-:* calculated accurately based on the required definition
+:* Select, reuse or adapt the security methods to maintain confidentiality, integrity, authenticity, non-repudiation (following recommendations documented in CEN WS CWA2 related to digital signature and use of certificates)
-:* preserved during the data transfer process
+:* Select which additional services could be provided as part of the submission protocol from reporting entities to national regulator, for example tracking or monitoring submitted reports, visualization of XBRL instances, pre-validation including formulae[4] which defining regulatory requirements, display the specific data set (templates) that each reporting entity is expected to fulfil, etc.
-It is also a good idea to plan and prepare the adaptation of all data requirements. For this, the regulator needs to obtain proper knowledge on the following topics:
+===Review internal information systems===
-:* Learn the basics, how XBRL works, what is the terminology.
-:* How the data models have been driven from business model and semantic rules into XBRL syntactic schemas and fillers forms that define reporting data. Take into account the last architecture modeling issues that the required information is providing.
-It is specially recommended to apply a structured methodology for data modeling. On this topic the Eurofiling architecture approach is proposing a methodology on normalization called Data Point Modeling. This will be introduced later in chapter 6, but it mainly consists on defining a method to model dictionary data, their aspects and relationships in terms of domains and hierarchies, the business validation rules and the corresponding classifications of the data in different tables and forms for filing and visualization.
+Regulators who elect to adopt XBRL for internal information systems will need to consider how to adapt
+existing systems for XBRL integration and data analysis.
-<center> [[Image: CEN_DPM-clarificationDiagram.jpg]]<br />
+All national regulators across Europe are responsible for defining their local regulation and communicating
-'''Figure 2: Diagram describing the DPM process and its relationship with XBRL.'''
+with their reporting entities. Existing, internal systems vary significantly between national regulators and some
+will need to adapt more than others to meet the new European directives. The purpose of this section is to
+establish a common set of high level guidelines based on current best practices that could apply for the
+internal use of XBRL in regulatory reporting to help realise the benefits of using a standard method of data
+exchange across Europe.
+The European framework and the XBRL International abstract model version 2.0 provide a clear method to
+enable consistent definition of business information. Aligning the adaptation of internal systems with align
+those methodologies is foreseen as the key to driving better regulatory practice across Europe.
+Making use of automated business-rule validation on reported data will help to assure high quality data and
+reduces the processing time associated with manual checks allowing more time to analyse and dedicate to
+analysis real supervisory activity. The creation of data-warehouses based on XBRL taxonomy frameworks and
+models will facilitate access to reporting information through the different perspectives of regulatory reporting
+(compliance, risk, prudency, transparency).
+In conclusion, adapting internal systems to work with XBRL reporting carries several advantages:
+:* full utilisation of the multi-dimensional data models and XBRL frameworks provided by European authorities, allowing use of OLAP-enabled databases and exploit this information for integration and analysis and regulatory activity using business intelligence tools;
+:* reuse and take advantage of native XBRL formula validation across multiple reporting documents to ensure the quality and consistency of the data submitted by the reporting entities saving time and effort in the process using multi-instance sub-module of the specification.
+===Prepare the communication plan for Reporting Entities===
+Once the regulator has defined all reporting requirements and project plan to adapt information systems to
+support the exchange of reporting information using XBRL, it will be required to establish a clear plan for
+communicating the new regulatory process to reporting Entities.
+This communication need to cover several steps to be actions taken by the national regulator to involve their
+main reporting entities as early as possible to ensure a smooth transition to new processes and new
+technology in the process normative.
+We recommend that national regulators hold periodic plenary sessions with the reporting entities under their
+jurisdiction to facilitate successful communication about XBRL adoption and implementation roadmap.
+Example content could include:
+:* communicating the perimeter of the new recommendations;
+:* presenting a technical overview of XBRL taxonomy frameworks and the DPM methodology used;
+:* presenting how to reduce the impact on current data exchange processes with reporting entities;
+:* communication of expected timelines for compliance.
+Other successful XBRL programs around the globe have found it beneficial to create an "''Early Adopters''"
+program between the national regulatory Authority and a reduced number of major reporting entities. The
+“''Early Adopters''” program can be used to set up an initial proof of concept for XBRL reporting exchange and
+facilitate the success of a full rollout.
+The main benefits of an “''Early Adopters''” program are:
+:* to refine the process in the receipt and acknowledgement of XBRL reports;
+:* to enable the reporting entities to study the new requirements, to analyse any potential impact in their business models, to realise the estimation effort required and develop or adapt their IT systems to support XBRL;
+:* to test the performance of services deployed by the national regulator in terms of processing, security enforcement, integrating, analysing and validating XBRL reports.
+===Summary===
+During this section the regulatory supervisor has been able to introduce all the topics required to establish a
+roadmap to adapt their systems and plan the new reporting information system to rollout.
+=How to implement and extend XBRL taxonomies=
+One of the key challenges faced by regulators when adopting the XBRL standard is to fit the reporting
+requirements set by European frameworks and directives into existing national supervisory and compliance
+processes.
+In most of the cases, the flexibility of the XBRL standard will allow the national supervisor to fulfil both
+requirements. Mechanisms to implement and extend taxonomies are likely to vary from one to another.
+The objective of this section is to provide a set of guidelines to facilitate a harmonized approach to XBRL
+implementation collected from previous national XBRL adoptions across Europe.
+The main objectives in regulatory reporting are: maintain data accuracy, data transparency, regulatory
+compliance and process interoperability.
+===European Framework background information===
+The scope of this section focuses on the European framework for regulatory reporting. Under this context,
+there are currently two major European Authorities that will drive the application of a harmonized reporting
+using XBRL. And therefore will address the corresponding recommendations in terms of implementation and
+extension of taxonomies for regulatory supervisors:
+:* Taxonomy frameworks of the European Banking Authority (EBA): COREP and FINREP;
+:* Taxonomy framework of the European Insurance and Occupational Pensions Authority (EIOPA) for Solvency II.
+<br /><center>
+[[Image:EuropeanFrameworkInitiatives2.jpg]]<br />
+'''Figure 3 — European Taxonomy Frameworks Diagram'''
 </center>
+<br />
+<br />
+These two authorities have been developing XBRL implementations which form the basis of the European
+frameworks pillars for supervisory reporting (Basel II, Solvency II and Financial Statements).<br />
+<br />
+Eurofiling initiative is an open collaboration between groups of experts, including regulatory reporting experts
+from EBA, EIOPA, XBRL Europe and other volunteers working on a common project to collect the regulatory
+reporting practice across Europe. The cross-sector definitions common to Solvency II, COREP and FINREP is
+most likely to be defined in the ''[http://www.eurofiling.info]'' namespace and location.<br />
+<br />
+National regulators will use the taxonomies defined by these authorities to implement their regulatory reporting
+process in accordance with national law and EU directives.<br />
+<br />
+In terms of XBRL implementation those National adoption will represent the third namespace owner for
+reporting (covering the national GAAP)1 as shown in figure 4 below.<br />
-:* How this data inherited from the European frameworks fits into the national reporting model. Study if the current information models for reporting entities have more disclosures or information. In case more detailed information is required, knowledge on the extension of European taxonomies is needed. This will be detailed in chapter 5.
+<center>
+[[Image:CEN_TaxonomyImplementationExtensionDiagram2.jpg]]<br />
+'''Figure 4 — National Supervisor Regulatory Extension Diagram'''
+</center>
+<br />
+Table 1 shows an example on the owners and namespaces and owner prefixes for the used to establish the
+institution that defines the different concepts to be reported in the corresponding models.<br />
+<br />
+<center>
+[[Image:OwnerNamespaces_pic1_2.png]]<br />
+'''Table 1 — Owner namespaces and prefixes example'''
+</center>
+[SOURCE: EBA Representation in XBRL of the Data Point Model]<br />
 <br />
-:The regulator will have to answer several questions before taking decisions that will mark their path to the reporting processes. These questions can be one of the following:<br />
+Another example on use is the EIOPA Solvency II XBRL Preparatory Taxonomy where we can find a similar
-::* How many different reporting templates do we need to receive from reporting entities?
+use of cross-sector definitions on EuroFiling owner namespace differentiated from EIOPA institution as owner
-::* What is the frequency of this reporting information quarterly, half-yearly, yearly?
+of solvency II concept definitions:<br />
-::* What is the smallest reporting unit of information to receive?
-::* What is the maximum recommended size for each report to receive?
+<center>
-::* What is the response time of the received reporting information?
+[[Image:EiopaSAmpleNamespaces-pic2_2.png]]<br />
-::* Is it allowed to submit partial reporting information?
+'''Table 2 — Example of owner Namespaces, prefixes and official locations'''
-::* Is it allowed to re send reports or partial reports for amendments after submission?
+</center>
+[SOURCE: EIOPA Solvency II XBRL Preparatory Taxonomy]<br />
+The use of different levels of reporting definitions identified by the use of owner, namespace, prefix and
+location, provides a proper method to harmonize the use of definitions and concept frameworks across
+Europe. For technical details on taxonomy architecture nomenclature refer to CEN Agreement document
+CWA1.
+<br />
 <br />
-===Adapt and Review reception infrastructures===
+===XBRL Standard extension Mechanism===
-From the IT's perspective the regulators will have the opportunity to review their current transmission infrastructures with the reporting entities to incorporate the new reporting standard to their channels:<br />
-In case the regulator has well established mechanisms in place, the required activity is to adapt these circuits to interchange XBRL instance documents, including additional circuits of submission for header information and validation reports following recommendations given in document (CWA2) and they will be introduced later in chapter 8.<br />
+XBRL is extensible. This means that the set of concepts defined in a taxonomy framework can be reused in
+local taxonomies using the import tag mechanism inherited from XML Schema definition of taxonomies as the
+next figure 5 illustrates:
+<br />
+<center>
+[[Image:CWA3TaxonomyExtension2.jpg]]<br>
+'''Figure 5: Import tag mechanism'''
+</center>
+<br />
+In the example of the figure 5 is shown the local national taxonomy schema es-be-rp22.xsd is using the
+concepts defined in the European taxonomy framework COREP extending the XSD schema defined in
+www.c-ebs.org for the t-c1-2006-07-01.xsd schema
 <br />
-A set of items to review are:
+<br />
-:* Select, reuse or adapt the transmission channel (web secure portal upload, email secure smtp, web service secure integration submission, other). This item will be further elaborated during the workshop to refer to final recommendations to be given from CWA2.
+It is important to notice that when a taxonomy extends another schema using the xsd:import mechanism all
-:* Select, reuse or adapt the security signature and certificates to be used for reporting entities.
+the inherited concepts to be used in the local taxonomy schema are referred with the corresponding
-:* Select the additional services on the submission protocol to implement (tracking or monitoring information submitted, visualization on reported instances, pre validation on regulatory requirement information, etc.)
+namespace (in this example the c-ebs namespace indicated that could be assigned to a concrete namespace
+prefix to shorten and be used along the relationships and local definitions (table rendering, formula assertions,
+dimension relationships, etc.)
+<br />
+<br />
+One of the recommendations when extending taxonomies is to fully qualify the schema location URL for the
+taxonomy resource we are extending, instead of using a local copy or a relative location.
 <br />
-===Adapt and Review internal Information systems===
+===Guideline for creating extension taxonomies===
-For those regulators that are adopting XBRL into their internal information systems, it is required to adapt and review how to fit the received information according to XBRL semantics into their information systems. This will permit to take advantage of the standard using OLAP models, formula validation across multiple reporting documents and exploiting the information using business intelligence tools. <br />
-Currently there are few national supervisors that can set a common set of recommendations to follow to be part of this section, as each national internal system is outside the scope of harmonization topics of this document. <br />
+A national regulator extending one of the European Framework taxonomies should take into account the
+following set of basic principles to facilitate efficient regulatory oversight, consistency of supervision and
+reduction of redundant data collection:<br />
+# '''''Simplicity of the reporting process''''': the resulting regulatory taxonomy architecture must focus on simplification of instance document creation.
+# '''''Stability''''': the application of the regulatory taxonomy architecture must minimize the impact of changes resulting from amendments to consuming systems.
+# '''''Consistency''''': the framework under the regulatory taxonomy architecture must be consistent in design and the taxonomies must be coherent and explicit.
+# '''''Compliance with specifications, best practices and related taxonomies''''': the regulatory taxonomy architecture must conform as much as possible to the approaches inherited from related projects (Level 1 and Level 2).
+# '''''Maintainability''''': the regulatory taxonomy architecture framework must be easy for supervisors to maintain.
+# '''''Performance''''': the application of the regulatory taxonomy architecture should result in other technical advantages including reduced size of instance documents, better performance in processing (e.g. DTS loading, validation),
+# '''''Review and avoid duplicate redefinition of concepts'''''. When extending existing taxonomy frameworks one of the common practices is to redefine a concept that does not match the local definition exactly. This practice should be avoided as far as possible to reduce complexity in the final framework aggregation. The current modularization of taxonomy frameworks and well documented metrics and aspects of the model allows a better adaptation to local redefinitions instead of building a new set of duplicated concepts for local purposes.
+# '''''Avoid redefinition of extended templates'''''. One of the lessons learned from early versions of European frameworks is that the extension mechanism to prohibit relationships or dimension definitions (grey cells not allowed for extended reporting templates) at the end is not a good practice in terms of taxonomy complexity and maintainability. In cases where the reporting template in a local extension is different the recommended approach is to define a new reporting template reusing as many of the existing concepts, metrics, relationships and aspects of the base taxonomy and then compound the concrete local aggregations, table, rendering and views.
-A clear assessment regarding internal adoption is that the European framework and the XBRL International abstract model version 2.0 provide a clear method to enable consistent definition of business information. Including rules and validations that facilitates the creation of XBRL data-warehouses to access and analyze reporting information through the different perspectives of regulatory reporting (compliance, risk, prudency, transparency).<br />
+As a summary the extensions should take into consideration the following high level guidelines:
+:* reduction of redundant or duplicate definitions;
+:* standardization, simplification;
+:* reduced information friction to facilitate (more) continuous monitoring and audit of controls;
+:* consistency of regulatory supervision;
+:* facilitate efficient regulatory oversight;
+:* maintain the coherence and consistency of the base taxonomy model.
+=Architecture, Methodology and Best Practices=
+==Introduction==
+Some reference documents that regulators should consider reading are:
+# '''''"An Architecture for European XBRL Taxonomies"''''' (EXTA [1]) where a description in the followingtopics is described:
+:* supporting concepts (Owner, Model supporting schema, Namespaces);
+:* public elements;
+:* dictionary of concepts (Metrics, Dimensions, Families, Perspectives, Domains, Explicit domain[2] members and hierarchies );
+:* reporting requirements layer (Frameworks, Taxonomies, Tables, Modules, Validation rules);
+:* architecture.
+#  '''''"Data Point Modelling Methodology"''''' (DPM Methodology [2])"
+#  '''''"Abstract description of the model represented in taxonomies following the DPM approach"''''' (Abstract Model 2.0 [3])
+#  '''''"Comparison of Conceptual, Logical and Physical models vs. the Data Point Modelling"''''' (Comparison DPM [4])
+<br /><br />
+This section will introduce regulators to the current design techniques and implementation approach used to
+represent financial models defined by European Regulators. It is important to become familiar with the
+terminology used in the European XBRL Architecture and Data Point Modelling Methodology, as these will be
+the base of best practice recommendations in terms of creating financial models based on European
+regulatory frameworks.<br />
 <br />
-===Prepare the communication plan for Reporting Entities===
-Once the regulator has taken all required actions to adapt the information systems to support the interchange of reporting information using XBRL, it is required to establish a clear communication plan for reporting Entities.<br />
-This section will be further elaborated during the workshop with information and references to the Declarer’s Handbook.<br />
+'''''XBRL Abstract Model version 2.0''''': defines the reference to understand and better design in a separate and
+consistent form the financial and business models and rules that conforms the aspects, concepts,
+relationships and formulae of the information to be modelled. Introduce an important decoupling vision for
+business reporting chain that enables design, architecture and implementation of XBRL.<br />
+<br />
+'''''Data Point Model''''', also known as DPM Methodology: A set of guidelines, based on a long track record in
+regulatory reporting modelling, describing methods for the definition and identification of the data exchanged
+in reporting frameworks. It establishes a systematic method to represent and describe the data to be reported.
+Using a data centric approach where properties are assigned to defined ‘data points’, including all their
+semantic aspects and relationships to give precision to their meaning.<br />
+<br />
+'''''XBRL Architecture''''': based on the dictionary of concepts modelled previously, this defines the set of technical
+definitions and rules that will enable the implementation of the model using the XBRL standard language in
+the reporting systems. This architecture should be used as a reference to ensure common practice across
+implementations to enable interoperable, consistent and harmonized reporting. To achieve this goal the
+architecture is intended to provide a set of definitions with a concrete structure to implement the model. It is
+intended to be flexible and open enough, based on previous XBRL implementation for European financial
+reporting framework versions, giving conventions in the way to implement the concrete frameworks.<br />
+<br />
+<br />
+==Context for a Reference Architecture==
+'''''XBRL standard has been adopted in Financial Supervisory Reporting'''''
+:* Public and Private Financial Statements for National Regulators extending COREP and FINREP taxonomy frameworks are in place in several countries across Europe.
+:* National financial statements using GAAP taxonomy definitions based on IFRS reporting.
+:* All these initiatives have required several changes in their current IT systems to integrate XBRL.
+:* Lack of Native XBRL treatment XBRL considered as a format ignoring the semantic information provided by the XBRL taxonomies.
+<br /><br />
+'''''Architectures on Distributed Systems have been established during last 10 years'''''
+:* Service Oriented Architectures enable modular implementation in the Architecture Stack.
+:* There are several Layers in the reference Reporting Architecture to decouple the external reporting reception with the internal processing and analytic systems:
+::* security Layer;
+::* front End and reception layer;
+::* middle Processing and XBRL treatment Layer;
+::* Integration and Analytic Layer.
+<br /><br />
+==Steps for implementation==
+'''''Launch an internal Proof of Concept project. Benefits:'''''
+:* Appropriate to evaluate XBRL requirements, functional services and technical processing capabilities to implement and adapt the information systems.
+:* It will enable a proper feedback on results for designing the different processes to build.
 <br />
-===Summary===
+<br />
-During this chapter the regulatory supervisor has been able to introduce all the topics required to establish a roadmap to adapt their systems and plan the reporting information adaptations to produce.<br />
+'''''Extend the reporting XBRL PoC to the architecture layers:'''''
+:* Design the Functional Architecture and their modules.
-Final conclusions will be further elaborated during the workshop based on input from the teams to summarize the  section with a diagram of concepts addressed (introduce, adapt, and communicate).<br />
+:* Review current product market status in XBRL processing, validation and reporting tools.
+:* Identify Information systems where to extract, collect, validate, receive or analyze the reporting information.
+:* Review the performance requirement on current implementation vs. XBRL PoC results.
+:* Identify the interfaces and transformations to be completed to current data information (messaging, data models, validations to run, storage and exploit systems, etc.).
+<br />
+<br />
+'''''XBRL Technical Architecture definition. Adapt and deploy the different technical architecture to
+support XBRL reporting process:'''''
+:* Define how to process XBRL information (natively using processors, products or tools, direct programming transformations building custom components, other, etc.).
+:* Adapt Development Environment: Integration tools for development teams to provide taxonomy editors/viewers, XBRL Processor for validation and formula editing, APIs to extract and compose data reported to the current integration components to exploit the information).
+:* Define or adapt Methodology for XBRL development and deployment.
+:* Define or adapt XBRL Process and Services catalogue to orchestrate the XBRL component execution in current integrated systems (different operational flows for XBRL reception, validation, storage and integration on Data Warehouse).
+:* Deploy XBRL components packaged with other infrastructure and security services (certificate, signature, reporting management policies, etc.) including performance designs.
+==XBRL Reference Architecture==
-----
+According to The Open Group Architecture Framework (TOGAF2)) architecture lifecycle (figure 6), a XBRL
+reference Architecture is a concrete specialization of The Open Group distributed Architecture in which
+services have been implemented to cover the functionalities of the reporting chain.<br />
 <br />
-<span style="background-color:yellow">The remaining open points will be further elaborated during the workshop based on input from the teams</span><br />
+<center>[[Image:TOGAFarchitecture.JPG]]<br>
+'''Figure 6 — TOGAF Architecture Lifecycle diagram'''
+</center>
+<br />
+[SOURCE: commons.wikimedia.org TOGAF ADM (Architecture Development Method) - The Open Group]<br />
+<br />
-:* Variety of Information Domains
+The information presented in this document and the reference documentation indicated at the beginning of the
-:* Variety of Information collection methods
+section will provide background information to help regulators to establish the goals of Preliminary phase and
-:* Gaming internal management support
+steps A and B in the lifecycle illustrated above.<br />
-:* Internal knowledge documentation
+<br />
-:* Explaining value for reporting entities
+The following section focus on steps C and D to complete the reference architecture for XBRL
-:* Data governance processes
+implementations, based on best practice across Europe.<br />
-:* Multiple approaches to XBRL implementations in other countries
-:* Legacy reporting requirements
-:* Obsolete and duplicated data
-:* Changing legal requirements
-:* Analysis of software requirements
-:* Monitoring Implementation
-:* Review data collected
-:* Data processing performance
 <br />
-=How to implement and extend XBRL taxonomies=
-One of the key challenges that regulators is facing when adopting XBRL standard is to fit the reporting requirements given by European frameworks and directives into the existing national supervisory and compliance processes. <br />
-In most of the cases the flexibility of the XBRL standard allows the national supervisor to fulfil both requirements, while the mechanisms to implement and extend taxonomies vary from one to another.<br />
+===Functional Architecture===
-The objective of the present chapter is to provide a set of guidelines collected from previous national XBRL adoptions across Europe that have been harmonized in several ways.<br />
-The regulatory reporting's main objectives are to keep data accuracy, transparency, compliance and interoperability.<br />
+For national regulators the Functional Architecture is the first step in designing the building blocks where the
+architecture layers will be implemented.<br />
+<br />
+The reporting cycle between parties will drive the different modules to be implemented. A typical set of
+functions could be:<br />
+<br />
+'''Interface with Reporting Entities'''
+:* Submit and receipt module
+::* Receipt of XBRL Reporting Data
+::* Consistency checking of reported information (XBRL valid 2.1) [1]
-===European Framework background information===
+:* Reporting Entities Front Services
-The scope of this chapter will focus on European framework for regulatory reporting. Under this context, there are currently two major European Authorities that will drive the application of a harmonized reporting using XBRL. And therefore will address the corresponding recommendations in terms of implementation and extension of taxonomies for regulatory supervisors:<br />
+::* Report follow up and status management
+::* Auxiliary services (visualization, taxonomy repository reference, form filling application)
-:* EBA Taxonomy frameworks:  COREP and FINREP
+'''Data Reporting Treatment'''
-:* EIOPA Taxonomy framework for Solvency II
+:* Data Validation Module
+::* XBRL advanced validation (formula, rules, and additional data compliance)
+::* Error and validation results reporting communication
+:* Data consumption and integration processes
+::* Post process data information
+::* Permanent record and storage on back office systems
+:* Analyst Information Services
+::* Preparation of data for internal reporting systems
+::* Integrate in Business Intelligence systems implemented in Data Warehouses (DW) and / or DataMarts (DM)
+:* Expectation Handling
+::* Due Dates
+::* Messages sent to late filers
+::* Confirm all expected set of data have been received
+:* Monitoring and Statistics
-<br /><center>
-[[Image:EuropeanFrameworkInitiatives.jpg]]<br />
+<br />
+<br />
+===Technical Architecture===
+According to the Functional architecture defined, the Technical reference architecture should at least enable
+decoupling reporting entities services from middleware data treatment components and the backend
+repositories and systems:<br />
+<br />
+'''Interface with Reporting Entities'''
+:* Multi-channel reception
+:* Access security services
+<br />
+<br />
+'''Middleware Processing Services'''
+:* XBRL Services
+::* Dedicated components and frameworks to process, validate and treat the reported data
+::* XBRL Repository (taxonomies and reports are stored, cached and retrieved to support )
+:* Infrastructure
+::* Platform dependent components to trace, secure, transform, adapt, route and integrate.
+<br />
+<br />
+'''Backend Systems Integration'''
+:* Messaging and Integration services
+::* To transform, adapt, convert and store into the different systems:
+:::* Corporate BackOffice
+:::* Data Warehouse systems (DW)
+:::* Relational Data Base Management Systems (RDBMS)
+:::* Department systems
+::* An Enterprise Service Bus with adaptors and connectors to internal systems
+:*Analytic Packages and Business Intelligence Tools
+::*Prepare and Post process data information
+<br />
+<br />
+As a summary, the figure 7 illustrates an overview diagram with the typical technical components and services
+that make up an XBRL Technical Architecture of Reference.<br />
+<br />
+<center> [[Image:CWA3XBRLarchitecture2.JPG]]<br>
+'''Figure 7 — XBRL Technical Architecture of Reference Overview'''
 </center>
-These two authorities have been developing the XBRL implementations that are the basis of the European framework pillars for supervisory reporting (Basel II, Solvency II and Financial Statements).
-Eurofiling as a common an open initiative represents the groups of experts on regulatory reporting from EBA, EIOPA and XBRL Europe and other volunteers that have been working in a common project to collect the regulatory reporting practice across Europe. The cross-sector part for Solvency II and new COREP and FINREP is most likely to be defined in the http://www.eurofiling.info namespace and location.<br />
-National Supervisors in their adoption will use those taxonomies to their regulatory reporting according to the study on the national laws and application of the EU directives.<br />
+The specific implementation technology selected for these services is fully dependent on each National
+Supervisor Authority (NSA), and out of the scope of these guidelines.<br />
+<br />
+Our recommendation is to invest enough time during the preparation phase to select specific technologies for
+each service, to determine the optimal solution in terms of products, tools or custom development frameworks
+and their functional coverage. As a good practice to ensure the success of the solution, we recommend
+creating a Proof of Concept (PoC) during the preparation phase to verify appropriate technology integration,
+performance and service quality that is required for the operational system, and allow time for refinement of
+the initial design.<br />
+<br />
+The evolution of this reference architecture is foreseen as distribute computing resources to process data
+using better computing capacities and storage facilities to optimize by scaling these resources. Several rising
+technologies like cloud computing and big data analytics are establishing new environments to process and
+find new correlation on collected information. Those technical architectures oriented towards separation of
+services implementation are better prepared to be evolved to these new technologies with less effort and
+investment. According to the TOGAF lifecycle we have introduced the initial steps for XBRL Architecture
+definition in National Supervisors.<br />
+<br />
+The next steps for the regulator will be to identify the concrete service implementation according to their
+needs.<br />
+<br />
+=Management and maintainability=
+==Introduction==
+This section describes how regulators should approach maintenance and management of taxonomy
+frameworks supporting regulatory reporting in XBRL. It explains taxonomy lifecycle and other relevant
+concepts.<br />
+<br />
+XBRL taxonomies3 define and represent the final format for the exchange of financial information between
+reporting entities and regulators. The taxonomies implements the model defined at a business level.
+Therefore, any change to normative regulation is likely to require an update to the definitions in the taxonomy.<br />
+<br />
+The nature of these changes could be caused mainly by adding new reporting templates or requirements, or
+by making adjustments or corrections to the existing model, or other causes related to re-implement with a
+better adequacy to XBRL standard recommendation updates (generic linkbase, formula recommendation,
+table linkbase), etc.,<br />
+<br />
+All these changes will need to be reflected in an updated version of the taxonomy framework, i.e. the set of
+files and resources (called Discoverable Taxonomy Set or DTS) that defines the XBRL reporting systems.<br />
+<br />
+All regulators using XBRL should follow a set of best practices to successfully handle taxonomy updates and
+should also take into consideration the correct synchronization and communication of these versions and
+changes to their reporting entities.<br />
+<br />
+==Publish the normative taxonomy framework==
+Firstly, the normative taxonomies must be published.<br />
+<br />
+The European National Supervisor should provide a public repository (website accessible by default) which
+provides access to the latest taxonomy framework version. This would facilitate to their reporting entities to
+access all files required to prepare the XBRL reports (enable the software applications to check, validate and
+process the XBRL taxonomy frameworks)<br />
+<br />
+One topic that needs harmonization across Europe is to coordinate the different XBRL European reporting
+taxonomy frameworks and their public repositories and location.<br />
+<br />
+Currently there are national supervisor is providing a local copy of the European taxonomy for their national
+extensions.<br />
+<br />
+Our recommendation is to refer to each authority’s repository (website by default) to find the normative
+taxonomy framework documents (for example Eurofiling for common schemas, EBA for COREP and FINREP,
+EIOPA for Solvency II. National regulators should host local taxonomy extensions on their own national
+repository (website)...<br />
+<br />
+Using this approach will facilitate the reporting entities to collect and use all corresponding resources for a
+given taxonomy framework. So the XBRL processing components can retrieve the set of Uniform Resource
+Locators (URLs) that build up the Discoverable Taxonomy Set (DTS) to be reported.<br />
+<br />
+Figure 8 illustrates an example of the banking area of domain localization for European taxonomy frameworks:<br />
+<br />
-In terms of XBRL implementation those National adoption will represent the third namespace owner for reporting (covering the national GAAP):
 <center>
-[[Image:CEN_TaxonomyImplementationExtensionDiagram.jpg]]<br />
+[[Image:LocalizationEuropeanTaxonomyFrameworks2.jpg]]<br>
-'''Figure 1 — National Supervisor Regulatory Extension Diagram'''<br />
+'''Figure 8: Repository taxonomy example Diagram'''
 </center>
-An example will be included during the workshop based on input from the teams about namespace domain URIs and taxonomy owners.<br />
+<br />
-===XBRL Standard extension Mechanism===
+==Taxonomy Cache Mechanism==
-<span style="background-color:yellow">XBRL standard mechanism to extension will be further elaborated during the workshop to introduce and use</span><br />
-:*What is an extension [final definition will be further elaborated during workshop]. Purpose of extending European regulatory framework taxonomies -> the objective is to add more disclosure on base information (in some cases could be used also to restrict not applicable regulatory reporting information)
+Most reporting systems based on XBRL rely on obtaining a local copy of all distributed resources that conform
-:*namespaces [final definition will be further elaborated during workshop] owner of data defined and protected namespaces level 1 and level 2
+to the taxonomy framework in their repositories on the Internet, in order to process the information models and
-:*flexibility
+to validate the data created in their reporting systems offline.<br />
-::*XBRL is extensible --> adaptation to national discretions
+<br />
-::*Modularised architecture of XBRL
+It is good practice to use this cache mechanism from several European taxonomy frameworks in the
-::*Structural changes in the data are not reflected in the instance
+processing software to gain in efficiency and performance for the reporting applications and systems.<br />
-:*One common format is more cost-effective than a numerous number of different proprietary formats
+<br />
+The following recommendations for taxonomy caching should be considered:
+:* National regulators should publish in their website detailed information for the latest version of their extension taxonomy created. This information should include: Links to previous versions and the dates for which they were in use, schema file names and namespaces, URLs of published documents, date and versions of taxonomy resources for the local national extension and references to the external European authority resources and common definitions.
+:* The reporting entity should use software capable of to retrieve all files in the corresponding Discoverable Taxonomy Sets (DTSs) to check if the cached version stored in the local copy corresponds to the last one published by the national supervisor in order to process XBRL reports.<br />
+<br />
-:*versioning
+<center>
+<center>
+=Annex A (informative)=
+</center>
+<center>
+==Terms and Definitions==
+</center>
+'''Eurofiling'''<br />
+The Eurofiling project is an open joint initiative of the European Banking Authority (EBA) and the European
+Insurance and Occupational Pensions Authority (EIOPA) in collaboration with XBRL Europe, as well as
+stakeholders as banks, solutions providers, academics and individuals. Eurofiling's main contributions are
+Data Models, XBRL taxonomies, know-how and documentation for Supervisory Frameworks: COREP,
+FINREP and Solvency II.<br />
+<br />
+'''European System of Financial Supervisors (ESFS)'''<br />
+Before and during the financial crisis in 2007 and 2008, the European Parliament has called for a move
+towards more integrated European supervision in order to ensure a true level playing field for all actors at the
+level of the European Union and to reflect the increasing integration of financial markets in the Union. As a
+result, the supervisory framework was strengthened to reduce risk and severity of future financial crises. The
+European System of Financial Supervisors comprises three European Supervisory Authorities, one for the
+banking sector (EBA), one for the securities sector (European Securities and Markets Authority, ESMA) and
+one for the insurance and occupational pensions sector (EIOPA), as well as the European Systemic Risk
+Board4 .<br />
+<br />
+'''European Banking Authority (EBA)'''5)<br />
+The European Banking Authority (EBA) is an independent EU Authority which works to ensure effective and
+consistent prudential regulation and supervision across the European banking sector. Its overall objectives are
+to maintain financial stability in the EU and to safeguard the integrity, efficiency and orderly functioning of the
+banking sector.<br />
+<br />
+The main task of the EBA is to contribute to the creation of the European Single Rulebook in banking whose
+objective is to provide a single set of harmonised prudential rules for financial institutions throughout the EU.
+The Authority also plays an important role in promoting convergence of supervisory practices and is mandated
+to assess risks and vulnerabilities in the EU banking sector.<br />
+<br />
+The EBA was established on 1 January 2011 as part of the European System of Financial Supervision (ESFS)
+and took over all existing responsibilities and tasks of the Committee of European Banking Supervisors.<br />
 <br />
-===Guideline on Extensions===
-<span style="background-color:yellow">[Extension recommendations will be further elaborated during workshop including a , list of best practice to follow based on the input of the teams.]</span><br />
-A taxonomy extending the European Framework should at least take into account a set of basic principles to facilitate efficient regulatory oversight, consistency of supervision and reduction of redundancies and duplications in their implementation:<br />
-# '''''Simplicity of the reporting process''''': the resulting regulatory taxonomy architecture must focus on simplification of instance document creation.
+'''COREP and FINREP'''<br />
-# '''''Stability''''': the application of the regulatory taxonomy architecture must minimize the impact of changes resulting from amendments of information requirements on consuming systems.
+To achieve a high level of harmonization and strong convergence in regular supervisory reporting
-# '''''Consistency''''': the framework under the regulatory taxonomy architecture must be consistent in design and the taxonomies must be coherent and explicit.
+requirements, the EBA has been developing guidelines on supervisory reporting with the aim of setting up a
-# '''''Compliance with specifications, best practices and related taxonomies''''': the regulatory taxonomy architecture must conform as much as possible to approaches inherited from related projects (Level 1 and Level 2).
+supervisory reporting model with common data definitions. The Guidelines on Financial Reporting cover
-# '''''Maintainability''''': the regulatory taxonomy architecture must allow for the framework be easy to maintain by supervisors.
+consolidated and sub-consolidated financial reporting for supervisory purposes based on IAS/IFRS
-# '''''Performance''''': the application of the regulatory taxonomy architecture should result in other technical advantages including reduced size of instance documents, better performance in processing (e.g. DTS loading, validation),
+(International Accounting Standards/International Financial Reporting Standard) as endorsed by the European
+Union. The original Guidelines on FINREP were issued by the Committee of European Banking Supervisors
+(CEBS) in December 2005. Agreed changes in IFRS were incorporated into the latest FINREP V1 published
+in December 2009.<br />
+<br />
+Due to Capital Requirements Regulation under CRD IV, further major changes to the accounting standards
+which will impact COREP and FINREP during 2013. The revised COREP and FINREP Taxonomy is expected
+to be published by the end of 2013 to take into account the new Implementation Technical Standard of these
+requirements.<br />
 <br />
-*Reduction of redundancies and duplications
+'''European Insurance and Occupational Pensions Authority (EIOPA)'''6)<br />
-*Standardization, simplification
+The European Insurance and Occupational Pensions Authority (EIOPA) was established in consequence of
-*Reduced information friction to facilitate (more) continuous monitoring and audit of controls
+the reforms to the structure of supervision of the financial sector in the European Union. The reform was
-*Consistency of Regulatory Supervision
+initiated by the European Commission, following the recommendations of a Committee of Wise Men, chaired
-*Facilitate Efficient Regulatory Oversight
+[5]
-*keep the coherence and consistency of the model
+by Mr. de Larosière, and supported by the European Council and Parliament.<br />
+<br />
+EIOPA’s main goals are:
+:* better protecting consumers, rebuilding trust in the financial system;
+:* ensuring a high, effective and consistent level of regulation and supervision taking account of the varying interests of all Member States and the different nature of financial institutions;
+:* greater harmonisation and coherent application of rules for financial institutions & markets across the European Union;
+:* strengthening oversight of cross-border groups;
+:* promote coordinated European Union supervisory response.
+<br />
+EIOPA’s core responsibilities are to support the stability of the financial system, transparency of markets and
+financial products as well as the protection of policyholders, pension scheme members and beneficiaries.
+EIOPA is commissioned to monitor and identify trends, potential risks and vulnerabilities stemming from the
+micro-prudential level, across borders and across sectors.<br />
+<br />
+EIOPA is an independent advisory body to the European Parliament, the Council of the European Union and
+the European Commission.<br />
 <br />
-=Architecture, Methodology and Best Practices=
+'''SOLVENCY II'''7)<br />
-<span style="background-color:#A9D0F5">This chapter links to CWA1.</span><span style="background-color:yellow">Use also references to documents drafted before and if not enough clear for roll-out package as a new supervisor, rewrite or add sample information to them.</span><br />
+The Solvency II Directive 2009/138/EC is an EU Directive that codifies and harmonises the EU insurance
-Some reference document to analyze are:
+regulation. Primarily this concerns the amount of capital that EU insurance companies must hold to reduce the
-# '''''"An Architecture for European XBRL Taxonomies"''''' where a description in the following topics is described:
+risk of insolvency.<br />
-#:* Supporting concepts(Owner, Model supporting schema, Namespaces)
+<br />
-#:* Public elements
+Once the Omnibus II directive is approved by the European Parliament, Solvency II will be scheduled to come
-#:* Dictionary of concepts (Metrics, Dimensions, Families, Perspectives, Domains, Explicit domain members and hierarchies)
+)9)
-#:* Reporting requirements layer (Frameworks, Taxonomies, Tables, Modules, Validation rules)
+into effect.<br />
-#:* Architecture
+<br />
-# '''''"Data Point Modelling Methodology"'''''
-# '''''"Abstract description of the model represented in taxonomies following the DPM approach"'''''
-# '''''"Comparison of Conceptual, Logical and Physical models vs. the Data Point Modelling."'''''
+<center>
+==Bibliography==
+</center>
+<br />
+<br />
-This chapter will introduce to regulators the current design techniques and implementation approach used in representing financial models defined by European Regulators. It is important to get familiar with terminology used in European XBRL Architecture, and Data Point Modelling Methodology, as these will be the base of best practice recommendations in terms of creating financial models based on European regulatory frameworks, as it is the perimeter of present document.
+[1] EXTA. European XBRL Taxonomy Architecture, Declerck, Thierry; Hommes, Roland; Heinze, Katrin. Eurofiling.
+http://www.xbrlwiki.info/index.php?title=European_XBRL_Taxonomy_Architecture<br />
+<br />
+[2]
+DPM
+Methodology.
+Data
+Point
+Modelling
+(DPM)
+Methodology.
+http://www.eurofiling.info/cen/wp-content/upLoads/data/DPM_methodolgy.docx
+Morilla,
+Victor.
+Eurofiling.<br />
+<br />
-; '''XBRL Abstract Layer version 2.0''' : Defines the reference to understand and better design in a separate and consistent form the financial and business models and rules that conforms the aspects, concepts, relationships and rules of the information to be modelled. Introduce an important decoupling vision for business reporting chain that enables design, architecture and implementation of XBRL.
+[3] XAM2.0. XBRL Abstract Model version 2.0, Frankel, D.; Fischer, H.; Foster, W.; Lam, R.; 2012 June. XBRL
+International Inc. http://xbrl.org/Specification/abstractmodel-primary/PWD-2012-06-06/abstractmodel-primary-pwd-
+-06-06.html<br />
+<br />
-; '''Data Point Model, also known as DPM Methodology''' : Is a set of guidance methods, based on long track experience in supervisory reporting modelling, for the definition and identification of the data exchanged in reporting frameworks. It establish a robust and consistent method to represent and describe the data to be reported as the centre of definition, and all the semantics that belong to the data giving precision to its meaning
+[4] Comparison Models DPM. Comparison of Conceptual, Logical and Physical models vs. the Data Point Modelling.
+Santos, I. 2012 August. Eurofiling, http://www.eurofiling.info/cen/wp-
+content/upLoads/data/ComparisonModels_DPM.docx<br />
+<br />
-; '''XBRL Architecture''' : Based on the dictionary of concepts modelled previously, it defines the set of technical definitions and rules that will enable the implementation of the model using XBRL standard language in the reporting systems. The architecture will be the guideline to ensure common practice across implementations to enable the interoperable, consistent and harmonized reporting. To achieve this goal the architecture will give enclose in a concrete structure using a set of definitions the possible open alternatives to implement the model, based on past XBRL implementation for European financial reporting frameworks versions, giving conventions in the way to implement the concrete frameworks.
+[5] DPM Formal Model. Abstract description of the model represented in taxonomies following the DPM approach.
+European Banking Authority. 2012 December. Eurofiling.: http://www.eurofiling.info/finrepTaxonomy/DPM-Formal-
+Model.pdf<br />
+<br />
-=Management and maintainability=
+[6] De Larosière Report. The High-Level Group on Financial Supervision in the EU. Report. de Larosière, J.; Balcerowicz,
-This chapter should include all topics related to how the supervisor is facing the taxonomy frameworks usage, repository location and management, mirror and caching procedures to check different and current version and also extension visibility to make the harmonization of taxonomies transparent to other countries (if possible, at least as a recommendation on best practices).  It will be further elaborated during workshop based on the input of the teams.<br />
+L; Issing, O.; Masera, R.; Mc Carthy, C.; Nyberg, L.; Pérez, J.; Ruding, O.; Brussels, Belgium. February 25th, 2009.
+European Commision. http://ec.europa.eu/internal_market/finances/docs/de_larosiere_report_en.pdf<br />
+<br />
-This would cover localization (in terms of how to physically locate), availability and download. <br />
+[7] EIOPA-SII-PoC. Preliminary Information on the EIOPA Solvency II DPM and XBRL Taxonomy Framework Architecture.
+March. EIOPA. https://eiopa.europa.eu/publications/eu-wide-reporting-formats/index.html<br />
+<br />
-It should be worth noting the necessity to add a link or task to CWA2 in order to see the possibility to study the use of taxonomy package descriptor (from corefiling) as suggested by coordinator group management.<br />
+[8] SII Taxonomy Consultation. Consultation on the Solvency II XBRL Taxonomy. 2011. EIOPA.
+https://eiopa.europa.eu/consultations/consultation-papers/2011-closed-consultations/july-2011/consultation-on-the-
+solvency-ii-xbrl-taxonomy/index.html<br />
+<br />
-:* transparency
+[9] ITS-DPM. Implementing Technical Standard (ITS) on Supervisory Reporting (Data Point Model). European Banking
-:** Comparability of data across Europe
+Authority. 2013 July. http://eba.europa.eu/regulation-and-policy/supervisory-reporting/implementing-technical-
-:** Possibility of a faster exchange of information with regard to the financial crisis
+standard-on-supervisory-reporting-data-point-model-<br />
-:** Versioning will be supported
+<br />
-:** Open source
-:* validation
+[10] EBA TS. Technical standards on supervisory reporting. European Banking Authority. 2012 February.
-:** Validation via standardised approaches
+http://eba.europa.eu/documents/10180/16010/2012_02_20_ITS_on_reporting_including-feedback.pdf+<br />
-:** Extensive possibilities for formula definitions
+<br />
-:** Summarisation of formulas --> reduction of the amount of formulas
-:** No need for specific in-house solutions for the reporting entities
-:* harmonisation
+[11] TOGAF. TOGAF® Version 9.1. The Open Group Technical Standard. 2011 December.
-:** Approach is in line with the reconciliation for an harmonised reporting in the EU
+https://www2.opengroup.org/ogsys/catalog/g116<br />
-:** Uniform validation rules can be used
+<br />
-:** Allows cooperation on a unified data basis (i.e. Colleagues of Supervisors)
-:** Enables an effective analysis of cross-border financial institutions
-:* standardisation
+[12] XBRL-ES Tec. XBRL White Paper Technology Working Group. 2005 March. XBRL Spain Technology Working Group.
-:** Assures competitive capacity
+http://www.xbrl.org.es/downloads/libros/White_Paper.pdf<br />
-:** Eases the exchange with other European countries
+<br />
-:** Enables the use of standardised technology
-:** Eases interoperability
-:** Minimises risks
-:** No other standardised business reporting standard exists
-=How to transmit, process, and validate instances=
+[13] XBRL Books. XBRL Spain. 2012. http://www.xbrl.es/downloads/libros/XBRL_books.pdf<br />
-This chapter will be further elaborated during workshop including the reference of conclusions from CWA2, and all topics related to how the supervisor is facing the taxonomy frameworks usage.<br />
+<br />
-----
+[14] XBRL 2.1 Rec. Extensible Business Reporting Language (XBRL) 2.1. Engel, P.; Hamscher, W.; Shuetrim, G.; vun
+Kannon, D.; Wallis, Hugh; XBRL International Inc. Dec 2003-Jan2012. http://www.xbrl.org/specification/xbrl-
+recommendation-2003-12-31+corrected-errata-2012-01-25.htm<br />
 <br />
-'''Bibliography''' <br />
-[1]	xxx
+[15] XBRL Dim 1.0. XBRL Dimensions 1.0. Sep 2006 - Jan2012. Hernández-Ros , I.; Wallis, H.; XBRL International Inc.
+available at: http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-
+errata-2012-01-25-clean.html<br />
+<br />
-[2]	xxx
+[16] Formula Overview. Formula and related specifications. Shuetrim, G; XBRL International Inc. June 2009.
+http://www.xbrl.org/Specification/formula/REC-2009-06-22/overview/Formula-Overview-REC-2009-06-22.rtf<br />
+<br />

European Regulatory Roll-out Package guide

From XBRLWiki

Current revision

Contents

Scope

How to start with XBRL. Supervisory Perspective

Determine the level of XBRL adoption

Plan and prepare the new reporting models

Review existing reception infrastructure

Review internal information systems

Prepare the communication plan for Reporting Entities

Summary

How to implement and extend XBRL taxonomies

European Framework background information

XBRL Standard extension Mechanism

Guideline for creating extension taxonomies

Architecture, Methodology and Best Practices

Introduction

Context for a Reference Architecture

Steps for implementation

XBRL Reference Architecture

Functional Architecture

Technical Architecture

Management and maintainability

Introduction

Publish the normative taxonomy framework

Taxonomy Cache Mechanism

Annex A (informative)

Terms and Definitions

Bibliography

Views

Personal tools

Navigation

Search

Toolbox