Imported from previous forum
I noticed that UnitOfMeasure has an enumeration for USD. The example given in the spec for this is eurodollars, and that a contract represents 1,000,000 USD.
It seems somewhat unusual that dollars get this kind of special treatment in a global protocol. There are certainly futures contracts in other eurocurrencies, e.g. euroyen, as well as FX futures, all of which are measured in a given amount of a foreign currency.
I’m curious about what best practice should be to represent this? It seems like it would be better either:
A. To deprecate USD and use something generic, like “Cash” or “Currency”, with another field to indicate what the specific currency is, or
B. To import the full list of ISO currency codes into UnitOfMeasure. There are only three that are of the same format as ISO currencies: CBM, CER, and CRT. For now, at least, these don’t conflict with any currency.
Thoughts?
The proposal came via CME and NYMEX. I remember arguing against this unsuccessfully at the time. If you could do a bit of research internally that would be great. It really does not seem correct, even using the argument that USD is a reserve currency and part of a cross pairs - still seems like it is not correct. There was some argument to support this put forth at the time.
I noticed that UnitOfMeasure has an enumeration for USD. The example given in the spec for this is eurodollars, and that a contract represents 1,000,000 USD.
It seems somewhat unusual that dollars get this kind of special treatment in a global protocol. There are certainly futures contracts in other eurocurrencies, e.g. euroyen, as well as FX futures, all of which are measured in a given amount of a foreign currency.
I’m curious about what best practice should be to represent this? It seems like it would be better either:
A. To deprecate USD and use something generic, like “Cash” or “Currency”, with another field to indicate what the specific currency is, or
B. To import the full list of ISO currency codes into UnitOfMeasure. There are only three that are of the same format as ISO currencies: CBM, CER, and CRT. For now, at least, these don’t conflict with any currency.
Thoughts?
We do have the requirement of currencies other than USD although certainly not the full set of ISO codes but I believe more than just EUR, e.g. CHF. Maybe it is wise not to define a simple union of data types but to add currencies as requested by extension proposals. Or we need to ensure that values do not overlap with the existing major currencies.
I noticed that UnitOfMeasure has an enumeration for USD. The example given in the spec for this is eurodollars, and that a contract represents 1,000,000 USD.
It seems somewhat unusual that dollars get this kind of special treatment in a global protocol. There are certainly futures contracts in other eurocurrencies, e.g. euroyen, as well as FX futures, all of which are measured in a given amount of a foreign currency.
I’m curious about what best practice should be to represent this? It seems like it would be better either:
A. To deprecate USD and use something generic, like “Cash” or “Currency”, with another field to indicate what the specific currency is, or
B. To import the full list of ISO currency codes into UnitOfMeasure. There are only three that are of the same format as ISO currencies: CBM, CER, and CRT. For now, at least, these don’t conflict with any currency.
Thoughts?
The logical conclusion is that in some cases, the UnitOfMeasure requires a modifier.
If the UnitOfMeasure is tons (or tonnes), the modifier could be short/long or imperial/metric.
Same with Currency, we would need the modifier of the specific currency.
It is correct that other contracts denominated with a notional of some quantity of currency would need additional enumerations to represent which specific currencies need to be added - or an optional new tag of “UnitOfMeasureDescriptor” in order to accurately describe a contract’s UnitOfMeasure unambiguous specifics for the notional quantity represented.
We do have the requirement of currencies other than USD although certainly not the full set of ISO codes but I believe more than just EUR, e.g. CHF. Maybe it is wise not to define a simple union of data types but to add currencies as requested by extension proposals. Or we need to ensure that values do not overlap with the existing major currencies.
I noticed that UnitOfMeasure has an enumeration for USD. The example given in the spec for this is eurodollars, and that a contract represents 1,000,000 USD.
It seems somewhat unusual that dollars get this kind of special treatment in a global protocol. There are certainly futures contracts in other eurocurrencies, e.g. euroyen, as well as FX futures, all of which are measured in a given amount of a foreign currency.
I’m curious about what best practice should be to represent this? It seems like it would be better either:
A. To deprecate USD and use something generic, like “Cash” or “Currency”, with another field to indicate what the specific currency is, or
B. To import the full list of ISO currency codes into UnitOfMeasure. There are only three that are of the same format as ISO currencies: CBM, CER, and CRT. For now, at least, these don’t conflict with any currency.
Thoughts?
Our requirements seem to be simpler and only for the cash market and related to currency bonds, e.g. a bond denoted in Turkish Lira, traded in Turkish Lira and settled in EUR. This is where I thought that UnitOfMeasure (996), TradingCurrency (1245) and SettlCurrency (120) would be appropriate. Maybe “CASH” is more appropriate and then requires an additional tag as you say to convey the currency.
The logical conclusion is that in some cases, the UnitOfMeasure requires a modifier.
If the UnitOfMeasure is tons (or tonnes), the modifier could be short/long or imperial/metric.
Same with Currency, we would need the modifier of the specific currency.
It is correct that other contracts denominated with a notional of some quantity of currency would need additional enumerations to represent which specific currencies need to be added - or an optional new tag of “UnitOfMeasureDescriptor” in order to accurately describe a contract’s UnitOfMeasure unambiguous specifics for the notional quantity represented.We do have the requirement of currencies other than USD although certainly not the full set of ISO codes but I believe more than just EUR, e.g. CHF. Maybe it is wise not to define a simple union of data types but to add currencies as requested by extension proposals. Or we need to ensure that values do not overlap with the existing major currencies.
I noticed that UnitOfMeasure has an enumeration for USD. The example given in the spec for this is eurodollars, and that a contract represents 1,000,000 USD.
It seems somewhat unusual that dollars get this kind of special treatment in a global protocol. There are certainly futures contracts in other eurocurrencies, e.g. euroyen, as well as FX futures, all of which are measured in a given amount of a foreign currency.
I’m curious about what best practice should be to represent this? It seems like it would be better either:
A. To deprecate USD and use something generic, like “Cash” or “Currency”, with another field to indicate what the specific currency is, or
B. To import the full list of ISO currency codes into UnitOfMeasure. There are only three that are of the same format as ISO currencies: CBM, CER, and CRT. For now, at least, these don’t conflict with any currency.
Thoughts?
The logical conclusion is that in some cases, the UnitOfMeasure requires a modifier.
If the UnitOfMeasure is tons (or tonnes), the modifier could be short/long or imperial/metric.
Same with Currency, we would need the modifier of the specific currency.
It is correct that other contracts denominated with a notional of some quantity of currency would need additional enumerations to represent which specific currencies need to be added - or an optional new tag of “UnitOfMeasureDescriptor” in order to accurately describe a contract’s UnitOfMeasure unambiguous specifics for the notional quantity represented.
This certainly fits with the FIX Type/SubType model of representing something. From that standpoint, I like it.
But it does have a possible issue, which has more to do with the representation of FIX in the Repository and its translation to FIXML. Either we add specific currencies explicitly, which would require an EP every time an exchange lists a contract on a currency not previously specified, or we have to define the field as the union of the ISO currency list + specific enumerations, e.g. long, short, metric. I don’t like the former approach at all. And I don’t know how well the latter approach would be supported by the Repository infrastructure, or if it was, whether the resulting FIXML schema would be capable of discerning between valid and invalid non-currency enumerations.