Date

11 May 2015

Attendees

Dennis Wisnosky

Goals

Discussion items20150511 FIBO FBC FTC.docx

20150511 FIBO FBC FTC

Elisa presents the draft RFC specification for FBC. This is based on what was previously produced for FND, BE, IND and so on. Most of these have similar boiler-plate material, based on BE (FND has different boiler plate).

Mike notes that FND itself still reflects the original ontologies submitted to the OMG, and the new modeling principles that Elisa has implemented for all the OMG specs, still requires documentation formally in the FIBO specs. HOWEVR most of that is in FND. So we have an opportunity to reflect a small part of those changes as appropriate, in thie FBC spec. Those changes would then also be applied in ID and BE at a future draft.

Gareth Isaac: What is the anticipated timeline for this document ready for review, the internal review period - and the anticipated date this will be submitted to OMG. Can be reviewed now. OMG June 2015.

ISO 20022 as a reference applies only to the SEC specification, not any of the others.

Elisa has updated the acknowledgements section based on people's participation. Also included every organization listed for both loans and securities, from the EDM Council site.

Action: All to review and ensure they have not been left out, when this is published.

Section 6.3 is standard boiler plate and out of date, on how to interpret the business content (this was written around a business facing presentation of the material, not on what we have now).

On 6.4 changes to adopted OMG specs, this will require some changes, including to other FIBO specs - for example, where to put "Arrangements", where we need a top level class for System among other things. Also some of these would be put into "arrangement “as a sort of catch-all. Initially System is needed to describe writing systems, but want to include other kinds of systems. Describes the need in this section, for new ontologies and classes that will be required fro FND and elsewhere.

Action review today: the structure of the content that is going in. would like feedback on what people would like to see.

Structure at present is the module metadata, then the ontology metadata, the diagrams, and then the substantive tables. The substantive tables are where Elisa believes we can improve upon what we have previously been submitting. The tables with the metadata are all based on metadata that can be seen (a) in the About files, and (for the ontologies, (b)) for the ontology specific metadata.

Then come the diagrams. We have had issues with resolution in previous specs, but in this one, Elisa has managed to make these blowable up. The main tables are too wide for the page and use very small text. The column headings were originally framed for a business audience e.g. "Type of Thing". We might want to review that. At some points we have included both explanatory notes and editorial notes, thought we did agree to remove Editorial note as not being appropriate for a business audience. The tables have a lot of white space because they have properties and classes in the same table. This was in line with business requirements for a single spreadsheet style of presentation, with classes and their properties.

An earlier alternative was separate tables for classes and properties, which would be appropriate for a modeler audience but not really for a business audience.

Question: when submitted, is this Word document authoritative, or is it a reflection of something else authoritative? This document and the OWL files are both considered authorative.

This spec is generated from the ODM based UML model, as is the OWL.

Because it's generated, not sure if this needs to be legible. This is difficult for SMEs to review. While this presentation was trying to replicate a spreadsheet view for SMEs, it may be more appropriate to have separate spreadsheets for SMEs, and have a more modeler-oriented presentation format for these specs (in line with how we have made the diagrams more modeler-oriented).

There seems to be a consensus that this would make sense.

Pete suggests that for an SME audience, we can go with a much simpler spreadsheet format anyway, with term, definition and synonym. Mike notes that in the original SR, we had both simple spreadsheet (term definition and synonym), and a more complete spreadsheet, so that SMEs could choose form between them. This format issue should be taken to the Leadership Team as it will apply across specs.

Action: DWiz make this an FLT agenda item.

Proposals are either more of a glossary style, or more of an OMG UML model reporting style. The Languages ontology has a very large amount of textual material that's in the body of the ontology itself, whereas most ontologies just have a single paragraph abstract. Similarly, the Language ontology has an explanatory note that spans 3 pages.

Main thing for today is to start to pull he spec together.

Next part of this meeting: we are looking at Protege on Elisa's machine.

Q: How come there are 2 triples for isRegisteredIn? One of these is inferred, based on the hierarchy of properties, in addition to being asserted. Similarly, registration date and other things are inferred, because of property inheritance. isGovernedBy is also duplicated. Some of the material which is also asserted, is also inferred.

The question is, is this an issue with the reasoner, or something we have done wrong to cause this to happen? This depends on the rule that the reasoner is using to inferred. It's not uncommon that things you have asserted are also inferred by some other path. There is some way to filter this out. This should not be a redundant pair of triples, but just one triple being shown both ways. However if you were to filter it to not display the inferred relations, you would end up also not seeing other things you need to see. It's useful from an ontology editing perspective to see both the inferred and asserted triples. In the example, there are also come relationships that are only inferred. For example, 'identifies' PinnacleBank. Typo: 'dentifies' rather than 'identifies'.

Action: Elisa to investigate where that came from.

Instance data (individuals) have been created for various banks, with their properties. Also individuals for languages and language codes. Bantu languages have only Roman, plus punctuation marks like ! standing in for certain sounds. So duplication of inferences is seen where denotation is used and because this is a child of another property, this causes additional inferencing.

Are there any UML diagrams for BC yet? Yes, most of them. These have been circulated over the past few weeks, in the form of slides.

Action: Elisa will put this material in the wiki.

Elisa has made a few changes on what is in some of these diagrams, and will update these in due course. The diagrams are divided into a simple hierarchy (taxnomy) diagrams, and separate diagram(s) with the restrictions.

