A Guide To Taking The Pain Out Of CRD IV

By Mark Winstone | 9 May 2014

Content management specialists SynApps Solutions’ Sales & Marketing Director Mark Winstone argues that banks need to move swiftly to address mandated changes to reporting formats – and that content management solution–based technology might prove your best friend here.

Regulatory reporting is inexorably moving to become more electronic – and at lightning speed.

After all, post the Credit Crunch/global financial crisis, governments want far stricter financial reporting regimes in order to prevent any future liquidity crises knocking the world off balance for years on end.

And to make efficiency improvements, as well as to promote transparency, policy makers are standardising the way they want banks to present information to them – namely it needs to be captured in XBRL, for eXtensible Business Reporting Language, a global data standard for exchanging business information which will bring consistency and accuracy to the reporting process.

As a result, financial services organisations need to gear up to be able to produce, on a regular basis, a standard report so the regulators can get a clear understanding of whether you have over-stretched yourselves or not. Provision of reports in the new standard demanded, in this XBRL format, became mandatory from January this year (2014) and all these rules now apply, going forward.

And very soon, it will also be necessary to report on the much larger regulations around FINREP (Financial Reporting) and COREP (Common Reporting) – with each report filed in the correct, designated XBRL format. That report must also comply with the specific taxonomy (structure) as defined by the relevant regulator.

June 2014 marks the start of Liquidity reporting in XBRL, closely followed by the first COREP and FINREP reports. The first mandated full Solvency II reports in XBRL are expected to be submitted in early 2016, meanwhile – although in January an interim reporting period, during which National Competent Authorities (NCAs) must either comply with the regulation or give reasons why they cannot, was also introduced.

All this translates to pressure on financial organisations to get this worked out in time. For example, each of the specific report structures are being passed down from the European Banking Authority (EBA) to the local regulatory organisations. That one centralised taxonomy, which will have a common set of rules that govern how the data in the report should be presented also means you have to be conformant.

Basically, you need to be on top of this – now. And the Capital Requirements Directive (CRD)[1] IV is the one that you need to face down first.

Dealing with CRD IV

This means a great deal of information has to be captured and properly taxonimised, and in a relatively short period of time. How are financial institutions coping?

The situation for many banks is that the required information will be there – but sitting in a number of different in-house systems, e.g. SAP, Oracle or an internally developed application specific to the financial organisation – as  well as Microsoft Excel.

Clearly, there is no easy way to get XBRL directly out of such sources in the correct structure for the authorities in an easy or risk-free way. One technique might be to manually extract data into a spreadsheet, add manually entered information to ‘enhance’ the aggregate, export the data as CSV: but that won’t give you XBRL production and validation. That requires extra work and manipulation.

The question financial services firms need to engage with is, to what depth of competence can they handle the inner workings of financial reporting templates and compliance with the required taxonomies? Or more pointedly: can they develop this expertise in-house, or should they bring in help?

To go down the first route, remember you need the following in place – and now:

  • the correct developer and skills in-house
  • sufficient technology resource to interpret the rules and map them on to your business needs
  • an XBRL ‘transformer’ (a tool to move data from one format to another)
  • a proven way to handle error exceptions and XBRL error returns
  • the confidence all the data got entered into the right templates.

And a means of making all the above into an integrated and well-managed business process, as CRD IV, COREP (Common Reporting), LC (liquid coverage), FINREP (Financial Reporting) and Large Exposures and Stable Funding Ratio become more and more part of your business’ vocabulary.

Painless and efficient CRD IV automation: a sourcing guide

If you have all this in place and are in the process of meeting the imminent deadline for the first Liquidity filings, then you have committed resource in place to cracking the problem, in good time.

If you don’t, maybe it’s time to look at some of the technology help available that could manage all of these issues for you and let you get back to concentrating on your core business?

To do that, you need to source a technology that has the functionality to convert your collated and validated data to XBRL, and in the structure as defined by the relevant regulatory taxonomy.

You’re also going to want to know it can guarantee conformance to the associated rule set defined for that taxonomy – and approves it.

The software also needs to flag any errors found during the validation process, plus be able to contain the workflow functionality that can quickly route information back to the originator to be corrected and re-filed.

To help you search for a solution, here are our tips on how financial institutions can meet the CRD IV challenge in the most efficient, pain-free way. Look, then, for solutions that offer the following profile:

  • Scalability and comprehensiveness are going to matter here. You need a system that not manages CRD IV but also other formats coming down the Basel line: think COREP, LC, FINREP, Large Exposures and Stable Funding Ratio etc. – and not just in terms of the right structure (taxonomy) but also the right content (rules) and format (XBRL)
  • Don’t blind yourself to the fact that regulations are both vague and in flux. In practical terms, that means you need a supplier partner at the top table with the Powers That Be, or the structures you code up within your XBRL engine may be incomplete, leaving you vulnerable
  • A streamlined CRD IV review and approval process is a big help. To move information between different people and collate/verify data, in other words. To be frank, what chance do you have of meeting your deadlines otherwise?
  • Security is key to do any CRD IV job safely and efficiently. So make sure you have it!
  • A full audit history of the review and approval cycle will help. So you always know who and when it was approved. You should also have access to historical reports, so everyone – including the auditors – can see what has been submitted and correctly retained for the required period.

The good news is that such software and help is available – software that will produce, transport and validate your reporting data into XBRL using the configured regulation taxonomy. Automating this complexity is going to help you avoid a lot of manual heavy lifting – plus maybe ‘dodge the bullet’ of fines for missing deadlines and associated reputational damage.

So, this is the bottom line: if you need a proven CRD IV solution in good time to meet this challenging regulatory change adequately, but best start looking now. The good news is that with such a solution in place, it will put your organisation in a position to meet any and all future compliance requirements in an efficient and consistent manner.


By Mark Winstone, Sales & Marketing Director, SynApps

Become a bobsguide member to access the following

1. Unrestricted access to bobsguide
2. Send a proposal request
3. Insights delivered daily to your inbox
4. Career development