Last time (‘Can CRD-IV Compliance Be Made Into A Process?‘) we looked at the implications for banks and financial services organisations resulting from new regulatory demands from the EBA the European Banking Agency.

The EBA has mandated that all reports filed to it going forward need to follow certain prescribed formatting rules, centred on the database language of XBRL– with the first real deadline being FINREP, for FINancial REPorting which you need to be set up for by no later than November.

More importantly: we started to talk about what you could do to prepare. You won’t be surprised to hear that vendors are scrambling to offer ‘solutions’ here. What you actually need, though, is more likely to be what we at SynApps solutions, working with our key partners of XBRL firm CoreFiling and main enterprise content management partner, EMC (with the Documentum platform) have brought to market: the production of EBA-conformant reports via the delivery of XBRL as a service.

We do that via our ConXReporting tool, which takes the correct XBRL that CoreFiling helped produce but as part of a more complete system that can help you build a transparent, reliable process for getting things like FINREP production right.

This is what I want to discuss a bit more today. What might we mean when we call this a service?

Do you have the time to do this any other way?

I think this is an efficient service for the following reasons:

Because it’s a cloud-delivered solution, there’s no time-lag or big up front investment needed on your organisation’s behalf. A lot of projects, even for vital work, get pushed back because of the issues of provisioning resource, setting up servers, assigning development resource. You don’t need to do that with ConXReporting – and to be honest, given it’s now Q2, I wonder if you would have the time anyway.

This is a real service that you can just plug in tomorrow and work with.

Secondly, there are features of the ConXReporting approach that are genuinely unique to it that the other solutions don’t have – which means you’d have to work on providing them. Take persistence. The vast majority of the other systems hold validations transiently – they don’t store them for future reference. That will almost certainly prove to be quite a hassle, as chances are the whole EBA system will change (it has done so far!) and things like the taxonomies will change. That means if the data is not there in three months time if you have to re-jig it, you’d have to go back and start over – which isn’t just a chore, it invites the same opportunity for manual error that you wanted to avoid by automating your XBRL work in the first place. ConXReporting offers you ways to re-apply and re-validate, which is a great back-stop should you need it. (Think of it like a tax return. Few people keep all the information after they finish; most of us file online and that’s it. FINREP is like doing the tax return every two months – so you would want to keep the data and only update as needed, surely?)

Risk management

Persistence – keeping the information – is very useful then. But that’s not all. The workflow aspect of this is just as vital, our customers are telling us. Banks want to delegate EBA report work out and handle it as efficiently as they can internally. To do that, they want a process but also visibility. Who did this work? Where did that figure comes from, what were the bases used to derive it? What happens if you need to change resource allocation around? Our ‘XBRL as a service’ procedure is very good at helping your managers and administrators handle the HR and auditing/security side of FINREP (and soon, COREP and the rest). You are going to know, very quickly, who did what, when did they do it and why they did it – or be equipped with enough insight into the process to ask why.

To sum up: we genuinely are offering a service-led way of helping you manage the CRD IV report production process. That means from the efficiency, risk management and general peace of mind aspects, ConXReporting is going to be the way you want to get set for all this XBRL-based work, going forward.

Can I end by wishing you both an amazing summer – but also not too many headaches dealing with all things XBRL!

Can I ask how you are coping with all things CRD-IV reporting? The reason I ask is that, as you will know, SynApps has recently moved into this market.

What sort of a market is it? It’s one tied to the twin themes of compliance and deadlines. As anyone in the European financial services sector will know – the EBA, the European Banking Agency, is pressing for a uniform reporting structure to help it better track banks’ underlying financial strength. In practical terms, that means you complying with its strict requirements in terms of filing your financial records in the database language of XBRL.

That’s the compliance side. The deadline side is just as important. As it stands, the deadline that is mostly affecting you is likely to be that of FINREP which is looming for the end of the year (November), with another, COREP , coming soon after. And if you are a financial services organisation, you have no choice but to give the Agency what it wants and in the form it wants, when required.

That’s the CRD (Capital Requirements Directive) (more accurately, CRD IV) system summarised. The question has to be, then, are you – as a financial organisation – set up to properly conform to these compliance structures – and meet those non-negotiable deadlines?

The chances are that if you aren’t looking to make the production of XBRL-format reports as slick as possible, you may struggle. After all, you’re going to need to do it in as consistent and as compliant a manner as you can.

That’s why we at SynApps have started talking about XBRL ‘as a service.’

Let’s dive down into that a bit more. As you may know, we’ve been working with a company that is 100% focused on the XBRL problem, a great UK firm called CoreFiling. What CoreFiling has done is to produce a way to allow you to accurately produce, and even more importantly validate, XBRL.

In one move, that offers you a lot of help in terms of meeting the CRD-IV requirements. What we are doing – working with our enterprise content management partner, EMC (with the Documentum platform) – is to make that process into an actual service.

Conformant

What do I mean by that? Well, with a piece of software called the ConXReporting tool, we use CoreFiling to validate the XBRL and add a complete environment around that to help you and your team complete the requisite CRD IV work – at such a level of automation that we think the term ‘service’ is entirely accurate.

