ISIN symbol in new order single

[fplpo_x]

Imported from previous forum

[fplpo_x]

[ original email was from Shakir Kagzi - shakir.kagzi@ftindia.com ]
Hi,

I have a query for ISIN symbol in new order single.

If ID source is ISIN, what should be the value in Tag48 (security ID)and Tag55 (Symbol)? The ISIN value of the corresponding symbol should be present in security ID or symbol?

Example: Security symbol is XYZ for which ISIN number is IN12345678. What will be the corresponding value in tag 48 and 55?

Thanks in advance.

[fplpo_x]

[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Shakir,

most receivers wuld happily accept a single one of the identifiers (only Symbol or SecurityID + SecurityIDSource), but if you want to send both:

Symbol (55)="XYZ"
SecurityID (48)="IN12345678"
SecurityIDSource (22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
There’s an older thread on a similar topic http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not really identifying where you want the instrument traded. An ISIN identifies an instrument but not a place of trade and a symbol is not unique. Depends on the instruments you are trading but if you are trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the identifiers (only
Symbol or SecurityID + SecurityIDSource), but if you want to send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[peterpapazoglou_x]

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not really
identifying where you want the instrument traded. An ISIN identifies an
instrument but not a place of trade and a symbol is not unique. Depends
on the instruments you are trading but if you are trading globally then
you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the identifiers
(only Symbol or SecurityID + SecurityIDSource), but if you want to
send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
True.

While the SecurityExchange (207) field is used to qualify the Symbol (or other security identifier) in cases where those are not sufficently unique (the SecurityExchange field then representing the primary place of listing or the “issuer” of the Symbol), the ExDestination (100) field is used to designate the marketplace you want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol is not
unique. Depends on the instruments you are trading but if you are
trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the identifiers
(only Symbol or SecurityID + SecurityIDSource), but if you want to
send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from Shakir Kagzi - shakir.kagzi@ftindia.com ]
Ours is a sell side application which interacts with multiple exchanges. The other problem is the buy side sends only ISIN without 207/100. This becomes difficult for us to identify the exchange. What could be the solution?
Thanks everyone.
Shakir

True.

While the SecurityExchange (207) field is used to qualify the Symbol (or
other security identifier) in cases where those are not sufficently
unique (the SecurityExchange field then representing the primary place
of listing or the “issuer” of the Symbol), the ExDestination (100) field
is used to designate the marketplace you want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol is
not unique. Depends on the instruments you are trading but if you
are trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the identifiers
(only Symbol or SecurityID + SecurityIDSource), but if you want to
send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
ISINs should be globally unique, so the security identifier should not be a problem. If you send an order to an exchange (through a FIX session between you and the exchange) you normally do not have to provide the 100 or 207 fields. But of course, this means you must know what security is traded at what exchange when you receive an order from the buy-side. Exchanges have various ways of providing that information, including using the FIX Security Defintion or Security List messages. If the buy-side do not provide the ExDestination (100), they would not care where you execute the order.

The ExDestination (100) field is only needed when you receive orders that can be routed to multiple exchanges (when the same ISIN or Symbol is traded in multiple exchanges, ECNs or other venues). It could then be provided on inbound messages (if the buy-side wants to execute at a particular exchange), but does not necesarily make sence on onbound (unless the receiver can route too).

The SecurityExchange (207) field is only needed if you trade different security that share the same ID (e.g. Symbol). A symbol of “IBM” would mean that “big blue” computer shop in the US, but could be something totally different in India (e.g. “India Bicycles & Motors”). In those cases you would have to qualify the ID (Symbol) with the issuer of the symbol (often the exchange that primarily lists the instrument).

Regards

Rikard

Ours is a sell side application which interacts with multiple exchanges.
The other problem is the buy side sends only ISIN without 207/100. This
becomes difficult for us to identify the exchange. What could be the
solution? Thanks everyone. Shakir

True.

While the SecurityExchange (207) field is used to qualify the Symbol
(or other security identifier) in cases where those are not
sufficently unique (the SecurityExchange field then representing the
primary place of listing or the “issuer” of the Symbol), the
ExDestination (100) field is used to designate the marketplace you
want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol is
not unique. Depends on the instruments you are trading but if you
are trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the
identifiers (only Symbol or SecurityID + SecurityIDSource), but
if you want to send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[peterpapazoglou_x]

Without 100, you need to assume an exchange … the primary exchange for example

Ours is a sell side application which interacts with multiple exchanges.
The other problem is the buy side sends only ISIN without 207/100. This
becomes difficult for us to identify the exchange. What could be the
solution? Thanks everyone. Shakir

True.

While the SecurityExchange (207) field is used to qualify the Symbol
(or other security identifier) in cases where those are not
sufficently unique (the SecurityExchange field then representing the
primary place of listing or the “issuer” of the Symbol), the
ExDestination (100) field is used to designate the marketplace you
want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol is
not unique. Depends on the instruments you are trading but if you
are trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the
identifiers (only Symbol or SecurityID + SecurityIDSource), but
if you want to send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Hi Shakir,

There are a few options:

1. You ask the buy-side how they want to solve this problem.
2. You make an assumption - always trade on market X for instrument Y for buy-side Z.

The ISIN can refer to any number of market instruments so an ISIN is just not enough to guarantee that you pick the right market.

have a look at this web page from iShares Exchange-Traded Funds (ETFs) | iShares UK – BlackRock

You can see that the same ISIN is traded on the LSE in GBP, VirtX in GBP, Euronext Amsterdam in EUR and Milan in EUR.

Unless you can determine a watertight rule to default this you are going to end up in a mess if they buy side “means” one thing and your system assumes another.

Years back while working for a sell-side we had the mother and father of all lookup tables to convert ISIN to RIC based on ISIN, client ID, traderID and (I think) side. Not nice, but that was years ago - I would not recommend that approach.

Ours is a sell side application which interacts with multiple exchanges.
The other problem is the buy side sends only ISIN without 207/100. This
becomes difficult for us to identify the exchange. What could be the
solution? Thanks everyone. Shakir

True.

While the SecurityExchange (207) field is used to qualify the Symbol
(or other security identifier) in cases where those are not
sufficently unique (the SecurityExchange field then representing the
primary place of listing or the “issuer” of the Symbol), the
ExDestination (100) field is used to designate the marketplace you
want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol is
not unique. Depends on the instruments you are trading but if you
are trading globally then you need to think more about this issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the
identifiers (only Symbol or SecurityID + SecurityIDSource), but
if you want to send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678” SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard

[fplpo_x]

[ original email was from Shakir Kagzi - shakir.kagzi@ftindia.com ]
Hi,

I get your point. The problem is the ISIN is same for a security listed on 2 different exchanges. The buy side is not ready to sent 207/100 in new single order request. If order is in RIC we have taken the extension as the exchange but for ISIN there is a problem.

Thank you all.
Shakir

Hi Shakir,

There are a few options:

1. You ask the buy-side how they want to solve this problem.
2. You make an assumption - always trade on market X for instrument Y
   for buy-side Z.

The ISIN can refer to any number of market instruments so an ISIN is
just not enough to guarantee that you pick the right market.

have a look at this web page from iShares Exchange-Traded Funds (ETFs) | iShares UK – BlackRock
/fund_pricing_and_exchange.do?fundId=157498

You can see that the same ISIN is traded on the LSE in GBP, VirtX in
GBP, Euronext Amsterdam in EUR and Milan in EUR.

Unless you can determine a watertight rule to default this you are going
to end up in a mess if they buy side “means” one thing and your system
assumes another.

Years back while working for a sell-side we had the mother and father of
all lookup tables to convert ISIN to RIC based on ISIN, client ID,
traderID and (I think) side. Not nice, but that was years ago - I would
not recommend that approach.

Ours is a sell side application which interacts with multiple
exchanges. The other problem is the buy side sends only ISIN without
207/100. This becomes difficult for us to identify the exchange. What
could be the solution? Thanks everyone. Shakir

True.

While the SecurityExchange (207) field is used to qualify the Symbol
(or other security identifier) in cases where those are not
sufficently unique (the SecurityExchange field then representing the
primary place of listing or the “issuer” of the Symbol), the
ExDestination (100) field is used to designate the marketplace you
want the order executed at.

Regards

Rikard

Exchange Code - tag 100 may also be needed by some recipients

There’s an older thread on a similar topic

http://www.fixprotocol.org/discuss/read/89dd1193

In the example below by sending a symbol and an ISIN you are not
really identifying where you want the instrument traded. An ISIN
identifies an instrument but not a place of trade and a symbol
is not unique. Depends on the instruments you are trading but if
you are trading globally then you need to think more about this
issue.

Cheers,

John

Shakir,

most receivers wuld happily accept a single one of the
identifiers (only Symbol or SecurityID + SecurityIDSource),
but if you want to send both:

Symbol (55)=“XYZ” SecurityID (48)=“IN12345678”
SecurityIDSource
(22)=“4” (ISIN)

Regards

Rikard