FISD HOME Financial Information Services Division of Software & Information Industry Association - Your Market Data Business Connectionvisit the SIIA website

Google


web www.fisd.net

MARKET DATA
BUSINESS MANAGEMENT
CONTRACTS
OTHER
ADMINISTRATIVE
MARKET DATA CONTENT
REFERENCE DATA
MARKET DATA
DEFINITION LANGUAGE
FISD WIKI
INDUSTRY ISSUES
MARKET DATA REGULATION
MiFID JOINT
WORKING GROUP
FISD ON LINKEDIN
2008 CODiE Awards Call for Nominations


Market Data Training


Inside Market Data


Inside Reference Data


Symbology/Security Indentification

Report from Meeting of Unique Security ID Committee

April 18, 2001


Organizations Present

ADP, Bank of New York, Bloomberg, Bridge Information Services, Brown Brothers, BNY Clearing, Capital Group, Credit Suisse First Boston, DTCC, FISD, Goldman Sachs, Interactive Data Corporation, JP Morgan/Chase, Lehman Brothers, Mellon Trust, Merrill Lynch, Merrill Lynch SPS, Metamatrix, Moody's Investor Service, Prudential Securities, Reuters, Standard & Poor's/CUSIP, State Street Bank, SWIFT, Swiss American Securities, Thomson Financial, Wachovia Securities

Meeting Objectives

This inquiry grew out of discussions with the ANNA Service Bureau (ASB) on the relationship between ISIN, market identification code and register level identification. The goal is to determine the requirements for unique security identification and to help the industry meet the automation objectives of T+1 and STP. FISD is acting as a neutral facilitator of the discussion.

Hypothesis: As the common link for automated trading/execution systems, primary identification must contain all relevant information (i.e. all data elements required to set up and maintain security master files) essential to precisely and uniquely identify the security throughout its life span. The discussion with ANNA confirms that ISIN is a unique identifier per the ISO-6166 standard and the ISIN guidelines for fungibility. However, since ISIN is a unique issue identifier and not always a unique security identifier -- additional data elements might be required.

The Problem

Financial instruments can be issued, priced, traded and settled in many ways. Market level identifiers (ISIN) do identify a security at the issue level and are valid for front office systems and for the aggregation of global positions. But the world of (cross-border/cross-location/cross-exchange) security issuance, pricing, trading, and settlement has become more complex. Different identifiers are relevant at various levels. It seems plausible that a multi-level product identification scheme might be required to identify:

  • the market (regulated or not) on which the trade took place;
  • the clearing system through which the trade will clear;
  • the central depository or ICSD where the trade will settle; and
  • the registration to perform "electronic book entry" to record changes of securities ownership.
There are a number of reasons why a multi-level product identification scheme might be desirable. In particular:
  1. New exchanges, ECN's and ATS's operate in markets where previously there was only one exchange. That means that a single security may be registered and traded on more than one exchange/ECN/ATS in the same geography. The proliferation of cross-border marketplaces also means that market level identifiers (such as ISIN, CUSIP, SEDOL) can't be relied on to uniquely identify the market where an instrument trades.
     
  2. Exchanges are developing multiple trading linkages allowing their members trading access to securities held on other exchanges. In essence, securities registered on one exchange may be traded on a linked exchange. Registers of securities are not exchange or country dependent and the same security can be registered in one or many locations and traded in each. Where an instrument is held in more than one register, settlement issues can arise if client orders are taken/filled without explicit reference to the register required. Where an instrument in one register can be traded on multiple markets, efficient operations processes (such as depository management or corporate actions) will require a common identifier at the market level.
     
  3. In addition, inter-depository links allow settlement to occur in multiple locations. In essence, the means of settling trades in an instrument is becoming less a property of the instrument, and increasingly driven by the market or counter-party preferences.
     
  4. Finally, there are pricing/valuation/currency variations for a single instrument trading in multiple locations. Security pricing needs to be referenced at the market level

Consequently, the relationship between a security, an exchange, the price and a settlement system has become a multiple of the possible permutations of register, exchange/market center and settlement system for a security. As a result, ISIN alone no longer provides an unambiguous pointer to trade and settlement location -- or security price. The expectation is that historically rare trade failures associated with incorrect sourcing and delivery of securities will become a more significant problem.

Investigation Approach

The working group agreed that the first step is to fully document the problem for each segment of the industry by instrument type and function. The second step will be to identify the full range of possible solutions. The third step will be to balance the requirements for unique security identification against practical implementation reality. The final step will be to achieve industry consensus on the path forward.

The chart below describes the approach we're suggesting to define the scope of the problem for each segment/function. The indicated companies agreed to help refine the specific issues. The core questions out of the first phase of the investigation are:

  1. What do industry participants need for unique security identification (at what level of granularity and for which type of product) to perform their function.
     
  2. Are these data elements needed for identification of the attribute of the security or attributes of an event/transaction.
     
  3. How do various segments of the industry currently get the information they need to fulfill their security identification functions?
     
  4. What are the real-world, concrete examples of problem situations? [Alternatively, what industry adjustments/developments will make this issue more important and why?

Types of Parties

Volunteer

Types of Functions

Identification Factors

Buy-Side Investment Management.

Capital Group, Credit Suisse

Trading/Portfolio Management

Currency (trade, hold)

Sell-Side Trading

Merrill Lynch

Trade Execution

Market (listing, trade)

Custody

Chase, Mellon and BONY

Positions (trading/holding)

Issue (ISIN, National Number)

Operations

Goldman Sachs

Pricing/Valuation

Regulatory/Legal Restrictions

NNA/Numbering Assignment

CUSIP

Settlement

Fungibility

Vendors/Pricing

Telekurs, Bridge, Bloomberg, Reuters, Moody's

Corporate Actions

Register Level

Depository

 

Regulatory Reporting/Compliance

Sub-agent of settlement (custodian)

Markets/ECN

 

Risk Management

Symbol

  

Database Management

 

Timeline

FISD has set two broad milestones. The first is to deliver an unbiased and comprehensive statement of the problem by June, 2001 (at the next ANNA User Group meeting in London). The second is to have an analysis of the possible solutions by November, 2001 (at the FISD World Financial Information Conference).

  • Initial investigation assignments are due to FISD on or before May 1.
  • The next working meeting is scheduled from 10:00am - 1:00pm on May 4 at Merrill Lynch (World Financial Center, North Tower) in New York City.
  • FISD agreed to work with SWIFT to ensure a broad discussion of this issue. We will try to manage this inquiry on a global basis with the results of the discussion in North America feeding into the next meeting in Europe -- and so on. All meetings will be accessible via conference call and scheduled to facilitate cross-continental participation.