Battle over future of data ID standards hots up

By Allan D. Grody, president, FinancialInterGroup Advisors

Bloomberg, Markit, Cusip Service Bureau andother data vendors have been posting on the various blogs and giving interviewsabout the administration of the International Securities Identification (ISIN) numberingsystem. Bloomberg and Markit offer their own codes while contending ISINs are apoor chose as a unique product identifier (UPI) for Europe’s Mifid II/Mifirimplementation which affects all tradeable contracts and instruments. Cusipthinks otherwise, being the largest issuer of ISINs. The International Swaps andDerivatives Association would like to see the completion of regulators consultationson all identifiers before deciding.

Bloomberg describes quasi-monopolistic practicescarried out by embed intermediaries in the ISIN process that is designed toassign codes to identify financial instruments and contracts. They point outthat newly regulated over-the-counter derivatives are not covered by ISINs andspeculate whether the European Securities and Markets Authority, the proponentof Mifid II/Mifir legislation and its support of ISINs haven’t been misinformedabout the ISIN system. 

While archaic, ISINs have become fundamentalto the functioning of the industry’s infrastructure even though new regulatorydemands and teachings from ours and other industries show other, more efficientpaths that can followed. Those paths, by borrowing methods from commercialbarcodes and Internet domain naming procedures, can accommodate a moreefficient error free automated process, one that removes intermediaries fromthe process and provides direct from-the-source data.  

Following a half century of sovereigncountries’ independently constructing and assigning their own codes, and after nearlythree decades of the ISIN standards, it may be time to question whether thesecodes, intended purely for identification purposes, are still fit for purpose.Also, whether the means by which they are assigned and registered is stillvalid.

This reexamination should be considered inlight of more direct at-source methods of assigning and registering codes. Alsoto rethink the structure of these codes to enable direct data aggregation ofthe financial transactions in which these codes are embedded. Data aggregationhas emerged as the key requirement for enterprise-wide risk management and globalsystemic risk analysis, and for aggregating swaps trade repository transactionsand observing counterparty risk.

This rethink is necessitated not only asglobal regulators and government standards setters demand data aggregation capabilitiesbut also as a vastly changed financial industry has evolved from specificcoding schemes used in sovereign markets to ones needed for global markets. Itis also playing out against the background of the legacy systems of thecomputer age of a half-century ago, when these numbering schemes were firstinvented, to the real-time needs of an evolving industry’s infrastructuregrappling to transform itself in the digital age.

TestingNew Data Standards

The first real test of global codingschemes is playing out in the newly regulated global swaps markets where theISIN standard is being questioned as the appropriate standard for the required UniqueProduct Identifier (UPI). Also remaining is the question of whether the newfinancial market participant code, the legal entity identifier (LEI), can beused for data aggregation and, also, as the prefix for the unique transactionidentifier (the UTI), whether in its full version (20 characters) or in itsshortened (hashed) version of ten (10) characters as proposed by Isda.   

The decades old ISIN system of securitiesidentification is administered by over one hundred National Numbering Agencies(NNAs) and Substitute National Numbering Agencies (SNNAs), and two InternationalCentral Securities Depositories (ICSDs), Clearstream and Euroclear Bank. Thecodes they construct define the principle method computers access, process, associateand aggregate securities transactions throughout the automated plumbing of ourglobal financial system. That method is data mapping, itself an archaic errorprone and costly process.

In addition, the Association of NationalNumbering Agencies (ANNA) organises its NNA members to feed locally registeredcodes to a centralised data base administered by the ANNA Service Bureau. SixFinancial and the CUSIP Service Bureau manage and administer the ANNA ServiceBureau under contract to ANNA. In addition, the data base includes market andasset classification codes and, most recently, the Legal Entity identifiers(LEIs). These codes collectively identify issuers of securities, lead and individualfund managers, swaps dealers and swaps market participants, clearing organisationsand central securities depositories (CSDs). 

ISINvs. GLEIS

