ADVERTISEMENT
Time is ticking away and the first round of Solvency II reporting cycle is just about to begin. With the growing concern and arising questions about readiness, timeliness and all measures being in place, decision-makers in insurance undertakings have just started to look around for options to handle regulatory reporting burden in a better way. One of the most important changes, apart from new rules for capital requirements’ calculations and necessity to incorporate holistic oversight of entities’ risk-related matters, has been the reinforcement of regulatory reporting processes with the mandate on using XBRL technology along the way.
In prior years there was a heated debate on how insurers should approach the implementation of XBRL to actually benefit from it. Fortunately, many insurers were able to postpone their investments in the accommodation of XBRL into their current ICT infrastructure and processes thanks to Tool for Undertakings (T4U) provided by EIOPA. However, limited process automation capabilities and enterprise’s level support offered with this tool might be insufficient for some undertakings, especially with the prospect of EIOPA budgets being slashed by European Commission which may further adversely impact the future development of the tool.
Although it seemed quite a good idea at first, because it helps undertakings to familiarize with the technology, it may also discourage some of them from active participation in technological shift from the outset. Remaining in limbo can be hazardous in the long-term. Since submission date is approaching rapidly it may be the right time to restore the discussion about the importance of XBRL in future reporting in insurance sector.
Uncertain regulatory environment
The landscape of regulatory reporting has undergone significant changes in recent years and new regulations are looming on the horizon. While the impact of regulatory environment has always been indisputable in financial services industry, Solvency II has introduced many novelties into disclosure processes and risk management practices for undertakings. Solvency II rules are more overarching in nature, thus essentially requiring insurers to dwell on all aspects of their businesses. It is said that NCAs of banking sectors and the EBA would like to rely more on the assessment of data governance practices than stress-test data starting from 2017. This new approach means that supervisors will be getting more interested in looking through internal functions of entities. It is probable that undertakings will be subject to similar requirements under Solvency II.
Currently, meeting the regulatory regime is considered challenging but what future prospects may bring is even more daunting requirements. Undertakings will be under pressure to adapt quickly their disclosure processes and continuously innovate in the area of streaming, profiling, cleansing, enriching, validating and delivering large amount of data. All of these must be circumscribed into year-by-year narrowing time frame for submissions.
On top of that, insurers must carefully observe changes in regulations in other areas of the financial sector. Many undertakings often offer products with clauses that go beyond standard insurance business, such as pension-like schemes. Also, with current dissatisfaction with the returns of sovereign bonds, insurers are becoming more interested in the commercial mortgage market and in funding long-term infrastructure projects.
In the future, it is expected that supervisor will require more granular data from undertakings. The AnaCredit project in banking sector is not the only example where XBRL is considered seriously as a reporting format. The trend is clear. XBRL is the most promising of all semantic technologies in the reporting field available on the market. Its widespread adoption is inevitable but the pace will depend on the XBRL learning curve of undertakings and regulators.
Versioning of data model and taxonomy
XBRL provides very rich syntax to define reporting concepts and relationships between them of various nature. Like COREP/FINREP, the Solvency II taxonomy has been modeled using Data Points Methodology (DPM) which is based on systematic use of constructs from definition linkbase to express every characteristic of each reporting item (i.e. data point) e.g. measurement basis, instrument type, amount type or settlement principles applied etc. This allows to describe data points, which are represented as facts in instance documents, in an unambiguous and unique manner. That, in turn, enables to build high quality conceptual model (Data Points Model, also DPM) of the reporting framework and translate it into robust XBRL taxonomy.
Beyond doubt, Data Points Model is very handy educational tool. It helps taxonomy recipients to understand the underlying regulatory data content requirements. Most often, the discovery process of this content and building first DPM conceptual model results in excessively dimensional taxonomies which are later turned into so-called Highly Dimensional (HD) layer. The discussion about its usability is still open, however there are well-known issues and concerns about modelling data in this way. One of these may be problems in reaching satisfactory performance (consequences: higher hardware requirements, maintenance costs and more processing-time needed) due to large number of breakdown/dimensions which generate a plethora of contexts in instance documents. The question about the actual usage of these dimensions and benefits they bring for business users is also valid. In practice, it seems that filtering through overabundant breakdowns to reach desirable data can be troublesome or inconvenient at least. To solve this problem EIOPA came up with the idea of Medium (MD) layer. In a nutshell, it is about reducing as many breakdowns as possible but keeping the uniqueness of each data point at the same time. The easiest way to achieve that is to create new distinct XBRL elements whose names are derived from the concatenation of names of original elements and associated breakdowns modeled in HD layer.
It is expected that the underlying conceptual model will undergo similar changes as FINREP/COREP did in prior years. This means not only the normalization of SII XBRL taxonomy itself but it will also break ground for harmonization of metrics and breakdowns between these reporting frameworks. Of course, it will not happen overnight but since the evolution of the DPM conceptual model is imminent, then maintenance and versioning of taxonomies snap into focus. In general, there are four sources of changes that have impact on SII taxonomy:
- Updates to regulations, Implementing Technical Standards (ITS), accounting standards and other legally binding documents that determine the reporting scope.
- Updates to XBRL base specification and its modules (e.g. Extensible Enumerations).
- Updates totheimplementationofXBRL technology by regulator:
- new custom XML constructs implemented by regulator to facilitate processing (e.g. Filling Indicators);
- changes in modelling of data points (addition/reduction of breakdowns);
- changes in modularization of the taxonomy (references, and paths in schemas and linkbase files);
- changes in the arrangement of tables (layout and structural model in table linkbase); and
- changes in the assertions implementing business rules to be verified for the report on the level of taxonomy and database.
- Errata, e.g. spelling errors, small refinements in breakdown compositions of data points.
All of these must be taken into account when building efficient ETL processes and mappings between cells in Quantitative Reporting Templates (QRT) and data points of the taxonomy. From our brief market survey we conclude that these processes are not fully automated and often engage a lot of human resources e.g. regular meetings between IT specialists and business experts.
One thing is certain: EIOPA will continually release new versions of Solvency II taxonomy. Only this year, four new releases of the taxonomy are planned. The implementation process of these changes can be hard to cope for those undertakings who will have to update various components of their solution and processes separately. This will require much more time, resources, and it is far more prone to errors. Only flexible XBRL solutions can deal with this prospect. It is popular for undertakings, who have not yet formulated long-term strategy in this area, to rely on software vendors who offer not only tools for easy Excel-XBRL conversions but also a wide array of other tools facilitating the streamline and mapping of source data with XBRL taxonomy.
XBRL Versioning Specification[1] does not resolve all issues related to multidimensional DPM-based taxonomies. One of major EU regulators of banking sector uses, for example, one central database repository built upon star-schema which is able to store all metrics, domains, dimensions and relationships (arcs, resources used in definition, formula and table linkbases etc). All changes in taxonomies are updated incrementally with date stamps, which means that nothing is deleted from the model. Thanks to this approach, it is feasible to compare taxonomies at various points in time as well as to generate the taxonomy directly from database. It should be noted that undertakings also need to have these capabilities. In some cases they have to resubmit their reports that must be compliant with earlier versions of the taxonomy. While building sustainable solutions they have to take into account the versioning issues.
Detecting and fixing errors in the instance document
Validation is a key element of every XBRL-based submission process. This is what differentiates good XBRL processing engines from the best ones. There are many software vendors that offer products with similar functionalities, but the devil lies in the details, so the approach how to handle certain validations is something that makes a difference. In general, undertakings should consider solutions that offer at least the following:
- Rendering of tables based on Table Linkbase Specification – visualization of fact space with all headers and labels that is legible and easy-to-use for business users.
- Validation against general XBRL syntax, i.e. XBRL Specification 2.1 and Dimensions.
- Validation against European Filing Rules defined by EIOPA – these rules are intended to uniform some technical aspects of instance documents (putting constraints on the use of some XBRL constructs) to increase processing capabilities of collection systems e.g. filling indicators and context consistency checks.
- Validation against XBRL Formula Linkbase e.g. business rules that define existence and reconciliation checks (column/row aggregations, ‘cross-refs’ and other value consistency checks).
It is also possible to implement assertion checks for more complex business rules in order, for example, to automate some compliance and assurance processes of internal audit functions of the entity. For now, however, it is paramount for undertakings to focus on four sets of functionalities mentioned above to submit successfully their XBRL reports.
The other concern, but equally important, is a swift error handling. It is almost certain that some errors will be thrown while preparing instance documents. Standard error messages in traceback format are often not meaningful for business users and therefore they need assistance from IT experts. The disclosure process could be delayed and turn out to be more time-consuming than expected. It could be resolved, to some extent, by solutions that combine user-friendly interface with the functionality of linking user-definable error output with location of errors.
The native support of XBRL formula validations is another thing that is hard to implement and, therefore, most of software vendors find ways to cut corners. They offer workarounds with intermediary formats to validate business rules and claim outstanding processing times. However, these methods make the whole validating process less reliable and highly vulnerable to taxonomy changes. Problematic as it could be, it is definitely harder to industrialize disclosure processes in the long run.
The native support of XBRL formula provides a big advantage in the case when validation rules modifications have been done during the solution lifecycle. That is why it is worth to consider from the very beginning implementation of a solution which allows for validation of instances with respect to a taxonomy in accordance with the XBRL specifications, and European Filing Rules. It will significantly cut down development effort and maintenance cost to absolute minimum.
At Fujitsu, we understand what challenges our clients face and the resilience of XBRL solutions that is needed to meet all regulatory requirements.
Our significant investment in software research and development gives our customers confidence that they will be equipped with highly scalable XBRL solutions that will address their current and future needs.
[1] It is used mostly in flat and hybrid taxonomies e.g. IFRS or US-GAAP
About Fujitsu
Fujitsu is the leading Japanese Information and Communication Technology (ICT) company offering a full range of technology products, solutions and services. Over 162,000 Fujitsu people support customers in more than 100 countries. Fujitsu applies their experience and power of ICT to shape the future of society with their customers.
Fujitsu is an industry leader in XBRL area helping organizations in all aspects of XBRL implementations with 13 years of proven track record and excellence. Our presence in XII working groups and deep commitment in the development of XBRL standard drive and facilitate its adoption worldwide.
Fujitsu combines a unique set of software engineering competences with invaluable insights into XBRL technology implementations. Our dedication to deliver top quality and customer-oriented solutions is invariably praised by our clients. We are proud that our flagship XBRL solutions are implemented by over 220 major financial market supervisors and global financial services institutions from 50 countries.
FUJITSU Software Interstage XWand is 100% compliant with XBRL standard and taxonomy agnostic which means that once you implement our software package you can work with any XBRL taxonomy regardless of the underlying accounting frameworks.
Interstage XWand provides a framework for incorporating XBRL into applications that can analyze, collect, and disclose financial information in the shortest period of time. With modular architecture, ease-of-use and a comprehensive API, Interstage XWand enables rapid development of feature-rich, industrial strength XBRL applications.
We are continuously engaged in advancing our comprehensive XBRL suite to meet growing demands of our clients in respect to XBRL engine performance. Our recent optimization activities, conjoint efforts of Fujitsu’s development team and European supervisors, resulted in unparalleled improvements in loading and processing times of large instances, table linkbase processor’s rendering time (including the problematic tables with Z-axis and not pre-determined number of records- open tables) as well as validation times of XBRL business rules.
We stay abreast of the implementation of all modular extensions to XBRL specification and increasing performance needs in XBRL data processing. Our solutions allow for efficient XBRL processing purely in-memory, i.e. without intermediary formats, and enable both ‘bolt-on’ implementation and deep integration with any technologies and platforms depending on the organization readiness. This is something that differentiates and puts us head and shoulders above the competition.
Our global presence, high level of customer service, combined with our technical skills, innovative XBRL products and network of experts on hand for consultation have helped others to succeed.
For more information about Interstage XWand please visit our website http://www.fujitsu.com/xwand or contact Center of Excellence for EMEA region: [email protected], tel. (+48 12) 429 43 45.
]]>
