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.

So, we’ve been talking in the last few blogs about the motivation, challenges and realities of content migration. I think it’s time to conclude with a couple of thoughts about why you’d benefit from doing all this with a partner like SynApps.

There’s the do nothing option, of course. We discussed the option of just leaving it all in situ. However, if you leave the content where it is, then you are stuck with the old system, probably no vendor maintenance to help, and you will still have the overhead of looking after and oiling the creaky wheels of the rusty old thing in order to keep it running. That is not the way to go; you might save money, but it’s very much a false economy.

In particular, it isn’t addressing the fact that if the system goes down, there could be some very key information in there that could get irretrievably lost.

We talked about the GIGO approach – you lift all the old rubbish and transfer it in the new system.  You’ve still got a large quantity of rubbish to sift through – and if it is not classified properly, then your first page of search is going to be full of rubbish, which will not impress users. So that is not a recommended route either.

We talked about getting the business to help. In our view, there should be more of this involvement and team collaboration. In the rare instances where the business has been involved, the results have been very beneficial indeed – often, when you get the right kind of interest and buy in to getting data appropriately sifted, business users will provide a very extensive set of additional information. It’s very rewarding to work with the business like this and we would love to see more of it.

In most cases, organisations try and push the data enhancement work over to the developer team. We have been busy developing tools when that happens to help; for instance, we have a way to analyse the information from, for example, a folder structure, take information from that, then map that to the data model and the search experience. Take my word for it, the search results are much more consistent with what the end user would expect had that work not been done by you and our team!

A robust security model for your migrated content

Another aspect of working with a professional services team is security. One thing we haven’t really addressed at all is that some people think that a security model for corporate content is an old-fashioned approach. I can find this information on Google and on the Internet. Why can’t I do the same with my corporate information?’

The problem, of course, is that a) Google won’t have all the ‘corporate memory’ that is unique to your organisation and b) we have to look after the security of corporate information. Obviously, where the information is in public domain, it’s fine to use Google. But within the corporate four walls, one of the key things that we have to ensure is that we maintain security on that information. That is key, and judged to be so by regulators and auditors.

The advantage of tools such as the EMC Kazeon tool, which we discussed when we looked at de-duplication (Why Do I Want To De-Duplicate My Data When I Migrate My Content?’) for example, is that it searches all your data because it has access to it all and it creates a large index. The security challenge, then, is: how do you ensure that only the relevant people get access to it?

That index of information doesn’t typically contain any sort of security model. So you need to layer a robust security model on top, to help make sure that only the relevant people get the relevant information from your corporate data bank of content – that we will have helped you safely migrate, extend, improve and leverage.

Again, that’s what people experienced in multiple content migration integration projects know how to do.

And that is what you get when you do content migration with SynApps. Come and talk to us and find out more – and whatever happens, good luck with your content migration challenges!

Regardless of how conscientious an organisation is when it comes to data, there will always be multiple copies of documents stored on a file system or in an e-mail. Think about it: two people get the same e-mail and they both file it away; people will take a document and copy it and keep their own copy and store it on the company file system. Before too long you will have a lot of this content proliferating – and at some point downstream, it may well need to be migrated.

That’s why, as the next chapter in our look at content migration (see previous blogs ‘What Do We Really Mean By The Term ‘Content’?, ‘The Perils Of The ‘Garbage In’ School Of Content Migration,’ ‘Enhancing Your Data Will Really Help Migrate Content Effectively’), we need to look at the very important role de-duplicating content has to play in a successful migration.

First off, be aware that de-duplication effort is prevalent. Google, when it does a search, does de-duplication; other search engines do as well. Google often comes back and says,  ‘Your results have been constrained by removing similar content’. Google does that out of the box and it does it for you. You will have to do it yourself. But there is help to be had. But think, how do we know what content we have got anyway? Somebody may have changed the name of the file, but it is still the same content, after all.

The good news is that there are a number of applications, both commercial and Open Source, that can help you analyse the data you have in a system and create an index of that discovered information which can then be searched by end-users. Google works on addressing it by URL, but there are offerings from EMC, an Ediscovery product called Kazeon, that can access live e-mail systems as well as Documentum and SharePoint repositories and file systems. Incidentally, Kazeon can also “crack the file open” to analyse the textural content and can highlight any sensitive information contained within.

You will soon have a very powerful way to search information, as these tools can let you search your content through a simple browser interface and then manipulate it as you wish. This latter approach also facilitates the classification and data enhancement of content that can then be subsequently loaded into your new ECRM system if so desired.

In SynApps’ case, with our content migration service, we do the data sorting that we discussed earlier and for the data clean up prior to migration we use a tool like Kazeon. Obviously, there are other tools around e.g. the Open Source ones, which do similar things but Kazeon is an excellent tool which we would recommend.

