Open community of practice for filing and XBRL with Open Source
Header image

Blockchain

XBRLchain = XBRL secured by Blockchain

Paper presented in the 44th World Continuous Auditing and Reporting Symposium, Seville (Spain) 21-22 March 2019.

Open Webinar Monday, 29th October 2018 – 15:00-16:00 CET. See the video record and the presentation slides.

Open Webinar Monday, 29th October 2018 – 15:00-16:00 CET. See the video record and the presentation slides.

Where is the problem to solve?

The key point in regulatory disclosure is that a business report is legally binding for the issuer when that business report is filed by the issuer to the supervisor and, consequently, published by the supervisor. Then the Supervisor is providing the characteristic of non-repudiation (acting as a Notary) to the business report: the issuer cannot deny having sent the business report. The customary approach for secure a business report is simply download it from the supervisor’s website, as exemplified in the cases of CNMV. The consumer is therefore secure that the report is the actual report legally filed by the issuer to the supervisor. However, the business report itself lacks of any security feature. In the case of a non-supervisory searcher, as Arelle Filing Index, the solution is hyperlink by URL to the supervisory webpage SEC .

Why if simply the issuer put its digital signature in the report? For an IT point of view is an optimal solution. BUT (in practical terms) the existing digital signatures depends on Certification Authorities, that unfortunately are far away of establishing enough reciprocal trusted relations, hence lacking of interoperability and extensibility for most consumers. Moreover, the digital signature must be published somewhere, well concatenated to the report or well in an independent file.

Hence, each different consumer must download independently the same report from the supervisor website as security feature, being this download the only proof of integrity (report unmodified) and non-repudiation (the issuer cannot successfully dispute its filing -hence authorship-) of the report.

The supervisor website acts as a Web Notary. But a Supervisory-based notarization leaves out relevant issuers’ non-regulatory reports, hence not published by the Supervisor, as Corporate Social Responsibility, Integrated Reporting, Environmental Impact and so on. Let see the diagram below.

Anna and Bob trust in the public website of their respective national Supervisor or Officially Appointed Mechanism. However, when Carol receives a report from a third party supply chain, she has no other method to check its Integrity and Non-repudiation than compare the report with its original supervisory publication website.

Note the URL of the original supervisory publication  is NOT necessarily part of the report. Find a particular report in a foreign supervisor website is not necessarily an easy task. See now the same situation but with a public & indelible ledger based in blockchain:

Carol can now check the report’s Hash code using whatever Check Server she want (or directly if she owns an Observer node). If the hash code is found in the Ledger, Carol can be sure of (a) the Integrity of the report (no modifications) and (b) the Identity of who Notarize the report (such Notary –strongly identified by the blockchain- cannot successfully dispute its Notarization: Non-repudiation).

Note the report do not necessarily must be public. As the hash code is an inherent characteristic of each particular report, having the report derivate its hash code is trivial. However, having a hash code provides no information at all about the original report (this one-way function is known as cryptographic hash function). Made a hash code public do not compromise report’s confidentiality: it is equivalent to get a key but ignore where is the lock.

See below a running Proof of Concept example, with testing credentials for free use.

However, nothing is perfect. When Anna consult the OAM website used by Bob, or Bob consult the Supervisory website used by Anna, or Carol consult whatever the OAM website or the Supervisory website, all the three folks may find difficulties if not fluent on the language or other characteristics of the websites.

This approach is an evolution (currently in PoC development) of the XBRLchain concept, now optionally storing also the stable URL of each report in the blockchain, in addition to the hash code and the Identity of who Notarizes the report. A characteristic of blockchain is that all the nodes have an on-line local copy of the ledger. Therefore, when someone notarizes a report, such notarization is simultaneously updated in all the nodes. A smart contract functionality can be implemented, triggering an event when a new notarization is propagated. A Financial Gateway (currently in PoC development) can immediately read the report from the publication website by using the Notarized URL and including its attributes in an index of reports. See the sequence below:

David can now query the updated Financial Gateway about the reports matching a set of attributes, obtaining a list of URLs as answer. David can then download the selected reports directly from the respective websites. There are other interesting characteristics of this approach, not represented in the diagram for the sake of clarity. The Financial Gateway can also (a) check the hash code of the reports, (b) store the reports in full (e.g. as backup or accelerator of original publishing websites), (c) safely index non-regulatory reports (e.g. environmental, social responsibility, and so on), (d) be a Business Intelligence public server, (e) act as Notary by default if a publication website fails in its Notarization function, among many other functions.

Moreover, there can be several Financial Gateways running independently, without interferences. Note no agreement, communication channel, link, RSS, or any special mechanism is required between the Gateway and the publication nodes: with the Notarization in blockchain is enough. All the information for starting from scratch the index of reports or re-synchronizing it can be obtaining by reading the Notarizations in the local copy of the ledger. As the Notarizations are propagated simultaneously to all the blockchain nodes, and the publication websites are of public access by nature, there are no restrictions for entrepreneurs or public initiatives in building all the Financial Gateways with specific features they want.

