 |
Symbology/Security Indentification
|
|
|
|
|
ANNA
User Group Meeting ReportZurich Switzerland
March
14, 2001
ANNA
Service Bureau FISD
has been in active discussion with the new ANNA Service Bureau (ASB) on assignment,
maintenance and commercial issues related to ISIN. FISD and SWIFT have collaborated
to produce a joint specification on the STP
requirements of primary security identification numbers.
The second ANNA User Group meeting was held March 14 in Zurich. The next User
Group meeting is June 12 in London. ASB
Status - The
ASB became official in January 2001. Most of the initial effort has focused on
sorting out the operational and technical infrastructure as well as on technical
testing. The ASB is scheduled to become operational in July, 2001.
- Both
Standard & Poor’s and Telekurs Financial will operate as data hubs for receiving
inbound ISIN data from NNAs. Both sites will operate regional offices (Telekurs
= Asia and Australia; S&P = Europe and Americas; no decision as yet on Africa).
There will be fully redundant databases in both NY and Zurich.
- In
addition to validating and processing all daily ISIN files, the ASB will be responsible
for delivering a daily batch file containing all adds, updates and deletes. The
ASB is building a customer support facility. Full details of the technical, customer
support and licensing approach will be outlined in their final specification report
due at the end of April.
- We
saw a demonstration of the real-time dissemination system during the User Group
meeting. The real-time system will be used for ad hoc queries and as a notification
mechanism for late breaking updates.
Data
Integrity - The
discussion on exception processing during the working meeting outlined the core
data quality issue and focused on two options: (1) should the ASB mandate completion
of every field on data input (for better QA). Or (2) should the ASB allow for
incomplete data entry (for better ISIN coverage). This is integral to how the
ASB will maintain data integrity.
- Both
FISD and SWIFT members strongly suggested that – as a rule -- all descriptive
elements required for unique instrument identification should be considered mandatory.
Incomplete data is OK as long as the minimum data set for identification is captured.
If the minimum data set is incomplete, the ASB should not process the record.
- FISD
and SWIFT accepted the responsibility for evaluating the proposed list of data
elements involved in ISIN files as outlined in (post document insert URL) the
February 2001 Business and Technical Specification prepared by the ASB. It’s also
important to note that the list of mandatory data elements will vary by instrument
type.
Licensing
Issues - The
commercial structure for access and usage of data processed by the ASB has not
been fully articulated. Nevertheless, three core issues were discussed:
1.
One of the primary functions of the ASB is as commercial facilitator for the NNAs.
The ASB has proposed a joint license agreement incorporating the various bilateral
requirements of the NNAs. That proposal is under consideration by the NNAs and
was not shared with the User Group. 2.
The point was
clearly made however, that the redistribution and use of ISIN is dependent on
the outcome of that negotiation. As a result, the ASB agreed to share the results
of this discussion with the industry prior to implementation in July. 3.
The operating principle proposed by FISD was for transparency and unencumbered
redistribution of the ISIN. In essence, the commercial terms and conditions of
the ASB for core identification should not impede commerce in any way. FISD is
proposing three levels of commercial terms based on the use of the data:
- Level 1:
The identification component of the ASB feed (the ISIN) should be unrestricted
and the core ISIN should contain all data elements required for unique identification.
- Level
2: ISIN plus the additional data elements currently contained in the GIAM
2 feed. Vendors point out that they will continue to get value added direct feeds
from many of the NNAs and will use the ASB feed primarily for validation of unique
identification.
- Level
3: Full ASB data set including cross-reference data and any other value-added
information added in the future.
- FISD
members also pointed out the existence of special redistribution scenarios that
impede commerce and asked the ASB to create a mechanism to address those situations
as they occur. FISD members agreed to identify real-world examples of practical
problems resulting from existing commercial restrictions for consideration by
the ASB.
Unique
Security Identification - One
of the critical by-products of these discussions has been to open the dialogue
on the requirements for unique security identification and the relationship between
ISIN, MIC and register level identifiers.
- It
is important to reiterate that the core rationale behind the creation of the ASB
is to help the industry meet the automation requirements of T+1 and STP. As the
common link for automated trading/execution systems, primary identifiers 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.
- Core
security identification ultimately means all data elements required to set up
and maintain security master files. ISIN is a unique identifier per the ISO-6166
standards and the ISIN guidelines for fungibility. However, the current discussion
suggests that because ISIN is a unique issue identifier (not always a unique security
identifier), a compromise might be required.
- The
first step is to identify the minimum requirement for unique identification (i.e.
ISIN, MIC, and register level identification) and the appropriate level of granularity.
The discussion needs to bear in mind the differences between attributes of a security
versus attributes of a transaction. The final component is (of course) to balance
the requirements for unique identification against practical implementation reality.
- Click
here to view the working paper developed by ANNA-WG2 under the covenorship of
Euroclear on MIC (http://www.fisd.net/security/030801.html)
- FISD
volunteered to facilitate a meeting designed to give this issue a broad and complete
airing. We want to understand and document the problem before the industry implements
an incomplete solution. All sides of the security master business (i.e. reconciliation,
compliance, pricing, custodial, clearing, settlement, valuation, risk management)
must be included in the discussion. Our goal is to coordinate the discussion and
write a paper for consideration at the June User Group meeting.
Action
Items 1.
FISD and SWIFT to define the mandatory data elements (ASB level 1 data) required
for identification by security type. 2.
FISD to organize industry feedback on the minimum requirements for unique identification
and the appropriate level of granularity. The investigation must be based on real-world
examples (from point-of issue to point-of-settlement) of the problem. The deadline
for the initial paper is the June ANNA User Group meeting. 3.
Post the ASB
business and technical specifications document and the Euroclear paper on MIC
on FISD.net for industry consideration.
SWIFT
to extend the scope of MIC to include ECN, ATS and new exchanges. The MIC codes
need to be updated and published on the web.
|
|
|
