Imported from previous forum
[ original email was from Mikael Brännström - m.brannstrom@ngm.se ]
Hi,
When a security is traded in multiple “books”, how should a book be identified in FIX (e.g. in New Order Single)?
We are choosing between two solutions:
(1) The book has a unique identifier.
(2) The book is identified with multiple fields. SecurityID (ISIN), Currency and MarketSegmentID.
Regarding (1), how should the book id be specified in FIX?
Regarding (2), ISIN+Currency seem to be a somewhat common requirement. We also need to qualify with market segment/sub market. The prev thread http://fixprotocol.org/discuss/read/d4e0d90e has already given some answers on ISIN+Currency.
What is the recommended best practice in FIX?
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Mikael,
there may be regional conventions and specific implementations out there, but there is no global standard that I know of. Some marketplaces use a synthetic identifier-number, others the SEDOL (or similar) and yet other require a separate FIX-connection to each “market segment”.
I would also be a bit sceptic on using the Currency field as it is not part of the component which is really intented to contain the Security identificatiton. As I’ve said earlier, I would support extending the component with a Currency field to support that dimension of the problem.
On “market segments” I do support an analysis of whether it should be included in the block too, but I’m not sure we really understand all dimensions there. We must also cater for the fact that not all markets will use the proposed concept of “market segment”, but may still have the “multiple book” problem. So I would not bet on it being a future extension to FIX.
So today, if your problem is “Currency” only, I would agree using it to identify the “book” is a good solution. If your problem is “market segmentation” in general, you could consider complementing the ExDestination (100) with a PartyID of the PartyRole (452) = “73” - Execution venue.
Regards
Rikard
Hi,
When a security is traded in multiple “books”, how should a book be
identified in FIX (e.g. in New Order Single)?We are choosing between two solutions:
(1) The book has a unique identifier.
(2) The book is identified with multiple fields. SecurityID (ISIN),
Currency and MarketSegmentID.Regarding (1), how should the book id be specified in FIX?
Regarding (2), ISIN+Currency seem to be a somewhat common requirement.
We also need to qualify with market segment/sub market. The prev thread
http://fixprotocol.org/discuss/read/d4e0d90e has already given some
answers on ISIN+Currency.What is the recommended best practice in FIX?
[ original email was from Mikael Brännström - m.brannstrom@ngm.se ]
> Some marketplaces
use a synthetic identifier-number, others the SEDOL (or similar) …
Is the SecurityID field used for that? The consequence of that would be duplicate SecurityDefinition etc to be sent for the same security.
On “market segments” I do support an analysis of whether it should be
included in the block too, but I’m not sure we really
understand all dimensions there. We must also cater for the fact that
not all markets will use the proposed concept of “market segment”, but
may still have the “multiple book” problem. So I would not bet on it
being a future extension to FIX.
This is one of the reasons why we considered the unique book id approach (1). Also, as Niall mentioned in http://fixprotocol.org/discuss/read/1eece756, LSE uses a 4 part key. Adding more and more fields can cause the book identification to become quite messy. One issue is that the order book id doesn’t seem to fit anywhere in FIX.
So today, if your problem is “Currency” only, I would agree using it to
identify the “book” is a good solution. If your problem is “market
segmentation” in general, you could consider complementing the
ExDestination (100) with a PartyID of the PartyRole (452) = “73” -
Execution venue.
Ok, thanks.
Regards
Mikael
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Mikael,
let’s get a bit more specific. As you are probably aware OMX has been issuing unique synthetic “order book identifiers” since the late 90’s (i.e. one id-number identifying the Security + Currency + Market segment). In FIX those will be represented by:
- SecurityID (48) = synthetic key
- SecurityIDSource (22) = Tbd - Marketplace assigned identifier
(The new enum value is part of the GEMC/EEWG Phase I proposal)
The above identifier is the only one needed for orders, etc. When reference data is distributed to market participants, we also provide alternative identifiers as:
- Symbol (55)
- SecurityAltID (455) = nnnnn
- SecurityAltIDSource (456) = 4 - ISIN number
This means that a single ISIN can be represented by multiple Security Definition messages, one for each “order book”. The ISIN (in our case) generally represents the fungible instrument, so you can offset it in any of the “order books”.
I am not claiming that the above represents a perfect solution.
Regards
Rikard
Some marketplaces use a synthetic identifier-number, others the SEDOL
(or similar) …Is the SecurityID field used for that? The consequence of that would be
duplicate SecurityDefinition etc to be sent for the same security.On “market segments” I do support an analysis of whether it should be
included in the block too, but I’m not sure we really
understand all dimensions there. We must also cater for the fact that
not all markets will use the proposed concept of “market segment”, but
may still have the “multiple book” problem. So I would not bet on it
being a future extension to FIX.This is one of the reasons why we considered the unique book id approach
(1). Also, as Niall mentioned in
http://fixprotocol.org/discuss/read/1eece756, LSE uses a 4 part key.
Adding more and more fields can cause the book identification to become
quite messy. One issue is that the order book id doesn’t seem to fit
anywhere in FIX.So today, if your problem is “Currency” only, I would agree using it
to identify the “book” is a good solution. If your problem is “market
segmentation” in general, you could consider complementing the
ExDestination (100) with a PartyID of the PartyRole (452) = “73” -
Execution venue.Ok, thanks.
Regards Mikael
[ original email was from Niall McCallion - nmccallion@espeed.co.uk ]
This is informational rather than answering your question. You reminded me that others may find this useful to know.
The LSE have advised us that they have a four part key: “…our 4 way key (ISIN,CR,CC,SEGMENT) as the Country of register is different for each security…”
Practically this means we cannot guarantee an ISIN and an ExDestination or symbol suffix to uniquely identify every instrument. We also need segment and currency to be guaranteed as there are a number of instruments with the same ISIN and segment on the LSE.
Hi,
When a security is traded in multiple “books”, how should a book be
identified in FIX (e.g. in New Order Single)?We are choosing between two solutions:
(1) The book has a unique identifier.
(2) The book is identified with multiple fields. SecurityID (ISIN),
Currency and MarketSegmentID.Regarding (1), how should the book id be specified in FIX?
Regarding (2), ISIN+Currency seem to be a somewhat common requirement.
We also need to qualify with market segment/sub market. The prev thread
http://fixprotocol.org/discuss/read/d4e0d90e has already given some
answers on ISIN+Currency.What is the recommended best practice in FIX?