Object required in CDM to capture Index names required for regulatory reporting

[winitall01]

Context

Generic object required in CDM to capture Index names required for regulatory reporting

Background

ESMA EMIR Reporting requires reporting of index names for following fields:

1. 2.85 - Name of the floating rate of leg 1
2. 2.101 - Name of the floating rate of leg 2
3. 2.16 - Name of the underlying index

Currently, there’s no option for capturing index names for the floating rate legs and the underlying index in CDM.

Proposal

Summary

This proposal intends to utilise and rearranging existing CDM objects to resolve the issue of capturing index namexs.

Currently, CDM has a type object named as IndexReferenceInformation

This attribute is currently defined to capture information required of Credit Default Swap Index.

Additionally, there's a type object named as Index which is currently used in EMIR jurisdiction rule modelling to deduce index nmae. Type Index is CDM extends Product base but contain no attributes of its own.

Resolution (Proposed)

Step 1: Split ‘IndexReferenceInformation’ into

1. Generic ‘IndexReferenceInformation’ - to capture generic index related information
2. Specfic ‘AdditionalIndexReferenceInformation’ - to capture specific index related information required for CDS
   

Step 2: use ‘IndexReferenceInformation’ in type Index as

This could resolve the requirement of 2.16 - Name of the underlying index

Step 3: Include ‘IndexReferenceInformation’ in FloatingRateOption

This will resolve the requirement of supplying names for Floating Rate Legs as required for fields 2.85 and 2.101.

[rvincentISDA]

Could you increase the size of the screenshot. It is not legible currently.

[rvincentISDA]

Rather than splitting the IndexReferenceInformation should the approach rather bring the index name, indexID, floatingRateIndex, InflationRateIndex as attributes of an index alongside the IndexReferenceInformation. The latter could be renamed as CreditReferenceInformation.
You would then have the FloatingRateIndexOption to extend an Index with the relevant data constraint. This might seems more natural.
The reference to IndexReferenceInforfmation type for CDS and elsewhere could be replaced by an Index type

[rvincentISDA]

To clarify my updated suggestion after discussion with Vineet.

[rvincentISDA]

[rvincentISDA]

[rvincentISDA]

This approach avoids nesting index name and ID into a unnecessary new type.
Arguably we could even avoid adding IndexName and ID given they might already be representable as part of the
ProductBase-> productIdentifier and
ProductBase->productTaxonomy-> value->name
and the FloatingRateIndexEnum and the InflationRateIndexEnum are themselve specialised ProductTaxonomies.

[hugohills-regnosys]

@rvincentISDA your approach proposes the following incorrect type hierarchies:

• FloatingRateOption extends Index extends ProductBase - which is wrong because it would mean a FloatingRateOption was effectively a product. i.e. it inherits both productIdentifier and productTaxomony attributes from ProductBase
• CreditIndexReferenceInformation extends Index extends ProductBase - which is wrong because it would mean a CreditIndexReferenceInformation was effectively a product. i.e. it inherits both productIdentifier and productTaxomony attributes from ProductBase

Neither FloatingRateOption or CreditIndexReferenceInformation should extend ProductBase.

[rvincentISDA]

Thanks Hugo. Maybe we should get others' perspectives.

The association to ProductBase by extension does not make a data type the super type product. It is only associating a list of possible Identifiers and a taxonomy. The design will most like have to also categorise the Identifiers (ISIN, FIGI etc) similarly to the structural definition of ProductBase. ESMA for example requires to report the ISIN of an FRO.

Maybe it's ProductBase that carries the wrong name and is overloaded with purposes?

[lolabeis]

We should separate the short-term change (driven by immediate DRR requirements) vs the target state.

In the target state, FloatingRateOption and alsoCreditIndexReferenceInformation both extending Index (and TBD whether Index should extend ProductBase - see below) is likely where we want to be.

In the short-term, doing this without any further refactoring of ProductBase attributes has the disadvantage that @hugohills-regnosys mentioned. In addition, it would introduce the confusion that Index identifiers could be set along 2 different paths:

• the productIdentifier attribute, which is the existing one used in production e.g. for equity index
• the new indexName and indexId attributes

This inconsistency could be addressed by harmonising productIdentifier and indexName / indexId, indeed along the lines suggested by @rvincentISDA. However, this is not a change that can be built in the short-term. In fact, it is related to the broader issue re Observable (#2106), which also raises the question of Product vs Observable. Arguably an index is more the latter than the former. Absent that harmonisation, the benefit of hosting both cases under a single Index object is limited as their treatment needs to be forked anyway, whereas there are clear drawbacks.

Given the proposed change's impact on DRR, whereby reporting of certain index fields is currently blocked, we should proceed with the proposed short-term change while taking note of the aspirational target state.

[iansloyan]

Thank you for presenting the issue to us @lolabeis @winitall01

If we hone in on the problem being solved - FloatingRateOption is missing id and name of the floating rate index. So to fix that we are inserting an improved IndexReferenceInformation attribute which can store those details. This attribute should be available in Index today but is not.

I think we are good to proceed on this basis with the related PR on condition that an issue is raised to solve the longer term issue add IndexReferenceInformation to Index, have FloatingRateOption extend or be of type Index, and deal with any refactoring or duplication in IndexReferenceInformation with productIdentifier and productTaxonomy which is inherited into index from product base. (Keeping the symmetry of product type usage in place with each product/instrument having taxonomy + product id inherited from base)
A projected date for when that could be completed would also be welcome.

[lolabeis]

Thank you @iansloyan @chrisisla. A new issue has been raised accordingly. ☝️

For good audit trail purposes, can I ask you both to formally click on "Approve" for PR #2336, before we merge? (just added you as reviewers)