 |
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:
- 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.
- 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.
- 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.
- 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:
- What do industry participants need for unique security identification (at what
level of granularity and for which type of product) to perform their function.
- Are these data
elements needed for identification of the attribute of the security or attributes
of an event/transaction.
- How do various segments of the industry currently get the information they
need to fulfill their security identification functions?
- 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.
|
|
|