 Hello, everyone, and welcome. My name is Eric Franson. We would like to thank you today for joining us for this webinar, a production of Dataversity with our speaker, Mike Bennett, of EDMC. Today, Mike will be discussing a semantic solution for financial regulatory compliance. Just a few quick points to get us started. Due to the large number of people that we expect on these sessions, you will be muted during the webinar. We will be collecting questions from you in the Q&A box in the bottom right-hand corner of your screen. Certainly feel free to ask those questions at any point during the presentation when they're top of mind. We will get to as many of them as we can at the end of the presentation. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and any additional information that may come up during the webinar. This webinar is part of a series. The Smart Data Webinar series takes place every second Thursday in the calendar year. So we will be doing this again on December 10th, and you can check out previous editions of this series at Dataversity.net. The newly revamped Dataversity.net. And now a few words about our speaker for today. Mike Bennett is the head of semantics and standards at the Enterprise Data Management Council and a director of HyperCube, a semantics implementation firm. Mike is the originator of the EDM Council's semantics repository, a project aimed at developing an industry consensus view and standard for financial instrument terms and definitions. Mike specializes in implementing business semantics. He has worked on a number of financial industry standards, including the Market Data Definition Language, MDDL, and has sat on several ISO committees for the ISO 20022 messaging standard, as well as chairing the Object Management Group's Finance Domain Task Force. With that, welcome, Mike Bennett. Mike, are you there? It seems that Mike may be muted. Oh, I self-muted. Can you hear me now? There you are. Hello. Apologies for that. Can you? It's my sound nice and clear. It's a bit muddy, but we can understand what you're saying. Welcome. Lovely. And thank you for the introduction, Eric. So hopefully you can all see my screen. So today I should be talking about a semantic solution for financial regulatory compliance. So basically I'll be touching on some of the regulatory requirements in finance and in particular. Oh, we seem to have lost Mike's audio, so give us just a minute to get him back on. Hello. This is Mike Bennett. Hello, Mike. Welcome back. Hi. I'm really sorry about that. My skype fell over for some reason. Okay. So just running through the agenda very quickly. I'll be giving an overview of some of the recent finance industry reporting challenges around this data aggregate. We seem to have lost Mike again. Apologies, everyone. Just a moment. I'm on a telephone now. Hopefully it won't go away. I'm really sorry about that. Nope. That's all right. Okay. So then I'll be describing a non-disruptive way. In fact, I'll be describing a couple of ways that reference ontologies can be used, including what we call a non-disruptive solution for risk data aggregation requirements using R2-RML wrappers. And then I'll focus on the kind of ontology that's required to support that and how to develop and extend from the financial industry business ontology or FIBO and some of the data strategy considerations around that. So I'll start with a slightly zen question to get you in a different frame of mind. What is the sound of one-hand clapping? We will come back to that. First, though, what happened in 2008 in the global financial crisis? So what we had was a whole lot of financial institutions with different positions or exposures in relation to one another. We had different lending positions and trades and so on. And at any given time, there's a dynamic difference between the exposures of each node in this network, each financial institution to a whole range of others. And as time goes on, particularly around 2007, 2008, we started to see that some of these start to look a little bit shaky. So that raises the question, well, if you're this institution over on the left, for example, what happens to you when something in the middle goes pop? So what are your remaining positions or exposures? So that's really, in a nutshell, the important question around the financial crisis and the subsequent efforts to better monitor and understand what's happening in the financial system. So you have this overall system, you have what we call systemic risk. But what actually happened, we might not be able to stop the next crisis, but there was a crisis within a crisis in a way in that it took quite a long time, some weeks in some cases, for different firms to identify what their exposure was to banks that had either just gone down like Lehman Brothers or were likely to go down. And it wasn't because of a shortage of data. So they have all the data in different databases and different records of what their positions are between their firm and another firm. But turning that data into actionable knowledge was the real problem, and that's what took weeks. So data isn't the problem. So in order to address this kind of question of how to improve upon systemic risk and reporting, the Basel Committee for Banking Supervision came up with a thing called BCBS239, which is a risk data aggregation reporting regime. Now, unlike a lot of regulatory reporting requirements, this doesn't set out a report and say kindly send in this report, but rather it sets out a number of principles. And the requirement is for the 30 identified firms called global systemically important banks have to comply with these principles in January 2016, not very far away. And subsequently over the next couple of years, the domestically systemically important banks will have to do the same. So this will actually have a knock on effect across the whole of the financial services industry. And there are 14 broad principles. They cover things like data governance, including the IT infrastructure itself, but also the overall management of data quality, so things like accuracy, completeness, timeliness, and so on. And interestingly also adaptability on frequency, the ability to create more reports more quickly when a financial crisis is happening. So a lot of data quality measures in the middle here and then a number of other kind of housekeeping things like supervisory measures and home host cooperation and so on. These principles will geared towards firms firstly showing and demonstrating that they have good governance over their own data assets, and secondly demonstrating that they can report on whatever the regulators require in the next crisis. So not reporting on the last crisis, but whatever comes up next that they've got the data governance infrastructure that enables them to report in a timely and accurate fashion at whatever level of detail or aggregation the data needs to be at. So that's what the principles are aimed at achieving. And there are really four overarching themes in BCBS 239. So one is the overarching governance and infrastructure, so what is the actual data governance framework and the IT infrastructure to support that. Another is the capability for providing data at different levels of aggregation and the risk reporting practices both within the firm for risk management and reporting to regulators and so on. And then finally is the overall cooperation and supervisory side of things as well. So those are the main themes. Now what does this mean for the financial firms? So really what this is doing is ensuring that financial firms have adequate infrastructure for reporting the key information that's required for risk management including the board and senior manager within the firm and thereby improve the decision making process and as part of that enhance the management of information right across different legal entities understanding the overall risk exposures as per that network of exposures that I described earlier and thereby reduce the probability and severity of losses and improve the speed at which information is available to decision makers in each firm and thereby improve their strategic planning for risk management. So this is a very far reaching but very sort of overarching kind of regulation. So the Enterprise Data Management Council have been working very closely with firms right since the beginning of when this came out and have come up with a number of interesting observations. It doesn't just affect the globally systemically important banks. The good news is that the concepts required for risk data aggregation seem to be understood the same by everyone. And one common theme that's coming out of this is the need for a common financial language. Also there's the realization of the need to move to a more of a cultural shift in how we actually do data quality management and IT governance and so on. And a lot of interesting problems under the hood like the different sources of data, you know, accounting and reporting and so on and how to get some harmonized view of all this information. So that's just a set of observations that Mike Atkin and John Bottega of the EDM Council came out with a year or so back that hasn't really changed I think. So what we're looking at is a move towards a culture of compliance, i.e. of established mature governance of data quality covering operations and quality controls and so on. And one of the things mentioned in the risk data aggregation reporting requirements is to define what you mean by a control environment. And that isn't just about taking control of data, but about the firm itself. The business stakeholders really taking control of the common language, the concepts that the business deals with, and that's what I'm going to focus on in today's talk. And essentially bringing data into the conversation if you like. It's something that needs to bring together the business and the IT side of things. So just to focus on that a little bit, I think over the years we've always had a good sense of what a control environment looks like for what we call the behavioral side of things. Applications and business processes and being able to formally manage the relationship between business and IT delivery in terms of what applications should do. What this does is put the same kind of focus on the data side of things. It's something that's been perhaps neglected over the years that we need the same level of discipline on the business oversight and management of data and data quality as we have seen up to now in application requirements and so on. So this is the data's moment in the spotlight if you were. And to reinforce that, one of the principles in BCBS 239 is principle two, which says a bank should establish integrated data taxonomies and architecture across the banking group, including information on characteristics of the data, what we call metadata, use of single identifiers, unified naming conventions, including for counter parties and customers and so on. So this isn't describing the need for a single data model. It's describing a need for taxonomies and for good metadata and essentially describing what it requires to be able to reconcile among multiple data models to elevate data to the level of business meaning essentially. So the way I look at this is that if you do all that, if you have a good governance environment covering data, you have the same kind of qualities and disciplines that we've traditionally seen with application management, you're actually going to save a lot of money, a lot of cost overruns and unknowns in integration and things like that. So the regulators are really doing the banks a favor by requiring them to do the kind of thing that actually saves money in the long term but requires some investment up front, which we've often been reluctant to do, in order to have a good data governance framework in place. Excuse me. And part of that, I just mentioned the Zackerman framework here for information architecture. I mentioned about the functional side of things. The second column here where we have a good understanding of the linkage between business process models, application architecture, system design and so on. The first column is the same kind of thing for data and this is where what we call a semantic model comes in. So in the same way you define business process to define at a business level what is the required behavior of applications. So from the data point of view, the business level describes what are the meanings of the concepts that can then be implemented in logical data models and physical data models and so on. So this whole framework, it's really just a description of best practice in that information technology space. So let's position that. We have what we call a conceptual model. So that would be a business process model in the behavioral side, semantic model on the data side of things. That business realization, that business understanding of the world is then realized in some design, some logical model or platform independent model which can then be implemented in one or more physical environments. So the conceptual model really provides what we call the language interface in business and technology. This is not something to be done by technology and parked on a shelf and never revisited. It's something that business should own and that does require a cultural change in business to take some ownership of what is happening in IT and in particular what is happening on the data side of IT by having a business understanding of the concepts that are reflected in these different databases and other resources. So this is one thing that we call a kind of conceptual model. So we're going to be describing a kind of ontology which is a kind of conceptual model. Conceptual model is anything in which the model is technology independent. So for a conceptual model for data, something like first order logic or higher orders of logic are a good thing because they are independent of any particular technology implementation and they're unambiguous. But the other thing with a conceptual model is that everything in the model represents something in the world or something in the business domain. This is not a data model. This is not a conceptual data model. It's a model of the things from which you can then derive adequate data models for things. So it provides a technology neutral view of some aspect of the problem domain including in the case of ontologies the business semantics for data. So on the basis of that and the requirement for common language across the financial industry, the financial industry business ontology was started some years ago now. It's a multi-year project sponsored by the Enterprise Data Management Council. We defined some initial straw man views of the business meanings of things that we could find in various data standards and subjected those to a long series of business subject matter expert reviews. Then we've managed to get the reference concepts for the main instrument classes and so on to a known state in terms of their subject matter expert review status. And then teamed up with a group called the Object Management Group to turn this into a series of formal standards under the OMG umbrella. For example, FIBO foundations and in fact business entities, common instrument terms and so on are going through that same process right now in the Object Management Group. So this is a suite of standards that capture the business semantics of concepts. So when you talk about a conceptual model and conceptual ontology the first question that often comes up is well that's all very well but what's it for? What can you do with it? And at one level the point of it is that it's not supposed to be a piece of technology that does something. It's a management tool for managing IT development itself. However, because of the way that we've framed the meanings of things in formal ontology terms using formal first order logic and the web ontology language, we actually have something which is a conceptual ontology but can also be put to work in various ways. And so the key for this to work correctly is that it is still a conceptual ontology. It's still a model of things in the world but it is one in which the ontology can be put to work in a couple of useful ways. So I just want to briefly explore those and then we'll go on to look a little bit at the nature of the ontology this requires. So we did a proof of concept. This is still ongoing in fact between the Enterprise Data Management Council and one U.S.-based GCIP or Globally Systemically Important Bank and Cambridge Semantics as a vendor. We took some work that we've done on swaps which is a kind of financial derivative. I showed the ability to do automated classification using the reasoning capabilities of these ontologies to take undifferentiated data about swaps and define is this a basis swap, a currency swap and so on. So extracting new information out of existing information that can help in risk management and so on. So for this proof of concept we loaded the existing ontology from FIBO, modified and extended it as you would expect to have to do in any firm for your own firm-specific concepts. Then there are a number of tools for mapping and loading data from the range of different sources into a graph store for processing. So for this POC they loaded the swap model from FIBO, mapped some data that's extracted from the bank's own system into that model, loaded all that into the solution called ANZO from Cambridge Semantics, ran automatic rules for classifying swaps and so on and created management dashboards for visualizing the data. So that was a very good indication of what you can do with what was otherwise a conceptual model but because it has those concepts you can put it to work doing something useful. Now that really helps towards things like the ability of management to get better insights into their risks and so on which is one of the key BCBS 239 requirements. But what about the reporting requirement? So there's some interesting questions. I'm not going to try and answer these questions but just mention them. If you're putting all your data into a triple store is that now the system of records? How often do you update it? How do you deal with overnight data versus real-time data? Where do you call the provenance of the data and the data lineage that has gone into that and so on? So when standing up a triple store application for extracting particular insights out of data that's not necessarily a challenge but if you're wanting to use this common language to report on data of the business itself wouldn't it be better if we could somehow use the ontology to report on the data in situ in the various systems that you've just put all this effort into creating data quality management and data lineage and so on within your existing environment. So some interesting possibilities you can do with that. So here's the initial triple store base. You have all your data extracted and transformed and loaded from different databases into your triple store and then the reference ontology which is FIBO extended with local terms can be used for creating management dashboards and other views and for reporting and so on. But with those interesting questions around the status of the triple store data and the various data management considerations around that. So an alternative to that is to use something called R2-RML. This is a standard which maps between a relational database format and a triple store based RDF format. So if you have the reference ontology and have your legacy data in the same places where it always was there's some technology available from CapCenter which allows you to map between these thereby if I go to the next slide we'll show it a bit more clearly thereby allowing you to treat the reference ontology as a virtual knowledge base. So you have semantic queries or the semantic querying language called Sparkle with which you can query against the business concepts in the reference ontology then for each data source a RDF representation of the database scheme has been created and then you have mappings between those and that means that you've got this whole range of data instead of having to interact with each data model design when building or updating queries for new reports and new forms and so on you can simply treat the reference ontology plus the wrappers as though that is a triple store with the data in it and what happens is your semantic queries get converted into conventional database queries. Now there are still applications as we've seen where having the data extracted and loaded into a graph triple store allows you to do a lot of new and interesting things in reasoning over that data, gathering new insights, creating graphs of ownership and exposures and things like that and indeed creating some of the content for these reports. So having the best of both worlds knowing when to put data in a triple store and maybe that's sort of loaded there and it's just for that application and then discarded or when to have your systems of record being what is queried for this kind of risk data aggregation reporting and in many firms just to add a bit of detail to this, those firms that have done a lot of work already on data lineage, some mature kind of data governance structures will tend to already have what we call a golden copy, a system of record for the actual data that they have the most confidence in so typically you might take the data from one data provider would be the best source for equity data and for another one will be where you get your debt data and so on and so a lot of work has gone into this kind of data lineage and metadata management to end up with a source of the truth in the existing data assets of the firm and of course there'll still be other things that are perhaps outside of that that provide extra information that's useful for reporting and for management dashboards so that's like a slightly more realistic view of what this kind of solution looks like so what you've got is the ability to create these flexible new different reports essentially the first point is showing the regulators in January that you have the kind of data governance and data lineage and the whole control environment and the ability to provide reports at different levels of aggregation and to provide different management views of risk related information or without necessarily disturbing or changing the governance framework of your existing data assets so we think that's quite a powerful proposition it's one of many things that you can do with an ontology even while it is still a conceptual model so it doesn't just sit on the shelf gathering dust so essentially then just to summarize on that side of things a reference ontology as we call it this is a single ontology that has concept representations for all the meanings that the different kinds of data in the organization will have is very much the key to semantic space reporting and querying both in terms of direct interrogation of data sources and in terms of standing up new semantic web processing applications it needs to capture all the concepts that your data might have and be able to disambiguate across a whole range of data and that requires a very different approach this is no longer a technical challenge now it requires an approach whereby you have an understanding of classification theory you have quite deep hierarchies of or taxonomies of kinds of thing so that you can disambiguate even things that are very similar in data itself like a loan product might look exactly the same in the data as a loan contract and a swap report will look exactly the same as a swap confirmation message the data is not the key to the meanings it is having this deep disambiguation between for example contracts, commitments, credit facilities, other kinds of things so to build this kind of reference ontology really means thinking about meaning so it helps to not think I wonder what the data looks like at this stage that's the problem for further down the line this is a computationally independent model of the meanings of things in the world and those meanings don't even come from data typically what it means to be a deposit taking institution isn't about some data you can immediately see it is what it says it is, it's something that takes deposits so we have to capture the meanings of things and then only later think about what data could there be that would give a clue to those meanings so what we really talk about here is almost like a different discipline this is the discipline of applied ontology essentially and it's about thinking about classification there's a particular approach we call fratative classification we'll only briefly describe that today it's about thinking of the context one might say oh we have this term called price so we know what price means well it might be the closing price of the Frankfurt exchange or it might be the price that you just bought 100 shares in IBM or something those are different concepts the different context provides very different concepts for what are often the same words so we have to get away from words we have to recognise meanings we have to apply certain principles from applied ontology to how do you create a single coherent set of unambiguous concepts which could then be shared across the organisation and that's essentially the principles behind FIBO itself but from a scope point of view of course FIBO only standardises the stuff that is applicable to all banks so within the firm you need to apply these same principles in extending it for other stuff that is unique to the bank that you're in and also there are a number of concepts for BTBS 239 that are not yet in FIBO and that you need to think about as well so a little bit of history of FIBO just to give you a sense of where it came from and then I'll talk a little bit more about the underlying principles and so on so years ago we had an initiative called the Market Data Definition Language or MDBL which provided a very nice design of an XML schema for market data although a lot of industry participants were really going oh well what we really wanted was business concepts again and this is ancient history here in the ISO 2022 universe there was a working group to provide a financial industry business information model or data model it was actually SC4 working group 11 which was a logical data model design at that time I should add here that since then the folks over at SWIFT as the Registration Authority of ISO 2022 have elevated a lot of these concepts to a very semantic level you've got some really good business semantics now in there that weren't there at the time of this history that I'm describing where we were getting again physical and logical models FPML again an excellent very well attested standard for derivatives message models but to give you an example FPML doesn't have a term called interest rate swap so you have to know in your head what an interest rate swap is in order to assemble the relevant pieces to build the right message so the conceptual model of what you need to know to build those messages seems to be what wasn't really there and what the industry participants were really asking for as we saw in the EDM Council is some common unambiguous shared meaning of these things so I won't spend much time on this but yeah we basically when you dive into some of the standards like MDDL it throws up these interesting questions about for example equity could easily be described in classes and then what I got involved was when somebody wanted to figure out what are the classes of debt and I'm quite familiar with debt instruments and so I was able to explain to them that there wasn't an answer to that question you needed to understand faceted classification of things you needed to be able to understand the difference between different meanings of the same words in different places and so on so another interesting thing back then this is before 5.0 started really there was an initiative called the investment roadmap this was maintained by a fixed protocol ISDA for FPML, ISITC, FISD, SWIFT, XBRL and they created a little chart of what all the different parts of the process were on the left here so pre-trade, trade, clearing, settlement and so on and different instrument classes and you can see that all these different instruments covered various different things and then ISO 20.022 provides messaging across all of those spaces and a good logical model for those concepts and the aim with FIBO is to cover the business concepts of those same things so all the different instruments and the terms needed for those at different points in the trade and clearing and settlement process so it could essentially break that out to three layers you've got the messaging, you've got a common understanding of the data common logical data design which has since really been elevated in many places into meaning in ISO 20.022 so this diagram is slightly out of date and you've got FIBO setting out to capture unambiguous shared meaning independent of any logical model design so the conclusion of the industry from looking at these different data modeling standards was most of these, all of these actually have exceptional design and of course good design is about working out the most elegant way of framing the data for stuff and is therefore not the same as good semantics if you had a good semantics it wouldn't be a good design and for messaging model if it's a good design it's not a semantic model there's simply different kinds of model doing different things and a lot of the knowledge that came around the table during those working group activities were real business knowledge from real business stakeholders that you then have to go and look for in meeting minutes or in the depths of some UML logical model at the time or try and use something like a data dictionary to try and define the business meanings of data elements which of course in a good design can be reused in many different ways as they should be so what the industry needed was a separate semantic standard and for that we need to recognize the concept of concepts we need to know how to recognize the concept how to abstract away from the way we see our world so in our own minds we have visual and audio inputs we see things we hear things but we conceptualize we extract away from that sensory input to the concepts themselves and the same way so does a business a business has concepts that it deals with and we have to understand and recognize those concepts and those then tend to be framed in data and so on so part of the art of creating the kind of reference ontology that I'm talking about is the art of not designing it's about detecting what are the kinds of thing in the world what distinguishes things from each other how does the business conceptualize its world which it may do very differently from the way a human conceptualizes its world for example and then finding common ways in which to represent those kinds of concepts in a reference ontology that is a single view of the meanings of things themselves so there's a couple of techniques that need to be understood for this for example I mentioned faculty classification a couple of times so let's say you have a thing the whole set of things if you like in the world the set of which everything is a member you could differentiate red things and blue things so you've got some subclasses, some kind of thing and obviously you'd apply this, you know, it could be a contract a transaction or something for each kind of thing you have ways in which you distinguish kinds of that thing but unlike a data model you don't have to do it all in a single tree kind of hierarchy you don't have to have single inheritance so you might take the same set of things and divide them into round things and square things so in an ontology this is your faculty classification a round red thing and a round blue thing you don't need to put the shapes and the colors one on top of the other you have this multiple division and then intersection of kinds of thing and so for example in derivatives you have swaps and options and forwards you also have commodities derivatives and rate derivatives and so on and there's no right or wrong order in which to use those different facets you simply have intersections of different sets of subsets of the kind of thing you're interested in that's what we call faculty classification another important part of creating this kind of reference ontology is the use of partitions now I'm not going to try and explain the partitions because that is a whole session in its own right but just to describe the way that we think about the meanings of stuff and then use these kind of partitions to distinguish them so consider this slightly lippy dog here who apart from being a talking dog is saying what if you're just a dog and not someone's pet so the sign there saying no pets the dog is like well I'm not someone's pet I'm just a dog what is the difference in meaning between a pet and a dog is a dog always a pet, is a pet always a dog how do we deal with those kind of concepts and that's where these upper ontology partitions come in it allows us to distinguish between something like a dog something like a pet which is a concept that only exists in some context and so typically you'll have data sources that are very contextual like customer data and issue a data for a security and sometimes it's the same thing behind an issue and a customer relationship and any other number of other relationships you have there's a lot of contextually specific stuff which in the individual data sources you know what the context is because you know what that database is for but in an overarching ontology we have to be able to distinguish those so we create what we call these partitions such as independent, relative, and mediating thing and that allows us to formally describe those kind of distinctions so that's one of our partitions the thing in itself is the thing in some context versus what is the context that defines that and everything that is a concept whether it's customer or counterpart or whatever falls into one of those partitions at the same time it also falls into whether it's continual or occurrence that allows us to talk about things that are only meaningful with reference to times such as corporate events and securities issuance process and so on and because of fast declassification something can be both a relative or an independent thing and a continual or an occurrence thing and also it could be either concrete or abstract so that allows us to define abstractions like goals which are very critical for risk and so on so that led us to having a number of interesting patterns high level sets of primitive concepts such as transactions the event side of transactions for things like a payment workflow the way the commitments are undertaken and discharged during transaction workflow but as whole abstract language of commitments and transactions which allows us to build out quite rich visual models of complex instruments like credit default swaps and so on so that's some of the thinking behind that and I'm nearly out of time now so just to pull that together I want to talk about what are the kinds of things you need to report on for risk and how you apply that kind of conceptual thinking to that kind of problem so risk at its most simple is probability times impact but probability of what that's where your event comes in impact of what is your goal so probability of default, loss given default are typical probabilities and impacts in financial risk for example but there's three levels of risk that regulators will ultimately be interested in there's the risk to the firm itself which is based on the goals of that firm but there are also risks like concentrations of something in different markets and overall risks to the entire financial system like one of those global system important banks start to look shaky so that means we need to apply our kind of classification thinking to four very distinct kinds of concept your basic static reference concepts which Fibre covers at the moment things like loans and bonds and equities and so on then you got terms that have a temporal basis like the current time to maturity and actually your holdings of individual positions which will have a different time to maturity tomorrow than they did today for example and variable things like credit ratings and so on and then of course all your real time stuff like pricing and yields and analytics and so on your valuations, loan to value ratios and so on and while the static terms define the commitments made in the contract and you can classify contracts according to whether they're fixed or floating rate notes different kinds of interest rates and so on you also have what really happens in the world itself the changes in behavior of market participants consequences of different changes in underlying interest rates predictions of what different market players may do next and so on so all of those different kinds of things different subsystem risk factors like the volatility of a given marketplace and so on all have implications for risk data and aggregation reporting requirements so we can anticipate that you need a conceptual ontology that fully covers and disambigurates all of this very wide range of kinds of things and classifies them accordingly so FIBO itself, we have these various you see in the middle there the contract ontologies those static reference terms we have a number of common concepts around business entities, common financial terms indices and so on and a foundations ontology for the basic semantic building blocks like commitments and so on and then coming down the line we've got things like pricing and analytics and so on and further down the line we need for reporting right now in fact positions and holdings and other real-time stuff about the bank itself so you can see the status of development of this we've got three that are in process in the OMG we've got FIBO foundations of which the pieces needed for those three are in what we call a green or complete status in the OMG and then all these others coming down the line so this slide when you get the deck you can actually click through to the different current versions of these specifications on the OMG site and get to use FIBO as a whole so what I've tried to emphasize here is conceptual ontology the kind of reference ontology you need for that kind of reporting solution though described and for being able to draw inferences from data that you hold and so on is an exercise in detecting what concepts there are we don't start with a word and wonder what it means we start with a concept and then add one or more words that you might want to use for that concept for convenience but the meaning is all in the internal logic of the ontology and the way in which things are grounded in high level simple concepts like commitment and transaction and so on so the concepts are what they are it's not an application question you don't look at an application and let that drive what concepts or how concepts are represented you simply let it drive whether you choose this or that concept in a given application so what is the sound of one hand clapping if you got into that Zen mindset of thinking about the nature of things then it's exactly the same as sound or the other hand clapping again it's a matter of having a very different way of thinking about meaning this is not a technical exercise a good reference ontology starts with the aptitude and motivation to consider these almost Zen-like questions and then when you got that all correct figure out the technology implementation side of things this may actually be a bit of a recruiting challenge because you need people who can think in terms of terminology classification theory, library science, philosophy and so on stuff that seems best tangentially if not irrelevant in technology development it's precisely the stuff that should be centre stage in building the kind of conceptual model which you can then use for risk data aggregation reporting across the whole firm so thank you very much and I'll take any questions Mike thank you so much let's go ahead and jump right into the questions our first question came in right around slide 28 or so you were talking about conceptual models at that point and the question refers to Project Actus ACTUS Project Actus tries to represent every conceivable financial contract by a standard language how far will the uniform occasion of models work into the more atomic level of financial instruments? Right excellent question and I should probably have mentioned ACTUS along the way there's so much one wants to talk about in these things I think this is slide 28 so Project Actus is based on identifying a number of particular cash flow features and classifying things according to that so I'm going to take you from slide 28 down to this facet of classification idea because for example you can have you can classify bonds according to fixed versus floating from a front office point of view then from a risk management point of view you might be more interested in is it a corporate bond or a treasury bond or a municipal bond or something so again there are multiple parallel ways that we want to classify things what ACTUS does is it classifies things around cash flow FIBO also reflects cash flow is done by a detailed analysis of the range of cash flow commitments that are described in the contracts and so unsurprisingly these come out pretty much the same as the categories in ACTUS what ACTUS then does is use those categories to feed specific risk management heuristics algorithms within a set of tools that they do so it's very, very complementary we've actually worked very closely with the ACTUS folks over the years does that answer your question? I don't know we won't find out if this attendee posts another comment the next question I think is referring to the issue of specificity the question is isn't there a legal meaning for interest rate swap if I'm reading that correctly the buried question there is how do you connect the legal meanings for things as we understand them into this sort of a model? Right, very good question and in fact the most fundamental thing about FIBO which seems to have missed along the way here is the meaning of everything is grounded in the legal realities of contract and law and accounting concepts and so on but basically what gives something its meaning is these high level primitive concepts such as commitment and obligation and rights and so on and transactions so for example transaction is always a exchange of two sets of commitments between parties for each party that commitment is an obligation of one party and a right to receive on the other by having that kind of very high level primitive language by extracting everything down to the semantically simplest possible thing those things are grounded in law and contract and as I say things like accounting as well as things like geographical and physical and so on but the legal reality is the fundamental point at which the meaning gets in if you like built up for the meaning of that so then interest rate swap is quite unambiguous it's an exchange of two commitments in which each commitment is a commitment to pay some interest stream and you then can subclassify those according to differences between the interest streams and then the whole classification question comes round to how far down do you subdivide things well that depends on what you're interested in and in the new regulatory framework the regulators might be interested in a different thing tomorrow than they were yesterday so you might have to come up with a different way of classifying things based on existing characteristics that they have so that's where the whole art of classification comes in it's actually quite a deep subject but I hope I've summarized it adequately there okay next question any thoughts on how we will manage the alignment with NIEM government sponsored or MISMO MBA sponsored standards right excellent so MISMO is the mortgage industry standard I can't remember what the S and the M and the O stand for but I mentioned at the beginning of FIBO we started off looking at some of these road map of existing standards in the securities and derivative space and as soon became clear we needed to also think about loans so we have a very active FIBO content team working on loans and they're focusing on the MISMO standard in the same way that for securities we focused on the ISO2022 and that fib in model that I mentioned to look at the concepts that are framed in a logical data model and look at each concept and say well that piece of logical data what's the real thing that it's reporting on or carrying information about what kind of real thing does it correspond to is it a credit facility or is it a loan product or is it a loan contract and so on so basically the end result of all of this work is to have the concepts that correspond to the content of those kinds of logical and physical standard in this space but we don't have to sit down and wonder what is the scope of the terms we need to cover because these standards like MISMO have already done that. We know that we've done our job when we've formally represented the meanings of all the stuff that's in those logical models. All right, the next question. Does the system imply that all the data and documents are stored in the triple store and follow on to that? In that case the reference ontology is not a virtualization federation layer like the vendor's proposal? Right, so if I go back to this slide here the aim of using these R2-RML based wrappers is that you don't have to stand up data in a triple store so all you have is the reference ontology in OWL and when you do queries against that using the Sparkle the semantic querying language it looks to the queries as though there's a triple store full of the instance data but there isn't. The data remains in its existing systems of record with all its lineage and everything else intact and by having a mapping between each of these data sources and the reference ontology you create what you might call a virtual ontology, really more a virtual knowledge base in that ontology is the schema if you like and the knowledge base is the instances. There's no extra instance data being stood up there. It's all in its existing systems of record in this solution. Okay. Sure. We have time for one final question. I'm going to challenge you with a bit of disambiguation challenge here, Mike. What is the quote unquote format of FIBO? Not RDF I suppose but XML, can FIBO be used by a search engine for example? The default format of FIBO is RDF XML. We're also looking to make it available in turtle and other formats in the future. The visuals that I showed use the underlying logic of the web ontology language and the work we've done over the last few years has been to express that our logic in RDF itself. And if you go to that where is what slide, you'll see that that points to a number of resources that are RDF out in the RDF XML dialect of RDF, but they are RDF. All right. I am sorry, we do have some more questions, but we are out of time. Thank you, Mike, for this great presentation in Q&A. I'm hosting this recorded webinar and the slides to dataversity.net within two business days and I will send out a follow-up email to all registrants to let you know how to access that material. The next smart data webinar will be on Thursday December 10th same bat time, same bat channel and our topic will be stepping into data science with Charlie Volmer for attending today's webinar. Thank you so much to our speaker, Mike Bennett and I hope all of you have a great day. Thanks, Eric.