Date

29 Feb 2016

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/browse/SEC/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel

5) Todays content discussion.

UML

Spreadsheet

Protégé

6) For next week.

Proceedings

20160229 FIBO-SEC FCT

Will be back to FBC next week.

Good news: latest versions of Foundations and BE are in GitHub in Yellow, will shortly be in Pink. Alignment of SEC to the latest updates will follow shortly. Will post OMG-submitted materials to the WIKI as well--stay tuned.

SEC open issue to refactor to FBC is complete. There will be a new refactoring effort (small) given the newest BE and FND work. Review of roadmap. This week: Securities Restrictions (on schedule at this point). Next SEC meeting: March 28. Need input from group on what we have to date. Anticipate iteration on some of this stuff as we get into Equity and Debt (not surprising). Post April 11: likely Debt Instruments first, then Equity Road map not in stone, if you see anything we need that is missing, speak up. Everything we have done to date is in GitHub in Pink, today's ontology excluded as it is still in (too much) motion. Need input on: Definitions in pretty much everything; properties in Issuance, Listings, Assets. PLEASE help us out here--this is why you are here.

Gareth Isaac: For the Securities Identification, would FISN (standard for the Financial Instrument Short Name (ISO 18774)) be appropriate to fall under the identifier area? Looking at Restrictions in Protege. Main classes reviews. Some classes might be better as individuals, e.g., Regulations. Should Reg-S be under a US jurisdiction? Right, but should it be a class at all? Seems like a instance of regulation to me. Granted, with a specific jurisdiction? Gareth Isaac :nope - but need to get a strategy on US, UK , etc. legislation approach. Does it make sense to have a distinct ontology that itemizes individual regulations? Right now, we have a few pointed out (wrongly?) as classes.

Discussion of Jurisdiction-specific restrictions...want to align our approach with other parts of FIBO (BE). Challenge: help us understand what is important around a regulation/restriction on a security so that we can properly capture this. Discuss: general (not granular) and right is better than granular and wrong. If we want to get granular, we need to be right. Gareth: this stuff is a moving target, so we should keep the core parts as simple as possible...jurisdiction stuff should be left to extensions for local/individual implementation. We have various "kinds" of restrictions...are there other "kinds" that we need? Gareth Isaac: Recommend making information separate for the examples to ensure the testing of the FIBO core aspects can be achieved. However that may not form part of "Core FIBO", but a more regional version is likely to be more appropriate. However that exercise is needed to find any 'bugs' in the core FIBO with the exercise of the regional aspects.

When you look at the ontology, you will see very little in the way of restrictions, please advise. Need a review of the classes themselves (ignore the definitions that are currently in place as they are largely placeholders). (we started with a pretty immature "red" file and are a bit out of our expertise in tuning this).

Alvarez, Marc): If it helps, I think by definition restrictions is going to something that can be expected to develop over time, and this gets a little more complicated as (1) new restrictions can be introduced to existing regulations and (2) entirely new regulations with either additional use of existing restrictions as well as entirely new ones. So my view is that taking a higher level approach that can be extended over time is the appropriate strategy. We can expect more restrictions over time I'm afraid.

Elisa to Marc - great point. I think that the broader issue is that much of this is moving over time and that will not change. This suggests that we keep this fairly high level so as to accommodate changes. Also, once an OMG standard is in place, changes can only be additive. High level with enough so that an implementation can do a deep dive for their org by extending. But, we still need to validate our high level

Proposal: face to face working session in NYC at some point. Likely at Bloomberg offices. Will post to github/wiki etc. email to follow indicating such will be circulated.

Slides –

Decisions

Action items