Bloomberg has compared practices of theevolving Global Legal Entity Identifier System (GLEIS) favorably to establishedISIN practices. The GLEIS is the global system established by the G20’s neweststandards setting body, the Financial Stability Board (FSB), to administer theLegal Entity Identifier (LEI) – a new code for financial market participants. InBloomberg’s postings the administrative process of the GLEIS is found to bemore virtuous than those of the ISIN system; being more transparent; having non-exclusiveassignment of facility operators; encouraging competition; and having a lessrestrictive (non-profit) revenue model to mitigate costs to end users.

Common to both is that the GLEIS like theISIN system relies on local numbering conventions and independentlyadministered facilities operators, NNAs in the case of ISIN’s and LOUs (LocalOperating Units) in the case of the GLEIS. In light of well-establishedself-assigned and self-registered methods of direct data input and codeidentification in other industries the necessity of intermediaries should be questionedin the value chain of code identification and assignment.

For example, both the GLEIS and the ISINsystem have myriad of companies and government agencies as data intermediaries,as either NNAs, SNNAs or LOUs, and some operate in all three capacities (WMDatenservice and the London Stock Exchange are two such examples). They includecentral bankers, patent offices, data vendors, central depositories, businessregistrars, exchanges, clearing organisations and technology companies. These diverseset of organisations operate for-profit, cost recovery, and non-profitbusinesses, and some operate under all three business models.

The separate NNA codes, constructeddifferently by each NNA, many relating to the same issuing company, are broughttogether through the ISIN system by adding the home country of the issuingcompany’s two character ISO country code to the local home country code, thencalculating and adding a check digit. It is then left to a mapping process toassociate all the separate codes for the same issuing company together throughassociating them with the ISIN. In turn, as the end objective for use of thesecodes, all financial transactions containing these codes are aggregated into atotal position of the same security.

The process of managing ISIN and local NNA codesfinds analysts at National Numbering Agencies struggling with interpretingoffering documents. These analysts interact with people at issuers, investmentbankers, talk with lawyers and accountants, all of whom had a hand in creatingthe enabling documents (i.e. trusts, prospectuses, collective investmentregulatory filings etc) that describe these securities.  This is necessary to help them interpret theoffering documents so they can describe the bond, or equity issue or mutualfund, and assign it a code. Analysts at data vendors, likewise, struggle at adata element level to interpret these documents so they can provide deeperdetail beyond the name of the contract or instrument or the legal entity.

In stark contrast, most annual financialreports prepared for regulators are transformed at-source from paper documentsinto computer readable format through the XBRL (eXtensible Business ReportingLanguage) data tagging convention. Also, Municipal bond data is transformedfrom paper documents by lead underwriters through an input template at theelemental data level for setting up data processing attributes for recording bythe US’s central depository, Depository Trust Company (DTC). InternationalSwaps and Derivatives Association (Isda) transforms contracts into data fieldswithin an fpML (Financial Product Markup Language) data tagging protocol.

However, data from prospectuses, trusts,offering memorandum, articles of incorporation and other such documents thatare the source of contract, instrument and financial market participant onboardinginformation is left to multiple interpretations by regulators, data vendors,NNAs and LOUs. Providing computerised formatted data, uniquely identified andin standard form, from its source would go a long way to improve data quality,eliminate unnecessary supply chain intermediaries, and reduce the overall costsof systems and manual process that supports the duplicate plumbing of financialsystems in each financial institution and across all financial marketutilities. We and others have estimated that cost to the industry at $50 – $100billion.

Now, while comparisons of ISINs to LEIs arewarranted, it is an insular comparison made by practitioners historicallyanchored in the system of the NNA and ISIN codes, and now extended to thethinking that went into the new GLEIS with its LOU intermediaries and LEI  “dumb number” codes. There are differences asnoted by Bloomberg, but at the margins, with much in common. They are, inessence cut from the same ‘legacy’ cloth.

DataMapping - Compensating for Non-standard Identification

