June 18, 2002
 

This report provides a synopsis of FISD’s activities related to symbology, security identification and security numbering including the results from the ANNA General Meeting (May 2002) and the FISD Working Meeting (June 2002). Supporting documentation is available on the Security Identification section of the FISD web site.

EXECUTIVE SUMMARY

ANNA General Meeting: FISD (representing the ISIN User Group) was invited as a guest at the Association of National Numbering Agencies (ANNA) meeting (May 30-31) in Athens, Greece. This was the 10th anniversary of the creation of ANNA. A copy of our presentation is posted on the FISD site.

ASB Contract: FISD members are working with the ANNA Service Bureau (ASB) to adopt a modular contract for access and usage of ISIN numbers. The modular approach promotes a core license with separate addenda for NNA’s that currently require additional licensing terms. FISD members have drafted a modular contract for NNA consideration.

Progress was made at the Athens meeting toward adoption of the proposed contract. The NNA’s understand the concept and are ready to evaluate the content of the contract as proposed by the ISIN User Group (through FISD). The ANNA Board agreed to review the revised standard contract and to make a recommendation (with supporting documentation) to the NNA’s by June 30, 2002.

Unique Security Identification: FISD has been in active discussions with ANNA on ISIN, its role in STP and the additional data elements necessary to ensure that ISIN contains all relevant information essential to precisely and uniquely identify financial instruments. FISD research indicates that while ISIN is a unique issue identifier, it is not always a unique instrument identifier. In addition to the ISIN, the most critical data elements are the official place of listing (OPOL) for multiple listings and a register level identifier for settlement compatibility.

It is unclear whether the mission of the ASB is solely on the collection, maintenance and dissemination of ISIN and CFI data or whether the mission could be expanded to enable the ASB to add additional data elements required for unique and precise instrument identification.

Business Entity Identification: FISD has been involved in discussions with SWIFT and SC4 on the need for an International Business Entity Identifier (IBEI). These identifiers are needed to for counterparty identification on transactions, risk management and regulatory reporting – but do not currently exist.  Report

This issue is now under review by SC4/WG8. The proposal is to extend the Bank Identifier Code (BIC ISO 9362) to cover all entities that are relevant to the securities industry and to include BIC under the SC4 work program. SC4 is forming a working group to investigate these issues and has invited FISD to participate in the working group and contribute to the investigation. The IBEI working group is on the agenda for consideration at the October SC4 meeting in Istanbul. FISD will be coordinating industry commentary and will submit a paper to SC4 (deadline is September 20).

Market Identification Codes (MIC): SWIFT (the registration authority) is in the process of updating Market Identification Codes (MIC). As of May over 90% of the MIC had been validated. 80% have been confirmed, 10% withdrawn and 10% are still under investigation. MIC has been expanded to include ECN/ATS. For a copy of the MIC currently under investigation, contact Sandy Dinetz at 212.855.1392.

Classification of Financial Instruments (CFI): During the ANNA meeting, there was significant discussion on the extent to which CFI Codes are being used by the securities industry. The NNA’s are very interested in getting a better understanding of whether the business case still exists for this standard (ANNA would continue to make the data available. The issue is whether the CFI code is required and being used by the industry).

ANNA is the official registration authority for CFI and is obligated to maintain the standard. As part of their obligation, ANNA members are working to assign CFI for new ISIN’s by June 2003 and for existing ISIN’s by January 2004. Industry participants are encouraged to provide input on the value of the CFI code versus the importance of continuing to provide the underlying data that goes into the CFI. Comments can be directed through Michael Atkin.

ASB CONTRACT

FISD members have developed a modular contract covering access to ISIN data provided by the ANNA Service Bureau. The modular contract consists of a core license and allows for the addition of separate addenda for Numbering Agencies that require additional licensing terms. Based on the original documentation, the goal of the ASB contract is to:

• Centralize and simplify contract administration to avoid complex or non-available bilateral agreements – and to resolve data accuracy, technical and access issues.
   
• Clarify NNA business requirements including which NNA’s require bilateral agreements and which are covered under the core ANNA agreement.
   
• Promote transparent pricing, data usage policies and commercial terms and conditions.
   
