Symbology and Security Identification Status Report

November 7, 2002

This report provides a synopsis of FISD activities related to symbology, reference data and securities numbering including results of the FISD working meetings in Amsterdam (September) and individual discussions with depositories, buy-side investment managers, numbering agencies, custodians and vendors.

EXECUTIVE SUMMARY

Reference Data: There has been a significant amount of recent discussion on reference data quality issues. We see this as a signal that the industry is becoming fully aware that STP automation is more than just about transaction system connectivity. Reference data fuels STP and is a component of every process (front, middle and back) within user firms. Standards and reference data consistency are needed to facilitate automation and achieve high trade matching rates. The light is beginning to shine on FISD security identification and data interchange activities.

ANNA Service Bureau: The members of the Association of National Numbering Agencies (ANNA) are focusing their efforts on quality, timeliness and maintenance of the ISIN and CFI standards. And the industry has validated the importance of ISIN as well as its value as a primary key issue level identifier. Progress is being made on the adoption of a modular contract for the ASB datafeed.

In addition, the principals of the ANNA Service Bureau (S&P and Telekurs Financial) fully understand the importance of a market level identifier and have reinforced their interest in adding missing data elements to the ISIN data feed. The ASB has not (as yet) released commercial or technical details of how this would work moving forward.

London Stock Exchange/SEDOL: The London Stock Exchange (LSE) has received authorization to extend SEDOL to meet industry requirements for a market level identifier. LSE has done extensive customer research with custodians, investment banks, clearing agents, industry groups and vendors and has made some adjustments to both the proposed SEDOL format revisions as well as to the commercial structures associated with SEDOL dissemination.

Vendor Initiatives: A number of market data vendors are independently looking into reference data issues and strategies for improving front/back office symbology. FISD is keeping track of the various vendor initiatives and working to ensure that vendor activities are coordinated with the industry-wide standards discussions.

Industry Coordination: Over the past few weeks FISD has met with DTCC, SIA’s Cross Border Committee, ISITC, two separate buy-side groups, and a number of individual investment banks on reference data and security numbering issues. We have also been keeping track of discussions within SWIFT, BMA, ISSA and SC4. The good news is that there is broad interest in industry initiatives dealing with reference data/security identification. There is still some confusion in the marketplace about all the issues and discussions that are underway.

Some concern has been expressed about both the implementation obstacles and commercial challenges associated with the various proposals. And while we have found broad support for a market level identifier, the user firms want to make sure the operational details are well defined before these proposals are implemented. For example, user firms point out that there are a number of issues associated with multi-listed securities (settlement, security identification, valuation, corporate actions, etc.). And while the issues are different, they all will have systems and commercial implications. The goal is to ensure that the proposals are viable and that systems changes/implementation is as cost-efficient as possible.

REFERENCE DATA

“Nothing good can happen between trade date and settlement – only bad things can happen. That’s why it’s in our best interest to confirm trades as quickly and efficiently as possible.”

I heard this quote at a conference a while ago and thought it to be the perfect summary of the business drivers behind the automation requirements associated with STP. Just to put things in context, what the industry is talking about is eliminating manual processes, reducing errors and delays caused by poor processes and making the entire security transactions chain (from security set up through settlement) more efficient.

This whole discussion is about reducing errors, saving money and managing risk. And reference data problems and data processing challenges play a big part – including things such as re-keying data as it gets passed among the trade processing chain … manually maintaining security master files fed by different data sources and used by different departments and between the front, middle and back offices … and researching security identification mismatches and problems with cross referencing due to multiple numbering schemes.

Costs are Real

Manual processes cost significant money. Money from trade failures (Tower Research suggests that 30% of trade failures are caused by bad reference data) … from trade repairs (SWIFT estimates that 50% of transactions need repair at an average of $6/repair) … from settlement delays (SWIFT estimates that 15% of trades fail to settle on time at an average of $50 for settlement failure) … and from the allocation of resources for security master file maintenance (Tower estimates that 58 FTE are required on average to maintain reference data).

The Definition of Reference Data

Reference data refers to the static information that describes assets and account entries used in the processing of transactions, in compliance measurement, analytics, risk management and client reporting. Reference data describes the underlying accounts and parties involved in a transaction – who’s buying, who’s selling, the broker/dealer, the custodian or clearing agent responsible for settling the trade, the instrument being traded, corporate action information affecting the instrument or its related entities, currency codes, country codes and place of settlement. A recent report indicated that about 40% of a trade record is composed of referential data.

Reference Data Fuels STP

Reference data is a component of every process within user firms – in the front office for sales, research, trading and order management – in the middle office for collateral management and regulatory reporting – and in the back office for trade confirmation, settlement and asset management.

