‘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.

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)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.