The hierarchy of contract types common to securities, derivatives and loans, are all in FBC. Some improvements have been made to put Options and Future children of Derivatives. This is becoming closer to the deeper, complex taxonomy in the legacy FIBO.

Steve Creek: I think there may be some multiple inheritance around cash, currency, this needs to be fleshed out a little more

Mike explains the polyhierrchical nature of derivative. David and Mike and Max have worked through some changes in the current hierarchy on swaps, swap streams and confirmation messages. The current model is incorrect since it incorporated two separate views of the world and does NOT represent what the legacy model showed. Most of this work will be in Derivatives, but we will make sure that the abstractions in FBC are not incorrect or inconsistent, as they are now.

Elisa summarizes these changes will go into the JIRA, and then into the wiki.

Looking at definition spreadsheet. Some of these have been updated, with feedback from Citi. Every element has a definition. Pete is happy t review these models now that he is able to find them in JIRA.

Definition of Financial Instrument is being worked on based on Citi - others are welcome to submit their homework to contribute to this.

Summary: The spreadsheets that were going into the document were not satisfactory and we will look to the FLT for guidance on how to improve on this.

Ontologies have been in GitHub for a while, and ongoing tweaks have been being made to these from time to time, and Elisa will upload those changes. Otherwise the ontologies in the Pink GitHub are fairly current. Homework last week was to review all that stuff - only heard from Citi.

Homework was to review the stuff that ... and also to provide some instances. Two tabs to review are Legal Entity and Financial Intermediary. We only want to include information about an entity that would be publicly available. The stuff in the spreadsheet seems to be real information about real banks. Things like national bank versus state chartered bank, havd been added to the ontology and is reflected in the spreadsheet.

Need feedback on all of these for a wide range of financial institutions. Also who regulates them and who their IDs are registered with.

National versus state banks - this is a very US centric view. However some of them are also international e.g. where thy have a SWIFT BIC code.

By national bank, do we mean something that is governed by the Federal Reserve system? What happens in other federations e.g. Germany or Brazil? If these are chartered at the level of the country then they would also come under this heading of Nationally Chartered.

If banks are chartered regionally rather than nationally in other countries, we might be able to re-use this US-based structure. The aim is to be able to test this with individuals.

We would appreciate feedback from other banks, esp non US ones.

There is a concern that this is very slanted to a US view, and any European or other concepts would have to be jammed into this US based structure, which participants are not happy about.

We agreed last time that we need a hierarchy of services and who regulates those services. Regulator and registrar are separate things. Some things like routing number might be service specific.

Mike has comments on the features about FinancialIntermediary, to do with the breakdown of what is independent thing and what is relative thing properties. So, since FinnciaIntermediary is itself a relative thing, NONE of the properties shown in this spreadsheet, should be properties of the FinancialInternmediary, they should be properties that may be a property of any of the kinds of formal organizations that represent the form that these intermediaries may take. Similarly, as Elisa notes, there are some registration identifiers that are specifically and only related to one service, e.g. BIC, SWIFT codes and so on - these would be properties of a distinct "thing in a rule" specific to that service.

Mike Pool will be able to talk to a few more sources who can shed some light on this.

Elisa: we should regard the table for FinancialIntermediaries as a place to collect a range of properties, some of which will then be modeled as a feature of the independent thing, and sometimes would be properties of service-specific relative entity definitions. So please do not interpret the FunctionalEntity properties as if they would be modeled as properties of the Relative Thing - this is just a convenient place to collect this information. We also need to understand the relationship between Relative Thing concepts and instance data. For example Fidelity, being set up to do several things would be acting as an investment company, as a depository and so on. These are all separate roles that the entity fulfills.

The aim here is to look at those specific roles that we know are regulated, how they are regulated, who regulates them, what are the services defined for that. Then we would stop there for FBC , and refine and extend this in Derivatives, Securities, Loans etc. for roles and regulatory frameworks that are specific to those areas only.

For FBC we need to tease out the examples. We need these for Fidelity, and for Goldman, ad a minimal number of others, so we can cross-check that we have a consistent and non brittle framework. We could do with this for BofA and for Wells as well.

Homework: tease out which of the identifiers given in the FinancialIntermediary tab are service specific, and which of them are organization specific. The spreadsheet includes things like employer, which are not remotely relevant to this exercise. This was to validate that the registration model worked. Treat this as an identifier and move on. It was only after looking at things like employer number, that we realized that some of these identifiers are service specific.

Pete Rivett: FYI, EINs are not just for employers. See http://www.irs.gov/Businesses/Small-Businesses-&-Self-Employed/Do-You-Need-an-EIN for the list of conditions any ONE of which is sufficient for needing an EIN.

Mike is concerned that harvesting such a wide range of kinds of identifier means that you end up finding identifiers for every kind of roles that things play and every kind of regulator that regulates those

EIN is a number which is used in the US more widely than just for employment. It is a feature of an organization, not a function of the role of Employer. When we can show that the pattern works, then we will consider the FBC work to be done. Then their specifications can adopt that pattern.

OMG deadline of 18 May is next Monday - FIBO report going in is IND and FIGI.

FBC draft submitted in Berlin after a couple more iterations.

Proceedings

See slides from last week's call (dated 5/6/2015), which are repeated on the Draft Specification page as well.

Action items

Are there any UML diagrams for BC yet? Yes, most of them. These have been circulated over the past few weeks, in the form of slides.

Action: Elisa will put this material in the wiki.
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Browser not supported