Date

30 Oct 2018

Attendees

Agenda

1) Use Case reminder

2) Where we are on our road map.

3) Open Action Items

4) JIRA Issues Review - https://jira.edmcouncil.org/projects/DER/issues/DER-10?filter=allopenissues

5) Todays content discussion.

Chatlog is available at

6) For next week.

Proceedings:

This week we continued to discuss some of the recent work by CFTC towards a next-generation reporting approach in terms of the fields they are considering for integration. Much of the conversation centered around the concept of a "bespoke" or made-to-order instrument, may be challenging to represent in FIBO, as what one is looking for are outliers, and that may be from the perspective of the reporting party rather than from the perspective of the organization that they are reporting to.

Some notes from the discussion:

Bespoke - any OTC Derivative Contract -
- need general definition, which could be some OTC derivative contract
- then bespoke ... anything made to order, which is different on a per user basis (so in the mapping, it's simply a property on the swap from the perspective of the reporting party, and this might not be in FIBO)

A bespoke instrument is one that does not fall into any of some number of categories ... the "left-overs" ... the critical thing is the set of properties of the instrument.

The CPMI-IOSCO technical guidance on the harmonization of critical OTC derivatives data elements is available at https://www.bis.org/cpmi/publ/d175.pdf. One approach would be to ensure that we have encoded all of these elements and to be able to query across them to determine the nature of a given instrument.

The goal from a CFTC perspective is to identify exposure and risk at a high level - so anything custom could be higher risk, with a goal of making it easier to identify that the cash flows are non-standard

- if the instrument does not fit a standard algorithm, then for valuation models something custom / bespoke would be flagged
- one approach would be to create a set of queries against parameters of the ontology that would identify which models conform or don't conform to a particular algorithmic / analysis model (which would require modeling those algorithms and the properties they use for analysis purposes, and map those to the properties of the instruments under analysis)
- target might be to get an understanding of the set of evolving parameters / queries over time and those contracts that are 'exotic' or that don't fall into a given classification scheme would help categorize them

Jeff: It is true that the classification of a financial contract instrument type is needed in order to assign the correct algorithmic processor for the purpose of analyzing the risk (cash flows and other risk behaviors) of each contract. So the inability to perform that type of classification (disambiguation) means that one would not be able to assign it to the proper analytical model ("contract type" in ACTUS, as an example ) hence, flagged as an exception.

The discussion also covered the CFTC's need for views / canned queries against the information, subsets by instrument type that exclude other things that CFTC isn't of interest ...

For next week, Dean will present his "tree-shaking" example ... 11/6, to show how the views approach might work, and record the session for anyone who can't make it.

Decisions:

Action items

Dean Allemang to give a presentation on "tree-shaking" on our next call (11/6), which should help with the question of how to generate "views" from the CFTC or any other perspective. Note that this meeting should be recorded for folks that cannot make the call.

Browser not supported