 |
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:
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.
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.
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.
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)
- 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
|
|
|