 I'm David Newman and I'm going to share this presentation with Dennis and we're going to give you sort of a FIBO 101 to get you introduced to FIBO and what it is, where it's going. So some of the topics I'm going to cover is what is FIBO, how does it use semantic technology, why is it important to your firm and to regulators, what are some of the significant ways that FIBO can be applied now, how can FIBO be applied in the future and then the process behind FIBO, what is that, what is the methodology, how are we going to grow and evolve FIBO into the kind of broad capability to reflect the entire financial industry. And so if you ask, you know, is FIBO boiling the ocean, the answer is it absolutely is, but as Sherry said it takes a village, well it takes a whole industry to create a FIBO and that's what we're all about. So Elaine talked also about BCBS 239 as being one of the major drivers for FIBO from the regulatory point of view where we learned from bitter experience that financial organizations couldn't actually identify the risks of their own portfolios and global regulators couldn't tell the risks of the overall financial system and so there was a demand to create a common language in the industry. So besides fulfilling BCBS 239 if we take a look at many of our major processes, in this case loan origination and securitization which I picked because that ties back to the global financial crisis, not only did we discover that data was highly opaque within organizations and across the industry, but standards themselves are in many ways highly siloed and highly opaque because processes cut across horizontally many, many different standards. So we have the MISMO standard which covers borrowers and loan originators and loan investors and part of the securitization process and then going beyond that into many other phases of securitization there is no one single common standard. So the intent of FIBO is to come up with a standard that will tie together all of the other standards. So the enterprise data management council which has as its constituency many of the global financial organizations and regulatory agencies said that well we're very well positioned to lead the charge to come up with this common financial language and we're going to partner with the object management group which is a technology standardization organization and we're also going to put a stake in the ground that the standard that we're going to use to define the common language has to be upwardly compatible with the future 5, 10, 15, 20 years out and so we looked at many different conventional approaches which we discarded and we selected semantic web technology because it is the most expressive capability to define concepts. So FIBO is a system of concepts that are essentially based on the notion of contracts. So as financial instruments are based on contracts and parties to the contract have to be defined and customers are individuals or organizations that are participants with contracts through accounts. We've modeled all of this holistically in FIBO. Again the mother of all concepts in FIBO is the contract, is the agreement. So this is something that you will see throughout FIBO. So some of the organizations that participate in the FIBO effort is a list of many of the major financial organizations across the world as well as many of the key regulatory agencies that are very interested in FIBO because they are beginning to see that there really is no alternative to achieve a common language in the industry. So how does FIBO use semantic technology? Well a little bit about semantic technology. The strength of any information management paradigm is directly related to the level of expressivity of its internal model. So as we look at a linear trajectory from weak semantics up to strong semantics we can also see an evolution of looking at information from strings to a much more animated sense of objects, rich objects that are animated that have relationships with each other with rich forms of expressivity. So as we move up the stack of expressivity from relational models to XML to relational schemas to XML schemas we come to the semantic web language stack. And then even beyond that we see certain indications of other next generation semantic technologies that are even more expressive and that we're moving up this stack of expressivity. Something like the evolution of the nervous system. So we want to have that most advanced capability. So semantic technology defines concepts through the notion of an ontology. So an ontology is a way to express concepts. Take the example of corporate ownership. Now the basic elements of an ontology we can define as subjects, predicates, objects, basic statements that are linguistically aligned with how we think and speak. So a corporation owns another corporation as an example, subject, predicate, object. Now we could weave in additional concepts into the structure which we could call subclasses or sub-properties if you will. So owns greater than 50% voting shares is a kind of owns. We say it's a sub-property of owns. We can also weave in other concepts. We could say that the concept of is majority owned by is the inverse or the polar opposite of owns more than 50% voting shares. If you know one and you know the other is inversely related you could infer the other concept. So we could also insert facts or individuals into an ontology. We could say that global bank is a type of corporation, subject, predicate, object. London bank is a type of corporation. Global bank, a type of corporation, owns more than 50% voting shares of London bank. We can then use the computer to look at the rules of the ontology and draw an inference. London bank is majority owned by global bank. Global bank therefore plays the role of a parent company and London bank therefore plays the role of a subsidiary. So we could use reasoning and inference to infer relationships and conclusions that are not immediately apparent by the fundamental data. So why should FIBO be important to your firm and to regulators? So FIBO essentially will provide an underlying conceptual data scaffolding by which you can also weave in the concepts that are unique to your own organization. So it will provide that backbone of concept that's been validated across the industry so that we can have alignment on common meaning. That is the most important aspect of what an ontology like FIBO can do. It'll also help us to fulfill use cases like BCBS 239, provide a financial Rosetta Stone capability across the enterprise. Because if we have a common model, we could link in and align information that's defined in many different legacy databases that all align on common meaning, we can link that to the common model. We can also use FIBO and semantics as a way to improve regulatory compliance from a regulatory reporting point of view, reduce those MRAs. We can use also the graph of relationships to help us to better manage risk, financial risk, credit risk, market risk. And then lastly, faster time to knowledge is really what this is all about so that we could have knowledge at our fingertips that workers at an organization can get answers to their business questions immediately. Customers can have immediate answers to the information they're seeking. So a few more things on how can FIBO be applied right now. So if we look at conventional glossaries that you would find in a business enterprise glossary, we can look at this as two-dimensional. We have a label or a term and a definition. If we're lucky, we can actually have a taxonomy that's somewhat operational. So that's basically two-dimensional data. Fast forward to FIBO, semantics, and the reality of information is that it's multi-dimensional. Concepts are linked into other concepts which are linked into other concepts. What you see here is a screenshot of smart logic semaphore, which has taken in what we're calling the FIBO vocabulary, which is an extraction of our core FIBO RDF owl-based semantic model. And it's converted automatically into a form that we could drop into many vendor products like smart logic semaphore like Calibra, Abinicio, and others in order to begin to see this multi-dimensional view of concepts. As I said a little earlier, it could also provide a conceptual scaffolding for companies to extend their own information models. So with the elementary structure of FIBO, we could extend that. For example, with Wells Fargo, we would have a Wells Fargo business ontology that reuses FIBO, it imports FIBO, it reuses FIBO, and will extend FIBO with Wells Fargo's unique business definitions with its own unique DNA to create an enterprise model. And then you could extend your enterprise models with line of business models that will reuse the enterprise concepts that reuse the industry level concepts. And so you can have concepts like the definition of customer that may vary at differing levels managed and governed in one common, broadly multi-dimensional linked model. So this is also how we could begin to support a Rosetta Stone capability. So the notion that global bank owns more than 50% voting shares of London bank is unstructured information, but it means something very understandable and very similar to what we have in this example from Excel, which is very similar to this example that we show with a relational database and so on and so forth with XML or big data. We can use semantic mapping capabilities to link to this common model that we looked at a little earlier, the notion of corporate ownership. It's all the same concept from a business point of view, even though the legacy data is defined in very disparate ways. Another very major important innovation of semantics in FIBO is the ability to unify data at rest with data in motion so that we don't have this Tower of Babel syndrome that we have today. So here is an example of a derivative, an interest rate swap trade confirmation called FPML, it's an XML dialect. We can represent this XML payload in FIBO using a protocol called JSON-LD and the terminology that's in the payload is the exact same terminology that's in FIBO. It's the exact same terminology that FIBO describes a particular interest rate swap contract. So the terminology of the data in the model equals the exact terminology and meaning of the data at rest equals the exact same terminology of the data in motion. This is a big, big thing and will make a significant innovation to reducing the reconciliation hell that we take for granted today in the sense where the proverbial frog in the boiling pot, it is a pain point that we can fix and we can change. So a few more things, how can FIBO be applied in the future? So one area that we're actually working on right now is to take the meaning of concepts in FIBO and be able to represent this as semantic markup on the web. So there's an organization called schema.org. It's basically formed by the search engines, Google, Yahoo and Bing and Yandex and a few others. The goal is to take the common language of the financial industry and make it available for publicly facing websites to take the models that are in FIBO and allow this to be embedded in web pages where a machine can be able to consume the content on a web page and understand it. So Google, for example, is capturing information that's marked up semantically on web pages updating its knowledge graph so that when people enter a text string into the Google query box, they're able to get answers where we'll be able to go with this using FIBO's initiative, which we'll hear about later in another presentation, will be, for example, find the lowest 30-year home mortgage rate that ultimately I may qualify for. So it's going to open up a lot of opportunity for digital agents to be able to understand what people understand today on the web so that we'll be able to delegate so many more activities to digital agents, like applying for loans and others. The notion of blockchain, that's a massive new innovation in the field today. However, a big gap with blockchain is that there are no standards. So this is an area where we believe that FIBO can also make a tremendous impact positively by providing standards for smart contracts. Smart contracts you'll hear more about in a blockchain presentation tomorrow will allow the capability of having this notion of a distributed ledger, which you'll hear much more about tomorrow, where we can perform transactions and eliminating a lot of intermediaries today so that we could perform settlements in seconds rather than in days. So in this example where we have an interest rate swap, this can be rendered over a blockchain. And if we use a standard like FIBO, we'll be able to fulfill regulatory requirements and we'll also be able to better understand the content that's going to be expressed or anchored in the blockchain in the exact same standardized way that I've described. So we basically can leverage FIBO for helping us to make sense of information in a decentralized world, and FIBO is the answer. So let me turn this over now to Dennis to tell you actually how are we going to do this? What is the FIBO methodology? What is our rollout strategy? In addition to hats, we have an outstanding program. I think you agree, those of you who have been reading what it is, without standing speakers you've seen three of them already. And basically all the things that David talked about, there's a talk that's coming up about that. My part of this is the methodology we've been developing for the last three years since I've been part of FIBO. I began my quest with this many web technology as a Chief Technology Officer for DoD, which had exactly, that I did for five years, for business, which had exactly the same problem that the financial industry has, and that little number at the bottom right-hand corner of the spreadsheet had to be zero by putting some fudge factor in, and that wasn't the way to go. So FIBO began in 2008, Mike Bennett back there started to do FIBO along with Mike Atkin, and then David Newman came along, and I began in 2012 after I left the department. So my job has been to figure out how to deliver these FIBOs. Began in 2012, 2012, in fleshing out the FIBOs, in taking what was a business exceptional model in UML, and beginning to do FIBO in RDF-L, and it went a big way, and that's still going on. In fact, the FIBO V that David talked about, the camera, I'll mention it again in a few moments, that is a SCOS version of FIBO, which is RDFS. So it's taxonomy. It's not a true ontology, the way that we look at it, but even better than that is we can then go from an RDF-L model to a natural language listing that's like a business index that you'll be seeing. So 2013, we moved into being able to scale FIBO, which is our goal we have to achieve. So we developed a build, test, deploy, maintain methodology, much like we build airplanes in DoD, that same kind of a concept that build it, test it, deploy it, see what's wrong with it quickly, and then figure out a way to keep it going. So it's RDF-L plus ODM-based UML, that's adopted as our system of records. Everything is based upon RDF-L. So Spiral Development, I have an outstanding team, in fact, I'm gonna introduce my team to you, and I really love it when someone does something better than I could have thought about it. This was Bob and T-Garden. Bob and stand up, where are you? Not in the room? There she is, okay. So Bob and T-Garden developed this slide, which shows how we build, test, deploy, maintain. When I was in the architects of business, I would always be asked, when will your architecture be done? Never, because the business is always evolving, and this is also true with FIBO. There are 35-Bode domains, and these domains, and they're subdomains, within that there's 30 domains. You've heard about a few of them from the speakers already this morning. They change over time, and so there's a lot of interaction. So the circle goes around and around and around. We have a continuous integration spiral methodology built on the kind of technologies that you probably all use, which is GitHub for the repository, and Jenkins to test FIBO as the domains are evolving, and then Jira to manage issues, and last in confluence to enable us to do wikis. So there are about 150 people right now who have access to GitHub. Those are the true FIBO geeks, and there are about 500 who have access to the continuous process that you are using or using our wiki. So we have teams. The key team is the leadership team of FIBO, which is myself, David Newman, Mike Bennett, Mike Atkin, Mike Mariton, those are the EDM Council staff, and everyone who is ahead of one of our other teams, so our FIBO content teams, those are the people who are taking one of these domains, let's say derivatives or loans, that's Lynn Callaghan who's gonna be talking along with Mike Gushold later on this afternoon, in fact, right after lunch. This is a very simple 25 page document, and it is available on the EDM Council website, and it is what guides our delivery of all of our content with the FIBO content teams, and also proof of concepts. You're gonna hear proof of concept talk tomorrow, State Street is doing rather has done that work, so there'll be people from State Street. Is Mike Levansky here? Okay, so Mike is from Dunn and Bradstreet. So all of these teams, I think you're starting to get the idea. This is a village that's worldwide doing FIBO, it's not me, certainly it's not me, it's not me and David, not me and David and Mike Bennett, it's everybody working together, figuring out all aspects of how we're doing this together and going forward. So 2016, this is a breakout year for us. We've done the release of language and country codes, that's the LCC thing, finance and business concepts, the FBC, Indies and Indicators, Byzantines, those are OMG specs. What's already in testing now is loan, securities and derivatives, sorry, securities and equities and derivatives, and then the POCOC is the phase one derivatives that was done by Dunn and Bradstreet, State Street and Cambridge Semantics, who's also here. Cambridge Semantics, someone here from there? Yeah, back there in the back. So part of the team. 2016, we're introducing what we call four FIBO flavors. We have FIBO colors and the colors are ways of helping us keep straight the status of a FIBO. A red FIBO is a FIBO that has had not much work done on it in the last year or so. A pink FIBO is a FIBO that's in the testing process. The yellow FIBO is FIBO that's been documented and a green FIBO is one that is a OMG ratified spec. So the colors I think make sense, red, pink, yellow, green. And if you look at those colors, you can tell exactly the degree of confidence you should have in what they are. But better than that, we've had people who want to get into FIBO today. So we started an early adopter program. We hope we call it FIBO V. And that's the RDF, that's the RDFS, which is SCOS. And David mentioned FIBO.SKIMA.ORG. You'll be hearing a talk about that today as well. And FIBO Natural Language, which many vendors can already do, just ingest the RDF out and produce the English. So earlier adopter program, I'm gonna show you a picture of what that is. That's initially started by Wells Fargo, by Deutsche Bank and by Bank of New York Mellon. And there'll be two more banks added probably by the end of April. So they're taking the FIBO now and forming a super FIBO content team, if you would, focused on debt and equity bonds. And they'll be fleshing out all of the FIBOs. So the FIBO that's released in September will be some subset of all 30 of these domains. So a different departure from what we've done before. So we're on a at least quarterly release schedule going forward through 2016 and beyond. We're retiring the red FIBOs because red FIBOs are conceptual models that have been sitting, we're taking them all out now, focusing on debt and equities. And now we're calling that the baby pink. It kind of looks purple on that chart. So what happens is that the content teams take the content out of anywhere in the baby pink and they decide that they want to focus on either the system of record, all that stuff that's in the pink pink that's showing there. And they want to publish the RDFL and the FIBO in an involving OMG standard called the Semantic Integration Model for Federation. Hope I got that right. Or they want to align with fabadaskiman.org so the team that's doing that or they want to generate natural language or they want to generate SCOS. So you see the feedback loops in here and that's really the important part and that's where the tooling comes in. How do we understand what each of the teams is saying to us? But here's a model that I'll leave up there for a little while and let you kind of study it. So you see all the colors that are in there, that old ancient drum looking thing. That has the two repositories that are all both in GitHub. One of them is the baby pink. Those are all the FIBOs that are raw material, huge amount of data. And then you see the pink, the yellow and the green. If you don't know what that means, it means not tested or being tested. It means able to be released. That's the pink. And it means documented and it means OMG standard. So I use the word and advisedly because it means all of those things. So what we've had in the past is that left-hand side. The FIBO leadership team, the FIBO content teams, the FIBO vendor team, the FIBO process teams all working together to listen to what our constituency, us has been saying to ourselves and then having an automated process using Jenkins to tell us whether or not these FIBOs behave internally like using the inference engine that David said. And what happens if you put two of the domains together? So we've had that left side. We had in this picture last year the vendor part of this at the bottom, but haven't had much traction because we haven't had much for them to do. But tomorrow there's an entire vendor track here. In fact, it's two sessions. So all the vendors that are speaking are now stepping up to the plate. Many of them are joining EDM Council to be able to do with their tools what we've been doing with only a couple of tools so far. Look at the right side. What's going to happen is that we're going to publish and this will begin in September. We're going to publish not exactly in the wild like some of our members would have it, but we're gonna be publishing FIBO on the right-hand side with all the documentation that you would see if you were publishing software. This has been changed, that's been deprecated, this has been added, those kinds of things. So a FIBO with release notes. So some subset of all 30 of the domains will be published and then the fund will start because instead of having just a dozen or so people telling us what's wrong and we like to hear feedback even if we don't like what the feedback is we have to have it. We're gonna have many, many people mauled over the world telling us what they like and don't like, add this, take that out. So much like any open source project would work except this is data and this is vocabulary the banks have to depend upon. So that means an extensive amount of testing has to happen. And so that right side over there goes back and follows the very same path that we've been following here with our close team and it'll be much more input. Our intention is to use the same JIRA and the same Confluence Wiki that both of which are open to be a real, to have access to the real GitHub. We're requiring people be EDM council members but to have access to what's been published that's gonna be on an EDM website called spec.edm.org and then whatever the status of the particular ontologies are. So this is a big change for us. We have to learn how to do it. All of this is a learning process and you can see our two little owl people up there. One of those owl persons is an ontologist and on the other side are the subject matter experts or the taxonomous. These teams are required to be organized like that. And that's why we have our in-house ontologist Mike and Lisa and Dean and then other people who are the teams who some of whom are also quite advanced in understanding how ontologists work and then of course subject matter experts who provide the data, who provide the understanding of what the data really means. So we have our early adopter program for this year. If you follow those numbers there, those numbers are to do how we operate, extract from the red, which is what's happening now, into that baby pink that's over there on the right side and then look at all the colors on the left side. That's through our material that the Fibro content team for the early adopters have to work with and then they'll be fitting into the right side of that standard Fibro process. So we're treating them as users. And this is a small prototype team compared to how many people will eventually be using Fibro over the next six months. And they'll be in that standard process so that in September, our intention is to have a, who most like to call it Fibro world. David and I like that term in Manhattan, New York City. That's where most of the financial industry is. And at that time we expect to be rolling out Fibro V. But remember that Fibro V is a SCOS version of Fibro RDFL plus UML. So it's a SCOS version of the system of record. Always when there's a change, and you should have seen that in that other drum picture that I showed, all changes go back to the RDFL. So even if someone has a brilliant idea, they wanna change the SCOS. Nope, you go back and change the RDFL, generate the SCOS. That's how we'll keep all of this straight. The back of these wonderful hats say unambiguous shared meaning. And it has to be unambiguous across all of those flavors. The system of record, the Fibro V, the schema.org and the vocabulary.