 Welcome. My name is Manesh Pratel. I'm the Chief Technology Officer of Ragnosis, and today, you might have seen in the beginning, we are proud members of Finos as of last week, so that's good. So a couple of months ago, multi-organisation, multi-location team came together to attempt something ambitious. What would we help if I put the slide up? So Finos helped bring together Morgan Stanley, Microsoft and Ragnosis together, where we hacked around the clock over four different regions, four different time zones in its first-of-a-kind text print. So the text print looked to demonstrate how financial institutions can comply with trade processing for the upcoming USCFTC requirements using entirely open source components, all within three days. Given the time zone differences, the text print was held virtually. We started off in the UK Garner shift, and we ended up in the West Coast shift, so it was literally around the clock. There's code being submitted. Everything was done on Finos GitLab, so all the code is there, so if you just Google Finos Labs, there's Moffa, Ragnosis, text print, all the source code is there. And it was a print. So why is this important? So every year, the financial industry spends billions trying to comply with complex data requirements. For every reporting regime and jurisdiction, firms must sift through hundreds and hundreds of pages of legal text, then they have to manually interpret that, and then they have to code that into the IT systems. As a result, while many financial institutions share the same reporting requirements, they usually implement their logic slightly differently, and this forms fragmented technology, and that adds risk and cost. So the field is ripe for a shake-up by RekTech, the application of technology to address regular challenges. So the ability to build, execute and validate the reporting logic in an open source and technology agonistic way could be huge for the industry, and that's what we achieved as part of this text print. Let's have a look at the components. Right, so the first component is what we call digital regulatory reporting. So the industry is getting better organised at tackling this. Digital regulatory report in DRR is a programme that mutualises the cost and risk of this. It's an industry-wide initiative to address the global trade report requirements. Currently, there is a task force of multiple banks that are working on this right now, and they're due to complete the US CFTC regulation which is due by the end of the year. So this is happening, this is live, this is going to be live at the end of the year, and beyond that is going to scale to the entire G20. So this programme is geared towards production, it's happening. So the DRR involves industry participants working together to deliver an open source functional expression of the rules. So the DRR rules are expressed in a domain specific language called the Rosetta DSL. It's translated into code through an automatic process called code generation. What you're seeing on screen right now is the Rosetta platform doing just that. You have some code and then you can run it and then produce some output. So the Rosetta DSL and associate code generators are currently being processed for contribution to Finos. So those are the two open source projects developed by Ragnosis, which are being used by the DRR programme. So on top of that, the open source components, Rosetta provides a low-code collaborative platform allowing institutions to comply to regulations in a safer, cheaper and faster way, all in the open source. It's safer because industry standardises the rule interpretation and codifies it. It's cheaper as industry collaborates together to divide up their effort and it's faster as we can automate integration into our IT systems. Now that last point is all about what this text print was about, integration into firm system. So we've got the industry together, we're building the rules and this text print is about how we can integrate this into the firm systems using only open source components. Okay, so that brings us to Morfa. Morfa is a technology as part of Finos and I'll let Stephen explain more. Hi, this is Stephen Goldbaum from the Morfa project. I'm here to give some background into how Morfa fits into this collaborative effort. Morfa is a part of the Finos ecosystem and was contributed by Morgan Stanley in 2020. Projects goal is to provide a common way to share business logic. In doing so, we hope to improve the interoperability and agility across the industry. Quarter sharing business logic is being able to save it into a common format that can be shared across teams and technologies. Morfa does this with what's known as an intermediate representation or IR. Having business logic saved in this format allows teams to write tools to do useful things with it. This could include interactive UIs to help users understand what an application is doing or writing translators to execute the business logic in a variety of different technologies. This could be comparing for something like digital regulations where the goals to deliver regulations as code that can still be executed in a variety of technologies that exist across the industry. A major component of dealing with business logic is writing it. In various meetings with Finos, we recognize an opportunity to combine Rosetta's advanced rule authoring capabilities with the features of Morfa. By compiling Rosetta into Morfa's IR, we'd be able to take advantage of the best of both technologies. This was the basis for our collaborative effort. Okay, so this was an international hackathon and Stephen couldn't be here in person and we decided against doing video conferences, so we recorded everything. All right, so far what we've seen is industries come together to create the DRR programme with digitizing regulations. You've heard that those digitized regulations can be represented as business logic in Rosetta, and we've seen that Morfa is an open source Finos project where those digital business rules can be executed. Now, at the output of Morfa, you've got code. How can you trust the code? That's where Boschee comes in. It's a project for Microsoft research and it already integrates with Morfa, and I'll let Mark for Microsoft tell you the rest. The Boschee programme in language and tooling staff are a project out of Microsoft research focused on the problem of simplifying building high assurance software using formula methods and automated reasoning. This is in contrast to the current state of the art for higher assurance software development, which is heavily focused on manual processes and workflows to generate quality software. So, instead of depending on software development checklist, code review or criteria, unit test coverage, writing large test suites, and this sort of thing, we want to introduce an automated tooling suite that will allow us to automatically reason about all possible errors in your software. We will send that exist to automatically generate failing inputs to prove that certain errors can exist, or at least identify cases or whole sets of the state space where these errors are impossible. The Boschee language is the first part of this project, and it's a functional language that has an interesting block structure and local variable reassignment setup. This language is designed to be very approachable from someone coming from a Java or a C-shell per typescript background, where you have functions and integers. You can declare local variables, have control flow blocks that reassign the variables, and other sort of similar computations. So, in this case, we have a simple calculator that's doing some adds value and sign computations. Built into the language, we provide a testing framework. So, you can write classic tests like you would write today, unit tests that take no parameters, call a function of the concrete value, and just check that the result satisfies the specified property. The Boschee programming tooling stack also supports what are known as property-based tests. So, I might assert that, for all x, if x is less than zero, then calling the sign will return negative one. Now, existing property-based testing tools often use what are called phasing methods, where they just randomly generate various concrete inputs to find a counter-example for this test to fail. Boschee actually supports new extensions to the Z3 symbolic prover that was developed here at Microsoft Research that allows to prove not only for a set of concrete values or a set of hand-selected inputs that we occur in unit tests, but to prove that, for all possible integers, this implementation already satisfies the condition specified by this test, or if it fails to generate a concrete input. So, let's take a look here at how the requirement of x is greater than zero, the sign is one. Now, if we go and look at our calc implementation, we'll see that we actually have a minor case where the R is equal to zero, that the test we properly specify in the implementation diverge. So, let's see how that works by running our testing framework on a set of unit tests. We'll see that it actually can prove that, for all of the negative values, there is no possible input that violates the property specified in our test. But, for the positive value, it quickly finds the zero counter-example value that will cause that assertion to fail and violate our condition. And, of course, this works without requiring any unit test beyond just that one symbolic property test. The nice thing about the Baskier-Buisney framework is that it allows us to check not just properties that you specify in unit tests, but also to go and look at the entire application and find lots of common errors that division by a zero or underflow, unisender, arithmetic or other bounds access. So, you can run this checker on your application entirely to find any possible runtime error that would occur. And, if we look at our simple application, it checks for three possible errors, and it finds that none of them can occur on any input and reports this result as such. So, this is a really exciting possibility for us, as far as making the construction of highly assurance software very simple and very natural for today's developers. But, it also turns out that the FinTech space is a network where there's a lot of interest in highly assurance software and being able to demonstrate concretely why a given piece of software, why your confidence in a given piece of software. And, that's why it is really exciting to work with our partners at Morgan Stanley and Ragnosis on this hackathon to hook up some of the financial software that they're building to our checker backend to allow them to take advantage of this machine area that we've built. Okay, so that last part is the most important. It's about checking the software. So, what we've seen so far are the different components. You have digital directory reporting. You represent your logic. You have Rosetta, where the logic is digitised. You have Morpha, where that digitised logic is made executable. And then, once you have executable logic, you don't actually have to write the boski. The boski automatically, the testing framework, tells you whether it's right or wrong. Shows you all the inputs that you could possibly give that would break it. So, now you have software that you can trust. Okay, so bringing it all together. So, digital directory reporting is written using the Rosetta platform. So, those two work together. Morpha being an open source Finos project already works with boski. So, the two projects have already integrated together. So, the main objective of this text print was to develop a Rosetta to Morpha code generator. This would demonstrate that Morpha can be used to execute the rules represented in DRR that the industry is currently writing. So, the text print focus on two rules. So, these are real rules as part of the CFTC deliverable fuels by the end of the year. They were the trade date and event timestamps. So, we built a prototype that you could upload data in the format that is represented in DRR and execute the rules against Morpha and produce output and then put it in a tabular format. So, everything was done automatically. The hard part was writing the Rosetta to Morpha code generator and once that component was ready, the entire executable platform was generated within seconds. So, it was a really good plan. It came together really well and all of this was done within just a few days. So, the prototype proves that the digital regulations that are represented in the Rosetta DSL as part of the DRR program can be executed with Morpha and then the code assurance can be run using Boski. So, now all these components fit together, there's another advantage. We can make use of all the integrations that come with, for example, Morpha because it's all in the open source. So, Attila now is going to tell us about some of the tools that you can use as part of Morpha. Hi, my name is Attila Mihae. I'm a co-creator of Morpha and I'm here to give you a little demonstration of the various tools that we used during this text print. So, as Minash already mentioned, the Ragnosys team started by creating a transpiler that takes Rosetta source files and produces Elm source files. So, the next thing we did was used our Morpha Realm Mi command to turn those Elm sources into the Morpha IR. The Morpha IR is a language-independent representation of the domain model and business logic and we store that in a JSON format. It's the central integration point for the Morpha platform. All the tools either produce Morpha IR or consume Morpha IR. So, at this point, since we have the IR, we could turn that into any execution technology that we support, for example, running in Scala or TypeScript. But we have this unique capability where we can test our business logic and make sure that it does what we expect even before we decide on the final execution environment. So, we have two specifically to support that, could Morpha Elm develop. So, let me run that right now. That starts off a web server that serves a web UI that looks like this. It allows you to browse the IR. It shows you a graph of the various types and functions. But if you want to test a specific function, you can select that in this tree here. Let me just make it bigger and show you what it does. So, it basically, just by looking at the IR, it figured out all the inputs for the function. It knows exactly what are the possible inputs. I could start typing them in, but instead of doing that, I'll just go with a previously saved test case. So, I clicked on it and the editors got immediately populated. And what's exciting is that it also highlighted the execution path in this decision tree. So, not only that you see the actual output that was produced for these inputs, but you can also see how the execution flowed through, which is really useful for the business user to understand if the business logic behaves as expected. And what's important is that this is actually how it will be executed in the system. This is not just some visualisation that somebody created. This was auto-generated from the actual specification of the business logic. And of course, you can play around with it if you choose a different input. You can see that that follows the path that is expected. And if it is, then you can save it as a test case and then build up a whole test suite of various test cases. And then, of course, you can integrate this into your build pipeline as well. So, once you're satisfied with the business logic, you can actually go back and run one of our backends on core generators. So, I'm going to do that right now. So, you can see that it generated a bunch of Scala files. It did Scala because a default one is Scala if you don't specify what language you want. And so, now you're ready to integrate your validated business logic into the system that you want to integrate into it. And that's it. Thank you. Okay. So, takeaways and next steps. So, one of the most interesting takeaways on TechSprint was its task force format. So, I didn't really know a lot of people from the hackathon. We came together within just three days. We all became friends and we collaborated together and produced something that we never thought we didn't have at the beginning. So, this could serve as a blueprint for Finos to serve innovation. So, collaboration enabled innovation. The technologies and teams worked together and proved that the whole is greater than the sum of the parts. The Rosetta Timor for Code Generator delivered in TechSprint is going to be included in the formal open source contribution to Finos. So, this is all going to make its way into production code. And finally, this will create the first bridge between the ongoing DRI industry program and the wider Finos community. So, you may have heard that there is a special interest, there's a SIGS, special interest group for innovation for regulation that is part of Finos. So, this will bridge the gap between that group and what's going on in the wider community. We did a small part of the regulation. We only have three days to do it, but now is the next part. So, we're going to take that and we're going to scale it up to the whole thing. So, by the end of the year, what we plan to have with Morfa is an end-to-end solution where you can take the digital rules and execute it all the way through using the Morfa platform. The potential benefits for open collaboration in the registry space are massive. And this textbook demonstrates how new ground can be broken when the barriers are taken down. And here's some final words for Mark from Microsoft. This hackathon was a lot of fun for me personally because I got to work with two great companies and teams literally could distribute it around the world. And we saw this proof of concept come together very quickly that I think did a great job of illustrating the potential value that automated software validation could have in the financial services industry. It also really inspired me to continue working on this core vision of Boski around high assurance software development, but also illustrated the value of collaborating in open source and the ability to build a community there. And I'd really like to continue to collaborate with the entire FinTech industry in that space and hopefully bring some really exciting technology to the general availability. Cool. So that's what it was. This hackathon, this text print, was building collaboration between three different technologies that had never worked together before and producing an end-to-end very quickly and making a blueprint so that we can take this scale forward and actually create a full open source solution. Thank you. Any questions? Okay. Well, I'm available. So I'll be around. Please come grab me if you want to learn more. All the source code that we developed is all on GitHub. It's on Finos Labs and it will shortly be part of Finos. Hopefully, fingers crossed once the contribution goes through. So, yeah. Thank you very much. Oh, gone. Okay. So the digital actually reporting program is a consortium of pretty much most of the large banking institutions. They've come together under the ISDA banner, so ISDA bought them together, but then that's expanded out to ISLA and ICMA as well, so the trade associations. And they're chairing the group of banks that are digitised. So every week there's meetings and there's a governance layer. They're all digitising it using Rosetta in order to create their digitised regulations. The regulators themselves are observing this very closely. As you know, regulators don't tend to bless implementations. That's not what they do yet. But the idea is if we create open standards, show collaboration, then introduce and get the regulators to the table, then one day I believe the two things will meet up. But they're very much aware of what's going on. So, yeah, we've worked with a number of regulators and every regulator sees a ton of value in this. So, yeah, they're watching this very closely. And the main takeaway is that it's the actual industry is coming together and building the rules. So there's two models. Either the regulators mandate to everyone, here's how to do it, it's not going to happen. Or the industry comes together and creates an open standard and then the regulators, rather than adopter, they accept it. So it gives a nod to it. And that's what's happening right now. And the rules are right, three minutes. The rules right now are, like I said, the CFTC regulations are new regulations coming online at the end of the year for the US. That's expanding to the G20. So we estimate there's going to be over 100 reports over the next three or four years that are digitised in this manner. Great. Thank you very much.