2018-11-06 Meeting notes

Date

06 Nov 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.

6) For next week.

Proceedings:

20181106 FIBO DER FCT

MA introduces British Banks initiative: Build off the activities we have done with CFTC, SSC, WF. MA has put together basic strategy for how we approach this exercise, the objectives, tasks and people. This is prepared for Gary Goldberg who is on the call. MA: Now working to coordinate between groups of participants.

MA: The plan is to take 15 - 20 core concepts for IR Swaps, harmonize common meaning (with FIBO and the ISDA CDM) and then align that common meaning to bank’s systems and then generate reports that would be consistent across CFTC, EMIR and other regs. Now pulling together the banks, the FIBO team to harmonize the ontology, and derivatives SMEs to make sure the concepts are translated right into their attribute detail.

Introducing Gary Goldberg. CDO of Mizuho in Europe. Parent bank is a GSIB. GG: starting at FIMA last year, sees that not enough knowledge sharing between regulators and banks. Came up with European Banking and Regulator Forum, so get Bs and Rs together across Europe to talk about common problems. Common problem identified as regulatory reporting. BoE and FCA doing good work on trying to get data science initiatives going. Working on some prototypes with banking community. Want to get to a self executing rule book, and common codes a bank can use to execute this. What that lacks is a clear input layer that allows those benefits to be realized. See FIBO has gone a long way towards that. There is demand across the group (15 banks, 5 regs) to get a clear and unambiguous input layer, so when we add a set of attributes for reg reporting (e.g. new MiFID 2) there is a requirement for a Transaction Reporting report. This almost completely duplicated the EMIR transaction reporting report. Makes extra work. We could use those 2 reports, and CFTC reporting, together, as a prototype Take a set of attributes we can distil out of those datasets for the 15 core attributes for an IR Swap, can we get an unambiguous definition for an i/p layer. So all banks when reporting get exactly the same result. If this is so, we have demonstrated the capability of a single input layer to solve multiple parallel reporting requirements.

Long term goal is a clear unambiguous i/p layer across everything, so that banks don't need to supply multiple variations of the same data, but supply a core set of data attributes from which the reg can extract whatever information they wanted. At present the regs lack the capability to sensibly aggregate data from multiple entities because these are reporting on different bases, with different assumptions. Changes to any of this currently takes a large multi year

exercise in regulatory consultation.

EBRDF is the acronym of the body. Not to be confounded with RDF, the acronym for the underlying plumbing of the Semantic Web - a happy coincidence!

DN welcomes this. Our mission for many years has been to build a semantic harmonization layer based on a common semantic model for finance (FIBO). DN: The above initiative is a necessary alignment of the planets. Addressing the above issues using conventional tech is neither cost effective, precise nor achievable / sustainable. So we needed to do something different. We have evidence that the work we are doing will operationally hit the mark, a we have done this now at WF.

Introductions: DN chairs the FIBO initiative, from early in the FIBO days. At WF, leads team in the Innovation R&D group, with focus on the future of data. Developing operational infrastructure that leverages semantic capabilities and using FIBO a conceptual scaffolding from which a WF ontology is developed as a harmonization layer for different LoBs. Another prototype coming, to take multiple inputs of FpML and map into FIBO and bring into a semantic graph for reporting, for the collateral business activity. Likely completing Q1. have been able to ingest data from multiple LoBs and truly harmonize these, with significant reuse. So this is empirically doable. In this group, have taken the CFTC IRSwaps model, mapped to FIBO, and can create this broad based linkage and mapping.

DN: Question is how we want to demonstrate this operationally. GG: If we take this specific data model, give each bank raw data, if they can all output the same input in the same way and get the same result, then we know that the layer is completely unambiguous. GG: Example: Gave a description to some banks for apples, sometimes get kiwis, as they asked for green fruit. If we got mostly apples and some kiwis, then we know there are more attributed needed. When everyone gets the same results, we have demonstrated success.

MA: Also DN introduced us to ISDA, and they have been showing the CDM to us, and we FIBO to them. ISDA have agreed to be part of this initiative. MA now recruiting the parts of the puzzle. Banks SMEs, FIBO people and derivatives people.

MA shows the starting concepts we chose to start with, based on CFTC mapping. This is now part of the Project Plan for GG to evaluate. MA has list of folks being recruited, on the working document (on screen). Other participants to think about e.g .key Derivatives players (Barclays, CS).

MA: The FIBO folks and the derivative SMEs have agreed to put in their time. Awaits approval of GG.

MA: ISDA has done some analysis between CFTC, EMIR and MiFID 2, have done a spreadsheet comparing the terms for these, have circulated to key members of this group. This will make the job a lot easier. MA: not much else to do before project launch. Get familiar with the spreadsheet, look at the concepts and make sure they are in FIBO (which we know they are).

DN: the easiest part is the mapping. Will see commonality May be some misalignments or variations. Minimal. can offset that once we see it.

DN: Question is on the expectations to demonstrate this operationally. Limited number of vendors who do this; many ways of operationalizing it. Need to figure that out. Need to know the expectation. How to define the platform.

Have MA and GG worked through those questions? MA has been looking at the concepts, underlying attributes, checking they exist in FIBO and that SMEs can map from their systems to those concepts. That's as far as we got so far.

GG: From that point, the next conversation is to align the definitions of the attributes in those concepts - and to the regulatory reports.

