 |
Symbology/Security Indentification
|
|
|
|
|
ANNA/SWIFT
Specification to ASBJanuary 10, 2001
Members
of both FISD and SWIFT have reviewed this document. We have reorganized the original
specifications document into three broad categories: (1) core product specification,
(2) performance issues related to ANNA guidelines/rules, and (3) access and licensing
issues. Comments in red reflect the notes provided to FISD as part of the review
process.
It
is important to reiterate that the goal of supporting the ASB is to help the industry
meet the automation requirements of T+1 and STP. As such, all financial instruments
that are issued and tradable should have an ISIN* -- and all numbering agencies
need to understand and adhere to the ISO 6166 standard. As the common link for
automated trading/execution systems, primary identifiers (ISIN) must be available
prior to the date of security issuance and contain all relevant information essential
to precisely and uniquely identify the security throughout its life span. We view
unique identification as a core rationale behind the creation of the ASB. And
while we recognize that some of the requirements outlined in this specification
might require modification of the ISO 6166 standard, we strongly encourage the
ASB to directly address this essential issue.
*
Assignment of ISIN's
to certain instruments (i.e. futures, options, commercial paper, other derivatives)
-- particularly those that are traded under exchange symbology -- pose special
problems. It is not clear that the industry should yet conclude that ISO 6166
is the solution to this problem. The two issues to be examined include the problems
of turnover (i.e. multiplication of the number of ISIN's needed) in these securities
and the cost implications associated with assignment, database storage and downstream
licensing. The issue of whether to assign ISIN's to ALL financial instruments
is complex and is worthy of open debate.Note:
For the purposes of this document, FISD and SWIFT view the "customer"
as the entire ISIN supply chain. Where timing requirements are defined, care must
be exercised to ensure that notification is sufficient to enable vendors to react
to the timeframe requirements of the end users.
Product
Specification a)
Core Data Element Definition Core/basic
security identification information -- meaning all data elements required to uniquely
set-up a master security file -- should be accessible to all levels of the marketplace
on fair and reasonable commercial terms. There must be an absolute level playing
field between core ISIN data and any other value-added proprietary products in
terms of timeliness, content and dissemination priority. The core product must
include enough information to explicitly identify the security.
- Priority 1: The industry needs to be able to support multiple prices for a
single ISIN and internal systems need to be able to handle the method of communication.
- Priority 1: The minimal requirement is for the industry to agree and have access
to a uniform exchange code and register level identifier.
The seemingly
universal opinion is that in the absence of a standard that creates truly unique
ISIN numbers, a compromise might be the inclusion of MIC (if market identification
code is used to identify settlement exchange) and CCY of issue as integral parts
of the "ISIN" identification. These two data fields are mandatory in
instructions for all settlement locations globally. The point has been made that
the current standard offers some advantages that would be sacrificed if the ISIN
were made truly unique (e.g. ability to roll up stocks). In
the research SWIFT conducted with many financial institutions, they determined
that a minimum data set necessary to form a usable database comprised 17 fields.
Those fields are indicated in red. FISD members have expanded that list and have
defined two data element levels. Level 1 (L1) includes elements currently contained
in the GIAM 2 feed. Level 2 (L2) elements are also required data elements -- not
currently being disseminated by NNA's -- but that are essential for automated
execution and trade processing. In
addition, serious concerns have been expressed about the ISO 10962 Classification
of Financial Instruments (CFI) code. The feeling is that since a number of NNA's
do not correctly use and disseminate CFI codes the core ASB product should treat
the required data elements as individual fields. Those fields can certainly be
based on and use the CFI methodology. The following list is a consolidation of
the information that should be included in the core product:
•[L1]
Security Type (should include both type/CFI categories and subtype/CFI groups)
•[L2]
Market Identifier (Dealing exchange, new/to be defined)
•[L1]
Currency of Denomination Identifier (currency of issue)
•[L2] Country of Issue Registration (new/to be defined)
•[L1]
ISIN Code •[L1]
ISIN Type and Status (action code for change, delete, modify)
•[L2] Cross-References to Originators Local Identifier
(i.e. SEDOL, CUSIP, etc., new/to be defined) •[L1]
Date Added •[L1]
Date/Time of Last Update •[L1]
Date and Reason Deleted •[L1]
Issuer Name (long/ISO 18774 and short) •[L1]
Issue Description (140 characters, ISO 18773)
•[L1] CFI Code or Other Security Type Classification
(ISO 10962)
•[L1] Nominal/Face Value
•[L1]
Country of Issuer (Domicile code for issuer/lead manager)
•[L1] Bearer/Registered |
•[L1]
Syndication Code •[L1]
Coupon Rate for Fixed Term and Preferred Instruments
•[L1]
Maturity Code (fixed income)/Expiry Date (warrants)
•[L2]
Strike Price for Warrants/Options (if ISIN is assigned for options)
•[L2] Underlying Issue for Warrants/Options
•[L1]
Type of Interest (payment type)
•[L1] Interest Payment Date (accrual)
•[L1] Interest Frequency (if fixed)
•[L1]
Interest First Payment •[L2]
Restrictions (e.g. regulation 144A, S, D, 3C7)
•[L1] Any Comments (all explanations e.g. name changes,
mergers)
•[L1] Error Flag
•[L1]
Sender References •[L2]
Previous ISIN number if security previously existed under another ISIN number,
effective date and reason for change. (CoAcs, new/to be defined) |
Note:
Additional data elements (i.e. refunding, pre-refunding, secondary issued)
are needed for municipal securities -- particularly if they grow in international
trading and if GSTPA needs the ISIN for trade processing. b)
Timeliness, Accuracy and Usability Timely
electronic access to ISIN data (in a standard format) prior to settlement date
is essential for ISIN to survive as the standard in a STP environment. Adherence
to the ISO standards and ANNA Guidelines are mandatory. There should be no workarounds
to handle internal NNA system issues unless ISO 6166 is modified to specifically
define how internal values are defined. The goal is to help the industry move
away from manual processes toward proactive electronic comparisons. Priority
1: Access to the data must be available in electronic batch form on a daily
download and be available in interactive/real time. If the NNA provides intra-day
services, such services should be available to vendors/users. Daily or intra-day
electronic batch files must be easy to use (no encryption) and must ensure
referential integrity (i.e. provide the ability to determine additions
and changes to the information).
Priority
1: The ASB will use best efforts to make the ISIN data available to the user upon
receipt from the NNA (ideally within 1 hour).
Priority
1: The ASB will provide access to all data in its database as per the agreed content
of an ISIN record. The datafeed processing for both internal (i.e. value-added
products) and external (i.e. ASB) should be done in parallel. In addition, data
that is supplied by NNA's to fulfill their obligations as numbering agencies should
not be diverted for private purposes.
Priority
1: The ASB will use best efforts to provide accurate pass through (no errors in
transcription) of the information from the NNA and be accessible on a consistently
reliable (i.e. target is 99.999%) basis to all users.
Priority
2: All data (including historical records) required for initial master security
file set-up must be available from the ASB.
c)
Corporate Actions Corporate
actions (those that result in a new symbol and require a new ISIN) are not communicated
to the NNA in a timely manner. If there is a significant time gap between the
corporate action announcement and the assignment of the new ISIN, the trade is
based on the old security resulting in more manual processes and failures. The
problem is related to: (1) the lack of guidelines/regulations on communication
about corporate action to NNA, and (2) the lack of a standard global practice
(ISO rule) on the relationship between corporate actions and ISIN.
- Priority 1: NNAs should adopt local rules and standards that minimize the requirements
for the issuance of new security identification numbers and ISINs, unless absolutely
necessary based on legal changes in the security or instrument (as opposed to
simple changes in descriptive information).
- Priority 1: The
minimal requirement is for ANNA to support a uniform rule for when a security
identification number will change and that the goal of such rule shall be to minimize
the number of changes to the identification number itself.
- Priority 2: Communication between the NNA, paying agent and clearing agency
about corporate action linkages needs to be enhanced.
Performance
Issues
a)
New Issue Assignment Past
experience has demonstrated that some National Numbering Agencies (NNA's) are
slow to assign numbers due to manual processes and have difficulty managing the
assignment queue (backlog) when a new issue comes to market. As a result the number
is provided to the vendor after the fact -- which means the vendor has a symbol
in their database with no ISIN. Without the ISIN, the trade cannot be cleared
or settled.
- Priority 1: ISIN data is needed prior to issuance of the financial offering
and no later than the date of initial trading.
In the event that no ISIN
is allocated on the date of issue, an ISIN must be allocated by the date of first
availability for trading if this date is different from the date of issue. If
the date of issue and date of availability for trading are the same, the ISIN
must be available at the time of issue.
- Priority 1: On bulk assignment of ISIN (e.g. for U.S. Federal Agencies and
Canadian Depository for Securities Ltd.), communication must occur at the earliest
possible date.
At the very least, all new ISIN data needs to be made available
to the industry within the same timeframe as available to the NNA itself for preparation
of any security identification or corporate action processing.
b)
Non-Assignment of ISIN The
global financial industry has experienced problems with the assignment of ISIN
when the instrument doesn't meet the criteria of the NNA. This frequently results
in assignment delays and assignment of "dummy ISIN" by vendors, clearing
agencies and user firms. Assignment delays and dummy assignments inhibit the use
of ISIN as the global standard in some cases.
1.
Priority 1: All securities that are issued and tradable should have a uniform
symbology.
In general, no financial instrument should be issued without
an ISIN (recognize there is an open question on whether ISIN is the solution for
derivatives), even if only in short form/limited information on the security is
available. The goal is for the ASB to ensure that all NNA's allocate ISIN as per
the ISO standard. Allocation of an ISIN should not be optional or at the discretion
of the NNA.
2.
Priority 1: The ANNA Service Bureau should develop a clear, standard definition
of the minimum amount of information that needs to be provided in order to get
a number assigned. Communication between the issuer and the NNA on the request
for ISIN needs to be clarified and enhanced.
This refers to the requirements
of the issuers at initial assignment. The goal is for the ASB to define the minimal
standard for the release of the number and to have that standard applied on an
equal basis by NNA's.
3.
Priority 1: Dummy numbers should not be created and processed as an ISIN.
If
the ISIN is not available but the minimum information set is complete, the ASB
(or the substitute agency) should assign the ISIN and then reverse the process
into the NNA database.
Data vendors should not be forced to assign dummy ISINs under any circumstances.
Financial
institutions need to be able to allocate dummy numbers to compensate for non-assignment
and facilitate trading and settlement. If assignment problems are resolved, the
allocation of dummy numbers will be redundant.
Priority 1: NNA's (or substitute agency) should be able to codify all financial
instruments. If unable to assign a number, the industry should be notified within
24 hours of issue of a security if the NNA has been unable to assign an ISIN,
together with indication of remedial action. In the event that the service is
made interactive, then the notification would be required immediately.
The goal is for the ASB to work with ANNA and the NNA's to ensure
adherence to the standard.
Priority 2/3: The ANNA User Group is interested in working with the ANNA Service
Bureau to review and back-fill all existing valid securities without an ISIN for
subsequent assignment.
c)
Multiple Assignment of ISIN Clear
rules of assignment are required to deal with situations where the underwriter
approaches more than one numbering agency for an ISIN (i.e. multiple ISIN's assigned
to bonds in Japan). The industry seeks clarification of who is sanctioned to assign
ISIN's as well as the criteria for such assignment.
- Priority 1: The minimal requirement is for ANNA to designate the official NNA
in each country, and if more than one, to designate for which class of securities
each NNA is authorized to assign.
- Priority 1/2: The industry would like to see the ANNA Service Bureau establish
a real-time communication mechanism for notification of multiple assignment fixes
as well as to create a link between the numbers.
d)
Substitute Numbers Clarification
is required about the rules governing the assignment of substitute ISIN numbers.
- Priority 1: A clear escalation policy for when to use a substitute numbering
agency must be defined.
- Priority 1: All substitute NNA's must make substitute numbering data available
to vendors/users upon issuance.
Substitute numbering agencies must operate
on the same service level as primary numbering agencies (i.e. available on issue).
Access
and Licensing Issues The
value of ISIN in automated processing environments is dependent upon the customers
ability to both rely on it to precisely identify global securities and to store,
leverage and redistribute it easily and in an unrestricted manner for normal business
purposes. The primary requirement is for a single, centralized contract agreement
with the ASB that will facilitate access to and redistribution of core ISIN data.
a)
Licensing and Redistribution
1.
Priority 1: Distribution of the ISIN number should be unbundled from all other
data provided by the NNA. The license should permit downstream redistribution
of the ISIN without the imposition of re-licensing provisions, usage restrictions
or additional collateral agreements with individual NNA's for normal business
purposes.
- 2.
Priority 1: If additional agreements are required for redistribution of indicative/descriptive
data, the industry expects the ASB to be the central administrator for those addenda.
3.
Priority 1: There should be one uniform license to obtain, use and redistribute
ISIN information, regardless of the terms and conditions of an individual NNA.
The uniform license should be administered centrally by the ASB.
- 4.
Priority 1: The ASB product should be priced to take into account all the bilateral
needs of the NNA's who are contributing to the consolidated feed.
5.
Priority 1: The ideal product should be modular, allowing customers the ability
to select product segments as appropriate and pay fees accordingly. Customers
should receive credit against such cost if they maintain other direct services
with any of the NNA's.
b)
Customer Support
- 1.
Priority 1: Centralized, 24x7 support for data accuracy, timeliness, coverage,
technical and contractual issues.
- 2.
Priority 1: The ANNA Service Bureau should act as the contact point for resolving
multiple ISIN issues and any other data related questions.
3.
Priority 1: The ANNA Service Bureau should ensure prompt (one day or less) resolution
of disputes where multiple ISIN's have been allocated.
|
|
|
