Improve the definition of Instrument context type - add MIC

[openfin-johans]

Enhancement Request

The FDC3 Instrument context type is probably the most widely used and the first one people tend to look at when trying out FDC3 and their implementation or application. The most common identifiers are already standardized but these often requires subscriptions and many early adopters of FDC3 only use tickers (which are not unique) and therefore include extra information in the context object to help a receiving application to correctly identify the instrument. The Market Identifier Code (MIC) seems to be common although sent using different property names or worse - added to the ticker value itself. This enhancement would simply be to standardize the name used when your app has the capability to handle data specified in the ISO 10383 standard.

https://en.wikipedia.org/wiki/Market_Identifier_Code

Use Case:

Provide a more accurate representation of a financial instrument using freely available sources and allow for better matching between applications that use disparate data sources.

Details

Property	Type	Required	Example Value
type	string	Yes	'fdc3.instrument'
name	string	No	'Microsoft'
id.ticker	string	No	'MSFT'
id.BBG	string	No	'MSFT:US'
MIC	string	No	'XNAS'

Example

const instrument = {
    type: 'fdc3.instrument',
    name: 'International Business Machines',
    id: {
        ticker: 'ibm'
    },
    MIC: 'XNAS'
}

Additional Information

... please add any other information that can provide additional detail for this enhancement request

[kriswest]

Seems fine to me. However, if there are other types of code that identify exchanges we should put this under a market or exchange field allowing other code types (e.g. Bloomberg Exchange code, EOD etc.) and fields (e.g. country code, name) to be included.

Hence, how about:

const instrument = {
    type: 'fdc3.instrument',
    name: 'International Business Machines',
    id: {
        ticker: 'ibm'
    },
    market: {
       MIC: "XNMS",
       BBG: "UQ",
       name: "NASDAQ Global Market",
       COUNTRY_ISOALPHA2: "US"
    }
}

[openfin-johans]

Thanks @kriswest - I am having an internal debate with myself regarding your addition. On one hand I don't want encourage the use of "Market" and having to combine it with an id to find a match, but on the other hand - if anybody do need eg "Market Name" for their workflows - it's better if we do have a standardized way of doing so and flexibility to add other types of market code.s. So, in the end - I think you have a good point!

Happy for input from anybody close to symbology and market data.

[robmoffat]

Why don't we have a type for the components of the id, much as we do for other pieces of context?

I was thinking of this since symphony do this:

{
	"123": {
		"type": "org.symphonyoss.fin.security",
		"version": "0.1",
		"id": [
			{
				"type": "org.symphonyoss.fin.security.id.isin",
				"value": "US0378331005"
			},
			{
				"type": "org.symphonyoss.fin.security.id.cusip",
				"value": "037833100"
			},
			{
				"type": "org.symphonyoss.fin.security.id.openfigi",
				"value": "BBG000B9XRY4"
			}
		]
	},

Just thought I'd throw this in in case it helps to see how this problem is handled elsewhere - feel free to ignore

[robmoffat]

Interesting to note that symphony also uses a "version" field for all their JSON types too

[openfin-johans]

Hi @robmoffat - that's the old structure from work in the Symphony Foundation that become Finos Financial Objects and ultimately implemented as FDC3 context. Interesting story for sure not really related to this issue and the simple addition suggested - happy to discuss in another issue or during a meetup!

[robmoffat]

Interesting background! Do you know the history around moving away from typed ids?

[kriswest]

@robmoffat I wasn't around for the original decisions and can't comment on the history. However, the structure you propose is not ideal for use in javascript. I'd have to iterate the array to check for the presence of a particular id type or to retrieve it, whereas if you use an object where the key represents the identifier type this is easier:

//do I have a CUSIP?
if (instrument.id.CUSIP) { ... }

We don't use the reverse domain approach for naming (ala java package names) and wouldn't/couldn't use proprietary domains in the standard, however, this is recommended for a firm using the own proprietary id here to facilitate namespacing - although the presence of periods means using array access syntax in javascript (e.g. instrument.id[com.company.app]).

Instead, short capitalized names are used for references to external standards and well-known identifiers. This is easy to grok and results in simple clean code. Hence, I don't see a problem to solve there.

Regarding the 'market' and MIC, I think we should stick to a similar format for consistency and future-proofing (alternatives to MIC). I am interested to know if there is a reasonable alternative to market @openfin-johans, say 'venue', 'marketplace', 'exchange' or similar.

[openfin-johans]

@kriswest - I would say 'market' is the best alternative in order to keep it future-proof while also give flexibility to it's use.

[robmoffat]

The reason I'm asking this is because it seems like the market should be part of the ticker ID. The market / ticker id combination should be unique.

Admittedly, it's taken me a while to find this example, but MONDI is a dual-listed company called MNP on the JSE and MNDI on LSE.

We've specifically made id a map {} so that it can support multiple, different ids, (like BBG id) but in this case it can't.

https://www.londonstockexchange.com/stock/MNDI/mondi-plc/company-page
https://www.jse.co.za/jse/instruments/3725

I mean, this is a bit of an edge-case so maybe not worth worrying about. I totally take @kriswest's point that it is super-easy from a JS point-of-view to not worry about a map type in id.

[kriswest]

Admittedly, it's taken me a while to find this example, but MONDI is a dual-listed company called MNP on the JSE and MNDI on LSE.

I think those are different instruments then, even if they refer to the same company. They would have different tickers and market values (MNP:JSE and MNDI:LON) although I note they have a common ISIN (is this why ISINs exist?).

I totally take @kriswest's point that it is super-easy from a JS point-of-view to not worry about a map type in id.

To be clear we do use a map type and its far more convenient than an array type. Were we to use an array type we would have to consider what to do about multiple copies of an identifier and what you do if you want to refer to security in a particular market.

[openfin-johans]

Hi @robmoffat - this has been discussed quite a bit in the past. Items in ID should be unique in the sense they should individually refer to the instrument itself. Additional information like market identifiers doesn't refer to the Instrument and should therefore not be part of the ID.

The Mondi example is interesting since they have different tickers but the same ISIN but other IDs (SEDOL, OpenFigi, FactSet) would provide uniqueness - but another example where MIC would be handy to further identify the instrument when apps do not have access to the same market data:

{
"type": "fdc3.instrument",
"id": {
"ISIN": "GB00B1CRLC47",
"ticker": "MNP",
},
"name": "Mondi plc",
"market": {
"MIC": "XJSE"
}
}

{
"type": "fdc3.instrument",
"id": {
"ISIN": "GB00B1CRLC47",
"ticker": "MNDI",
},
"name": "Mondi plc",
"market": {
"MIC": "XLON"
}
}

A more typical example is SAND which is a ticker used for different companies on different exchanges - here we can see that eg ISIN is different and can be used directly while ticket has to be further combined with MIC to get a proper match.

{
"type": "fdc3.instrument",
"id": {
"ISIN": "SE0000667891",
"ticker": "SAND",
},
"name": "Sandvik AB",
"market": {
"MIC": "XSTO"
}
}

{
"type": "fdc3.instrument",
"id": {
"ISIN": "CA80013R2063",
"ticker": "SAND",
},
"name": "Sandstorm Gold Ltd.",
"market": {
"MIC": "XNYS"
}
}

Finally, MIC is already sent in various forms today outside the ID - we are just trying to standardise the naming convention.

[robmoffat]

I agree with all of this. I guess my point is really that the key is not a complete key, if it depends on some piece of data outside of the key, a la. https://estherk15.medium.com/normalized-data-c46b0fdbd0e7

This just strikes me as strange, that's all

[kriswest]

@openfin-johans are you ok with us adding this to the 2.1 milestone? We haven't yet approved the 2.0 pre-draft, but would need a PR (which I can help with) before this can go in. If there is a pressing need to get it in earlier let @mistryvinay and myself know - otherwise we can discuss at next Context and Intents meetings

[openfin-johans]

@kriswest - no rush at all - happy to go with 2.1. The fact that issue is up here might make a "community standard" anyway.

[nemery-flextrade]

Suggested existing standards
MIC - Market Identifier Code (ISO standard in the OP)
REUTERS? - Reuters Exchange Code (TBD if we can source a reference)
BLOOMBERG - TBD if we can source a reference

https://stockmarketmba.com/globalstockexchanges.php may work as a reference but looks incomplete

[kriswest]

@nemery-flextrade Do you mean the Reuters Exchange Code or Reuters Exchange Mnemonic, rather than RIC?

@openfin-johans the Context & Intents group think this ready to move to a PR (with a market field with field identifiers, in same pattern as the id field). The docs should point to any relevant standard (so ISO 10383 for MIC), which should also be included in the reference page (https://fdc3.finos.org/docs/next/references).

Are you up for taking on the PR, if not I can put it on my todo list and get to it in a few weeks time.

[kriswest]

@Soul-Master are you able to confirm the correct name and/or provide a reference from the Reuters Exchange Code or Mnemonic?

[nemery-flextrade]

@kriswest Updated my comment - let's sidestep the issue by referring to it as REUTERS.

[Soul-Master]

For Refinitiv platform, we accept 2 kinds of exchange identifiers.

1. MIC
   https://www.iso20022.org/market-identifier-codes
2. Exchange Codes (managed by our NDA team)
   For external users, you can find list of exchanges in the following file.
   https://community.developers.refinitiv.com/storage/attachments/901-exchange-codes.txt

Refer:
https://developers.refinitiv.com/en/article-catalog/article/functions-to-find-option-rics-traded-on-different-exchanges
https://developers.refinitiv.com/en/article-catalog/article/isin-ric-conversion-trth-thomson-reuters-tick-history-rest-api