How? Through templates that are fully conformant to the regulations, you can help team members quickly and comprehensively fill in what they need to. They can do this by the mechanisms they are used to/happy with, like Excel – as everything will be checked by the system and made consistent.

Which gets you the report completed quicker and more accurately. However, that’s not really enough, if you think about it. That’s because you also need to think about the workflow and the process. In each and every organisation needing to do FINREP, or COREP, etc., there will be identified individuals you need to push elements of this process out to. You also need reviewers to check and if necessary query what comes back, so as to make sure that what gets put in the central ‘pot’ for the final report makes sense.

It’s the production of that valid whole that we call the XBRL service.

We are going to take you from what is likely to be – if you have even got as far as properly preparing for this – a very manual, ad hoc effort to a smooth, safe and automated validation process that will offer you a way to implement a proper, auditable, internal process.

Now that I have given you a top-level view, in the next blog I will dive a bit more into what the specifics of the XBRL service is.

Thanks for your time – and good luck with CRD-IV!

In our previous blog, (‘The Beginner’s Guide To CRD IV Reporting – And Why Banks Need To Pay Attention’) we examined the detail of these new, mandated structures that financial services firms have to comply with to meet European banking reporting requirements. We discussed CoreFiling and its technology contribution. Now, we need to discuss what EMC and SynApps are offering this market.

So where does Enterprise Content Management come in? What we have done, as experts in ECM, is to integrate the XBRL processing engine from CoreFiling, our partner, with a state of the art business process management engine from our partner EMC which allows you to move information between different people to work with and collate and enter data. Finally, we are utilising ConXReporting technology which gives you the taxonomy and associated templates in the form of workbooks, managed in an enterprise document and records management environment.

ConXReporting allows us to generate the right output for all the various CRD IV formats, COREP (Common Reporting), LC (liquid coverage), FINREP (Financial Reporting) and Large Exposures and Stable Funding Ratio. This means you as a bank can now jump straight from data to report templates specific to your organisation, and based on a taxonomy which has been mandated by the European Banking Authority. For each of those report types, we can create reports that are specific to your organisation. We also provide security so that only the appropriate people will ever see those reports. As well as the compliance in ensuring that the reports are retained for the appropriate duration.  

We are used to working with big, complex document-based systems – it’s what we do! Here the emphasis is in particular on workflow. We also define a review and approval cycle so when Q1 2015 comes along and you have to create a COREP report, you can press a button that will then set off a business process defined for that template. All of the version and audit trail functionality that is within the underlying document management system is so great it just kicks into play, thus helping the team member do the job safely and efficiently.

One of the key things that happens here – which is over and above what you would get from regular ECM – is that CoreFiling converts your workbook to XBRL, validates it against the taxonomy and either approves it or sends back the information for the author to clean up and re-submit.

When the XBRL in that particular form has been validated and all the forms have been completed, they are merged into one report which then goes off to a different team who have access to the entire report, for final validation. Once that is done, the report is locked down and made available to the relevant regulatory body.

To sum up: you don’t have to edit XBRL and you get a full audit history of the review and approval cycle, so you always know who and when it was completed and signed off, and we will maintain this information for the regulatory number of years. You also have access to historical reports, should they be needed, so everyone (including your auditors) can see what has previously been submitted.

This is a very compelling set of features that is going to help financial institutions meet not just the first but all of their CRD IV deadlines, and in a very efficient, pain-free way.

That’s a lot of detail, but I hope we have got to the heart of what we are offering with our financial reporting functionality.

Recently we talked to you about moving into an interesting new market, financial compliance. In this blog, let’s explore this topic in a bit more depth.

A lot of financial regulation centres on Basel III, the regulations that govern global, financial organisations. In Europe, these have been collected together into CRD (Capital Requirements Directive) IV.  The point about CRD IV is that it brings together a whole set of governance around banking organisations post-2008 in order to prevent future liquidity crises.

The bigger picture is that European harmonisation of regulatory reporting requirements has meant firms are required to report the data to their competent authority. In the UK, that’s the FCA (Financial Conduct Authority), but it differs from country to country. In practical terms, this means any firms affected by CRD IV will need to obtain a suitable method of converting data into XBRL (eXtensible Business Reporting Language), which is based on XML (Extensible Markup Language) and so is able to make use of all the useful tools that come with that, in order to create an XBRL report that needs to be validated against the taxonomy which has been issued by the European Banking Authority (EBA).

The EBA is in effect insisting that it can only receive that information in XBRL, as are other sub-organisations. There is a lot of interaction going on between these different organisations across Europe, which also affects you if you operate in multiple geographies.

XBRL has been around for a while and suppliers have created functionality to be able to validate data being entered through rules implemented around XBRL. One of them is CoreFiling, who we work with and who has built up real expertise in this area.

CoreFiling’s software converts the user’s data to XBRL and then validates it against a set of rules which have been tailored to what the regulatory authorities want (i.e. to fit into some pre-defined taxonomies, which contain all the specific rules for validation of the data, and comprises part of the overall CRD IV filing report).

