Imported from previous forum
Hi all,
we currently have a discussion how we should cope with the missing Currency field in the OrderCancelRequest. We need to identify the instrument to process the OrderCancelRequest, but Currency is not part of the Instrument component for FIX 4.4 / 5.0.
Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing Currency for the OrderCancelRequest?
Re (2): IMHO, I would prefer to specify the security as part of the Instrument components SecurityAlt repeating group as
SecurityAltIDSource=6 (ISO Currency Code)
SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding the Currency to the OrderCancelRequest as a local extension.
Looking forward to your opinions / experiences.
Cheers, Jörg
[ original email was from Andrew Scott - ascott@latentzero.com ]
Jorg,
Is there some reason why you cannot reference 11 ClOrdID on the original order via 41 OrigClOrdID on the request [and possibly through a chain …]?
It seems to me that resolving the instrument on a cancel request is artificially creating a problem.
Hi all,
we currently have a discussion how we should cope with the missing
Currency field in the OrderCancelRequest. We need to identify the
instrument to process the OrderCancelRequest, but Currency is not part
of the Instrument component for FIX 4.4 / 5.0.Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing Currency
for the OrderCancelRequest?Re (2): IMHO, I would prefer to specify the security as part of the
Instrument components SecurityAlt repeating group asSecurityAltIDSource=6 (ISO Currency Code) SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding
the Currency to the OrderCancelRequest as a local extension.Looking forward to your opinions / experiences.
Cheers, Jörg
Another question is whether the instrument is really traded in multiple currencies on the same market. Otherwise the target market would also be sufficient to obtain uniqueness for the instruction if (Orig)ClOrdID or OrderID is not sufficient(or unavailable).
Regards,
Hanno.
Hi all,
we currently have a discussion how we should cope with the missing
Currency field in the OrderCancelRequest. We need to identify the
instrument to process the OrderCancelRequest, but Currency is not part
of the Instrument component for FIX 4.4 / 5.0.Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing Currency
for the OrderCancelRequest?Re (2): IMHO, I would prefer to specify the security as part of the
Instrument components SecurityAlt repeating group asSecurityAltIDSource=6 (ISO Currency Code) SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding
the Currency to the OrderCancelRequest as a local extension.Looking forward to your opinions / experiences.
Cheers, Jörg
Hi Hanno,
Another question is whether the instrument is really traded in
multiple currencies on the same market. Otherwise the target market
would also be sufficient to obtain uniqueness for the instruction if
(Orig)ClOrdID or OrderID is not sufficient(or unavailable).
OK, the exchange we are talking about is the SWX and we identify the instruments via ISIN + Currency. In our FIX gateway process, we do not want to keep state, but instead forward the request to the exchange.
At the exchange, the security id (derived from ISIN + Currency) and the OrderID are required fields.
There are a few securities which are identified by the same ISIN, but a different currency so we cannot drop the Currency for identification.
Using the also supplied OrderID to obtain the security id of the order would be possible, but requires an additional loop using the exchange API. We want to avoid this.
So I would like to come back to my original questions whether it is allowed to use the SecurityAltID to disambiguate.
Thanks all for your help so far and regards
Jörg
Hi all,
we currently have a discussion how we should cope with the missing
Currency field in the OrderCancelRequest. We need to identify the
instrument to process the OrderCancelRequest, but Currency is not part
of the Instrument component for FIX 4.4 / 5.0.Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing
Currency for the OrderCancelRequest?Re (2): IMHO, I would prefer to specify the security as part of the
Instrument components SecurityAlt repeating group asSecurityAltIDSource=6 (ISO Currency Code) SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding
the Currency to the OrderCancelRequest as a local extension.Looking forward to your opinions / experiences.
Cheers, Jörg
Jörg,
I understand your problem and agree that the avoidance of state must be the overriding principle to ensure proper performance.
I assume that your term “security ID” refers to what we (Global Exchanges & Markets Committee) have called a “marketplace assigned identifier” which we are currently proposing as an additional enum for SecurityIDSource (22). Do you have a chance to populate “security ID” in the gateway or is a synthetic ID only know to the exchange?
If all else fails, your proposal of SecurityAltID seems reasonable although I do not know how the values 6 and 7 (currency and country) made it into SecurityIDSource. I see alternate IDs on the same level and not as additional attributes which is the way you would use it. However, it still appears to be the best way forward.
In your case it sounds as if the exchange does not maintain ClOrdID (not OrderID) as primary key for direct access to the order. We will be moving to this model so that users can stick with their own IDs most of the time and no longer solely depend on the OrderID assigned by the exchange. The identifier ClOrdID and its usage is a fundamental FIX principle and would probably also solve your problem. If I understood it correctly, you are trying to solve security identification for cancellations instead of order identification.
Regards,
Hanno.
Hi Hanno,
Another question is whether the instrument is really traded in
multiple currencies on the same market. Otherwise the target market
would also be sufficient to obtain uniqueness for the instruction if
(Orig)ClOrdID or OrderID is not sufficient(or unavailable).OK, the exchange we are talking about is the SWX and we identify the
instruments via ISIN + Currency. In our FIX gateway process, we do not
want to keep state, but instead forward the request to the exchange. At
the exchange, the security id (derived from ISIN + Currency) and the
OrderID are required fields.There are a few securities which are identified by the same ISIN, but a
different currency so we cannot drop the Currency for identification.Using the also supplied OrderID to obtain the security id of the order
would be possible, but requires an additional loop using the exchange
API. We want to avoid this.So I would like to come back to my original questions whether it is
allowed to use the SecurityAltID to disambiguate.Thanks all for your help so far and regards
Jörg
Hanno,
I understand your problem and agree that the avoidance of state must
be the overriding principle to ensure proper performance.I assume that your term “security ID” refers to what we (Global
Exchanges & Markets Committee) have called a “marketplace assigned
identifier” which we are currently proposing as an additional enum for
SecurityIDSource (22). Do you have a chance to populate “security ID”
in the gateway or is a synthetic ID only know to the exchange?
Actually, it is some sort of internal ID. In FIX 4.2, we went the way to use IDSource=8 and SecurityID=ISIN.Currency (separate by “.”), but we feel this is quite non-standard and would like to be more FIX conform here.
If all else fails, your proposal of SecurityAltID seems reasonable
although I do not know how the values 6 and 7 (currency and country)
made it into SecurityIDSource. I see alternate IDs on the same level
and not as additional attributes which is the way you would use it.
However, it still appears to be the best way forward.
OK, thanks for the feedback.
In your case it sounds as if the exchange does not maintain ClOrdID (not
OrderID) as primary key for direct access to the order. We will be
moving to this model so that users can stick with their own IDs most of
the time and no longer solely depend on the OrderID assigned by the
exchange. The identifier ClOrdID and its usage is a fundamental FIX
principle and would probably also solve your problem.
If I understood it
correctly, you are trying to solve security identification for
cancellations instead of order identification.
Yes, probably I was a bit unclear here.
Cheers, Jörg
Regards, Hanno.
Hi Hanno,
Another question is whether the instrument is really traded in
multiple currencies on the same market. Otherwise the target market
would also be sufficient to obtain uniqueness for the instruction if
(Orig)ClOrdID or OrderID is not sufficient(or unavailable).OK, the exchange we are talking about is the SWX and we identify the
instruments via ISIN + Currency. In our FIX gateway process, we do not
want to keep state, but instead forward the request to the exchange.
At the exchange, the security id (derived from ISIN + Currency) and
the OrderID are required fields.There are a few securities which are identified by the same ISIN, but
a different currency so we cannot drop the Currency for
identification.Using the also supplied OrderID to obtain the security id of the order
would be possible, but requires an additional loop using the exchange
API. We want to avoid this.So I would like to come back to my original questions whether it is
allowed to use the SecurityAltID to disambiguate.Thanks all for your help so far and regards
Jörg
If all else fails, your proposal of SecurityAltID seems reasonable
although I do not know how the values 6 and 7 (currency and country)
made it into SecurityIDSource. I see alternate IDs on the same level and
not as additional attributes which is the way you would use it. However,
it still appears to be the best way forward.
I thought this was odd too. Especially because these cannot uniquely identify an instrument.
As it happens the ISIN code is also not a unique identifier and requires the currency to make it unique.
Could it be that the AltIDSource was added to address this?
Does anybody know the history?
I will propose that we allow the currency to be specified either in the Alt block or with the optional field. That way our connecting clients can decide what mechanism they require.
Ultimately I think that Currency needs to be added to Instrument as an Optional field.
Thanks
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Guys,
I support adding the Currency field (or a variant of it) to the component block as an optional additional qualifier for instrument IDs. The currency is currently part of the Security Definition (and similar messages), but outside the block.
I also think the purpose of the SecurityAltID is to contain alternative identifiers, not to complement the SecurityID, so I do not recommend using that field for the currency.
Do note that some markets use other mechanisms for identifying securities that are traded in various “books”, the reason for multiple “books” is not limited to trading in currencies.
Regards
Rikard
Currency field was not intended to be part of describing a security or instrument but to identify the currency in which the pricing information is denominated in. This is very clear in the data dictionary for this field: “Identifies currency used for price. Absence of this field is interpreted as the default for the security. It is recommended that systems provide the currency value whenever possible.”
This may be a fine line between the currency of the security vs. the currency of the price, but it seems to me that we may need a new field (SecurityCurrency) that is used to do exactly what Jorg and you want while Currency still continues to denominate the price attribute (i.e. the limit price is expressed in USD regardless of the Security’s currency which I suppose can be something else like CND).
Guys,
I support adding the Currency field (or a variant of it) to the
component block as an optional additional qualifier for
instrument IDs. The currency is currently part of the Security
Definition (and similar messages), but outside the block.I also think the purpose of the SecurityAltID is to contain alternative
identifiers, not to complement the SecurityID, so I do not recommend
using that field for the currency.Do note that some markets use other mechanisms for identifying
securities that are traded in various “books”, the reason for multiple
“books” is not limited to trading in currencies.Regards
Rikard
Currency field was not intended to be part of describing a security or
instrument but to identify the currency in which the pricing information
is denominated in. This is very clear in the data dictionary for this
field: “Identifies currency used for price. Absence of this field is
interpreted as the default for the security. It is recommended that
systems provide the currency value whenever possible.”
Problem is that sometimes the ISIN is quoted in two different currencies on the same Exchange (SWX). In this case there is no default value. So yes the recommendation is valid.
This may be a fine line between the currency of the security vs. the
currency of the price, but it seems to me that we may need a new field
(SecurityCurrency) that is used to do exactly what Jorg and you want
while Currency still continues to denominate the price attribute (i.e.
the limit price is expressed in USD regardless of the Security’s
currency which I suppose can be something else like CND).
I was discussing this with George Macdonald today. Essentially we have a Currency for Price and a Currency for Settlement.
You can have the situation especially in the US where clients are only able or want to settle in USD, but a security is quoted in its original currency.
[ original email was from George Brisco - george.brisco@trialius.com ]
I don’t think it makes sense for the currency to be part of the instrument block. It is not really a security identifier.
Take Vodafone for example, you may well want people to be able to talk in either GBP(Pounds) or GBp(Pence) for the same instrument.
Your question regards cancel/replaces, but surely you are also suffering this problem in original orders?
As for cancel/replaces, I would be very wary about using anything other than ClOrdId/OrigClOrdId.
George
Hi George,
I don’t think it makes sense for the currency to be part of the
instrument block. It is not really a security identifier.Take Vodafone for example, you may well want people to be able to talk
in either GBP(Pounds) or GBp(Pence) for the same instrument.Your question regards cancel/replaces, but surely you are also suffering
this problem in original orders?
We always identify securities via ISIN + Currency, but do not have this issue with the other requests since they contain the currency.
As for cancel/replaces, I would be very wary about using anything
other than ClOrdId/OrigClOrdId.
Ideally, yes. But as I said in my answer to Hanno Klein we just provide an interface to an exchange API and do not want to keep state.
Cheers, Jörg
[ original email was from George Brisco - george.brisco@trialius.com ]
> Ideally, yes. But as I said in my answer to Hanno Klein we just provide
an interface to an exchange API and do not want to keep state.
Ah, I understand better now.
I guess in that circumstance, your suggestion of SecurityAltID/SecurtityAltIDSource is fine. You are indeed using them as an aid to identifying the security, and your slightly esoteric use is just a bilateral agreement as described in the specs.
If it were me I would probably do a straw poll of clients to see if they are easily going to be able to populate 455/456 like this, because it seems to me you are populating it with a different “sort” of data from that that they might expect to put in there. You might find that they prefer a custom field or the inclusion of “currency” into the message.
George
Ideally, yes. But as I said in my answer to Hanno Klein we just
provide an interface to an exchange API and do not want to keep state.Ah, I understand better now.
I guess in that circumstance, your suggestion of
SecurityAltID/SecurtityAltIDSource is fine. You are indeed using them > as an aid to identifying the security, and your slightly esoteric use > is just a bilateral agreement as described in the specs.
Right, that’s the point.
If it were me I would probably do a straw poll of clients to see if
they are easily going to be able to populate 455/456 like this,
because it seems to me you are populating it with a different “sort”
of data from that that they might expect to put in there. You might
find that they prefer a custom field or the inclusion of “currency”
into the message.
According to Lisas answer, Currency was meant to describe the Price, not the instrument. But yes, the customers may expect something different.
Cheers, Jörg
Currency is not part of the Instrument component, never was, because it is meant to denote the currency denomination of price data.
We (the GTC) will make a note to consider adding Currency field to the Order Cancel Request message (or any other messages where this might be missing).
My preference would be to add the Currency field. The SecurityAltID repeating group is meant to identify the same security using different identifies (e.g. CUSIP and ISIN for IBM).
Hi all,
we currently have a discussion how we should cope with the missing
Currency field in the OrderCancelRequest. We need to identify the
instrument to process the OrderCancelRequest, but Currency is not part
of the Instrument component for FIX 4.4 / 5.0.Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing Currency
for the OrderCancelRequest?Re (2): IMHO, I would prefer to specify the security as part of the
Instrument components SecurityAlt repeating group asSecurityAltIDSource=6 (ISO Currency Code) SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding
the Currency to the OrderCancelRequest as a local extension.Looking forward to your opinions / experiences.
Cheers, Jörg
Currency is not part of the Instrument component, never was, because
it is meant to denote the currency denomination of price data.
Very good point, Lisa! This sheds some light on the reason why the Currency is not in the OrderCancelRequest.
We (the GTC) will make a note to consider adding Currency field to the
Order Cancel Request message (or any other messages where this might
be missing).
Hmmm, actually, this contradicts your first statement. Probably Currency should be renamed to PriceCurreny to make this clear.
My preference would be to add the Currency field. The SecurityAltID
repeating group is meant to identify the same security using different
identifies (e.g. CUSIP and ISIN for IBM).
The FIX 4.4 FIXimate speaks about “assisting in security identification”, so my interpretation is that it is OK. On the other hand, the name “Alt” = alternate is a bit misleading.
Thanks, Jörg
Hi all,
we currently have a discussion how we should cope with the missing
Currency field in the OrderCancelRequest. We need to identify the
instrument to process the OrderCancelRequest, but Currency is not part
of the Instrument component for FIX 4.4 / 5.0.Basically, I have got two questions:
(1) Why is the Currency field not part of the Instrument component?
(2) Is the SecurityAltID the correct way to supply the missing
Currency for the OrderCancelRequest?Re (2): IMHO, I would prefer to specify the security as part of the
Instrument components SecurityAlt repeating group asSecurityAltIDSource=6 (ISO Currency Code) SecurityAltID=currency
I would prefer this way to introducing a user defined field or adding
the Currency to the OrderCancelRequest as a local extension.Looking forward to your opinions / experiences.
Cheers, Jörg
Currency is not part of the Instrument component, never was, because it
is meant to denote the currency denomination of price data.We (the GTC) will make a note to consider adding Currency field to the
Order Cancel Request message (or any other messages where this might
be missing).My preference would be to add the Currency field. The SecurityAltID
repeating group is meant to identify the same security using different
identifies (e.g. CUSIP and ISIN for IBM).
Hi,
Cross referencing your answer to my reply in http://fixprotocol.org/discuss/read/592ece66