Mapping issues of ISINs and their localcodes are the same as those of the mapping issues of Legal Entity Identifiers.LEIs, like ISINS are constructed from local codes and, like ISINs, a prefix isattached. In the case of ISINs a country code is attached and with LEIs a codefor the facility operator assigning the local code, known as the Local OperatingUnit (LOU), is attached.

In invoking the current thinking oncryptographic discipline, not necessarily what the financial industry needs,regulators have declared the LEI codes ‘dumb’ numbers, although they have somestructure to them. There is nothing in the LEI code that allows it to beassociated with its registering parent. The LEI code is based on the ISOstandard that describes 18 alphanumeric characters followed by a two digitcheck sum. The structure shown above was imposed later by the FSB. The GLEIS isstill a work in progress. Still to be resolved is the way these LEIs are to berelated to one another to allow data aggregation up through the hierarchy ofownership and control.

The ISIN code and the Cusip number in theUS, both developed long ago is the exception to the ‘dumb’ number discipline.The ISIN contains an observable two character country code and the Cusip numberhas an issuer code prefix for the company, followed by an issue code for thecategory of stock (common, preferred, class of issue etc) or bond (rate, couponpayment frequency etc). This allows the codes to be used for identifying itshome country in the case of the ISIN and its issuer (legal entity) and issue inthe case of the Cusip code.

In the example of IBM, its Cusip isconstructed using an assigned issuer number for IBM (issuer code 459200)followed by 10 for common stock – all common stock issues are identified as“10” for all issuers, followed by a check digit “1” calculated from theprevious eight digits. This allows for the aggregation and valuation of allcommon stock of IBM held in a position on the books of a financial company by usingjust the code. If this concept was used for all NNA codes and all legal entitycodes, each starting out with a preassigned ‘company prefix’, then dataaggregation using just the codes would be possible.  Why would we want to do this is explainedbelow.  

This Cusip code construction is like thecommercial codes found in barcodes where a company prefix is first assigned andthen a product code affixed. Unlike Cusip numbers, however, the company prefixfor barcodes is uniquely assigned by a local facility operator from a globalpool of numbers, then the product code is affixed by the company itself, notthe facility intermediary as is the case of the NNA’s Cusip Service Bureau.This is a distinction with great meaning and implications for data aggregationthat we discuss below. 

Complex funds families, significant issuersof globally traded multiply listed securities, government issuers of sovereigndebt, complex financial institutions, and complex financial market participantshave multiple codes assigned to contracts and instruments, and legal entities.Many of these organisations will have thousands of these codes assigned.

DataAggregation – the End Objective

To aggregate transaction data for valuation,performance and risk analysis these independently derived dumb codes have to bemapped together, the NNA codes horizontally for a total picture of a singleasset position and the LEIs vertically through its hierarchies of ownership andcontrol for a aggregated view of a counterparty. These processes are the sameacross all financial market participants and their products. These mappings arein addition to the mappings to the hundreds of proprietary codes required bydata vendors and software companies to utilise their business applications anddata feeds.

If a company is given a globally uniqueregistration code a ‘company prefix’ and uses it as the prefix for assigningits multitude of legal entities and the many instruments it issues or tradeablecontracts it manufactures, then we have a mechanism to link them together fordata aggregation. This mechanism, placed directly in the codes will eliminateovertime the additional costs of facilities operators, data vendors, softwarecompanies and so many other intermediaries now necessary to map bothproprietary and “standard” codes at significant operational costs and risks tothe industry.

SteppingAway from a Legacy Mindset

Isn’t it time we step away from the legacymindset that is still acting to restrict our newest opportunity, thedevelopment of the LEI, from a restrictive view of an identification standardto one that facilitates the ultimate requirement of new uses for data standards– that of data aggregation?

Without a hierarchical construct to thebasic code structure for contracts, instruments and legal entities the mappingissue that causes so much cost and risk will persist and the regulatoryobjective of systemic risk analysis will go unfulfilled. Without at-sourceautomated input of data elements that relate legal terms from enablingdocuments into computer readable formats, our industry will always suffer fromdata quality issues and, thus, be inhibited from ever fulfilling the promise ofreal-time straight-through-processing.