This document outlines the current story on FISD’s involvement in reference data issues. The relationships between activities are illustrated in the diagram (map). The numbers on the diagram correspond to the numbers in the document and provide the detail associated with each activity.

1.  Commercial and Assignment Issues: FISD’s role in reference data started with issues related to the commercial structure of national numbers (ISIN, CUSIP, SEDOL, etc.) and with the problems associated with assignment and maintenance of numbers. That activity led to the development of a statement of principles. Commercial discussions are ongoing.

• All instruments that are traded should have a number.
• The number should be accurate, timely, well maintained and precise.
• Access to national numbers should be available on reasonable terms and conditions with everyone treated equally (level playing field).
• FISD specification to ANNA

2. Relationship with ANNA: Our activities led to the creation of a formal and ongoing relationship with the Association of National Numbering Agencies (ANNA).

• Creation of the ANNA Service Bureau to manage collection, maintenance, dissemination, customer service, contractual administration.
• Creation of the ISIN User Group to address issues associated with securities numbering.
• Creation of a modular ASB data redistribution contract. The ASB modular contract is in the final stages of being approved by the members of ANNA. We expect to receive a copy of the final contract shortly (pending).
• Discussion about data elements required by the industry and ANNA’s role in data collection/dissemination.
• FISD Presentation to ANNA on requirements
• ASB Contract Proposal
• ASB Contract Status

3. Security Identification: The churn on STP and automation opened up a wide range of discussions on the requirements for unique security identification and the conclusion that ISIN alone was not sufficient for unique and precise security identification.

• FISD research project on the requirements for unique security identification.
• ISIN + Official Places of Listing (OPOL) + Register Level Identifier = Unique identification.
• Other elements are attributes of a transaction (place of trade, CSD linkages).
• FISD Paper on Unique Security Identification

4. Security Identification Evangelism: Our research and conclusions were much debated and ultimately validated by the global market data industry.

• Long series of discussions with ANNA and the ASB on the requirements for unique security identification, the role of ISO codes and the potential for collection/dissemination of the required data including its link to ISIN.
• Series of meetings with DTCC, ISITC/IOA, SIA, BMA, Buy-Side User Groups, The Technology Council, ISO TC68/SC4, SWIFT (as maintenance authority for ISO 15022, MIC and BIC) and others on the results of our research and the status of our discussions with ANNA.
• Security Identification Home Page

5. More Identification Issues: FISD is invited into discussions about the requirements for identifiers for business entities, legal relationship, fund and counterparty identifiers, descriptive data, and financial instrument attributes.

• IBEI paper on the requirements for business entity identification and other standard identifiers.
• Discussions with X9D and ISO TC68/SC4. The SC4 working group has been formed and is now in the initial stages of defining the IBEI program.
• Discussions with the UK Reference Data User Group on global client and counterparty data hierarchies (ongoing).
• FISD Paper on Business Entity Identification

6. Reference Data: Reference data emerges as one of the hot core topics within market data. Studies and conferences abound. The relationship between reference data and automated trade processing becomes clear. As many have long suspected, reference data is ubiquitous, often manually captured, not well synchronized and not standardized.

• Reference data describes the underlying accounts and parties involved in a transaction – who’s buying, who’s selling, the broker/dealer, the custodian/clearing agent responsible for settling the trade, the instrument being traded, corporate action information affecting the instrument, etc.
   
  • Instrument identifiers (ISIN, CUSIP, SEDOL, Valoren, etc.)
  • Fixed income attributes (coupon rates, payment dates, floating rate terms, call/put features, etc.)
  • Fundamental data on equities (earnings ratios, market cap, dividend rates, etc.)
  • Descriptive data (security description, sector codes)
  • Index data (constituent information)
  • Historical data (historical prices and fundamentals)
  • Rates and Codes (tax rates, currency codes, depository/exchange codes)
     
• STP and shorter settlement cycles are the motivation behind the focus on reference data. Shorter cycles mean that more automation is needed. And automation needs accurate data that is compatible across multiple functions throughout the enterprise. If the data was consistent, firms could standardize processes and there would be less manual intervention. And fewer manual operations mean less risk and less expense.
   
• One of the keys to improving reference data is standards. These standards are required to realize the efficiency objectives of automation and are the subject of coordinated industry action.
   
  • Standards for Identification – including numbering schemes, instrument symbology, sector codes and business entity relationships required for unique and precise identification.
  • Standards for Content – to ensure that there is a common understanding or all reference data terms, definitions and relationships.
  • Standards for communication – focusing on trade messages and web services standards for messaging.
     
• FISD Reference Data Home Page

7. Market Data Definition Language (MDDL): Being positioned as the XML standard for security set-up as well as pricing. A significant number of firms are working on the adoption of MDDL as the basis for their security master file applications.

