20150810 FIBO-FBC FCT
Ref: Slides with today's date.
Updated draft spec is on the wiki. No comments received except from Pete, which have been addressed. EK still working on financial services and markets. Gareth has provided additional information on markets. These are in there, apart from the notion of a Central Counterparties. These are regarded as European specific, since the regulations that define these have only been seen in EU regulation. Mike notes that there is nothing specifically European about the concept, and it's a relatively recent regulatory development, so we can't assume this will always be European. We need input from experts in the regulatory space. Mike Atkin has a handle on regulatory innovations globally as part of his mandate at the EDM Council. Bill Nichols also has a handle on a lot of this. Needs people with capital markets experience to really review these regulatory concepts. Capital markets regulation is effectively global, even though the specific regulations are managed by ECB, US Fed institutions and so on.
Slide 5 gives the current state of what's been uploaded. Elisa is still working on some new material in the ontology as a result of the move of some concepts (products and services) into Foundations.
Slide 7 Outstanding Issues.
FBC19 still working on the refactoring on those. The reconciliation with David's Branch is less urgent since much work has to be described with reference to the existing published OMG standard anyway. Elisa is not going to worry about adding a list of services, just needs to make sure she has the right top level hook.
FBC18 reconciliation with David's Fork - Left open for now
FBC23 Example - Open for now, not done anything on this, apart from textual statements about examples in the Spec text.
FBC25 Pete is working on this (Conformance Section)
FBC27 Citi and State St to review list of regulatory - Open. Ian still working on this. There is US jurisdiction material in Pink but this has not been added to the spec yet. Elisa and Ian will work through this after this call. Ian to then do a more thorough review after it's been added to the spec.
FBC28 David B and Elisa to work on something
FBC26 Ian to review the new logo notation. Status: Ian has looked at this, thinks it all looks good. Was worried it seemed too technical but based on the written statement of the audience as being ontologists, they should be able to follow this. On that basis, all looks good. FBC26 can be closed. DONE
On the property, there was no mention of property characteristics e.g. Functional. EK: We don’t have many property types. Have not seen any that are of those types. There is a transitive property for hasPart, isPartOf but these are in the added material in Foundations. Therefore agrees that we should find a way to represent the property characteristics when we republish the Foundations spec. As a new boilerplate to be used across all specs, and not limited to FBC, then we should expect to include the property characteristics. This would be better if it was the same across all the specs, not a subset of stuff needed only for FBC. Elisa agrees. We can spend more time on the template for other specs, after we have submitted the FBC spec. That will then become the template for all specs.
11:22 AM: FBC9 can be closed. We have the top level hooks that are needed for this issue, in the refactored financial services ontology. DONE
FBC22 and 24 are duplicates. MB will do 24 and we will close 22. DONE
FBC8 MB recommendation for License. This is done. Elisa used a subset of the concepts MB provided. The non financial concept License is in FBC but should really be in Foundations. We can move this right away. MB to remind Elisa that this needs to be moved. DONE
FBC2 Buys and Sells Elisa has made the case. FBC2 to be moved to FND. DONE, it is now FND-33
In the context of a trade, who the buyer or seller is could be internal or external and so on. This is a teaching action not a modeling action. MB has it. Depends on Mike's other teaching action
FBC-19 duplicate of 23 and can be closed as duplicate DONE
FBC-12 Gareth still open
FBC20 KYC is on MB to do list. Elisa will take what she knows and put it in Section 7.3 and Mike will edit and revise that text, to close out this action. MB has sent text to EK. See also the meeting slides which also have KYC stuff.
Slide 8: Homework
for the EU stuff from Gaeth, really just need a couple of test individuals to make sure this works.
Use Cases MB taking on the Use Case piece as agreed above. Use the bullets on Slide 11 and 12
Biggest issue that Elisa has been working on is FBC19 has moved Product and service to new module of that name in Foundations, and removed restrictions that could be added back in FBC. Could add one back already, which is a product being characterized by a catalog. Payments and Schedules has been moved. Has refactored other things that depended on products and services e.g. REAs, business registries and so on. These are all refactored and done and in the spec. MB wrote what we know so far about use cases.
Financial Service Product, and Markets, are being worked on. Markets includes MTF, Exchange and something else (per legacy FIBO). Needs to revise the US jurisdiction specific ontologies based on these updates. Coordinating with Pete about how to organize some of this. A new Section 10 will cover jurisdiction specific stuff that we want to be normative. Complete through Section 8 except the stuff form MB on Section 7. MB also to review the text up to Section 8. Others esp. Ian please review that stuff as well.
Slide 13 Review, review, review
Next Meetings: Monday we have a F2F meeting all day at PWC's offices, on Monday 17th. So next week's FBC FCT call will still happen at 8am Pacific
PR: On KYC we need to check that what we have in the ontology addresses the use cases. Also the European Central Counterparty stuff relates to this.
Elisa still awaiting some ontology changes from Dennis's person.
Action: Dennis will ask them. DONE
Deadline is end of this week anticipate that everything they need will be in Pink. Elisa can walk them through that, hope they would agree, may identify gaps for the future.
To the draft spec...
Section 0 minimal review and changes it's FYI for OMG folks.
Section 1 is where we need to start the review, esp. relation to other standards section, which has a new statement on relation to CFI which needs to be checked. Pete to review Conformance (per JIRA TODO)
Terrms and definitions minimal change.
Section significantly changed, on the Audiences section
We will retain the Audiences section. MB to rereview it
Notations 6.3 is new
6.4 is the detailed additions to foundations.
6.4.8 the changes to FIBO Foundations Spec will add a 6.4.8 to the license class, and then this section moved to 6.4.9 these "other changes" are mainly changes to namespaces, and the diagram that contains the foundational blobs. Recommend we remove that diagram from Section 8 in foundations. MB agrees.
7.2 is usage scenarios need MB to work on this. This is where the new KYC text goes
Section 8 has the namespace definitions
Section 9 is the main content (jurisdiction independent ontologies).
:Some of the 9.3 still in work.
9.4 fin Prid and Err done, some Clients and Accounts would go in Foundations. Still working on this. Not too late to have a call with MB to figure out what of this goes to Foundations.
Everything that is in the spec now, is not likely to be changed and is ready for people to review and validate now.
Elisa summarizes where the work is. Section 7, some stuff in Section 8. For instance whether to include LCC namespaces in the Section 8 Namespace definitions. Also the namespaces for BE are in there.
Prefixes done (Section 8 also). but has not yet added the jurisdiction specific ones. These will be added by EK as she does the ontologies.
Section 9 Financial instruments. Ian and others please review. This is the anticipated final form of these.
Functional entities, Business Registries extends the registration stuff, as needed for the LEI registry which requires the Registry, Registered Address and so on. Registration Address should be in BE. There is work to do on this. Currently Registration Address is a child of Postal Address. This lets us do jurisdiction specific reasoning on these. Why have Registered Address a class? Need to be able to apply restrictions such as those which apply for registration, such as that in all places except ZA you have to not have a PO Box.
MB if we have Registered Address at all it would be a Relative Thing. This is the legal address at which you serve papers.
PR: Why is HQ address a property but Registered Address a class? Shouldn't they all be properties. There is a physical format around LEI's notion of Registered Address, which specifies a specific textual format and entries for these. Elisa wants to be able to reason over these which is why they need to be classes. In address cleansing, it doesn't matter how the address is used (what role it has). Elisa refuses to remove what thy have in the model at this time, which can be used for reasoning over locations of organizations about who regulates them, for the reasoning operational ontology applications that Elisa has been showing us. What can we use for addresses as a minimum that isn't wrong? Elisa asserts that none of what is proposed is wrong. We would need cascading restrictions if we were to get the same result via relationships. People are welcome to propose changes, but Elisa will not implement any changes that people are proposing.
Ian asks what is actually wrong in what people are saying? MB suggests that it should be a class but as a kind of relative thing. If we regard Address as 'an index to a location" as a kind of information artifact, Pete suggests that Index as a label is misleading. For example the index to a book is the whole collective of index entries. MB notes that address also has this. Elisa what a third thing which is an index to a location but it also registered for paying a license and so forth, adapted from LEI ROC.
LegalRegistrationAddress is a child of RegisteredAddress. Rename RegisteredAddress to RegistrationAddress and make it clear this is a physical format which is suitable for use as a LEI address.
Action: Foundations FCT will revisit the Address abstractions in the light of the original more sophisticated model.
Elisa is happy as long Address applies to a location. We can improve upon the rest as long as the fundamentals don't change.
Action: EK will rename Registered Address to Registration Address and make it a child of Address
in the sense given already.
Products and Services financial specifics are here. Moved certain things from financial services entities ontology to products and services ontology.
Section 10 for Jurisdiction specific stuff is empty. Elisa will try to load the jurisdiction specific stuff, need to find out whether it loads. Will go over this with Ian now if it loads. In Protege.
Boards of things as kinds of controlling parties. Includes the Federal Reserve Board and others.
There are 2 Controlling Entities, the FFIEC and the Fed Reserve Board. For Registration Authorities, there are 9. This is anyone that has a registry. For regulatory Agencies, there re 12 of these. Things like SEC, Federal Reserve System, etc. FSOC is in this list but maybe should be a Controlling Entity. Not sure what they do? Also
2 things maybe missing: FINRA and NRA. Ian: will have to consult on this.
Ian: is this meant to be illustrative or a formal part of the ontology? These are intended to cover thee US specific entities that are the primary regulators in the US. Does not need to be complete but must be precise.
Pete: The office of Thrift Supervision was abolished by the DFA. EK: however this is still a legacy organization. Assume the NCA and something else took over their roles. They did oversee savings and loans and there are a few of those left.
Pete Rivett: The law abolishes the Office of Thrift Supervision, which had authority over thrifts and thrift
holding companies. The Fed is taking over supervision of thrift holding companies, the OCC is responsible for federallycharted thrifts, and the FDIC is responsible for statecharted thrifts. So we need to know if that office still manages these or if that role has been taken on by others.
IM: Do we want to be able to make historic assertions, i.e. who regulated a thing in the past that relates to something that happened in the past, e.g. in mergers and acquisitions. Question on scope if do we need to be able to include the semantics of things that only existed in the past?
Elisa kept these specific ones in, however also asserted as part of the OCC which they weren't. They still have a web page. This doesn't answer the general scope question.
Action: The FLT needs to agree or disagree on whether to include historical things.
Elisa's example doesn't apply to this question, since this is a thing which is still referenced a lot, in the present.
So it has nothing to do with the scoping question about historicity but still needs to be considered either way.
Elisa will send Ian the list. Ian will review this in the light of Richard’s comment above, that we cover the main cases and that what we cover is accurate.
RB: We should only make sure we are not missing anything huge, not that we have covered everything.
Elisa: we are not doing the state ones but only the national ones for the US jurisdiction specific things.
Pete Rivett: http://www.occ.gov/about/whoweare/occforyou/bankers/otsintegration.html addresses the Thrift Entity question.
International ones are a separate matter. Some US entities can be regarded as having international oversight because of their nature
Mike Bennett Foundations FCT will revisit the Address abstractions in the light of the original more sophisticated model - FND-34Getting issue details... STATUS .
Elisa Kendall EK will rename Registered Address to Registration Address and make it a child of Address in the sense given already - FBC-31Getting issue details... STATUS .
Dennis Wisnosky The FLT needs to agree or disagree on whether to include historical things - FLT-44Getting issue details... STATUS .
Elisa Kendall Elisa to send to Ian, a list to review - FBC-32Getting issue details... STATUS
Mirek Sopek To review FBC re LEIWiz
FBC-33Getting issue details...