The bottom line is that reports have had to be created. CRD IV came into play at the beginning of this year- so January 1^st 2014; and all these rules now apply going forward. The first one of these specific format reports, for Liquidity Coverage Ratio, had to be in by the end of April this year. So there was a lot of pressure on financial organisations to get this in place. And soon banks will have to be filing others. They will also have to be able to report in different currencies, e.g. euros, pounds or dollars.

This means a lot of information has to be captured and properly organised. It’s very likely that a lot of this information will be held on a number of different systems, be it SAP, Oracle or some other financial systems.

Plainly, there is no easy way to get XBRL out of these systems. You can maybe add data into an Excel spreadsheet either manually or through some smart macros. But that doesn’t give you XBRL, unless you are prepared to do some very hard work on it.

CoreFiling is able to satisfy the requirements for these online report submissions; its clever software does this via applications that produce, transport and validate XBRL using a configured regulatory taxonomy. Specifically, it takes both CSV and Excel data and not only converts it into XBRL, but also validates it. So, if you have the data, you can put it in one end of the sausage machine and out comes what you need to meet your CRD IV requirement.

Next time, let’s talk more about how EMC and SynApps technology add value to this process.

We are pleased to say that we have the opportunity to hear from Andrea Whitehouse, Marketing Manager at our partner, acknowledged XBRL experts, CoreFiling who wants to discuss XBRL reporting needs

Banks and other financial institutions may currently be breathing a sigh of relief, having been offered a reprieve – albeit possibly a brief one – from the end-April submission date originally specified for the first Liquidity report filing under the new CRD IV reporting regime.

But even though the deadline has been put back to the end of June, many organisations, both large and small, are still scrambling to put in place a suitable mechanism for producing their XBRL filings – as many of the traditional vendor solutions are still unfit for purpose.

XBRL, the format in which the European Banking Authority (EBA) and its National Competent Authorities around Europe are expecting to receive the new COREP, FINREP and Liquidity reports, is not an easy technology for the uninitiated. And expertise in the market is in short supply.  

Meanwhile, we have heard stories of several organisations that bravely embarked on a DIY approach, only to admit defeat and, having wasted a lot of time, have now resorted to contacting companies that specialise in XBRL products.

So how can you ensure that you will be able to submit valid XBRL filings on time? By trusting in XBRL experts – organisations that can demonstrate in-depth expertise and experience in conquering the challenges represented by XBRL. The easiest way is to rely on XBRL products that are already tried, tested and proven in the market; a solution based on commercial-off-the-shelf (COTS) products goes a long way towards ensuring that all will be well.

However, it also depends upon how those products are integrated into existing systems, especially where data has to be extracted from multiple sources before being turned into XBRL documents.

One of the main challenges all organisations are facing in this new XBRL world is how to understand exactly what data is being reported in the final submission documents, for example. To the layman, the XBRL output from traditional conversion software is virtually unintelligible, so what happens when those in authority need to provide approval and sign off? What steps have been put in place to ensure that the data is correct? These are fundamental issues for most financial institutions, and ones that cannot be solved easily.

Additionally, we have heard reports that several organisations have had filings rejected at the regulatory gateway because of invalid filings, but had no easy way of determining where the problems lie. Relatively few stable COTS solutions exist to handle this issue.

There is also the problem that the situation with CRD IV is less stable than we might like. We have already seen a number of changes to the EBA taxonomy; and as the reporting regime evolves, it is likely that the taxonomy will be subject to regular updates. The problem is that solutions that rely on hard-coding may not be able to be updated easily and vendors may need time, not to mention additional fees, to implement changes; whereas systems that are taxonomy-driven will have provision to drop in a new version of the taxonomy in a relatively seamless manner.

The issues discussed above are all questions you need answers for as you implement your COREP, FINREP and Liquidity reporting solutions.

Those answers may not be readily available or systems easy to implement – but getting financial reports right first time is surely the goal of all regulated entities embarking on XBRL reporting.

About CoreFiling

CoreFiling partners with EMC and SynApps in the production of the XBRL Disclosure Management Platform™.  XDMP™ is a comprehensive XBRL workflow and reporting solution for the creation and management of XBRL documents ready for the submission of COREP, FINREP and Liquidity returns to European regulators.  The solution is built on a number of CoreFiling COTS products, plus EMC Documentum, with the SynApps ConXReporting providing the web front end. 

To handle the XBRL rendering issue CoreFiling provides Magnify® a comprehensive XBRL document review tool that allows filers to check the quality and validity of their disclosures.  Magnify® checks for compliant XBRL, but also checks conformance against regulatory filing rules, for example rules issued by the EBA, and highlights any discrepancies so that remedial action can be taken.

In April 2014, in advance of the original CRD IV deadline, the Bank of Ireland successfully submitted its first live filing to the PRA/FCA using the XDMP solution.

CoreFiling specialise in XBRL.  Regulators, government agencies and corporations around the world rely on CoreFiling for XBRL-based performance reporting solutions.  The company’s senior management and developers are active members of the XBRL consortium which oversees the development of the XBRL specifications.