Classification field to refine 'type' for contexts

[hughtroeger]

Enhancement Request

Use Case:

At FactSet we have an FDS_TYPE property that we use with contexts to further refine the type of the context. We use this field to determine whether to run extra resolutions on the context and add more properties to the id field. For instrument contexts some examples would include publicCompany, privateCompany, commodity, etf, mutualFund, future, option. We currently place this property inside id, but are wondering if that is the best place to put it. Would it make sense to have an optional top level classification field? Being an object itself with any number of sub properties. Also just want to present the use case and ask if others do anything like this or see value in it.

EDIT: examples have been updated to reflect classification being an object rather than a string following feedback. EDIT 2: examples have been updated to use classification.name rather than classification.fdc3

Contexts

Instrument

Details

Property	Type	Required	Example Value
type	string	Yes	'fdc3.instrument'
name	string	No	'Fidelity 500 Index Fund'
id.ticker	string	No	'FXAIX'
~~classification~~	~~string~~	~~No~~	~~'mutualFund'~~
classification	object	No	{name: 'mutualFund', FDS_TYPE: 'mutualFund', ~~fdc3: 'mutualFund',~~ }

Example

const instrument = {
    type: 'fdc3.instrument',
    name: 'Fidelity 500 Index Fund',
    id: {
        ticker: 'FXAIX',
        CUSIP: '315911750',
        ISIN: 'US3159117502',
        SEDOL: 'B4VF818'
    },
    //classification: 'mutualFund',
    classification: {
        //fdc3: 'mutualFund',
        name: 'mutualFund',
        FDS_TYPE: 'mutualFund'
    }
}

Example 2

const instrument = {
    type: "fdc3.instrument",
    name: "Microsoft",
    id: {
        ticker: "MSFT",
        RIC: "MSFT.OQ",
        ISIN: "US5949181045"
    },
    market: {
        MIC: "XNAS"
    },
    classification: {
        //fdc3: "publicCompany",
        name: "publicCompany",
        XYZ: "company",
        CDM: "equity"
    }
}

Additional Information

• Conceptually this is similar to supporting more granular types for contexts, but it wouldn't make sense to actually split off more types and fracture the listener ecosystem.
• If others feel the best place to put this info is in the existing id field then we can continue doing that.

[kriswest]

@hughtroeger sorry for the slow response on this one. I'm adding it to todays SWG agenda to talk about.

I appreciate the conundrum, classification info isn't really an id... I'd suspect that we should be extending with a new field (that can't be called type for obvious reasons), along the lines of the additions we made for market. Should we perhaps consider standardizing an enumerated type for the classifications? Is it likely to be a finite list?

[hughtroeger]

Hi @kriswest, sorry for the long delay. I am finally working on a PR for this. I think I'm going to go with classification for the name of the field, and make it a string instead of an object, but I am open to suggestions. An enumerated type makes sense to me. Here is the list we have for instruments:

commodity commodityIndex corporateDebt creditDefaultSwapIndex deal debt debtIndex etf fixedIncome future governmentBenchmarkDebt loan mortgageBackedSecurity municipalDebt mutualFund mutualFundIndex option otherDebt ownershipPrivateCompany pevcFirm pevcFund privateCompany publicCompany publicCompanyIndex sovereignDebt structuredProduct unknown

[kriswest]

Do you want to support the use of the defined values (i.e. give intellisense, but allow any string) or should we constrain the type/schema to a specific enum? Either is possible (theres a trick to getting typescript to not collapse the type down to just 'string' - not sure if we can use it with types generated from config schemas however).

[hughtroeger]

That's a good question. Trying to consider the tradeoffs. My initial feeling was that allowing flexible use of this property would potentially ease adoption for others and mean that adding new values doesn't require a spec update. Definitely want to avoid situations like some firms using 'etf' while others use 'ETF'. Also want it to fit well with the existing schema structures and not be awkward in the other languages we support. I will check with our internal stakeholders. What are your thoughts?

[kriswest]

@robmoffat mentioned that there are a set of classifications for instruments as part of the CDM project. it would would be worth researching those before finalising a list.

[openfin-johans]

hi @hughtroeger - nice work and sorry for being late to the party.

I really do think we should make this an "array" similar to the recently added market and of course the original id. I think it's unlikely we'll get the classifications just right and users are likely to overload it. Better to give the capability to actually say that it's the xyz classification rather than having to do various interpretations on the receiving end?

In addition we should use the approach of capitalizing official definitions and with that use your list as the "official" fdc3 classification that vendors hopefully will adopt over time!

So, my suggestion would be:

{
  "type": "fdc3.instrument",
  "name": "Microsoft",
  "id": {
    "ticker": "MSFT",
    "RIC": "MSFT.OQ",
    "ISIN": "US5949181045"
  },
  "market": {
    "MIC": "XNAS"
  },
  "classification": {
    "FDC3": "publicCompany",
    "xyz": "company",
    "CDM": "equity"
  }
}

[hughtroeger]

Thanks @openfin-johans, I received the same feedback internally, I will update this issue and my PR. I had considered that approach originally and wasn't sure if it was going to be too much. I definitely see the value in the flexibility and consistency with the market and id fields.

[hughtroeger]

@openfin-johans @kriswest - with classification being an object, do you think the 'standard' sub property should be called fdc3 or name? I know we already have a top level name in instrument, but the market field has a name sub-property too.

[kriswest]

Without an external standard to reference for the values, we could either go with 'fdc3' or we can acknowledge this is your list and use something like FDS (we have FDS_ID in the id field and BBG in market)

[openfin-johans]

I'd be in favour of having name as an official optional item for classification just as in market.

Basically if you have some classification but it doesn't adhere to any official standard (and you don't consider publishing it as reference data either) - then put the value in name rather then overloading any other parameter. You could of course leave it out but then a recipient might miss a possible valuable datapoint.

[hughtroeger]

I like classification.name, I updated the PR accordingly.