Regardless of the method chosen, the data de-duplication and data clean-up I’ve outlined here is fundamental to any migration process. Massive savings can be realised in existing storage usage through de-duplication, in some cases up to 60-80%! You can see how the de-duplication part is critical to the data enhancement, and you can then feed that in to whatever your migration approach is.

Next time, we will look at the business context – and why content migration integration with a partner like SynApps is helpful.

You may recall the last two blogs (‘What Do We Really Mean By The Term ‘Content’?’ And ‘The Perils Of The ‘Garbage In’ School Of Content Migration’) on the topic of content migration services, where we discussed what ‘content’ actually is, what forms it tends to reside in, what steps tend to be taken to preserve it and so on. Now we need to discuss two important aspects of the migration itself, partly to detail how we can help you but also to underline the importance of the concepts.

First let’s start with data enhancement. As they live in a file system, documents often have limited information associated with them, apart from their name. It can be useful to extend that, so that you can also include a name, title and subject and so on. The other ‘data’ to add is where that document sits within a folder structure. So think, finances and ‘expenses’ and a file classification by days or months and so on.

A common problem is that while the folder structure has probably served the organisation well over a period of time, never forget the information always has to be actively extracted with the folder approach. You search by going through the folder hierarchy – a hierarchy that has evolved over a period of time and is now many folders deep after 10 years or so of continuous service. That extraction process can end up being quite an onerous task.

In contrast, the current universally accepted and popular method for finding information is to Google it. I talked last time about how we can add a ‘Google’ front end to your content – Now I am going to start explaining what that really means.

The Google school of keeping ‘score’

So in Google, you type a few words into a text field, hit return and you get a list of information running into thousands of pages. In this paradigm, the way you get the information you want is to sort through the first page of the results to find the information you desire.

Very rarely will anyone go past that first page of results. That means that for the corporate data and content migration task, you need to ensure that the appropriate taxonomy to help this search gets added to the content in migrating, to ensure that the first page shows the most relevant results to the end user.

That’s why we emphasise the importance of data enhancement. We can work with you to ensure that when we put information into the system we can provide you with the necessary data taxonomy, not only the content (all systems will now typically search on the content, that is how Google does its indexing, plus using a few keywords). That is something which we provide as part of the migration process, getting the business to help clean up the data prior to the move and can add useful information to the data associated with each document. This is going to provide the end user with a much more enriched search capability.

Next, we’ll look at data de-duplication of content and data.

Earlier this year, we started talking about this fascinating area of data, or content, migration.

It’s such a huge topic that we only just touched the surface, so I think it’s time to go back and review some of the critical issues there. So why does an organisation need to migrate anything in the first place?

In most cases it’s because lot of information has accumulated over time and such legacy information often represents a significant collection of hard-won organisational knowledge. This ‘corporate memory’ is going to be lost if they move to a new system, simply because of the fact that technical incompatibilities may mean it can’t be read in a more modern system.

Is ‘content’ what I put on the website?

By the way, we should point out that the term ‘content’ is often mistaken for the information you have displayed on your website. And yes, the term ‘content management system’ is often used for technology to help you manage information that sits on your website – but it should also be understood to embrace what we are talking about here: the physical and electronic files in your organisation and also the data associated with it, which can be quite an extensive and complex structure to work with.

Other terms in this context may be ‘document and records management system’ and  ECRM.

If that is the content we are referring to, what is the target of a content migration integration project? The sources of data and information we come across are file systems. There are, as many of us will know, all sorts of file systems dotted around the organisation (a fact that in itself provides some challenge). Usually, that can be defined as ‘unstructured’ data.

Then you have got more ‘structured’ data, like the sort that sits in databases, connected to a number of different applications. These ‘databases’  can be simple things like Access all the way up to a large Oracle or Microsoft SQL Server type database, which tends to have a lot more information and a lot more relationships, which again means a lot of challenges.

You also have the legacy content management systems, which have ended up out-dated and needing to be replaced. These could either be bespoke or commercial, e.g. it could be based on Documentum or SharePoint, Open Text, or any commercial package that’s either on (or used to be on) the market. The specific problem with outdated commercial systems is that often the knowledge and skills around those systems has been lost some time ago.

Last, you have all the e-mail floating around – which will probably be the biggest container of information in an organisation these days. That’s because the contributors to the organisational e-mail system are not just your internal people, they are all your external contacts – plus the emails are often in the form of lots of documents coming in via attachments.

A model that is useful is thinking about two groups here, the contributors, people who put content into the system and the consumers that access that information and search for it and read it. Note that the volume of contributors to the e-mail systems is far more significant than would be if your content was only coming from the file system/databases/legacy content management system.

These are the sources of information – and the mass of information, in all their different formats, that we need to manage when we start a content migration service engagement.

Next time, let’s look at how to migrate all this stuff, which we now better understand as ‘content.’