 Hello everybody. So yeah, I can see that there's a lot of excitement here in the audience And I have a feeling that that excitement is because we're about to talk about regulations So how many people here deal with regulations directly? Oh, wow a fair amount of you. So I hope with this talk that That For the people who don't deal with regulations that I'm going to convince you to be excited to continue not dealing with regular regulations and then for those of you who do deal with regulations that I'm going to convince you to be excited because I think maybe the most exciting thing about regulations is the prospect of not having to think about them so much and so that's really what this this talk is about and Obviously, it's about that and open source But so the question is how would you think less about regulations in one way to think less about regulations is to not have to worry about implementing them so much and Then the next question is well, how can you not worry about implementing them? And the answer to that is open reg tech and so open reg tech is a Finos special interest group and one of their focuses is How can we deliver regulations as code through open source? So, you know, we've we've done a lot of Regulations as code thought and we've done a lot of open source But bringing those two together is one of the big focuses and why would we want to do that as with any financial firm? backed kind of thing it's because it makes good business sense and it makes good business sense because It reduces the effort. It's much more efficient if we can deliver pre Understood code instead of having each bank interpret and in design and implement the code behind a regulation And then it's also less risky, which I hope to show you by opening it up and Providing different pathways of communication and collaboration with regulations so Delivering regulations is code you might think well doesn't that lock us in like if a regulation is code. We all know that code Languages technologies evolve every two or three years, etc So if we were to deliver a regulation as code doesn't that mean that we have just now We've locked ourselves into a language that is going to be obsolete in a couple years or do we have we locked ourselves into an? Execution platform that's going to be obsolete and How do we make this all future-proof and that's really a key to open source regulations is that it has to Satisfy a whole wide range of all the systems and technologies and approaches that are different firms have for dealing with regulations So we can't lock somebody into a particular technology or language And so that's where more for which is a Finnaz open-stores project comes in and the whole goal of more for is to provide A data format for sharing business logic and so you know business logic being the calculations the rules The aggregations everything that is important about your application not where it runs or what technology it runs on Or what language you use to program it? But the the actual business logic that is the key to your the reason that your application exists And so more for is that data format? And that's the key to it so we can see How would that how would that benefit us well? Regulations happens to be a great use case for for why that would be beneficial because a regulation is a big piece of code That we want to share or cause different Different industries and different systems and different companies and be able to adapt it into their systems and their data and make it work And so a little bit about the the what we're going to cover We're going to cover a particular regulation called the LCR or the US liquidity coverage ratio regulation The thing about the LCR is that it's it's nicely sized It part this came out of the special interest group You know in discussing what we would use to as a first case The LCR was suggested because it's it's nicely sized It's it's complex enough to be meaningful, but it's easily understood as well And it's not competitive, which is a big key So if if we open source this we're not giving away anybody's competitive advantage And we can really understand what it means to collaborate an open source on a regulation And so the key to the LCR is that what it does is it takes cash flows all kinds of cash flows Into different groups and it categorizes those into different groups or buckets And then it applies a haircut to those based on the groups and then it aggregates all that stuff up And then from those aggregations it takes those results and applies some math on it to come up with a ratio Because the whole thing in the end is one number. It's a ratio. So we've got Categorization and rules we've got aggregation and then we've got math all mixed in to one one application One key to while we go through all this that one of the pillars of or actually three of the pillars of open-reg tech That first of all we need to get it correct. That is the primary thing that we want to do We don't want to send out a bad regulation and have everybody, you know do it wrong With that effort to get correctness is where the collaboration comes in, right? And so all that collaborative effort leads into the correctness and then with the collaboration comes agility And it goes around in a circle in a big cycle. So we want to we want this big cycle This is what we're aiming for in this whole thing and the whole effort And this ugly slide, this is my ugliest slide of the presentation this ugly slide is really to remind me to Stop talking about what we're doing and actually start showing you With some real proof so Let's take a look at the regulation the LCR. So this is one of the documents that defines the LCR And you can see that it's actually a pretty nicely structured Specification for an application it starts out with some definitions of the business concepts that are used in here And you can drill into here and see that it actually goes into You know the the data Constraints that that go along with these business concepts So here we're saying that a currency is defined as any of the G7 ISO currencies And then it's got some rules in there about you know, if it's not an ISO currency What do you do you convert it to USD etc. So it's it's Oops didn't want to do that, but it's a nicely specified regulation and Some of it's got other bits about you know the rules and stuff But the point here is that it's laid out fairly well in a in one document here and If we go and check out the code The code actually looks a lot like the documentation here, and so everything that we just saw in Those business concepts Sorry scrolling back a bit We find in the in those field definitions we find right away in the code and if we go and say look at currency We see that you know, there's the There's the G7 precisely defined and so where you saw all that text in the the documentation That actually translates down to this small bit of code, which is pretty convenient One of the other things that the that the spec does is it gives us all the data sets that are required in order to run the thing all the fields in the data set so which is nice and convenient because as You might have guessed we can take that and convert that straight into code as well So now we've defined the data set so here we're looking at where we looked at this assets data set we're looking at the code that defines that assets data set and again it matches exactly the specification and Here's the actual calculation, which is the definition of the LCR is high quality liquid asset amount Divided by the total net cash outflows and what this is really trying to do is make sure that you have enough coming in To be able to cover 30 days of going out if there was some kind of catastrophic situation and as you can see this is all a bunch of math and It's just so it defines here's the HQ LA amount and then over here it defines Well, this is what HQ LA amount is and then it keeps drilling down and drilling down into pieces of this until it gets Finally down to the bottom here where it starts to get into the aggregation parts and this is where we see that The regulation is trying to express something in English that is actually probably better expressed in a programming language So right here, you know We're wondering, you know, they're trying to translate what's what what the concepts are but if we go into the code we can see again it matches the The regulation Pretty straightforwardly so everything we saw in that structure from the LCR to the HQ LA definition to all those sub pieces All the way down to we get to the aggregation And so we can see in this code very clearly What the aggregation is doing and it's I think personally it's a lot more clear Then what they were trying to express in that in the English version And so you might say at this point well, I don't speak code and I don't read code You know, so that's great for you, but it's not going to really help me or my users out Which is where we start leveraging the more for tools So one of the things that more for provides in its tool set is a tool that allows you to interactively Go in and look at business logic So it's it's a bit like I don't like a museum exhibit of regulation and taxation or something like that You know, if you wanted to maybe if we had one of those in a hundred years This would be an interactive exhibit where you could go in and play with the LCR and I'm sure your kids would love doing that Or I guess grandkids at this point But what we can do is so here's the LCR again now It's in in in a visualization form and we start drilling into all these things So the HQ LA amount again now we can go back and we can see here's all the drill ins to that and We can drill in even further and and see How these rules are done and drill in even further and what we're doing actually is we're drilling from the math that defines the top through the aggregations and in all the way into the categorizations and that's an important note for anybody who's designed applications because Usually or yeah, I think it's pretty typical that an application like this would be divided into lots of pieces So the the categorization might be happening often ETL in sequel code The math might be in I don't know, you know scholar or something like that And then the aggregation might be in again in sequel or in spark or something like this But what we're looking at here is the entire regulation So if you can come into this tool you can and understand the regulation through this interactive way You can understand the entire LCR And so we can see here what's going on is this is this is the bit that's actually applying the rules To a particular cash flow And so it's saying that look if to get to an asset to be a part of the rule 20 a 1c it needs to have Particular particular Value so it needs to be the product needs to be sd7 sdc 10 Etc. So I mean here's the flow chart of the rules and so anybody who's developed an application like this has probably experienced The the moment when we've released the application and we start immediately getting calls from the business about well You know, I expected this particular asset to get assigned over here, but you've bucketed it over there what's going on and What usually happens in that case is that? the the dev teams go off for Days maybe and come back with an answer and what they're doing is they're trying to piece together All the little bits of code that's scattered out across the database across the application It's like a forensics exercise where they're trying to pull all this bits of code together and understand what's going on And with this tool then we're able to to instead of doing all that we can just point them to this tool and say hey Actually, you can go in and find out exactly why that that happened You know after the fact so we can you can go in forensically with this tool and discover that hey This asset got categorized into that bucket because it matched these particular fields And so that's pretty useful And then even further we can go in and start playing with these values. So this is another part of the the Specification it's a you know a smaller example, but what this is doing is Showing that with the morpher tools you can actually go in and see how things will Basically, what if scenarios the see how things will act. So in this case, we're applying this note for about how to calculate the the return amount that we want to use in in the aggregation by going in and Actually playing with the data. So in this case we see that like we Categorize the the collateral cast cast class as G to Q Plug that in now. We see interactively that you know, we're gonna come up with this result Actually, let's let's finish it off by actually plugging in some real numbers and we see that the actual result real-time and so if we go in again and say change it to now as One Q was specified now we go, you know, we follow the the branch And so all this is generated automatically with the morpher tools from the business logic So it's guaranteed to match what's in production. This is generated from the code. That's actually executing as well. And so By deploying this you're you're deploying live documentation. That's interactive That's guaranteed to be exactly what's happening in production as well And further We can now add test cases and use this in unit testing so One of the ideas behind this whole approach is that you've got the business experts giving in rules and interpreting the rules and if we can You know, maybe sit with the business experts and code this up real quick Then give them this UI then, you know, they can be sure that we are getting capturing the rules correctly the way that they expect them to be and Once they've done that they can play around with different data values and then Save those into test cases and those become part of the unit tests and so through these tools We've now added a whole bunch of unit tests to the liquidity coverage ratio Regulation now if we go into more of the regulation, it's interesting that that this Table here is actually specifying a set of business rules And what they've basically gone and done is created their own little mini programming language in in PDF format So like we're actually supposed to know that this star means that we want to select the maturity amount as of the return result And that this hash thing here means that we ignore this field And so they've created their own little programming language at which point you kind of think well We already have programming languages. Maybe we could use a programming language that exists Which obviously is what we're doing here, but an interesting thing in here is this little tidbit here So what this is doing is categorizing a deposit into? 32 j1 4 so it's saying if we get a deposit that matches all these Fields, then we want to categorize it into 32 j1 4 until we get to this point that says oh by the way If the collateral value is less than the maturity amount Subtract that from the chart maturity amount and then categorize that into 32 h Which is like a twist that Up until now nobody expected But it doesn't leave a question is to so are we supposed to just return 32 h with the maturity amount minus the collateral value or Should we return 32 h plus 32 ji with the difference so that we have two two groupings I Don't actually know the answer So I'm going to take a poll who thinks that we should just return 32 h Raise the hands one person who thinks we should return both Wow two people and everybody else is undecided which is cool, which is cool. It's cool to be undecided Well turns out I made a guess or we made a guess and We our guess was that we would just return the one and it also turns out that our business experts went in and created some test cases and We failed the test case because actually we should go we should be returning the two and so again the interactive tools Really spit up the the process of being able to understand this and so now let's go fix this and we didn't go in live into the code And Because I didn't know I had actually written the rule but all I need to do is undocumented that I'm going to kill it the server and then recompile and run the server again and Now we can take a look now. It's returning the two values and if we go into the test cases We see that it passes So we're all good. This is what it was supposed to be So that highlights the the the interactive nature of it, but really the reason I did this was because This is also what could be happening in open source so imagine that this is an open source collaboration in a project hosted by Finos, for example and We're getting those suggestions of you know, maybe Bank X says hey you interpreted this wrong. Let me submit a PR and You know, maybe even the regulators are involved and they're like, oh, yes That was unclear. This is what we meant and then we can all collaborate on that And so what happens with regulations is that there is a feedback loop between the regulators and those being regulated but it's very slow like they give us the The specs and we go off and think about them individually and then come back with a response and then there's this whole back and forth and it's very official But imagine an open source world where we were doing that all totally out in the open so everything's clear But a lot faster through PRs through comments and through suggestions and those kinds of things And so that's basically an example of how that could be, you know We could make those changes and fixes extremely quickly and it would be very clear for everybody What was meant by that regulation? All right, now I'm going to go back to Not live stream presentation All right, so now the one thing I haven't really talked about is It's great that we've written this it's great that we've collaborated on it. How are we going to execute it? Well, one of the ways we can execute it is by leveraging more of the Finnaz ecosystem And we have a presentation later today with Goldman and legend, but basically what we've done here is that we've implemented an entire regulation in one application in morpher and What we can do is we've got those datasets that were defined You know, we know what the datasets are that we need to run this thing So we can take that information and hand that off to legend and legend can Be used to procure that data set from our on-prem systems And then we can take that and hand that off to spark and we can run that in in something like the Databricks lake house and in that way the the regulation has been defined in open source the Execution environment is in a managed service and all we need to do is plug in our on-prem numbers to This this lake house and we can do that with legend and then the whole thing just runs And so that's an interesting. I mean that shows the value of pulling all these open source things and the interesting thing is that that's all Finnaz members and it's all open source technology and You might decide that's not how you want to run it. You might want to run it internally instead And so here we highlight that with morpher It doesn't dictate either The way you write it or the way you run it the whole goal with morpher is that it's in the middle It's the way you save that business logic and store it It's not Dictating that you need to run it in a particular way and it's not dictating that you need to write it in a particular way So we could actually take that big application and split it up for execution We might say that you know that categorization phase should happen in etl in sequel And so we'll generate that out into sequel and let that run in the etl part in that aggregation phase Should really happen in spark for example, and then that calculation phase You know, that's a natural fit for a regular programming language So we can put all that math and into scala and then bind that all together so We can do that because morpher provides these tools to be able to write what we call back ends But back ends are basically transpilers or the documentation that I showed you before is a back end to write Documentation and we give tools to other to the users so that they can write their own back ends And so it's flexible in that manner And then again so morpher is in the middle and so right now if you wanted to write an application The language that I showed you before is another open-source programming language called elm and That's one of the languages that we use another language which capital one is working on Is to be able to do the same thing in scala since that's a popular language And then we've also worked with Microsoft and their boss key team to be able to compile boss key into morpher We worked we had a presentation last year where we compiled pure and legend into a morpher We did a code sprint this year with with Ragnosis for Rosetta So morpher is really aimed at general purpose. It's not just for regulations. It's really for general purpose business logic and business logic is anywhere from trading systems to to regulations and So, you know, we really aim to be that middle and allow tools to do what they do best on Either the front or the back. We don't want to own execution And we don't want to own a programming language or a particular development environment We just want to be able to piece all those things together And so that's where morpher fits in and that's what makes it agile That's where the agility comes in alright, I Have to put a picture of myself in and I figured I put it in the end because I was tired of putting it in the beginning I was going to pepper it somewhere in the middle and just see what I would do with that But I decided let me just do it at the end I do have to highlight that the the LCR was contributed To Finos by Morgan Stanley. So it is a contribution Morgan Stanley It's open source now, but but we contributed You know the majority of it I have oops work at Morgan Stanley And that's me looking thoughtfully into the future of regulation. I Usually put a much more embarrassing picture of myself, but I figured maybe not this time All right, and then the final bit is one thing about the the contribution from Morgan Stanley was that It's not complete and we had the option of making it complete or leaving it incomplete and we decided to leave it incomplete specifically so that we could See what it's like to do it in open source So what would it be like to finish this off in the open source community? So expect to see some tech sprints Announced that that you know around the Finos community coming together to finish this thing off and make it complete And we get some experience about what it means to have an open source regulation through that And then here's all the links that you might be interested in To both look at more for and to look at the open red tech in the LCR with that I Think we're done. I have two minutes two minutes for questions Okay, great question. The question was whether Real-time regulations were valuable Verses these batch regulations and yes, there are regulations that that would benefit And it's not just the regulations It's the information obviously to the firms who need to know the results of those regulations And they probably want to know that in real time in a lot of cases And again that highlights one of the advantage of getting that business logic into something like morpher is that we can project it Into a real-time system. So, you know using something like Kafka streams. Yeah. Oh Was it okay? Perfect. I'm glad I I got I Fired the gun then Yeah, so so but yeah, we can generate the the Kafka streams logic or yeah, there's not the high I mean there we we actually Talked to Hazel cast about jet and being able to do the same thing with jet So there's a lot of options for being able to do that But the key is that you're not risking Rewriting your business logic just to make your real-time It's the same business logic and it's safe. You've already proven that it's correct You're just projecting it on to a different execution environment. Oh, thank you. Oh, excellent. Thank you So for those who couldn't hear it was just pure compliments All right, thank you