How to submit periodic reporting to financial regulators with the new XBRL format
July 17, 2017
Financial institutions has to perform periodic reporting to their local regulator, like Finansinspektionen in Sweden. With ever changing directives from the local regulator and the European Union the reporting can pose quite a problem with a lot of confusion. In order for the regulated companies to fullfil the reporting requirements it is necessary that the regulator can supply good documentation with details about what should be submitted and how this is done in practice. For example the Swedish Tax Agency offers great documentation with technical specifications with regards to how data should be delivered and how the files should be structured.
During the last couple of days we have worked with our partner and customer Kreditbörsen, which is a payment service provider that uses parts of the Bricknode platform and its partner Lendysoft as its back end in order to deliver its peer to peer lending platform.
The Swedish Financial Inspection (“SFI”) has a page with information regarding Periodic reporting but we deemed it very hard to understand and that is why we created this article as supplementary documentation.
As a payment service provider Kreditbörsen should report every six months where the report should contain the payment volumes together with the capital adequacy for the company.
At the SFI this report is split up into two different reports where the capital adequacy should be reported to the European Banking Authority through the SFI while the report with payment volumes is reported directly to the SFI.
Report with payment volumes
As stated before this report should be submitted directly to the SFI and no website should be used for sending the report. Instead a program should be installed from the SFI which is available for download from the following page http://www.fi.se/programvara where the person with access at the company can log on.
Once logged on the user can view which reports that are available and which ones are pending. For each report an easy form is shown with fields that should be completed with information. The information that should be completed can easily be found in the Lendysoft platform in the Admin section and then reports as the image below shows.
Within the section for reporting the user can select which timespan should be used in the report. For the first half of 2017 the view can look like the example report in the image below.
The information from the report in Lendysoft is entered into the application from the SFI and is then submitted through the application.
Report for capital adequacy
Historically this section has been reported directly to the SFI as well through the same application but recently this changed and now consists of a file of the type XBLR that should be uploaded to the SFI. There is scarce information available from the SFI with regards to this and the companies that are required to report are directed to the homepage of the European Banking Authority (EBA) where the documentation is extremely hard to understand. A lot of links are not working and the downloadable files does not offer any clear guidance either. The SFI has an example file on its homepage but it does not contain any details about the data that should be submitted for the capital adequacy. If the user has some knowledge about XML-files it is possible to understand where the registration number of the institution and the date for the report should be entered in the XML-elements.
After continued research with Google we found an Excel add-on from Altova which actually solves most of the problem. By installing the add-on there is a new menu in Excel titled EBA.
The user can now navigate to the menu and click on the button titled Insert New Report. A number of choices are shown but after trying a few options and looking in the example file from the SFI where the schema reference, shown in the image below, contains the word COREP it is possible to understand that the first option in Excel should be selected.
The image above was captured after opening the example file with Notepad++ where the user can see highlighting of the XML-code. This application works like Notepad but with a few more tools to help the user.
The Altova add-on view is illustrated by the image below.
By expanding the COREP alternative there are two new options shown.
In the example file from the SFI it says corep_ind.xsd which we assume means COREP IND in the Excel report.
When the user then clicks on OK the add-on creates number of tabs in the Excel file, one for each section of the report that can be included in COREP IND. These sections are called C 01.00, C02.00 etc. and by studying the section in the example file from the SFI which is called fIndicators it is possible to understand that only the sections C 00.01 and C 01.00 should be submitted.
In the Excel file there is not a section to the right called Tables where the user can un-check the sections of the report that is not needed and only leave C 01.00 and C 00.01 checked as the image below shows.
The user can now complete section C 00.01 which looks like the image blow.
By clicking the first cell for Accounting framework a dropdown is shown with two alternatives.
Since there is no clear and easy documentation to be found it is impossible to understand if the alternative x1 or x2 should be selected. By doing some research the user can understand that the Accounting framework options should reflect either GAAP or IFRS. Looking at the example file från the SFI it is possible to see that it contains the x2 selection and that is what we should use for IFRS.
For Reporting Level we have the same issue but since the selection with x6 is present in the example file we assume that it should be used.
In the section to the right of the Excel view there is a number of properties called EBA Filing Pane which looks like this:
We have changed Reference Date to the date of the report and the currency, language and Scheme. At the property called Identifier the user should enter the registration number for the company at the SFI.
Next up is the section C 01.00 where the information regarding capital adequacy should be entered. This section is illustrated by the image below.
The numbers that are situated to the right of the field texts are the field id numbers with WBA. When uploading the report to the SFI it is possible that the user might receive error messages if the amounts of the various fields does not add up. The user will then get the field codes with a simple illustration of which calculations that does not add up.
To explain how this validation, calculation, is conducted we can look at the top section of the report.
The texts are indented below their respective headers which means that the amount entered for OWN FUNDS should reflect the sum of all the sub-headers at the first level of indentation. If the user would enter an amount for OWN CET1 instruments and then go on to enter a value for the sub-headers that sum should be the same as the total for 080+090+091.
When the user has entered the values the next action should be to click on the button named Validate in order to test if the values add up.
In the example blow the user has filled out the report where the company has own capital of 1,600,000 of which 1,500,000 is comprised of Paid up share capital and 100,000 from the last years profit.
By clicking on Validate the following report is displayed to the user.
The report displays a few errors which are linked to the report section C 04.00 which is a bug in the add-on since the C 04.00 section was removed from the report earlier in this guide. If any errors are displayed for section C 01.00 it would have to be fixed. The user can now progress by clicking on Export to XBRL in order to get the following file.
If the company does not have to enter any more date it should never have to do anything else than just modifying this file with Notepad++ for each periodic report and then upload it to the SFI. Alternatively the add-on can be purchased from Altova for €399 which is a good investment in order to secure that future validations are performed when the XML-schemas are upgraded.
If the company itself does not want to work with the report it is possible to outsource this to consultants like for example Parseport .
More Bricknode Blog posts
Breaking down the 4 main hurdles for FinTech companies - March 22, 2017
Bricknode takes a bet on the open platform - March 14, 2017
An “App Store” for FinTech - February 15, 2017
Why financial software should be sold on a pay per use basis - January 12, 2017
How to work with tax reporting for financial services - January 4, 2017
The customer experience cannot be standardised! - December 11, 2016
The future of financial advisory - December 12, 2014