Join the Community

22,881

Expert opinions

43,907

Total members

481

New members (last 30 days)

221

New opinions (last 30 days)

28,959

Total comments

Join Sign in

XBRL and the Identity Issue

27 October 2009 1 comment

Gary Wright

Analyst

BISS Research

The DTCC/SWIFT/XBRL initiative will I am sure, be a success and be a springboard to a new age of data standards. However, there remains an important issue that needs attention and that is, to protect the identity of the issuer of the taxonomy and the security of the data they issue.

The obvious solution to the identity problem is to create a directory of the issuers of data and may be this should be held in a depository like the DTCC? It certainly should not be managed by a commercial organisation or a network like SWIFT. The reasons are that commercially it could become an expense issue and limit the potential usage and if it is by a network restrictive, accessible to only those on the network. Openness is the key to success but the villain of the piece when it comes down to security aspects.

May be the answer lies in the XBRL identity ownership being managed by a cooperative of utility organisations that have a vested interest in maintaining the security and uniqueness of the directory.

The unique business identity has been banded about for years without any realised solution. IdenTrust were one of the early purveyors of a solution to the identity risk problem but have achieved only modest penetration despite the sound logic and obvious rewards of their solution.

But with XBRL looking like a done deal solution it looks like the identity question will be finally answered.

The security around the data itself is also in the ‘must find an answer for' tray and in Codel the new company backed by BT the solution may be in front of our eyes.

The now question has to be not what or where is the solution, but how does the industry tie it all together?

External

This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.

4436

Report

XBRL Discussion Group

As XBRL becomes more recognised as a vitally important tool to reduce data costs and streamline communication in the financial services industry, the full opportunities need to be explored. To ensure a full and clear understanding by the financial services industry globally rather than just those countries where is has already been adopted, especially in light of the DTCC and SWIFT initiative.

Join group

9 opinions 7 members 20 March 2013

Comments: (1)

Andrew Chilcott Systems Integration Consultant at stpsolutions

28 October 2009

The key here, like all security issues, is for the recipient to have confidence that information regarding the corporate action event contained in the xbrl file has been published by the organization that claims to be the publisher and that the document is identical to the one that was published and has not been tampered with in any way between publication and receipt.

How can this be achieved? I think that what is necessary is a trusted third-party to act as a Certificate Authority (CA) that issues digital certificates to Issuers to encrypt the files and publishes the public key that enables the files to be read and authenticated.

In this scenario, all of the Issuers would have to register with the CA. Gary, if you read my comments on your previous blog you will see that I am suggesting that the likes of the DTCC and the FSA are the most likely candidates for holding a registry of all XBRL Issuers. I cannot see these organisations wanting to become CA's (although I have long held the belief that they should) so the answer maybe for an existing CA to issue a special root CA to DTCC or FSA or any other organisation that operates a Registry and these organizations can in turn use the same root certificate.

I don't think that there are many candidates for the registry operator role other than those that I have mentioned. The hardest part will be for them to agree on a common course of action.

One other problem arises. What happens to the XBRL file once it has been received. A file may contain hundreds of tagged items, the very nature of an xml file is that it is a text file and can be edited. How do you handle or authenticate that a piece of tagged data within an XBRL file has not been changed once it arrives inside your organization? I don't have the answer to that one.

Report