This kind of challenge will surely arise in Europe 2020+, when all the listed companies should report in the same European Single Electronic Format (ESEF) but trough near 30 different websites. An initiative affording this challenge is the European Financial Transparency Gateway (EFTG SMART 2016/9488, see video video and presentation in May and presentation in June 2018), as included into the Financial Technology (FinTech MEMO-18-1406) Action Plan of the European Commission, also in GitHub.

Our proposal hereby presented is the use of the XBRLchain concept as EFTG infrastructure layer. At the end of the day, no changes in the current Supervisory/OAM publication websites functionality are required at all. The only new feature is Notarize each report when made it public, and even this function can be requested to be assumed by the EFTG acting as Notary by default.

Insider Trading Risk and potential mitigation with blockchain

On 15 January 2019, this new of the Securities and Exchange Commission (SEC) was released: SEC Brings Charges in Edgar Hacking Case. The SEC’s complaint alleges that after hacking the newswire services, Ukrainian hacker Oleksandr Ieremenko turned his attention to EDGAR and, using deceptive hacking techniques, gained access in 2016. Ieremenko extracted EDGAR files containing nonpublic earnings results. The information was passed to individuals who used it to trade in the narrow window between when the files were extracted from SEC systems and when the companies released the information to the public.

The scheme was described by Roger Aitken as [Ieremenko] obtained non-public “test files,” which issuers can elect to submit in advance of making their official filings to help make sure EDGAR will process the filings as intended. It is explained that issuers sometimes elected to include non-public information in test filings, for example actual quarterly earnings results not yet released to the public. And, in Ieremenko’s case he extracted non-public test files from SEC servers, and then communicated such information to different groups of traders.

Investopedia: Insider trading is the buying or selling of a security by someone who has access to material nonpublic information about the security. Insider trading can be illegal or legal depending on when the insider makes the trade. It is illegal when the material information is still nonpublic.

In this particular case, the SEC reported that the nonpublic information was illegaly accessed by deceptive hacking

Are the current publication systems potentially offering windows for legal insider trading on SEC information?

Let review the process for publishing SEC information. A typical listed company (a) publish its report in the investor relations section of its website and (b) submit the report to the SEC, which in turn (c) publish the report in the EDGAR website and also (d) provides Really Simple Syndication (RSS) feeds for EDGAR structured disclosure submissions as a courtesy for those interested in viewing, analyzing, and manipulating the submissions. These feeds are updated every ten minutes.

Watching directly (a) the website of the listed companies and/or (c) the EDGAR system offers up to ten minutes of legal insider trading window in relation with the investors waiting for (d) delayed RSS feeds. Even one minute is much more than the time needed for high frequency trading and even for whatever “slower” algorithmic trading,

Placing computing daemons continuously querying companies and EGDAR websites for updates is a technical approach, often used. But it is not a very elegant solution. In fact, this approach creates a lot of useless traffic between update and update, than can eventually create overload to the web infrastructure.

 

In hypothetical case of the reports submitted by European listed companies, the situation would be even worst. The European listed company (a) publish (or not) its report in its own website and (b) submit the report to the national OAM, which in turn (c) publish the report in the national OAM’s website and may –or may not- (d) provide RSS feeds.

In turn, the OAM (e) would notify to the European Financial Transparency Gateway (EFTG) which in turn  (f) index/republish the report and/or (g) provide RSS feeds or equivalent. In short, there are multiple time offsets, hence creating legal insider trading windows, depending on how the investor is noticed about the existence of the released report.

 

By nature, blockchain offers a very interesting characteristic: all the nodes are simultaneously feeded with each new block for updating the local blockchain copy. Each blockchain node can explore in parallel each new block detecting the new entry of a Notarized Report. In the limit, in order to prevent any possibility of legal insider trading, a listed company may pot for (z) Notarize the Hash of the report with the URL of publication (but not actually publishing) (y) submit the report to the OAM, (x) wait for the OAM’s acknowledgment and (w) publish the report in the URL. Even when the OAM and/or the EFTG in turn Notarizes again the Hash of report,  this is simply the same Hash notarized several times.

In the step (z), all the Blockchain nodes are simultaneously informed of the immediate publication of a new report, and of the publication URL.  There are no possibilities of legal insider trading windows for specific investors.

Use case

Blockchain to secure the integrity and non-repudiation of a document, typically an XBRL instance document containing a business report.

