re: International Security Indentification
Dieter Stein / SunGard
14 Nov 2000 8:09AM ET
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
> >
>
