From XBRLWiki

CEN Workshop Agreement

Status: Working Group Working Draft

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 is a working document.
This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.
This document is a working document.

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 implement this CWA would be expected to consider all recommendations where the term “should” is used.

Contents 1 Scope 2 Normative references 3 Terms and definitions 4 How to start with XBRL. Supervisory Perspective 4.1 Determine the level of XBRL adoption 4.2 Plan and prepare the new reporting models 4.3 Adapt and Review reception infrastructures 4.4 Adapt and Review internal Information systems 4.5 Prepare the communication plan for Reporting Entities 4.6 Summary 5 How to implement and extend XBRL taxonomies 5.1 European Framework background information 5.2 XBRL Standard extension Mechanism 5.3 Guideline on Extensions 6 Architecture, Methodology and Best Practices 6.1 Context for a Reference Architecture 6.2 Steps for implementation 6.3 XBRL Reference Architecture 6.3.1 Functional Architecture 6.3.2 Technical Architecture 7 Management and maintainability 7.1 Publish the normative taxonomy framework 7.2 Taxonomy Cache Mechanism 8 Bibliography

Scope

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.

This CWA have divided the work/deliveries in two difference parts:

i) An XBRL supervisory roll-out guide: this is oriented towards national regulators on how to implement, extend and manage XBRL taxonomies

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)

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.

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

Some text

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.

EN xyz:199x, Title of the european standard.

EN ab c:199x, General title of series of parts — Part c: Title of part.

Terms and definitions

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

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

EIOPA is an independent advisory body to the European Parliament, the Council of the European Union and the European Commission.

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.

Once the Omnibus II directive is approved by the European Parliament, Solvency II will be scheduled to come into effect. [1] [2]

How to start with XBRL. Supervisory Perspective

This chapter describes how the XBRL standard can be implemented from the regulator's perspective.

First is presented the different levels of XBRL adoption, defining the supervisor's strategy.

This is followed by elaborating the minimum amount of steps needed to facilitate a proper introduction of the XBRL standard.

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.

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.

The following picture give an overview on the activities described in the chapter

Figure 1 —The Business Overview to Rollout XBRL reporting (Source: 24th XBRL International Conference: Academic Track 6)

Determine the level of XBRL adoption

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.

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:

• Using XBRL only as the electronic format of interchange.
• 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.

Plan and prepare the new reporting models

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.

Compliance with new regulation directives implies the adequacy of the reporting business models and rules to the XBRL language and semantics to be implemented.

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

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:

• 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.

We have assumed that the XBRL adoption is driven by a new reporting directive. But could be considered as an alternative that the adoption of XBRL is only a technology evolution on current reporting systems. This implies that the business models do not change and the reporting files and formats are being adapted to XBRL in a transparent way to the end users.

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.

Figure 2: DPM process and XBRL relationship (Source: Abstract description of the model represented in taxonomies following the DPM approach).

• 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 "How to implement and extend XBRL taxonomies".

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:

• How many different reporting templates do we need to receive from reporting entities?
• What is the frequency of this reporting information quarterly, half-yearly, yearly?
• What is the smallest reporting unit of information to receive?
• What is the maximum recommended size for each report to receive?
• What is the response time of the received reporting information?
• Is it allowed to submit partial reporting information?
• Is it allowed to re send reports or partial reports for amendments after submission?

Adapt and Review reception infrastructures

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:

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.

A set of items to review are:

• 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.
• Select, reuse or adapt the security signature and certificates to be used for reporting entities.
• 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.)

Adapt and Review internal Information systems

For those regulators that are adopting XBRL into their internal information systems, it is required to adapt and review how to integrate the received information according to XBRL semantics into their information systems.

Due to the fact that inside Europe each National Supervisor is responsible to define their local adaptation to their reporting entities, the internal systems are ranged from a very different landscape. 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 helping to enable the cross Europe practice.

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. To align those methodologies in current adaptation on internal systems is foresee as the key option to drive a better regulatory practice evolution across Europe. Including rules and validations on reported data facilitate the data quality automation reducing time in the process to check the data and allowing more time to analyse and dedicate to the 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).

As a conclusion, adapting the internal systems to XBRL reporting enable several advantages:

• Reuse the new multi-dimensional data models that conforms the XBRL standard for European supervisors using for example OLAP models to collect, integrate and exploit this information for analysis and regulatory activities 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.

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.

This consists on several actions taken by the National Supervisor Authority to involve since the beginning their main reporting entities in the process to adapt the new normative fully aligned with the corresponding technology changes.

During the roadmap of this communication plan it is recommended to establish periodic plenary sessions with reporting entities. An example on the content could be:

