The key to effective integration

This post is the second post in a series about how to build effective integrations between a DW/BI solution and an XBRL based reporting solution such as CRD IV or Solvency II. The previous post can be found here. In this post we describe how you can make your integration with your DW/BI solution more effective.

Knowing that there are great similarities between the XBRL structure and the classical dimensional model used in most Data Warehouse / Business Intelligence (DW/BI) solutions the possibility of reusing the DW design for your CRD IV/Solvency II reporting should be something to consider. Assuming that you have a DW/BI solution in place you would want to make sure that you have

  1. the same numbers in your internal BI reports as you have in your external reporting
  2. an effective and cost effective integration with your external reporting solution.

In order to make sure that you have the same numbers in your external and internal reporting you need to make sure that your dimensional model supports both types of reporting. In this instance you can consider the external reporting solution (or your XBRL vendor) as just an other reporting solution. many organizations use for example Excel for analytics, Reporting services for static reports and Qlik or Tableau for graphical ineractive reports. In this scenario your XBRL vendor would be one more reporting solution. In this way we base all the reports on the same values using the same data model and we should confident that we also get the same numbers.

How then do we get an efficient integration from the DW to the XBRL provider? One way of doing this is to basically export “fact tables” using the XBRL tags from your Dimension tables as keys/references. This should allow your XBRL solution map incoming numbers to it’s own internal data model and after that the templates should be populated automatically. What’s the down side? Well, you need to define what goes where. That is, how liquid are your assets, where are your exposures and so on. What’s the upside? That you should do this anyway and after the initial cost of defining and developing the integrations you will have a reporting solution that is faster, more reliable and in synch with your inernal reporting. Another advantage is that this strategy puts the power and the bargaining chips in your hand by decoupling your data and your design from your XBRL vendor.

What if you don’t have a BI solution yet? Can your CRD IV/Solvency II reporting be used to help you define your DW/BI solution? Can you have one solution for both? Ofcourse!

Dirept can help you define and design your DW architecture and we can even host your DW/BI solution and make sure that it is integrated properly with our XBRL generation.

Contact us at info@dirept.com.

How does XBRL relate to Business Intelligence?

Dirept is a company with a background in Business Intelligence and Data Warehousing. The reasons that we decided to build a solution for XBRL based regulatory reporting is that there was a shortage of high quality solutions that at the same time were easy to use but also because we recognized that the XBRL structure is a very familiar structure. In this half techy post we will explain how they are related and you should have atleast a basic understanding of Data Warehousing modeling principles. First we walk through the structure of an XBRL file.

An XBRL file is basically an XML file with four differnt sections:

  • The header
  • The filing indicators
  • The contexts
  • The metrics

The header and the filing indicators basically say what you intend to report.

The contexts and the metrics on the other hand relate very closely to dimensions and facts in the Business Intelligence (BI) world. A context in an XBRL file is a list of dimensions and the specific member of each dimension. This set of dimensions matches the foreign key (FK) section of a fact table in a data warehouse (DW). In a BI solution the combination of the FKs point out which attributes can be used to intrepret the specific metrics of that row. Basically a context in an XBRL file can be perceived as a specific row (or a grouped number of rows) in a specific fact table. The difference is that in a fact table you generally use a “dumb” int value wheras in a an XBRL context you use a global, unique and persistent code provided by the taxonomy issued by the supervising agency.

Unfortunately the codes used don’t make any sense when you watch them in the XBRL file. In order to understand the XBRL codes (from the EBA) you basically have three options. Look at the excel files, the many taxonomy files or the MS Access database. The easiest one, but also the most limited one, is ofcourse the one published in excel. Using these sources you can learn how the contents of your reports relate to the contents of your BI solution. This is also the basis of effective integrations between your BI solution and your reporting solution. More on that in the future!

If you are interested in more information about XBRL and how it relates to BI we are happy to help.

Swedish FSA rules two validation rules as incorrect

The swedish FSA finansinspektionen today ruled two of the EBAs validation rules as incorrect. The two rules should only be run if you are reporting the Corep report C 04. The two validation rules are:

  • e4887_e – Existence Assertion ID: eba_e4887_e Message: e4887_e: [C 04.00] {C 04.00, r850, c010} != empty
  • e4888_e – Existence Assertion ID: eba_e4888_e Message: e4888_e: [C 04.00] {C 04.00, r860, c010} != empty

The bugs in the validations rules were found by Dirept together with one of our clients. Since basically all of the Europan FSAs use the taxonomy from the EBA there is a great risk that your system provider or even your FSA are not yet aware of these bugs. The EBA has provided an excel sheet on the first of june 2017 where they have corrected these validation rules but it has not yet propagated all the way to all system providers and FSAs.

If you are interested knowing more about this error or products or our services you ar welcome to contacts us at info@dirept.com


Fi meddelar att valideringsreglerna stängs av

I vår förra nyhetsartikel skrev vi att vi tillsammans med en av våra kunder identifierade en bugg i FinansInspektionens validering av inlämnade filer. FI har idag meddelat Dirept att valideringsreglerna är felaktiga och att de nu stängs av. De berörda valideringsreglerna är:

  • e4887_e
  • e4888_e

Detta innebär att vår kund nu har möjlighet att rapportera in sin XBRL fil.

För Dirept är detta en naturlig del av vår kostnadsfria support, där vi dels hjälper våra kunder att identifiera eventuella brister i sin egen rapportering men även att vi hjälper kunden i dialogen med FI, för att säkerställa en godkänd inlämning av XBRL-rapporterna.

Bugg i FIs mottagning av filer

En av Direpts kunder som rapporterar tidigt har sprungit på en bugg kring hur EBA/FI hanterar valideringarna i den nu gällande taxonomin. Vi har skickat en fråga till Finansinspektionen angående deras implementering av EBAs valideringsregler och hur de planerar att hantera buggen.

Om du har några frågor kring årets XBRL-raportering till FI så är du välkommen höra av dig till oss på Dirept. Skicka bara en rad till info@dirept.com

Nedan kan du se felmeddelandet som vår kund fick

  • Fel: Validator: Formula; Message: Existence Assertion ID: eba_e4887_e Message: e4887_e: [C 04.00] {C 04.00, r850, c010} != empty
  • Fel: Validator: Formula; Message: Existence Assertion ID: eba_e4888_e Message: e4888_e: [C 04.00] {C 04.00, r860, c010} != empty

I korthet så innebär buggen att FinansInspektionen förväntar sig att rapporteringsskyldiga bolag ska ha fyllt i ett antal celler som finns i rapporteringsmallar som det rapporteringsskyldiga bolaget inte ska rapportera. Effekten blir att bolagen antingen inte lämnar in en XBRL-fil och väntar på att FI förklarar hur valideringsregeln ska hanteras eller att bolagen även fyller i C 04 mallen och riskerar göra fel när man rapporterar siffror som man inte har förberett.

Är ditt bolag skyldigt att rapportera? Tveka inte att kontakta oss så hjälper vi dig att få in en godkänd XBRL-fil med hjälp av vårt lättanvända system.