DN: that part is easy and can be done in spreadsheets. The next step is harder, where we have to ingest actual data, map the concepts and generate the reports, verifying that they match. Participants may have different infrastructure and methods.

PR: Another aspect: We have talked of mapping attributes. Also need to consider mapping of objects v attributes. Differing ones between FIBO, Report etc. PR: When you are talking about relationships between organizations and trades, whether you have direct links or an indirect representation of the role of the organization in relation to the trade. These are not always obvious.

TC: There is also a separate question of granularity e.g. how you represent a trade - one row versus two rows in a database. So common representations may need a 2 for one transformation. Meanwhile PR comment was based on modeling choices.

GG: These are all questions for how we get to a common representation. Then, how the bank migrates from their legacy reports to that standard. There will be several technical avenues to get there. GG: Modeling choice e.g. legs or trade; context of a trade (heading txn, proprietary txn) and so on.

PR point is that there is more to it than simply mapping the attributes.

GG in some reg reports, they do ask for the context. For example if a txn is for a funding position. So these conflate the reference data and the context.

MB we have the means to identify context within FIBO but we don't always use these for simpler use cases. We certainly have the means for this. Some reports are the context, some ask for the context explicitly In either case the ontology needs this.

Summing up: GG: this was useful. MA leaves.

ACTION: MA and GG to agree on the MA plan or to modify the MA plan. Add milestones and obtain resource commitments.

Part 2 of the DER call - The Tree Shaker (DA)

DA: This is in response to a common request for FIBO, that when you load something in FBO you get a lot of stuff that is not relevant. DA showing PPT deck on screen. Additional notes only. Renaming this to Tree Shaker. The current Tree Shaker is not quite zealous enough. Will then talk to impact on FIBO in general, the DER effort, and ontologies in general. Today is to socialize this and identify if this is a project to take forward.

The basic issue is that Financial Dates imports rel-rel which imports things not needed by FD. PR: Tree Shaking is a well known term in Java. The principle: split the referenced items into 2 pieces, the needed piece (comprises, isIncludedIn), and the rest that are not. For FD we can split all the self contained, needed pieces. These are designated as e.g. fibo-fnd-rel-rel1. In some examples, where there is a legacy OWL import that is no longer required, this will result in no version of that ontology being included by the Tree Shaker. The unused stuff ends up in e.g. rel-rel0. AV is not recommended to be split up (this has widely used metadata for every ontology).

Questions? DN: When you e.g. split arr into arr1 arr2 and arr3, if we then have other ontologies that have prior dependencies on arr, would we then have to identify all the other ontologies that are impacted by breaking this up, make sure it is all clean. DA: Yes, that makes this more complex than it seems. Someone else who imports arr, now needs to import arr1 2 and 3, but then when you check its imports, which become arr1 2 and 3, are there things in e.g. arr2 that that ontology uses?

Note that we do not change the identity of any resource in FIBO itself. If e.g. that upstream ontology does use something in arr2, then does it use all of it? If not, then for that upstream ontology, we break it up again into arr21 arr 22 and so on. Of course, if you run this over all of FIBO, then at any point you can jump in and get any item you might need. In the tree shaken version of FIBO you get ca 700 discrete ontologies instead of 300. DA the question is whether to provide this as a separate deliverable for FIBO, or a refactoring

of FIBO itself to do once.

MG: Is this the process of formalizing encapsulation? TC: have done this for XML. Would note that you can just do it once. As people do manual edits, the dependencies will change. So this is a regular process that has to be repeated.

DA if done as a regular process, does it have to be done on the sources, or is it a new publication deliverable where people have the option to choose to use 'Fractured FIBO'. DA the refactored stuff is useful for 3rd party apps. Would come back and do it again after there are changes. Would see this as a separate deliverable in that case. MG: This seems to be a potentially valuable development tool in that it can be used to formally encapsulate concepts in FIBO. Then you get a good containment of data. From my experience in XML as well, if concepts are not well encapsulated and layered you get these cross linkages that make it impossible to look at the right components. This gives a methodology to look at the way the model is structured so that it is efficient to look at.

DA: then the question becomes how to organize the structure. MG it becomes a recursive process that modelers have to in conjunction with the development requirement. Developers become the requirement builders. This process becomes a reorg process that, once run, minimizes these dependencies. Can then go back through the modules, understand why there are so many and repackage these.

MB it sounds like something worth doing to our actual base (other than the backward compatibility issues) as it would make a better starting point (a) for redundant imports and (b) for non optimal structure per Max comment.

DN: See this as a good way to manage the file structure that is now beyond human ability. Opens the door for that. EK: Yes you are onto something. Would like to see DA determine whether there are a few top level changes we could make that (even if it meant some deprecation until FIBO 3), that would dramatically simplify the modular hierarchy, typically in FND (less so in others), if you could determine whether e.g. breaking up rel-rel as described, but only that or a couple of critical changes. Would be more interesting than creating thousands of ontologies with one class each. EK also now, with Debt in DEC, is trying to combine all these into larger ontologies. This eliminated circular dependencies.

DA: Merge things in a general way, break up in necessity way. Use as a hygiene test.

Decisions:

Action items

Michael Atkin Former user (Deleted) agree on the MA plan or to modify the MA plan. Add milestones and obtain resource commitments.