 You can use FIBO as a starting point to determine what you need to implement and then how you can actually create, in this case, I'm going to talk about creating a data warehouse to actually have all the re-information in place, but actually it's more widely applicable to all sorts of areas of support, including common services and common processes. So that's what I'm going to cover today. So, just there's a standard sort of disclaimer here because some of what I'm saying today is about what we hope to do in the future, that's what our attention is, what we don't have committed plans. So, going through what we're going to talk about today, so why it's so hard to do. Sherry talked about this a little bit, but particularly in the financial industry, the actual underlying products, financial instruments in particular, are so complicated that it is not a trivial matter to understand relationships between products, between parties involved in transactions. So enter the need for a conceptual model, so we've got to talk a little bit about that. But most of what I'm going to do today is talk about the steps you need to do using our model, in this case I'm going to describe using IBM's industry model and the tooling that we are basing it on and you can see practically how to actually create something that's needed for a requirement. And then we'll talk a little bit about futures. So this presentation is actually based on something that I delivered at IBM's conference and my good friend, Dan DiCiccio from DTCC, he's a director there of information and he's very, very passionate like I am about making sure that what we deliver is what the business really requires. It's very much informed most, very much driven by the business requirements and that it actually will stand the test of time as well. So we want to build something that we know is robust for the future. Okay, so why do we need a standard in the first place? I think most people are sold on this idea already, but I mentioned before about, you know, even if you're trying to figure out how one bank is what they owe or how they are financially indebted to another bank. It sounds like it should be easier, but it's not and that's because of the whole complexity of instruments that you might have to swap based on a derivative, based on a derivative and God only knows what's underneath all of those financial instruments at the end of it. You know, all sorts of circular roots in terms of who owns the actual products underlying that. So that's within the industry. There's also, even within the lines of business, there isn't agreement as to what to call things. So typically the wealth management part of the bank will talk about their wealth clients. The retail side of the bank will talk about their customers. So which do we use? Do we use client? Do we use customer? Do we come to a common agreement? Do we let everybody call it whatever they want? That's something that you need to figure out. Then you have the standards bodies. So if you take some of the standards that we've been looking at, Basel is a huge one obviously in the financial industry, BCBS 239, Massive, then you've got FATCA, while it's a US initiative, it says global application, everybody around the world essentially has to worry about FATCA. And then there are the local, country, central bank implementations of those global standards. So if you take even, because we've been looking at various BCBS number XYZ over the last probably about 13 years, even within one of those documents, there isn't a huge consistency in terms. That's just within Basel. And then if you take that beyond that to other initiatives, it's very hard to actually get the commonality of what's required. So what Basel says they themselves want is a simplified and replicable method of calculating exposure to risk that can be universally applied to sources of transactions that are reconcilable to accounting records. Sounds easy, doesn't it? But it's not so easy. And also we need to figure out who the parties are in various transactions, they're looking at global identification standards. So what we need is we need a standard, we need something that helps us communicate, something that helps us define exactly what a client is when we talk about clients, what a credit default swap is when we're talking about that. And we need to be able to agree as an industry. So just on this one, when we're talking about translating from one language to another, it was interesting in terms of way back probably about 12 years ago when they started doing these sort of Google Translate applications. And there was a translation application that allowed you to translate from English to Russian. And so the best way to test that out was actually take a phrase, stick it in there, get the translation in Russian, take that in a completely different alphabet, stick it back into the same engine and see what came out again. So that kind of round trip, anybody familiar with round trip testing? Okay, so they took the phrase out of sight, out of mind. Put that in, took the Russian characters out, put it back in again. And what came out was invisible idiot. So just translating isn't enough. We want to make sure that what we get is something that's meaningful and something that is correct. So look at this from the bottom up initially. So here we've got Luxe systems on the left. Who else has seen this sort of a diagram before? Hands up. Yeah, a couple of people have seen this. The technical left to right diagram, so the left is all the source systems that you're dealing with. On the right is what you want to report. Who's familiar with this sort of a situation? Yeah, lots of hands going up as well. So essentially, this is where you're doing sort of that data acquisition, finding out where you're going to find the information. You're then reconciling the numbers, making sure that it's right for the risk reports that you want, or for the treasury reports. And then you're actually distributing it to the various people that you think need that, whether that's parts of the organization, different countries that are in the bank, or to the regulator. So bottom up, it doesn't really work. It's kind of like saying you're going to build a house and you pull together all the bricks and mortars off the trucks, you start pulling it together. It's just going to be a hell of a mess when you're finished. What you need is a plan, and that's where a conceptual model comes in. Now, there are all sorts of models. There's anti-relationship models, UML models, XML. All sorts of different ways of doing it. But what we really need is to start the business. So we need a common ontology. So what's the benefit of that? First of all, the business are the key drivers here. Business get to say what they want you to build. And we can't forget about that. So unless they can understand what it is they're going to build, then you're going to build the wrong thing. It's a bit like when you want to extend your house, and there are all sorts of specialists that come in about the electrician, the builder, and so on. All the people that you need to get together to build that house, you need to make sure that somebody is overseeing that, and that's the architect. The architect can actually tell you exactly how it's going to work. So as the person that's going to be paying the bills, you need to understand that plan, you need to understand the concepts. You don't need to know all of the specifics about how the electricity works. And we want to express that logically as some sort of a model. Okay, does anybody here not know what FIBO is? Okay, so FIBO as we all know is a collaborative effort, an industry standard, and we're trying to standard the language on financial instruments and other parts of the financial business. It's also being erratified by the OMG, and it helps us to come up a level essentially from all the technicalities. So let me talk a little bit now about the IBM industry models. So there's a number of different models, and this is how we helped you to get from a conceptual model all the way to implementation. So the first thing is the FSTM, which is financial services data model. It's actually a conceptual model, even though it's called a data model. That's for historic reasons. And it basically allows you to understand the whole business, not just for regulatory reporting, but for all aspects of the business to provide an information architecture for the business. It's there really to be your friend in terms of you want to build something out, we'll hear some suggested things that you should think about it about, and here's how you can implement those. So it's a jump starter and accelerator driven from business requirements into implementation. That FSTM is a common conceptual model that's used for both data warehousing models, operational models, service models, and process models. The data is, there's a commonality in the data that we need to capture, and that's the conceptual model. Very similar to FIBO, but let's walk through an example. So you've got involved party years, anybody that you care about that you want to operate with in the bank, in the business. We've got, within that we've got organizations and individuals. Within, I just think this, can I point at this? Yes, okay. And you can specify for an organization, what, let's take this out, sorry, but the organization type is, so partnership, corporation, and so on. And there are different things that you can say about the individual, so there's some things that apply to individuals that don't apply to organizations and so on. Ultimately, the whole model is broken into nine data concepts. So everything in the model is in one of these things. There's involved parties, there's categories, which are called classifications. There are arrangements, which are basically contracts or agreements. They're the products of the bank, locations, whether they're physical locations or whether they're electronic locations. Conditions, which say what are the rules. Events, which are anything that happens. Resource item, which is anything of value. And business direction item, which is essentially any of the aims of the organization. And you can figure out, you can apply all information, it's a bit like a coin sorter, you can take all the information and you can divide that into these different concepts. So for example, individual is an involved party, who's belonging to a segment of professional married individual, which is a classification or a segment. And they open a mortgage loan, which is an arrangement, based on the underlying mortgage product. In a branch in Dublin, which is location, with a variable interest rate, which is one of the conditions. And a fixed monthly repayment, which is a repayment itself as the event that happens every month. And the collateral is based on the house, which is something of value, a resource item, which, and the product is based on a particular business strategy. So you can very quickly figure out how information is organized and what information is relevant for particular areas. Just to give you a quick overview of how that relates to the other parts of the suite, if you like. So the business vocabulary requirements capabilities, that's where the FSTM fits. If you see at the bottom here, you can see all the different uses for those models. And basically they all plug in together, essentially you can map from one to the other. Very quickly, we'll talk about some of the customers who are using that, essentially they're using that so that they can be business focused. They're using that so that they can capture the requirements in a number of different ways, but specifically from the conceptual, and they can build that and roll it out. So Jim, Ty was talking this morning about if you build it, they will come, right? So that's kind of the idea that you build it anyway. You've got great vision, you're gonna build it. But actually what this means is there's a map there for building anything you want, but because there's a blueprint there to follow, you don't have to build it all at once. You can drive this by the business requirements and build it out, bit by bit, but you know where you're going to. There's, you know, if you take the, just to talk about data warehousing, there is a data model there with like 2,000 entities, because you can focus on the business requirements, you can figure out what subset of that might be 30 or 40 entities you need for a particular purpose. So from the perspective of regulatory reporting, you can translate from the regs to the part of the model that is useful. So in terms of how this positions with the implemented architecture, which is essentially where we want to get to with this, the supportive terms, I just want to introduce some of the components of the model, supportive terms is how we map something external, like FIBO, or like FATCA, or like Basel II, like liquidity coverage ratio. That's where we hold what somebody else says about the world. And then we translate that into something that we already have in the FSTM. And from the FSTM, you can create either a common services or a common data warehouse, an enterprise data warehouse model, or an enterprise data mark. So essentially that's how it works. With the FSTM on the right hand side, you can identify which part of the models and create your warehouse table. So I'm gonna bring you through some of those now. Very quickly, if we compare the two and try to figure out why we can put them side by side, FIBO is essentially a web of information, a web of concepts. And it seems that there are other types of models that will be added to this. If you look at some of the guidance on how to map any application to FIBO, there's guidance there in terms of mapping the individual schemas to FIBO. But what we're showing here is that you can take something like FSTM, map it once to the FSTM, and that becomes your central point of reference that is used for all other areas in the business. So FSTM is a taxonomy approach, is a tree, and it's part of an integrated suite of models. So let's look at how this works. We're gonna take an example, we're gonna use that to figure out what part of the entity relationship model you need and then use that to generate data warehouse tables. So I'm gonna skip over this so far. Gonna take one of the reports from FATCA. Here's one of the reports, and we're gonna say, well, how would we approach this? So on there, there's one field, which is a name on the return, which is essentially a legal entity. So here we have, just to explain, there's a, this is in a tool that we called IGC, or Information Governance Catalog, allows us to keep a hierarchy of the information that we have in FIBO. So here you can see the domains and the ontology of FIBO, and then you can see the definition, that's straight out of FIBO. And now we can see how that relates to the FSTM, which is, okay, it's a related term. So the related terms say, well, this particular thing called legal person, which is part of FIBO, that relates to individual and legal entity. How does that relate to the data warehouse model or the EOR model? Well, that's subordinated by financial legal status and individual. So it's just taking one particular concept and seeing how that relates. So these are the steps that we need to go through. And I'll go through them one by one using this simple example of legal entity. So let's start with the FIBO ontology. Not all of it is there yet. We've just done business entities and we'd like to extend that in the future. But if you take business entities, we start to look at the regulations and what concepts are required from FIBO. And let's have a look at natural person, which is where we started with the FATCA report. So you use this as a jumping off point to now start looking at the data model. Let's see how we can implement something that supports natural person. First of all, we look at the definition. We make sure that that's exactly what we wanted for that report. The description, the definition all comes from FIBO. And then we look at how that relates to the EOR model, which we can use for our enterprise data warehouse implementation. That identifies that we need individual, one entity. Now we want to look around individuals. See what else we might want from that. So around individual, we've got things like government benefit receipt status, housing tenure type, country, what country does the individual live in. All quite relevant for FATCA. So we start to figure out, yes, those are the areas that we need. And then we refine that scope. So we look at the entity, we do this for all those related entities, and we say, well, yes, we want birth date, we want death date, we wanted the death notification date, and so on. There are a number of different elements there that we can use. Again, this is where we're using, we have the information that we could possibly use in that 2000 or thereabouts entity model, but we're using our business driver to make sure we don't take in too much information because everything that we put in scope here, we're going to actually have to find source data for that. We try to keep very much focused on why do we need this? Yes, it'd be nice to implement everything because it's like a child in a sweet shop, you want to take everything in. But we want to stay very focused on making sure we deliver on business value. So we spend a bit of time refining the scope. And then, and this is just showing an ER, a tool that this is called IDA. Essentially, then we generate the data warehouse support. So you can see some tables here and some of the SQL that you might want to generate for that. So what are we going to do next? Essentially what we've done so far, we've done with a workgroup of clients. So that's, I've mentioned Dan from DTCC, but we also had a city involved, HSBC, Deutsche Bank, and some other banks involved as well. So they get to tell us what their priorities are. What we've decided is that when we first did this, we would start with those domains that have been ratified by the OMG because then we're pretty sure that we aren't going to have to go back and redo the work we've already done. So we're trying to wait until there is a finality about it. And then we're going to start mapping them to our models. And again, every time we expand this, we're giving you the ability to go all the way to implementation for the scope that's there. So next on the slide is FIBA foundations, which we're hoping to do this year in 2016. We're also looking at things like the financial instrument global identifier, because again, it goes back to the risk that's endemic there in terms of financial instruments where you need to know all the parties that are involved in transactions and know what your overall risk is. So essentially, as a summary, we've seen the benefit of bringing FIBA to bear and to use with the FSTM and with the industry models. We've seen the work that has been done is something that we can put our arms around, that we can benefit from, that our customers can benefit from. And likewise, we think that the industry models are a great asset for people to benefit from in terms of path to implementation. And we're very much involved with the EDM council to in terms of tying these standards together. Mike was working with us on this as well. And we wanna be able to make sure as we go forward, we make this relevant for the financial industry and keep everything up to date and moving with as the standard evolves. You've been involved with your models for many, many years. There was the financial banking one, the securities one, you didn't mention the insurance one by a insurance application architecture. Is this all rolled now into a single one for the industry or is that one... There are actually five different industry models. You mentioned the banking and financial markets one. They're combined. There's a separate one for insurance. So they're still separate offerings. And we haven't brought FIBO into the insurance one yet because we thought this was the most relevant industry. But if you think that there's a requirement there, then I'm happy to talk to you about it. Let me talk about it. Okay. There's some technical reason from an IBM standpoint why it's not in there already. In the underlying model, it's in a better balance. Yeah, well, at least... So I'm offering manager for both the banking and the insurance. So they're both developed out of Dublin by the same team. So although there are differences in the models themselves, we're well set up to bring them together if we think it's a good idea. Okay. So we started with FIBO, as it is, we've seen that it has grown. So initially, and I'm not the best expert to talk about this, but initially it was very much financial instrument-based. We've seen that cover a number of different areas. What we have seen is in terms of the match with the FSTM, I mean, let's just face facts. FSTM has been around for 20 years. So right now, it's a broader coverage of the industry, but I've no doubt that FIBO will grow to cover that as well. In terms of the vertical coverage, what I've seen is that our customers are asking us questions as to how we should implement that. And that's really the whole value out of doing this work in the first place. Again, I think FIBO will probably evolve in that area as well. And we look forward to kind of discussing it together. Okay. Any other questions? Okay. It is a product. It is. Yeah. Well, let me give you my card and if you want to get in touch with me, that's absolutely fine. Thank you. Yeah. Online, please repeat the question. Okay. Sorry, there are people online, so I want to repeat the question. So essentially, if I summarize the question, it is how do you advise people who are interested in FIBO and who are also interested in the models, how they fit together? Is that fair summary? Okay. So essentially, the reason, so there is some overlap at the conceptual level. Right now, there is broader coverage of the FSTM. So in terms of financial reporting, in terms of regulatory support, if that's your use case, then FIBO is a really good starting point. There are other areas, for example, customer management, fraud detection, which I think that FIBO may not be the best fit. So it depends really on your use case for now. So essentially, if you're looking for a mature model that's been around for 20 years and how that you can use FIBO as an industry starting point, but still get to an implementation. So you don't want to create your own data warehouse. You want to use something that's been around for a number of years and that has been used in 600 different customers. Rather than figuring it out yourself and creating your own tables based on a data model, this essentially gives you a route to that. Any other questions? Okay, thank you very much for your time.