naughty naughty HQ-bank for falsification of financial statements

 

So information security in financial reporting is unnecessary? So you think… I guess you’re not following the HQ-Bank saga in Sweden? Well the stars of this saga are going to prison to pay for falsification of financial information. It seems that even the KPMG auditor (Johan Dyrefors) approved 2009 and 2010 accounts. Credit to KPMG that it didn’t get approved internally. Evidence of malpractice started in 2009. It seems that this was just the tip of the iceberg of accounting malpractices for HQ-Bank.

You know information security is not purely about protecting the confidentiality of financial information, it is about protecting its integrity; ensuring absolute traceability back to the originating source, which is the identity in whichever role they are acting within when financial records are submitted. The financial reports that are submitted should be digitally time-stamped and digitally signed to protect integrity.

It is XBRL that gives transparency. XBRL gives a single language for all financial information from creation through to consumption. However in order to enforce Accountability, Responsibility and Traceability (ART), i.e. quality and integrity in financial reporting, you need information security. You know those deep cryptographic magical stuff that tells you if the financial information has been tampered with.

Lars Berlöf is going to be talking about this at the Nordic IT Security Conference on 5th November, I may even keep him company on stage, for a short time 😉 Lars knows about the challenges of transparency in financial reporting and is driven to enforce traceability hence, legality in all financial reporting, in Sweden, and across the whole world!

Here is a taster of what we will be talking about……

[youtube=http://youtu.be/an1yIoby_pc]

‘stupid loop’

Do you have any of these in your organisation? Maybe you have become attached to the old practices, and anyhow who wants change really?

So what would I define as a ‘stupid loop’? It’s pretty straightforward, it is when something strange happens to the integrity of the information, after INPUT and before OUTPUT. Effectively integrity is compromised during PROCESSING. An example could look as follows:

    1. Information submitted by paper (INPUT), by snail-mail, take your tax returns, or your company financial statements, for example;
    2. These statements are converted (PROCESSING) into some picture format for digital storage, i.e. .gif, tif;
    3. Then the picture files are converted back to text/numbers (PROCESSING), as they are unusable as pictures, no indexing (impossible to search);
    4. OUTPUT is distributed to end consumers, e.g. banks.
    5. End consumers use OUTPUT to make lending and other financial decisions.

Okay, this brings us to the integrity part. How much of the information INPUT has become misinterpreted during PROCESSING? The answer is that based on work done using software that translates graphics to text and numbers, that the risk to information integrity is at least 15%. So this means that of the information INPUT, information OUTPUT will not mirror INPUT exactly by 15%.

XBRL for Transparency
This brings us to XBRL (eXtensible Business Reporting Language). XBRL is a global industry standard and is the standard of financial reporting in Basel III (CRD IV). You could liken it to a universal language that everyone understands, hence there is nothing lost in translation after capture. XBRL gives some protection from accidental risks to information integrity. This gives true transparency and improved traceability, because it is easy during any audit process to see the original information at capture and how it has been processed or/and changed from capture through to when it is consumed; by a human or a system because it is all using the same language. If you’ve ever dabbled with XML, you will recognise XBRL like an old friend 😉

Securing XBRL for Traceabiltiy
This is where we get to the security part. XBRL is not secure, and in order to weave legality into submitted digital financial reports, their submission must to be intimately coupled to the individual and ultimately role of the initiated digital interaction. One could liken digitalised financial reports i.e. XBRL instances, to an information vehicle, programmed to get from A to B quickly and without hindrance. In securing digital reports, you have handed over a sealed package to the vehicle. The seal is unique and is watermarked by your signature that encapsulates not only your identity but also your appointed role. This package can only be opened by the intended recipient, and in his/her appointed role.

More CONTROL Less SPEND
No need to ‘teach your grandma to suck eggs’ as I am sure that you’ve worked out yourself by now that secured financial INPUT in XBRL-format should facilitate cost reductions because there is no longer any need to send paper reports by snail-mail, to convert to some strange format, only to be converted back again…. a ‘stupid loop’ indeed 😉

Additional reading:
(en) Securing XBRL – the next challenge (2014)
(en) Improved Business Process Through XBRL: A Use Case for Business Reporting (2006)

Securing XBRL – the next challenge

I just realised that I forgot to let you know that I co-published an article in the last week. My first publication since 2010… looks like I’m in business again…. Having said that, it is not that I haven’t been writing anything.. there’s this blog, and my MBA (that I finished January 2013). Although I must admit my blog activity has been a bit sketchy the last 3 years.

Back to the article. It is about securing XBRL. XBRL stands for eXtensible Business Reporting Language. It has been declared as the standard for financial reporting in Basel III. However XBRL is the child of XML, and XML is not secure. Hence back to the topic of the article. I will write more, for example I plan to explain what XBRL is, for those of you that are clueless about financial reporting. I was myself until I realised it came from XML, and XML I became intimate with when I was working in Switzerland from Zurich as a consultant coding connectors for Novell’s meta-directory service, often on beta versions, and working from readme.txt files as there were no books in 2000. I didn’t get much sleep during this year, but I sure did have fun!