 Good afternoon. My name is Mani Kiren. This presentation is going to be slightly different than what you have seen so far. This is about practitioner's perspective. So, we decided to do an experiment as a way of learning semantic model as well as about FIBO implementation. A few years ago, we did ontology-based semi-structured data management solution. Currently, we are converting the ontology into SCOS, and it was a successful implementation. So, we are always trying to introduce some innovation in managing the data in our organization. We have been working on the enterprise data architecture almost every day-to-day activities of all enterprise data architecture only. So, we thought, since we successfully implemented ontology for semi-structured data management, why can't we push that into the structured data world? That's how this project started. So, I'm here with two of my information architects, Geekim and Preeti Sharma. Why three people for a simple presentation, 30 minutes presentation, right? This is a journey for us. We are just beginning the journey. It is going to take some time. It takes a village for a significant amount of journey. That's why we are starting like this. I'm going to start with this enterprise architecture diagram. It is a very generic diagram. You might have seen this in your own organization or somewhere else, different variations. On the left-hand side is the sourcing of the data. On the right-hand side, the consumer of the data. So, in the center, enterprise repositories. In the center place as well as the right-hand side is more focused on data. They're all data-centric applications in any organization. On the left-hand side, especially on the top, the OLTP and other applications are very process-centric applications, very important applications built to solve a particular business problem, highly optimized for that function. The process and data are very tightly interlinked. Now, that's fine, but if you want to exchange data, share the data across the organization, it becomes difficult because without the context, we can't read the data. So, there is a 90s. There is a lot of distributed database application built. That's how it exploded. Now, in the last decade and a half, when we started building enterprise data warehouse, ODS solutions, the data was trying to come to ODS and the brunt of the work was taken by ETL, the transformation, business rules, all those information. But that didn't work. It became a very expensive proposition. So, okay, transaction data can come to ODS or data warehouse. Let's build a MDM solution in the last few years to integrate the data at the context level, at the master data domain level. And then it was sent to, let's say, ODS for master data to the data warehouse, conform dimensions, class schemes, all those things. So, we thought if MDM solution is the one that is going to give the context of the transaction data, why can't you apply the ontology there to bring some smartness into MDM? There is a genesis of this particular experiment. So, what is MDM? Let me not go into the detail. This is a truth about a particular data domain like product or client or instrument. Everybody has its own, their own definition. But one thing I would like to highlight here is the semantic consistency that even Gartner defends that. So, that means if you have to bring the data from the spread sources, it has to mean this. You need to understand what the data really mean. The semantic consistency is very important. So, it is very sweet spot for us in applying the ontology. So, in any real-world problem when you build the MDM solution, the first problem we are going to see is the data silos, right? Everybody has built their own application, highly optimized, functional, process oriented. It can be based on a business line, like equity is a fixed income or organization itself, different geographic location or subsidiaries, or it can be based on your function, a trading system versus an accounting system or a marketing system. So, all those data silos have to be integrated to build the MDM. For example, a typical use case, I want to know the counterparty ID. The counterparty ID may come from multiple places. A third-party system like a Bloomberg or a back-office system or a front-office system or a trading desk all may have different IDs for the same counterparty. Also, we don't know what they mean by an ID. Do they really mean the same thing or not? So, we need to bring them, scrub them, clean them, master them. So, the problem is multiple identifier, inconsistent class scheme. All those have to be resolved at the master data management level before the data can be exchanged for downstream applications, right? So, this is one example. We don't want to go through a lot of examples, but we put all of them into three categories. One is rationalization, classification and standardization. So, rationalization is bringing data from multiple systems like trading and portfolio system, remove the redundancies and rationalize them and keep it in the MDM repository. Classification is making sure the MDM system can accommodate multiple perspective, multiple viewpoints, regulatory view versus marketing view, for example. So, we need to make sure that we capture them. Standardization is a particular legal entity may play multiple roles, may deal with multiple securities, multiple transactions. All those have to be standardized. If you don't standardize, then all the downstream system may have inconsistent way of using the same data. So, it's less usable. So, in a perfect data model world, it is really difficult to accomplish this one if you want to have a perfect data model in the traditional technologies. The expensive part of MDM is the initial phase, requirements engineering and design. And there is a disconnect between requirements engineering and design. The problem is we have data silos. That means we are talking to multiple business partners. They have their own language. So, we need to understand multiple languages and come up with a common language. We need to capture their commonalities as well as variations in our model. And then, we have to show it back to them, entity relationship diagram. And they may not understand our design either. So, unless you test the MDM system way down during development and testing, we are not really sure we captured the real knowledge or not. So, to eliminate the expensive requirements engineering, we thought let's bring ontology-based modeling technique. Easy to capture. Easy to visualize. Easy to communicate with the business. Based on the RDF and OWL technologies, there is a very good infrastructure behind it. And we thought use fiber for this. You don't have to start from scratch. Don't reinvent the wheel. Use the fiber to explain and capture the differences or customization that we need to make. That's how we started. So, this experiment or proof of concept is not about a tool, not about a particular technology, but it's a proof of concept of testing the semantic model itself, or testing the semantics portion of our business process, our business model. So, this whole presentation is about a laboratory report, you can say. So, if this laboratory report experiment is successful, then we have to do a field study. That is the journey that is going to take us along. And if we find interesting results, we'll come back to some forum to show the results. Now, I'm going to give it to G to quickly explain the proof of concept methodology. To share our experience, our PRC experience. What we did was we did the semantic testing, which means we did not perform the technical testing. So, what we did is we played with ProTigy. By playing with ProTigy, we imported fiber ontology directly into our ProTigy environment as a data model, as a complete set of data model. And we populated sample-sample data. We created sample data considering some of the business situations we encountered during our everyday life project. And we carried through that data store. So, first step is importing fiber as a data model. Here are two perspectives. First thing is we imported data model. We did not create any data model from the scratch. Instead of a collecting result requirement and defining data dictionary, data element, instead of doing that, we just imported fiber from EMD count site and then ONG site. So, definitely, we don't have a full set of ontology yet because fiber is an ongoing effort. But still, we have a very nice resource as a starting point. So, once we imported the fiber into our ProTigy environment, we could visualize it using our ProTigy plug-ins. And we could have a discussion with our potential business users and validate the model, discuss upon it. And we tried to make it more fitable to our business practice by adding new ontology, modifying it, and tweaking it. Once we did that, next step was populating sample data, creating sample data considering some of the real business situation. So, we created some named individual into that ontology as a new data instance. And we added property assertions to describe that entities. And here, we could also observe very interesting perspective. Actually, in a traditional approach, this is where we encountered all those three problems, rationalization, standardization, and classification. Because within relational database, data mastering actually means we need to sketch in all the data from the multiple silos into one certain data schema. So, during that phase, we usually lose much part of data context, data semantics. But within this approach, we don't need to do that. Because integrating data, populating data means we are adding information, new knowledge as a statement. So, we are just adding statement by statement, not losing any context. And we still have a very nice set of data. The final step is calling. One of the things which excited us very much was within this ontology world, we can use inferencing functionality. So, we choose a real query as our main calling interface. We usually combine with the Hermit original. So, we compare two approaches from the calling, one from the traditional SQL world and the other one from the inferencing world. So, to prove this really works and you can change our data modeling life, the data management practice, we brought up with some computation question. We did main testing queries that we encountered during, while we are implementing many machines reports. But for this particular presentation, I brought up some specific question which was asked by that frank act. In the financial industry, everybody knows that this regulatory regime, regulatory framework is the main driver for the master data management challenge. Whenever we come up with new regulatory regime, we need to implement new analytics, new reporting, and we need to change some of the master data management perspective. How can we see that new challenge? We saw that challenge into perspective. First one is top-down perspective. Top-down perspective means when new regulatory requirement comes in, it is asking us to answer some specific question like a total exposure situation. So, what is a total exposure to certain counterparty? When you ask this question, we need to go through all the information that we store in our database and we need to find all the relationship between them and we need to provide all the relevant information at the same time. On the other side, there is also bottom-up perspective. We have a business expanding every day. We are having new securities, new strategies, new account, new product every day. And everything is a siloed. But still, we need to combine every information into certain criteria to meet a certain regulatory requirement. So, from here, I'm going to hand this over to my colleague, British Alma, so she's going to share our observation on top-down example. Thank you, Ghee. So, I'm going to talk about the top-down example, the first competency question about the total exposure. So, before I delve down into the details of what we did in the POC, the total exposure question, why does it come like through the further, from the regulatory reporting perspective. So, after the 2008 crisis, as we know in 2010, the Dodd-Frank Act was signed and it brought in many regulatory reforms to make more transparency or to bring more transparency in the financial industry. So, one of the, or some of the common themes these regulatory reforms had was that you need to know who you're dealing with. You need to know your legal entities, your counterparties. You may be dealing with the counterparties with the same legal entity in multiple roles. That legal entity may be a security issuer, it may be a counterparty to your contract, it may be the obligor or a broker. So, they can, the same legal entity can play multiple roles. And also, you may be dealing with certain subsidiaries of a legal entity where these subsidiaries have enhanced ratings or some hidden sector classification which you're not aware of. But in order to make sure that you understand them in case they default so it should not have like a lot of negative impact on your business, you need to really understand them. So, what do you need to know about them? So, you need not only need to know who that legal entity is, what is the legal entity identifier, you also need to know what their legal or incorporate hierarchy looks like. What are their subsidiaries that you may be dealing with through your contracts through the transactions? What is their credit rating profile? What certain sectors, industries or countries they are, they may have exposure to because indirectly you would have also have the exposure to those sectors and those countries. And there are many more things that you need to know. So, when you put all these things together, it really adds to the complexity of that total exposure question. So, I'm going to go back to this particular slide that Mani had shared earlier about the reference architecture. To answer that question about the counterparty exposure, where does the data reside? So, either it would reside in your master data management systems if you have one or you will have to directly go to the source systems to get this data. Now, this data might not exist in a single source system because on the left hand side, the sources are very, very process centric. So, you may have the legal entity information itself may be coming from one system and their transactional like subsidiaries information, the brokers and counterparty information may be coming from some other systems. So, once you have identified the source systems, now you need to know within one source system which table columns does the data reside. So, you need to know the data architecture, the data model and once you have identified the table columns, now where is the semantic? What business logic do I need to write to answer that query? So, someone who is knowledgeable in the data needs to tell you the business rules so that you can write your query in a SQL query or in the PL SQL code. So, this is from a single system and if you have to now gather the data from multiple systems, it just adds to the complexity of your query. And if something on the question itself changes, then you have to come back and modify your business logic, your query rules and then get the answers. So, this is how it is done on the relational world. Now, we wanted to see how we can do it using a semantic model, the FIBO model. So, we used the FIBO ontologies and we basically used the business entity ontology and the security ontology. And we imported these ontologies in Prata J and we loaded some sample data and specifically to look at like for the business, for the legal entity question, you know, all those aspects about who the legal entity is, what are their subsidiaries, their sector classification, their domicile countries and all. So, after adding the data and using the relationships, after asserting those relationships, we could get this kind of graph where in a single graph you could see that for a legal entity like Vodafone, what are the subsidiaries, what are the countries of domiciles, what are the various sectors. And some of these were asserted relationships and some of these were inferred relationships using Prata J Reesner. So, within a single graph we could get to all the information about a legal entity. And if you have to now query like what are the subsidiaries of a particular legal entity, just writing a single line of code, you are able to do it. Another example is what is the exposure to a legal entity through a contract? So, you have a swap contract, the contract has two legs and each leg has a counterparty. So, this is what we have asserted in the model. Now, can I know because of this contract through the subsidiaries, what is my exposure to the ultimate parent or what is my exposure to the sector of those ultimate parents? So, what we did here was we introduced a new property, new object property, and we specified the business rules for that new object property. And by introducing this new object property and by running the Hermit Reesner, it was automatically inferred that for a swap contract, what is the contract ultimate party? And now the same thing, swap contract, swap legs, counterparties. And now we can, through inferencing, we can figure out what is the exposure to the ultimate counterparty. So, to summarize, we can do the counterparty question through the relational data models. We are doing it today. But, and yes, any other company would be doing it. But we just wanted to see how it would look like using the FIBO model. And it looks quite promising. So, we would continue our experiments with FIBO. And with that, I'm going to hand it over to Guy who is going to talk about the second competency question of the bottom-up approach. Thanks, Grity. Okay. So, let me go back to Baddhamma's example. So, Baddhamma's example was this. How can you rebuild, how can you reclassify existing, like a product or financial instrument to new classification scheme to meet new regulatory regime? So, here's some example. If you see this diagram, this button box, it shows us some very typical classification scheme for financial instrument. I believe many of financial companies have some of code system like that. So, when you design this classification scheme, classification like a grouping scheme, the main idea is this. We want to define this classification scheme at the most detailed level. So, we can combine this bubble into a new classification scheme with a hierarchical structure. So, we had the IRS, CDS, TRS, and the forward disruption, everything. And we believe that this should work going forward. But when that framework came into play, here, now we have a new concept, which is a cleared and unclear swap. Before then, the swap was the swap. IRS was the IRS, and the CDS was the CDS. But from now on, we need to make a business reporting saying, okay, this is IRS, but also it's a cleared swap. This is the CDS, but also not unclear swap. And what's the big deal? Why we cannot solve this problem in our traditional relational database? Actually, logically, it should not be a big deal. We can just add a new column, add new entity, and everything should work fine. But reality is actually not working in that way. Because every step of changing data model for master data is very painful. Gathering requirement, designing entity is painful. For instance, what is a cleared swap? How we can define that? Can you just add a new column to existing security master? What do we need to define central clearing house? Then what is central clearing house? Is it a new entity or is it just a subset of existing legal entity? So every step takes a lot of time, and we need to decide. And even though we finalize the design and approach, implementation itself is very painful. Because once we add new column to data of existing database, we cannot leave it as a null value. We need to go back to the old historical data, and we need to fill up the column, which means we need migration process. So for this reason, actually, this type of data model changes that never happens in the master data level. What we did is we usually implement this complex business logic to classify cleared swap and unclear swap in the presentation layer. So we can see this classification only at the business reporting. Actually, this is one of major reason why we cannot match two numbers in the tool reports, even though they are actually meaning same thing. And the worst part is actually we are getting worse and worse. Because in the financial world, we have a very different type of data producer and data consumer. When you design master data, usually that happens from the front-of-the-side, which they are introducing new securities, new contracts, new type of derivatives, and new strategies in your account every day. And when they design master data, if this meets only the requirement from accounting side, it's just a good enough to be used. But usually the data consumers are like a product controller, risk management function, or compliance. They have a very different perspective than data producer. So as long as we have this discrepancy between data produced and data consumer, we'll have this bottom up problem. Then how we could do with this ontology definition? Firstly, we introduced some of the FIBLE definition related to this concept. And then we found, just we found this, okay, until now within FIBLE, we don't have ontology for central clearing house. So we've defined it. We just defined it as a new node. And we defined that cleared swap means subset of a derivative contract, which have a central clearing house as a counterparty. And it automatically defines the concept of the cleared swap and unclear swap. And once we extend that ontology, defining new classification is also easy. All it is just we stated, definition of the new classification as your new DL query, and we registered it as a new ontology. And now we have a cleared swap. This was quite a simple experiment, but from this small set of experiments, it was good enough to show us that this can be a new opportunity in master data management. Because by leveraging FIBLE, and by accepting it as a new data model, we can reduce much part of our requirement engineering and design. So this can actually change our life as a data modeler and information architecture. However, actually we are in the very early stage of this experiment. So the remaining question is how can you build actual system, actual enterprise system out of this concept? How can you build a system which meet service level requirement for enterprise wide system? So that is the remaining question. What we did was an experiment, hands-on experiment. We acted as the business analyst. We acted as the ontologist. And we created two competency questions. And we created a simple ontology extension to FIBLE, and loaded the data, sample data, and we experimented. It is very, very promising. So in our journey, next step is going to be expand the experiment to the real-life field study, integrate our internal systems with good infrastructure like a triple store. And we need to really evaluate that. Now, are we going to integrate if the relational database are not? Load all the products, instruments, and counterparties, and do a thorough next level of proof of concept. They are a pilot project, you may say. And if that is successful, then we are going to create a solution architecture to go along with it. We still have to decide are we going to have a soft coupling or hot coupling, separate draft database or combination of the relational database, all those things we are going to evaluate. If we find anything interesting, we will come back to some forum to show. Again, we really enjoyed working with the FIBLE, and EDM Council's contribution in this area. But to extend the ontology, FIBLE, in the areas of investment management, we are willing to collaborate with you, especially in the product instrument other areas. And also, we request other partners to share the customization and implementation best practices so that we can grow together, create the knowledge together. Thank you very much. So, before a question, let me also make some comments. So, excellent presentation and excellent work, Franklin Templeton guys. Now, we are really interested in welcoming partnership, and some of the work that you have done identifying some gaps in FIBLE that there are plenty because we are still very embryonic. And so, some of the areas where it is important to fill some of those gaps is where we are looking for all of our partners to feed us information so that we can prioritize that. And we are developing a mechanism by which we can I would not say crowd source yet, but I would say that we will be accelerating and expanding the ability to feed input into the FIBLE team so that we can capture the requirements. And this will be forthcoming as we further define our methodology and capabilities to capture that input. But also, most importantly, we are looking for partners to roll up the sleeves and partner with us in many of the FIBLE content teams. So, we have one in financial business and commerce where Alisa Kendall is heading that one up and some of the areas for like clearinghouse, etc. If it is not already there, it needs to be there. Yeah, thought so. So, we got that one. But derivatives is an area where you guys have done work and we have done a lot of prototype work, which will be interesting to stay tuned tomorrow where State Street did a proof of concept in derivatives. So, we should get you guys together. So, this was really good. So, any other questions? Yes. So, we have been working in this industry for a long time. So, we understand the business processes and the business domain very well. You don't need to have a lot of knowledge of FIBLE, but you should be willing to do a jump in and start swimming by looking at the documentation and play with it. So, initially playing around with the FIBLE is the difficult thing, the first four weeks probably. It's not difficult. It is kind of sad or masochistic, right? You need to enjoy it. But the whole thing may be six weeks. Six weeks it took for us to go three of us. Okay, thank you very much. Thank you.