The obvious goal for reference data is to ensure that there is a common understanding of all the data attributes and their respective data structures – particularly within security master files. Master files (which are currently fed by a number of external sources, manipulated into multiple formats according to functional requirements and stored in multiple systems throughout the firm) need to anticipate potential trades. Securities need to be set up well before they trade -- because “just in time processing” doesn’t offer the luxury of correcting missing or inaccurate data. If the data were consistent, there would be less need for manual intervention. Fewer manual operations mean less risk and less expense. And with the movement toward shorter settlement cycles, more automation and compatible data is required to achieve high matching rates.

Precise and Unique Security Identification is Critical

Throughout this discussion there has been a lot of attention on numbering schemes for instrument identification. The focus on security identification is appropriate because numbering systems are an important component of reference data. The core problem is that there are too many numbers (i.e. ISIN, multiple national numbers, proprietary vendor identifiers) but none that uniquely identify all attributes required for precision.

However, the objectives are fairly straight forward. The industry needs identification numbers to be accurate to facilitate the objectives of automation and risk management. As such, all instruments that are traded should have a number and that number should be accurate, timely, well maintained, precise and available/usable on reasonable terms and conditions – and satisfy the full lifecycle of a trade, from decision making to execution, through settlement, reporting, valuation and position keeping.

ANNA Service Bureau

The ANNA Service Bureau (ASB) is a service jointly operated by Standard & Poor’s and Telekurs Financial under license to ANNA. The ASB is operational and has successfully built the comprehensive database of ISIN information. The ASB has dramatically improved the assignment, maintenance, distribution and commercial management of ISIN. Most of the early data quality issues have been resolved. The commercial issues are being sorted out. But the problems of ISIN and it’s relationship to STP (unique and precise identification) still remain.

ISIN and STP Requirements

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 and the ANNA Service Bureau on a host of issues including definition of the additional data elements necessary to uniquely and precisely identify financial instruments throughout their 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 where each offering may have slightly different characteristics that nonetheless have significant impact in many places along the lifespan.

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 addition, there are some data elements that are missing from the ISIN feed but are needed for uniqueness such as restrictions, financial instrument classification, strike/exercise price for warrants, and mandatory separation price. These requirements have been validated by the industry and the focus has shifted toward implementation issues.

INDUSTRY INITIATIVES – THE CURRENT STORY

ANNA Service Bureau

The ASB is in a good position to link market level identifiers to ISIN and is currently considering the addition of market level identifiers to the ASB product line (probably via ISID plus).

London Stock Exchange/SEDOL

LSE has received internal authorization to extend SEDOL to meet industry requirements for a market level identifier. The current SEDOL is composed of a seven character numeric code with a check digit and a geographical identifier. The next iteration of SEDOL will consist of a seven character alphanumeric code which will maintain the check digit but not contain any inherent meaning. The code will identify an instrument but it will be the associated fields which contain the new identification data. Here’s an overview of the new proposed SEDOL system:

Vendor Initiatives

As mentioned, a number of market data vendors are independently looking into reference data issues and strategies for improving front/back office symbology. FISD is keeping track of the various vendor initiatives and working to ensure that vendor activities are coordinated with the industry-wide standards discussions. No formal announcements have been made and it would be inappropriate to comment on preliminary discussions – but stay tuned.

STORM BEFORE THE CALM

The light is finally shining on reference data and security identification issues as an acknowledgment of the data side of the STP equation. Groups from all segments of the industry – international investment managers, global custodians, clearing agents, depositories, vendors and industry groups (including SIA, FISD, ISITC, buy-side user groups, ISSA, SMPG, BMA through their SMF Portal Project, and the new reference data user group) – have been actively engaged in the discussions and are focusing new attention on the importance of reference data.

And while there is broad consensus on the importance of a market level identifier for dealing with multi-listed securities, there is some nervousness associated with all the emerging proposals. The nervousness exists because the industry is not homogenous. Different segments, and even functional areas within the same segment, use identifiers in different ways and there are open questions about the impact of implementation on internal systems and processes – not to mention questions about the commercial structures associated with the emerging proposals.

And while, most of the discussions have been focused on the concepts of uniqueness, there are also issues associated with settlement instructions, routing instructions, securities holding, corporate action treatment, fund and legal entity identification and new regulatory requirements (i.e. Patriot Act, BASLE II, G30 guidelines).

As this discussion shifts from problem definition to solutions proposals, one of our members suggested the importance of first principle and reminds us all that the industry wants fewer numbers, simpler cross-referencing, better symbology linkages and fewer exception processing. It’s time to pay close attention and to make sure the emerging proposals are coordinated in a way that meet the business, information architecture and technical requirements needed to facilitate automation and risk management.

I’d be grateful for your thoughts. Please direct your comments to Michael Atkin (p) 202-789-4450