• The objective of MDDL is to define all market data elements – including reference data and corporate actions – for all domains in the financial industry.
• Firms are using MDDL to integrate multiple data sources and feed multiple applications without the need for data translation and data normalization.
• The creation of a shared vocabulary (all terms, definitions and relationships) is a core output of MDDL.
• There is active interest in using MDDL for
   
  • End-of-day pricing – the original application envisioned for MDDL has resurfaced as a primary applications driver.
  • Security set-up applications – the primary initial application for MDDL including its use by LSE, BMA, 15022 and a number of vendors, end-users and infrastructure companies (FISD is not authorized to publicize the names as yet).
  • Corporate actions – part of the 15022 project and high on the list of requirements from REDAC.
  • Intra-day pricing – MDDL can fill the requirements for intraday pricing but must address bandwidth issues.
     
• MDDL Home Page

8. LSE SEDOL Initiative. Motivation for the LSE proposal is they were running out of SEDOL codes and need to move to alphanumeric identifiers.

• Opportunity to address the requirements for unique security identification as part of the initiative
   
  • SEDOL for all listed instruments (globally) and on demand for instruments that are not officially listed
  • SEDOL allocation at the place of listing level
  • Links between ISIN and SEDOL
  • Corporate action maintenance
  • MIC for place of trade
     
• Commercial discussions with vendors and end-users
• LSE adopts MDDL for its SEDOL initiative
• London Stock Exchange home page on SEDOL
• REDAC Report on Security Identification

9. Unique Security Identification based on SEDOL. Once the LSE rolls out its proposal, here’s how we would view the security identification hierarchy.

• Unique issue identifier = ISIN: Important for security roll-up, risk management, overall position keeping and trading decisions.
   
• Unique instrument identifier = Official Places of Listing (OPOL) = SEDOL: Important for portfolio valuation, fungibility issues for multi-listed instruments, corporate action issues across OPOLs, risk across OPOLs/currencies, position keeping, settlement, VMU interaction (cross-bridge settlement, SSI) and arbitrage across currencies/markets/OPOLs.
   
• Intra-day trading identification = Place of Trade = SEDOL + MIC = vendor codes = exchange ticker codes: Important for intra-day pricing decisions, arbitrage and market compliance.

10. Bond Market Association SMF Portal Project: BMA is proposing the creation of a “portal” to collect and disseminate new issue information on bonds.

• BMA adopts MDDL as their XML schema/vocabulary.
   
• BMA awards the portal project to Niteo Partners.
   
• The BMA Board recently announced it was abandoning the Portal Project and is now supporting the development and implementation of standards as the solution to the challenges associated with security set-up (MDDL for data definition and a new Web Services standard for messaging interface).
   
• BMA Statement on SMF Portal

11. 15022 Data Field Dictionary: The global financial industry (supported by the new G30 report on financial services) is recommending ISO 15022 as the repository for all data elements throughout the information/transaction lifecycle.

• TC68/SC4 is creating a new working group – Working Group 11 (WG11) -- to create an overall data model for the securities industry. The data model will be the basis for building new messages in ISO 15022 and will support master file structures and database design.
   
• FISD is in the process of becoming a direct liaison to SC4 and is being asked to participate in WG 11. The TDR for financial instrument attributes and corporate actions will be based on MDDL.
   
• ISO 15022 Home Page

12. Reference Data Coalition (REDAC): The purpose of REDAC is to ensure that the data requirements for STP automation are well defined and clearly articulated to all involved parties, facilitate coordination among the various reference data initiatives, and promote the development and implementation of practical standards in alignment with industry objectives.

• Resolve the information needed for instrument, client/counterparty, trade specific and accounting information – throughout the security lifecycle – as well as how it will be collected, disseminated and implemented.
   
• Evaluate and promote coordination among the standards activities related to reference data.
   
• Ensure the operational challenges associated with implementation of solutions are well defined and viable.
   
• Ensure the commercial models are not an impediment to global electronic commerce.
   
• Coordinate reference data activities and ensure broad participation by all segments, functions, groups (including RDUG) and entities involved in the transactions lifecycle.
   
• REDAC Steering Committee consists of 4 investment managers, 4 custodians and 4 broker dealers. REDAC is designed to be inclusive and has established an Advisory Committee structure to allow for active participation by all interested parties.
   
• The members of the UK Reference Data User Group (RDUG) and the Reference Data Coalition (REDAC) agreed that RDUG and REDAC should converge. The goal is to have a single group for addressing and coordinating reference data issues on global basis. We are currently working on how to structure the convergence.
   
• REDAC Terms of Reference
   
• REDAC Steering Committee Report