• Maintain a level playing field among all recipients of ISIN data.

The overall objective of the ISIN User Group is to facilitate the discussion about commercial structures that simplify the acquisition, redistribution and usage of primary identifiers and support the objectives of T+1 and STP while continuing to protect the commercial requirements of the data originators. ISIN User Group members continue to make a distinction between two primary data types – (1) the unrestricted use of core ISIN (including all data elements required for unique identification) and (2) all other information including cross-references, fundamental information and any other enhanced data sets. Primary identification numbers (ISIN) are fundamental to business process automation. Commercial structures should be designed to promote widespread access and usage.

ASB Proposal

The ASB attempted to create one uniform license to obtain, use and redistribute ISIN information. And while a single uniform contract is desirable, the ASB proposal mandate terms and conditions that are more restrictive than those already in place. Many of the ISIN User Group members get direct feeds from the NNA’s and will continue to use the ASB feed for validation of unique identification. It is very unlikely that they will accept a global licensing solution that conflicts with existing agreements.

ISIN User Group Proposal

The User Group has created a modular approach that consists of a core agreement and allows for the addition of separate addenda for NNA’s that require additional licensing terms. The proposed agreement was constructed from the ASB ISIN Data License with some alternative terms and conditions from agreements already in place. The modular agreement centralizes contract administration, creates a uniform template and provides a starting point for ongoing discussions about rights, obligations and usage requirements.

The approach was to base the modular agreement on pre-existing contracts to ensure its acceptability to the NNA’s. The User Group strongly believes that the contractual requirements of a majority of NNA’s have been incorporated into the modular license and that the vast majority of NNA’s will not require separate addenda.

Outcome

By the conclusion of the ANNA meeting, the ANNA Board agreed to review the revised standard contract and to make a recommendation (with supporting documentation) to the NNA’s. This was supposed to happen by June 30, 2002. We are tracking the status of the contractual review with ANNA and the ASB and will notify members of the outcome of these discussions as they occur.

UNIQUE SECURITY IDENTIFICATION

Financial institutions buy and sell a variety of instruments that can be issued, priced, traded and settled in many ways. As such, different types of identifiers are relevant at various levels for a variety of functions. The underlying problem is that the international standard (ISIN) alone is not sufficient for the automation requirements of T+1 and STP. Automation requires a precise instrument identification scheme to eliminate inefficiencies and mitigate the risks of trade failure.

Over the past year, FISD has been working with ANNA on a host of issues including definition of the additional data elements necessary to uniquely and precisely identify financial instruments throughout their entire lifespan. Our research indicates that while ISIN is a unique issue identifier, it is not always a unique security identifier. ISIN alone is not sufficient for unique identification because one ISIN can be shared among offerings in multiple locations.

The most critical data element for unique identification is the official place of listing (OPOL). OPOL identifies the primary and secondary markets where the security is listed and is needed to differentiate the security in the case of multiple listings. A market issuance in multiple locations will be subject to different settlement, pricing, tax/corporate event treatment, and allocation of national numbers.

Our research also indicates the importance of register level information for determining transferability across markets and to help route the security to the correct place of settlement and holding. Registration is needed to determine settlement compatibility and must be known at the point of trade to ensure that the risk is manageable.

In Athens, FISD strongly suggested that the ASB, as the consolidator of ISIN data for the NNA’s, has an opportunity and an obligation to ensure that the ASB feed contains all relevant information required to uniquely and precisely identify financial instruments. The ASB Board is considering the request but seems to favor keeping the ASB focused on its core mission – i.e. the collection, maintenance and dissemination of ISIN and CFI data. It is unclear whether ANNA is willing to extend the mission of the ASB to allow them to collect and provide additional data in response to marketplace needs.

FISD is waiting for a final decision by the ANNA Board on their interest and ability to provide OPOL/Register level (and beyond) information. If ANNA/ASB are not willing to provide this information, FISD members are interested in discussing alternative sources (and some have been identified) of acquiring the data.  Presentation

BUSINESS ENTITY IDENTIFICATION

As stated, financial institutions interact with a variety of entities associated with trading, settlement and account management. Identifiers for these entities are required for many reasons:

