FISD HOME Financial Information Services Division of Software & Information Industry Association - Your Market Data Business Connectionvisit the SIIA website

Google


web www.fisd.net

MARKET DATA
BUSINESS MANAGEMENT
CONTRACTS
OTHER
ADMINISTRATIVE
MARKET DATA CONTENT
REFERENCE DATA
MARKET DATA
DEFINITION LANGUAGE
FISD WIKI
INDUSTRY ISSUES
MARKET DATA REGULATION
MiFID JOINT
WORKING GROUP
FISD ON LINKEDIN
2008 CODiE Awards Call for Nominations


Market Data Training


Inside Market Data


Inside Reference Data


Symbology/Security Indentification

Uniqueness of Security Versus Settlement Instruction

Andrew Douglas, SWIFT

April 12, 2001


The Problem

In the "good old days", trading and settling a security was a relatively simple process. As a general rule, securities identification was unambiguous as a security was issued and traded on a single exchange and settled via a single proprietary settlement system. Because of this simple 1:1:1 relationship, the security identification code could be used to accurately deduce the place of trade and the place of settlement IF this information was not supplied by the trader. Thus the risk of delivery of a security from the wrong trading location or to the wrong settlement system was remote. Trade capture systems have consequently been developed to expect the security identifier to provide this information, not the trader.

However, in recent years, trading and settling a security has become increasingly complex as market practices have developed and additional settlement attributes have become more important:

  1. New regulated exchanges, ECN’s and ATS’s operate in markets where previously there was a single exchange. As a result, a single security may be registered and traded on more than one exchange/ECN/ATS in the same geography.

  2. Exchanges have begun to develop multiple trading linkages allowing their members trading access to securities held on other exchanges. Thus securities registered on one exchange may be traded on a linked exchange.

  3. Similarly, inter-depository links allow settlement to occur in settlement systems other than that traditionally associated with a particular exchange. Indeed, to a large extent, settlement systems and trading exchanges are no longer directly linked and settlement is becoming a preference of the trading counterparties rather than a condition of trading location.

  4. Registers of securities are not exchange or country dependent and the same security can be registered in 1 or many locations and traded in each.

Consequently, the relationship between a security, an exchange and a settlement system has become 1:X, where X represents the possible number of permutations of register, exchange and settlement system for a security. And undoubtedly, there will be as yet unrecognised market developments that will increase this degree of complexity in the future, after all who would have predicted the development of ECN’s and ATS’s 20 years ago?

As a result, the simple facts of life are that:

  • ISIN no longer provides an unambiguous pointer to trade and settlement location
  • Traders do not provide trading and settlement location because they have never had to

Consequently, historically rare trade failures related to incorrect sourcing and delivery of securities are becoming problematic as institutions cannot determine trading location, register or settlement location from the ISIN.

It should be noted, however, that ISIN in it’s current form still satisfies its primary purpose, to identify a security at the issue level and therefore can be successfully used to aggregate global positions held in a certain security.

The Solution Options

We can either:
 
1. Create a security identifier that is unique to any combination of security, register, trading location and settlement system allowing institutions to derive all relevant data from a single key.
 
This will require the following:
 
a.
  • Leave internal trading processes as currently operating
  • Redefine ISIN as the primary security identifier to take into account all permutations of register, trade and settlement location
  • Allocate ISIN’s to every possible permutation
  • Delete Place of Settlement from settlement instructions
  • Delete MIC from settlement instructions

Or alternatively,

b.

  • Leave internal trading processes as currently operating
  • Leave ISIN as is
  • Define an new primary identifier to take into account all permutations of register, trade and settlement location
  • Allocate new identifier to all securities in all possible
  • Modify systems to key off new identifier
  • Delete Place of Settlement from settlement instruction
  • Delete MIC from settlement instructions

1. Advantages

  • Financial Institutions will be able to infer trading and settlement location from a single data field. This will probably require no immediate system development work on their part other than the increase in size of their security masterfile or to switch primary key field.

2. Disadvantages

  • If we look at a relatively simple case, 1 security held on 2 registers. 1 of the registers is associated with 2 exchanges and these 2 exchanges have separate settlement systems. In this case, there is a requirement to have a security ID that uniquely identifies the following combinations:

Register A, Exchange 1, Settlement system 1

Register A, Exchange 2, Settlement system 2

Register B, Exchange 3, Settlement system 3

  • If we assume that Exchange 1 and 3 have trading links, the following additional combinations are now possible:

Register B, Exchange 3, Settlement system 1

Register A, Exchange 1, Settlement system 3

Register B, Exchange 1, Settlement system 3

Register A, Exchange 3, settlement system 1

Where traditionally, a single security identifier has sufficed, we now need 7 if the identifier is to preserve the unique attributes of trading and settlement. And as market practices develop and Exchanges/Settlement systems develop additional linkages, the number of unique combinations will increase. Ultimately this will create issues in the following areas:

  • NNA’s will be required to create additional ISIN’s and associated records for each unique combination of trading and settling location. In markets where there are multiple exchanges, exchange links, settlement links and registers, the workload would increase exponentially resulting in higher costs for ISIN allocation and storage and higher costs to the user.
     
  • Service Bureau storage capacity may need to be increased and additional effort associated with maintaining additional ISIN records will increase costs.
     
  • Additional ISIN records will increase the size of Institutional masterfiles requiring additional system capacity, development work etc.
     
  • Ultimately, markets with many securities, registers, Exchange and Settlement linkages will use up their ISIN numbers at a faster rate requiring a redefinition of the ISIN standard on a global basis.
     
  • Additional levels of future complexity will require constant redefinition of the ISIN standard to accommodate the new changes and this will lead to even higher rates of number exhaustion.
     
  • ISIN will no longer provide the ability to aggregate positions and holdings of fungible securities held across markets.
2. Explicitly state in each settlement instruction, the register, trading location and settlement location.
 
a)
  • Leave ISIN as currently specified
  • Leave Place of Settlement as currently specified (BIC of the settlement system) and ensure all settlement systems are allocated a BIC. Place of settlement is already identified by the various global market practice groups as a mandatory data field but currently, it is not a mandatory field in settlement instructions
  • Redefine MIC as the trading location identifier and allocate MIC’s to all regulated Exchanges, ECN’s and ATS’s.
  • Make MIC a mandatory data field in all settlement instructions
  • Create and allocate a register identifier as appropriate
  • Make register identifier a mandatory field in all settlement instructions where appropriate
  • Enforce a trading process whereby all trade tickets must specify ISIN, register if appropriate, trading exchange and settlement system (this is an internal issue for FI’s)

1. Advantages

  • System flexibility will be retained as additional levels of complexity can be accomodated through the addition of extra data fields into the instruction
  • System pressures will be reduced as only additional fields will need to be added to settlement instructions, there will be no additional security records.
2. Disadvantages
  • Traders will need to specify the register (if appropriate), trading location and settlement location in all trading tickets.
  • Systems may need modification to ensure full transcription of data from trading ticket to settlement instruction