How XBRLchain works?
The document is digested in a unique and secure code with a standard hash algorithm, and this code is indelibly written (notarization) by an authorized party in the blockchain ledger. Checking the validity of a document is done calculating again the code and comparing it with the one in the ledger, also retrieving the authorized party identification. The code provides integrity (report unmodified) and the authorized party identification provides non-repudiation (the authorized party cannot successfully dispute its notarization of the report).
Note that several authorized parties (issuer, auditor and supervisor) can sign independently the same document.

Identification of issuer, type of report, period, and so on is already mandatorily included in XBRL instance documents by the XBRL specification. The only requirement in that the XBRL instance document must by self-containing (not dependent of external references). Other information about authorized party additional identification and timestamp is trivial of implement.

How to notarize a document?

The authorized party invokes a notary webserver authorized to writing in the blockchain. The blockchain system must have a secure interface with the server, and a micro smart contract definition interacting with the ledger.

 

 

How to check a document?

Each check webserver with read access to the blockchain can retrieve each code written, with the respective authorized party/ies acting as notary/ies for such code. For demo purposes in this proof of concept, the code is a simple CRC32 concatenated as a XML comment at the end of the file.

 

Testing by yourself?

Go to www.xbrlchain.info and check the following file examples (use userId/Password test/test for Notarize, but once only each 10 minutes).

File name TESTING CODE? Valid hash code? Registered in blockchain?
Example_1.xhtml No N.A. N.A.
Example_2.xhtml Yes (2676830881) No (must be 2676830882) N.A.
Example_3.xhtml Yes (1751792560) Yes No
Example_4.xhtml Yes (2676830882) Yes Yes

The development of this Proof of Concept (PoC) is a webpage with two functions: Notarize and Check.

The web page runs in the website www.xbrlchain.info, created and managed by XBRL Spain on a standard web hosting. This web page is open to the public, with testing credentials for Notarization and free for Checking. The website is a Client that invokes an Observer Node of Alastria.

For Notarizing, the Observer Node starts a transaction with the Validator Nodes using the Ethereum Quorum protocol. The Validator Nodes prepare a block with the ordered list of transactions (if any) received each cycle of one second (or less depending on workload). The block is distributed to all the Nodes (following the blockchain architecture), which execute the Smart Contract, confirm the result and update the local Ledger copy accordingly. See diagram at right. At the end of the cycle, a new block has been added to the local Ledger copy existing in all and each one of the Observer Nodes and Validator Nodes as well.

For Checking, the Observer Node simply returns the required information from its local Ledger copy. Note the Ethereum Quorum throughput for reading is several orders of magnitude better than for writing. See more at Introduction to Quorum: Blockchain for the Financial Sector.

More? See below the minimalistic source code used for:

Public presentation in Brussels, October 10. Open webinars 29 & 30 October 2018 15:00-16:00 to be posted at eurofiling.academy

Even more? Consult the authors for further details

Who provides the notary web server/s and the check web server/s?
The market. It would be also an inhouse integration of webserver/local service. In this proof of concept it is used testing webservers developed by the authors (see the code below).

Blockchain technical details?

Each Node belongs to a different permissioned company, running an independent installation of the blockchain software and storing a local copy of the Ledger. By the blockchain architecture, the network remains fully operational and reliable even up to one third on the Validator Nodes are compromised (i.e. ten or more Validator Nodes captured simultaneously by an undetected attacker). This distributed network architecture provides a very high resilience having not a single point of failure, providing a clear advantage over traditional hierarchical approaches in the financial sector.

Why a permissioned Blockchain?

Facilities as accessible & available laboratory in the development of Proof of Concepts for test cases. One of the authors of XBRchain is the Chief Technical Officer of Alastria, the Blockchain Ecosystem (300+ members) running in Spain for the World.

Strong Identity facilities, to be based in the works of the Identity Commission (identity@alastria.io Leader: Carlos Pastor (BME), Sponsor: Moisés Menendez (Everis)) Develop an identity solution inspired by the SSI model and based on uPort. Develop mechanisms that allow for the rapid creation of Alastria identities inter-operating with existing identity mechanisms.

Performance and adequacy. See below a comparison of consensus approaches, (slide 21: IBM, Making Blockchain Real for Business) according to which a permissioned blockchain as Alastria is the optimum solution.

Who is who?

Alastria can be summarized as a semipublic, independent, permissioned and neutral Blockchain/DLT network, designed to be accordant with the existent regulation, that enables the 250 associates to experiment this technologies in a cooperative environment.

XBRL Spain is a non-for-profit association for the diffusion of technological standards, focused in the eXtensible Business Reporting Language

Openfiling is an open community of practice for filing and XBRL with Open Source.

Copyright (mandatory citation).

The design of the XBRLchain concept, the development of the proof of concept, and the publication of the results are an intellectual property of the authors, dated 2018-10-07, and working in most cases out of business hours and in weekends. The authors hereby grant a license Creative Commons BY (Creative Commons Attribution 4.0 International License), hence expressly requesting their attribution, as moral authorship right.

no