re: International Security Indentification
Dieter Stein / SunGard
15 Nov 2000 9:51AM ETDS15NOV00
This is indeed FIX compliant and would work, the trouble is that it would be yet another 'flavouring' element of FIX that would need to be agreed bilaterally. But it's a good compromise (except that I would omit the + delimiter and simply concatenate. The ISIN is fixed length, so a delimiter isn't necessary, and might unnecessarily trip up a parser expecting only alphanumeric characters in the SecurityID).
A few more snippets to add to the debate (again these comments refer to equities, the situation for debt securities is a little different and for listed derivatives it is a mess).
The country of register code should follow ISO 3166, which prescribes alpha-2 for this value. The ISO 3166 country naming convention is also followed by ISIN's themselves (governed by ISO 6166), which code the country in which the issuer of the security is registered or domiciled, as the first two characters of the ISIN. BTW the body issuing ISIN's is the Association of National Numbering Agencies (ANNA) on behalf of the International Standards Organization (ISO), or more precisely, ANNA's designated National Numbering Agency (NNA)in the country where the issuer of the security is registered or domiciled. In the UK for example, the NNA is the London Stock Exchange and in the US the NNA is the CUSIP Services Bureau.
The real-world problem with ISO 6166 is its definition of fungibility. Any securities which are fungible are supposed to have one and only one ISIN. There is a definition of fungibility in ISO 6166 which read like this: "Fungible means that a security ranks pari passu in all respects with a different version of the same security and can be exchanged into the other form and visa (sic!) versa at any time." The problem with this definition is that it is silent about where and how a trade in that security could feasibly be settled.
On the settlement side, the case for additionally specifying the country of register (of the security, not the domicile of the company that issues it!) would be to represent the fact that as long as the country of register is the same, the securities traded are probably fungible in a real-world sense of the world as opposed to the bookish ISO definition of the term. However, simply equating 'same register' and 'real-world fungibility' is not quite a good thing to do either, because, say, if I can settle through the same agency (e.g. Euroclear), different countries of register don't really matter.
Indeed, the FIX Settlement Instructions message (MsgType=T), introduced in FIX 4.1, addresses this issue by allowing you to specify the SettlLocation (Tag 166), which could be CEDEL, Euroclear, DTC etc.
The problem I have is on the FIX order related messages (e.g. MsgType=D). What throws me is why the start-of-day securities download provided by the London Stock Exchange and containing securities listed on the LSE gives me a significant number of securities master data records that are identical, except for the country of register. Surely there is only one order book or SEAQ/SEATS quote for the same security under the same ticker symbol, and the LSE ignores the country of register for its trading systems? So when I get an order for a security, which of the multiple records the LSE feed has created in my securities master database should my application associate the order with? I have yet to find somebody at the LSE or elsewhere who has a ready answer. Has anybody else got this problem with the LSE or possibly other exchanges as well?
Dieter
> A layman's suggestion to solve the problem in the meantime (until a CountryOfRegister tag can be defined and included in a future specification):
>
> DaimlerChrysler trades on more than 10 exchanges under the symbol DCX if I remember correctly. Symbol therefore makes no sense as mentioned before in this context. ISIN alone is not exchange specific, see DE0007100000 for DCX. Why not use a combination of ISIN and CountryOfRegister (is this always a 2-character identifier such as GB, DE, FR, etc?), and stick this combination into tag 48 (SecurityID)? Then, in tag 22 (IDSource), you take any number over 100 to identify "combination of ISIN+CountryOfRegister" to everyone who wants to use this. All this is "legal", and will not cause any problems on a FIX engine level.
>
> So, for example, you would identify DCX in Germany (which exchange exactly might not be an issue) with
>
> 55=DCX
> 48=DE0007100000+GE
> 22=201 (say that was the choice of IDSource)
> 15=EUR
>
> Does that make sense?
>
> -- Witold Sames
>
> > DS14NOV00
> >
> > I also speak from an equities viewpoint only, and agree with the points Karen Parton from ML makes. This dastardly fragmentation of liquidity between exchanges and/or ATS's. Don't you hate it. Life was much less complicated 5 years ago.
> >
> > We have found that the only way to uniquely identify a stock in a security master database is by ISIN/CUSIP/RIC/SEDOL etc. (which one doesn't really matter, but ISIN is probably the most universal symbology) + Exchange + Currency + Country of Register.
> >
> > The problem here is that the originator of an order may not know or care about the country or register, and may not care about exchange either, and possibly not even about currency. In an extreme case, the institution may wish to instruct the broker to buy/sell a certain stock on a best execution basis, whereever he can, and settle in the institution's desired base currency. It is then up to the broker to find the necessary liquidity amongst the merchandise he holds himself for market making purposes, or on one of the exchanges or ATS's where the stock is traded, or by crossing other customer orders, and execute the requisite FX trades to swap the cost/proceeds of the trade into the desired settlement currency of the institution, and lastly take care of any settlement/delivery as may be necessary.
> >
> > My point here is that ideally, I would like to see on an order the:
> > 1) ExDestination (100) (and/or from 4.1 onwards, SecurityExchange (207)) plus the
> > 2) Security ID/ID Source (48/22) where 22=4, the
> > 3) Currency (15) plus a
> > 4) new field CountryOfReg ( ).
> >
> > But I can't make all of these mandatory in FIX or else I will be asking too much from the institution and my FIX engine will reject perfectly good (in business terms) orders. The institution will complain to me on the phone about getting good orders rejected or simply get another broker to deal with it. In a domestic US environment (where most of the world's FIX connections operate) people will be scratching their heads about why suddenly the need to specify all this unnecessary ballast. Besides, what works as mandatory/non-mandatory for equities may not work the same way for other asset classes supported in FIX.
> >
> > So then, given that all of the above stipulated fields need to be non-mandatory, ergo might not be there at all, the FIX engine will happily pass the order through to my order management application, and just propagate the problem to a higher level - my front end application. The trading system needs to know all of the above to find the correct record in its security master file and process the order accordingly, and if there are any bits missing and it can't find a unique match, it would dump the order out to be processed manually. Which of course defies the purpose of FIX.
> >
> > As an aside, I find the Symbol (55), which of course is the only field associated with security identification that is actually mandatory, the least interesting - without the (non-mandatory)ExDestination (100) or SecurityExchange (207), the symbol is unlikely to be very useful. I can have multiple exchanges using the same symbol for multiple, entirely different securities, or I can have multiple exchanges using the same symbol for the same security. I simply don't know for sure. Yes a human can look at other fields on the order (if they exist!) and will also know the client, and will therefore have little trouble to make an educated guess, but adding artificial intelligence into our FIX engines to go through a similar process is probably not a path we want to go down. Of course, when FIX was born, none of this was an issue, since a stock would always be in USD and traded on either NASDAQ or NYSE, so the symbol alone was good enough.
> >
> > What to do? I think we should be practical and at least make Currency (15) mandatory, plus introduce a new, non-mandatory CountryOfReg. It should then be up to the trading partners to bilaterally agree upon, and/or up to the FIX networks to postulate, which additional (non-mandatory) marker fields are required in their implementation of FIX.
> >
> > Dieter
> >
> > > With the growth of more cross border exchanges, the identification of the security that was traded with the exchange on which it was traded has ceased to make sense. It is/soon will be possible to buy equity A on EASDAQ and sell it on Tradepoint, neither of which are country specific exchanges.
> > >
> > > For EQUITY (I am not qualified to speak about debt) the thing that was traded can be/is uniquely identified using globally accepted standard of a combination of ISIN and Country of Register. This is the lowest level of fungiblity as trading across exchanges incurs no special cost, whereas transferring between registers does. In your example of Guiness, the two securities (I believe) had different countries of register, GB & IE.
> > >
> > > The "currency" is irrelevant to security identification and, in Euroland, does not ease any confusion. The SEDOL is not issued for all securities and is rather UK centric. RICs are issued to identify source of price, so you get many RICs per tradable thing. ISIN however IS an internationally recognised identifier. Used in conjunction with the country of register, it DOES identify a security uniquely.
> > >
> > > Unfortunatly, FIX uses ONE tag (48) to communicate EITHER the ISIN OR a Country Code. In addition to this problem, there is also a lack of precision as to which country code is to be communicated in 48 - could be country of quotation, issuance or register, but only country of register results in a non-fungible security.
> > >
> > > To get around this problem for the immediate future, we will probably be forced to use SEDOL. This is not adequate for the long term as the cross border exchanges expand.
> > >
> > > Comments about how to get round this problem using 4.1/4.2 protocols appreciated. Looks at the moment like we'll either have to multiple instances of the 48/22 tag combo or force a format on the text message - neither of which meets the standards.
> > >
> > > Ideally, I'd like another tag to be added to the various messages (orders & executions esp.) A.S.A.P.
> > >
> > > -----------
> > >
> > > Karen Parten
> > > Karen_Parten@ml.com
> > > (piggy-backed off Mitch's log in as I'm waiting for my password)
> > >
> > > =============================================
> > > > I am curious as to how other firms are (or will be) identifying international (non-US) securities when using the FIX protocol.
> > > >
> > > > Seeing that there is no standard for international ticker symbols, our plan is to primarily rely on a combination of SEDOL and ISO currency code.
> > > >
> > > > The currency code will be used as a backup, in case our, or our trading partner's, SEDOL is slightly mismatched. For example, Guiness PLC trades in London and Ireland. The London version has one SEDOL, and the Ireland version has another SEDOL. One possibility is that our security master file may have incorrectly mapped the Irish SEDOL for the London version of the security. Assuming we want to trade Guiness on the London exchange, we would have sent the incorrect SEDOL to our trading partner. By also sending the currency code (which is set up correctly), our trading partner would be alerted to the mismatch and would alert us.
> > > >
> > > > How are other firms handling international security identification? Are you using SEDOL, ISIN, CINS, etc? Are you using any ticker symbols (e.g. RIC-code?)
> > > >
> > > > --Rich Lerman
> > > >
> > >
> >
>