• to communicate the perimeter of the new recommendations
• to share the technical overview on XBRL taxonomy frameworks and DPM modelling methodology used
• to reduce the impacts on current interchange processes that the reporting entities would have to adapt.

As a recommendation it is proven to facilitate the adoption to create an "Early Adopters" program between the National Supervisor Authority and a reduced numbers on the major reporting entities to set up an initial proof of concept for XBRL reporting exchange.

The main benefits of this practice are:

• to refine the process in the reception and acknowledgement of XBRL reports
• to enable the reporting entities to study the impacts and effort to adapt to XBRL requirements
• to improve the performance of services deployed in the National Supervisor in terms of processing, integrating and validating XBRL reports.

Summary

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 new reporting information system to rollout.

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.

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.

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.

The regulatory reporting's main objectives are to keep data accuracy, transparency, compliance and interoperability.

European Framework background information

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:

• EBA Taxonomy frameworks: COREP and FINREP
• EIOPA Taxonomy framework for Solvency II

Figure 3 — European Framework Initiatives Diagram (Source: Atos Risk & Compliance Reporting)

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.

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.

In terms of XBRL implementation those National adoption will represent the third namespace owner for reporting (covering the national GAAP):

Figure 4 — National Supervisor Regulatory Extension Diagram (Source: Atos Risk & Compliance Reporting)

See an example at Preliminary Information on the EIOPA Solvency II DPM and XBRL Taxonomy Architecture Page 35: III.3.3.1 Taxonomy levels


An example will be included during the workshop based on input from the teams about namespace domain URIs and taxonomy owners.

XBRL Standard extension Mechanism

• - XBRL is extensible --> adaptation to national discretions

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:

Figure 5: Example of Taxonomy Extension

In this example we can see that 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

It is important to notice that when a taxonomy extends another schema using the xsd:import mechanism all the inherited concepts to be used in the local taxonomy schema are referred with the corresponding 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.)

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.

Guideline on Extensions

[Extension recommendations will be further elaborated during workshop including a , list of best practice to follow based on the input of the teams.]

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:

1. Simplicity of the reporting process: the resulting regulatory taxonomy architecture must focus on simplification of instance document creation.
2. Stability: the application of the regulatory taxonomy architecture must minimize the impact of changes resulting from amendments of information requirements on consuming systems.
3. Consistency: the framework under the regulatory taxonomy architecture must be consistent in design and the taxonomies must be coherent and explicit.
4. 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).
5. Maintainability: the regulatory taxonomy architecture must allow for the framework be easy to maintain by supervisors.
6. 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),
7. Review and avoid duplicate redefinitions on concepts: When extending existing taxonomy frameworks one of the common practice is to redefine one concept that does not match exactly in the local normative with the European definition. This practice should be avoid as much as possible to reduce complexity in the final framework aggregation. The current modularization on 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.
8. 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 those cases where the reporting template in local extensions is different the recommended approach is to define a new reporting template reusing as much as possible the already defined concepts, metrics, relationships and aspects of the extended taxonomy framework and then compound the concrete local aggregations, table, rendering and views.

As a summary the extensions should take into consideration the following high level guidelines:

• Reduction of redundancies and duplications
• Standardization, simplification
• Reduced information friction to facilitate (more) continuous monitoring and audit of controls
• Consistency of Regulatory Supervision
• Facilitate Efficient Regulatory Oversight
• keep the coherence and consistency of the model

Architecture, Methodology and Best Practices

This chapter is taking the input from the recommendations set on CEN Workshop Agreement CWA1
Some reference document to analyze are:

1. "An Architecture for European XBRL Taxonomies" where a description in the following topics is described:

   • Supporting concepts(Owner, Model supporting schema, Namespaces)
   • Public elements
   • Dictionary of concepts (Metrics, Dimensions, Families, Perspectives, Domains, Explicit domain members and hierarchies)
   • Reporting requirements layer (Frameworks, Taxonomies, Tables, Modules, Validation rules)
   • Architecture

2. "Data Point Modelling Methodology"
3. "Abstract description of the model represented in taxonomies following the DPM approach"
4. "Comparison of Conceptual, Logical and Physical models vs. the Data Point Modelling."

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.

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.

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

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.

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 as a format versus XBRL as semantic information

• 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
• Bus Integration and Analytic Layer

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.

*Extend the reporting XBRL PoC to the architecture layers:

• Design the Functional Architecture and their modules.
• 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.).

• 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 DWH).
• 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 architecture lifecycle defined be the TOGAF [The Open Group Architecture Framework ], an XBRL reference Architecture is a concrete specialization of The Open Group distributed Architecture in which the services have been implemented to cover the functionalities of the reporting chain.

Figure 6 — The TOGAF Architecture Lifecycle diagram Origin of the diagram missing