• Counterparty identification on transactions (orders, trades, settlement, payments)
• Counterparty and issuer risk management
• Collateral management
• Data management (capture/sourcing, look-up and cross-referencing, maintenance)
• Legal agreements and documentation
• Corporate research
• Regulatory reporting

Importance of Business Entity Identifiers (BEI)

Industry standard entity identifiers that create precise linkages between legal entities, subsidiaries and investment “programs” are required to help firms manage portfolio and enterprise-wide risk. Most firms are currently able to create effective links from an issuer to a specific issue within their security master databases. The problem they encounter is that there is no standard methodology for linking multiple investment programs to a common legal entity. Firms are currently using name (problems with accuracy and consistency), internal codes (manual and error-prone process) or proprietary codes (commercial concerns and redistribution restrictions) to create these linkages.

What’s desired is an industry standard master company identifier for non-financial entities that links issues to investment programs to legal entity. This type of coding scheme would make it easier for investment firms to assess and manage total risk. The situation with Enron is a perfect example of the requirement. Enron (the legal entity) is at risk and firms need to know what issues in their portfolios are linked to the legal entity. Without such linkages, firms have a difficult time being able to gauge their total risk.

Status of Discussions

This issue has been under various forms of discussion within SWIFT since 1998. A working group was formed and recommended the assignment of BIC codes as a short-term solution and the creation of an IBEI “envelope” standard. The recommendation did not have sufficient support within ISO (at the time) and was not progressed. The problem still exists and is becoming more important. SWIFT has asked TC68 and SC4 to take over the IBEI work item. Two approaches have been identified.

IBEI Generator

The first (initially advocated by the SWIFT Standards Department) proposes a new code to identify business entities. A draft proposal was written to create an “IBEI generator” under the responsibility of a Registration Authority. The generator would be available on an IBEI website and used by financial institutions to attribute IBEIs to their client business entities. A strong control mechanism based on key information on the business entity, including its existing national identification number(s), would have avoided duplication of IBEI’s for the same entity by two different financial institutions. Publication and retrieval of attributed IBEIs would have been made publicly available through the IBEI website.

Extend BIC

Before moving forward with the IBEI generator proposal, SWIFT was asked to investigate whether the BIC could be extended to also cover identification of business entities. This suggestion was made based on the assumption that the purpose of the IBEI was similar to the purpose of the BIC (i.e. to identify only business entities of relevance to the securities industry).

SWIFT has created a multi-functional working group to investigate (throughout the full range of SWIFT messages) cases in which business entities would need to be identified by and IBEI rather than by another existing code (e.g. IBAN) or simply by its name/address. The goal is to be able to estimate the number and type of business entities that would need to an IBEI. If the resulting total number of necessary IBEI’s remains in a range that can be accommodated by the BIC scheme, SWIFT will propose to ISO to extend the scope of the BIC for that purpose. This solution (if feasible) would be preferable because it minimizes the investment required by the financial community.

SC4 Approach and Action

SC4-is in favor of extending the BIC-standard (ISO 9362) under the SC4 work program. The objective is to identify all entities of relevance to the securities industry - except mutual funds that have been determined to require a separate Fund Identification Code (FIC). SC4 is now considering the creation of a new working group to investigate the best way to achieve full coverage of entities (either using BIC or developing a new identification scheme).

This issue will be part of the SC4 plenary meeting (to be held in Istanbul October 14-15). The U.S. delegation consists of Cindy Fuller (X9), Sandy Dinetz (DTCC), John Goeller (Lehman) and Scott Preiss (S&P/CUSIP). The chair of SC4/TC68 is Nourredine Yous (Telekurs) FISD members are encouraged to provide input (in any form) to help clarify industry requirements and evaluate potential solutions. The U.S. delegates are willing to carry our requirements forward. Please direct your thoughts and recommendations to Michael Atkin.

MARKET IDENTIFICATION CODE

The Registration Authority is updating ISO 10383 Market Identification Code (MIC). The new list of MIC Codes will be incorporated into the ISO 15022 website. FISD has a copy of the latest spreadsheet. Any FISD members wishing to provide comments, suggestions and recommendation should contact Michael Atkin or Sandy Dinetz.