For the objective of present document guidelines, the reference documentation indicated at the beginning of the chapter will provide background information to help regulators to establish the goals of Preliminary phases and A and B steps in the lifecycle. The following section will focus on steps C and D to complete the reference architecture for XBRL implementations, based on best practice across Europe.

Functional Architecture

For Regulatory Supervisors the Functional Architecture is the first step in designing the building blocks where the architecture layers will be implemented. The reporting cycle between parties will drive the different modules to be implement. A typical set of functions for example are:

• Interface with Reporting Entities

• Reception Module

• Reception of XBRL Reporting Data
• Consistency Check of Reporting information (XBRL valid 2.1)

• Reporting Entities Front Services

• Report follow up and status management
• Auxiliary Services (visualization, taxonomy repository reference, Form Filling application)

• Data Reporting Treatment

• 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
• Record and Storage on back office systems

• Analyst Information Services

• Prepare data for internal reporting systems
• Integrate in Business DWH and Datamart systems

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:

• Interface with Reporting Entities

• Multi channel reception

• Access security services

• 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.
• Backend Systems Integration

• Messaging and Integration services

• To transform, adapt, convert and store into the different systems:

• Corporate BackOffice
• DWH systems
• RDBMS systems
• 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

As a summary the following overview diagram gives an idea on the typical technical components and services that conforms an XBRL Technical Architecture of Reference.

Figure 7 — XBRL Technical Architecture of Reference Overview

The specific implementation technology selected for these services is fully dependent on each National Supervisor Authority, and out of the scope of these guidelines.

The recommendation is to invest during the preparation enough time to select for each specific service the optimal solution in terms of products, tools or custom development frameworks to cover them. A Proof of Concept is envisaged during this preparation phases to ensure the proper technology integration, performance and service quality required for the operational system to be integrated.

The future guidelines on this reference architecture today indicate that the evolution on the delocalization of resources will provide an optimization on scaling the computing capacities and storage facilities using technologies that are starting to be mature in several environments (Cloud computing and Big Data analytics). As much the separation of services implementation with the concrete middleware and hardware infrastructure the better scale up and future evolution of the architecture for the national supervisor.

Conclusion According to the TOGAF lifecycle we have introduced the initial steps for XBRL Architecture definition in National Supervisors. The next steps will introduce each service as a reference on best practice implementation. [TbD ?]

Management and maintainability

In this chapter it will be described the main concepts to take into account by a regulator to maintain and manage the taxonomy frameworks lifecycle that gives support to regulatory reporting in XBRL.

At the end of the day the taxonomies represents the final format for financial information interchange and it is fully based in the data models defined at business level. Therefore, any change to that normative regulation will impact in a change of the taxonomy.

The nature of these changes could be caused by adding new reporting templates or requirements, doing some adjustments or corrections to existing model, etc.

Then, all these changes will be reflected in an updated taxonomy frameworks version, i.e. the set of files and resources that conforms the XBRL reporting systems.

As a conclusion each regulator using XBRL should follow a set of best practices to handle properly those taxonomy versions and should also take into consideration the proper synchronization and communication of these versions and changes to their reporting entities.

Publish the normative taxonomy framework

First important recommendation is to maintain the normative taxonomies published:

• The European National Supervisor should provide a public repository (website accessible by default) to the current 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)

One topic that needs harmonization across Europe is to coordinate the different XBRL European reporting taxonomy frameworks and their public repositories and location.

Currently each national supervisor is providing a local copy on European taxonomy for their national adaptation extensions. The recommendation is to refer to each authority repository (website by default) where the normative taxonomy framework referred is used (for example Eurofiling for common schemas, EBA for COREP and FINREP part, EIOPA for solvency II, and each national supervisor website for the local part).

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 URLs that build up the DTS to report.

The following diagram provides an example on the banking area of domain localization for European taxonomy frameworks:

Figure 8: Localization for European taxonomy frameworks

Taxonomy Cache Mechanism

Most of current reporting systems based on XBRL to elaborate reports, uses a mechanism to obtain a local copy of all distributed resources that conforms the taxonomy framework in their repositories on Internet, in order to process the information models and to validate the data created in their reporting systems.

It is a good practice to use several taxonomy cache mechanisms from European frameworks in the processing software to gain in efficiency and performance for the reporting applications and systems.

This relies in a set of recommendations:

• the supervisor publishes in their website a detailed information on the most up to date version of the normative taxonomy framework to be used, including links to previous versions and due dates. Some examples on the detailed information are: File Schema names and namespaces, URLs, date and version of resources that conforms the taxonomy, for the local National extension, and also the reference to the external European authority resources and common part.
• The reporting entity should use software capable to retrieve all corresponding taxonomy headers for the main schemas 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

Bibliography

[1] xxx

[2] xxx