Hello. Hi. I'm just going to give it another minute or two for people to join. And then I'll kick off. Okay, Dave, are we all set to go? Yes, we're good to go. Okay, great. Well, hello, I'm Tasha Elson, I'm the CEO at Finno's. And I'd like to thank you all for joining us this morning at our first menu summit. I hope you've enjoyed the conference so far and that you find these next sessions interesting. In my next very brief 10 minutes, I'm going to give you a little bit of an introduction to Finno's, as well as a very, very high level overview of the financial services market, and why we think there's such a great opportunity for collaboration through open source in the industry. So as I mentioned, we're Finno's the FinTech open source foundation, and we are the financial services vertical within the Linux foundation. And our aim is to help the financial services industry leverage open source software standards services and policies to solve industry challenges together, and really to innovate as well. We are a membership organization, and our 36 members of both corporate and associate members really do represent the community and the different participants in the financial services industry. We have large technology we have large banks large investment banks and technology firms both small and large, who really know financial services and open source. And we have associate members who are nonprofits, other nonprofits, government organizations academic institutions whose goals are whose our aims for the industry are aligned with ours. We have 37 active and incubating open source projects standards and special interest groups which is new for our foundation and a growing number of contributors focused on our our Finno's projects. So, it's a little bit harder than you might think to actually define financial services. It's a term that can be a little bit vague and, and quite encompassing for lots of different areas. So I've broken it down here at a very, very high level into banking investment management and insurance insurances sometimes included when people talk about financial services and sometimes not. Currently, it isn't one of our focus areas, although certainly a lot of our projects and the work that we do is applicable to that industry as well but really our core focus since our inception. At our inception was around investment banking, but we certainly are seeing that broaden as we become become a more mature foundation. So in any examples that I give in in the next few slides, I'm going to focus on investment banking, which is one part of banking there's also retail banking commercial banking and, and in each one of these categories you can drill deeper deeper deeper into specific areas and services. I'm going to focus on investment banking because that's my background, it's what I know. And certainly we do have a lot of projects that have come from that area of the bank. One other thing to mention before I move on is that this, this ecosystem gets very complicated. Different banks even will refer to these different areas with different terms and names, and they might cover parts of the banking and parts of investment management and, and really there can be a mix of the services that they provide to their end users. Within all of this you have branches and subsidiaries and counterparties. And so sometimes even doing something that seems quite simple like a single view of your client can be complicated and that can be complicated because you can have silos within within the different areas, and then even looking across areas is, it's a large amount of data to manage, which leads me to a little bit more about the volumes and the size and breadth of the industry. And again it can be difficult to actually define the value of the global financial services market but one report puts this value at $22 trillion. So that's pretty big. A few more stats is that who you'll hear about later puts the gross market value of OTC derivatives at $11.6 trillion. The BIS, the Bank for International Settlements reports that trading and FX markets in a single day last year reached $6.6 trillion. That's in one day. And also last year, the CBOE, the largest options exchange in the US had an average of 7.2 million options, options contracts traded every day. And this is just a few data points, you know, there are many, many more transactions and functions that happen, you know, including payments on the retail side, which really is a huge, huge market. And it's a critically, it's critical financial infrastructure, you know, it's recognized by governments and policymakers as a fundamental part of our economy and keeping nations running. So if we look at one of the biggest players in this, in this financial services ecosystem, it's banks, and you know, they're just in the US, the European Union, and the UK, there are more than 11,000 banks, and these banks and I'm going to use the term a little bit broadly because you can see that it actually in the European Union, they refer to them as credit institutions, the PRA, I've taken the regulated banks, building societies and credit unions to put in that number. And so those 11,000 banks employ more than 10 million people, again, just in those three markets, although they are reasonably big markets. And then to bring it down to a slightly more specific scale, something that that may be a little bit easier to grasp. We can take the example of one large bank and it does investment banking and corporate banking and retail banking as well. And they employ 250,000 people globally. And 50,000 of those people in technology. And that technology division has a budget, had a budget last year of almost 11 billion dollars. So, although they're not technology companies, a little bit, they're technology companies. And they, you know, banks have always understood that technology is important. But with recent changes, there's certainly more that they have to do to take advantage of new technology and you can, you know, that's clearly recognized by by that level of budget. So what are those 50,000 technology people in technology professionals in this one institution working on. Well, quite a lot of things in a bank, you can have anywhere from four to 7,000 applications, and those applications can be that that are developed in house so there's a lot of proprietary software, or supported maintained vendor software, and in actually open source does underpin a lot of those processes and that and those applications as well so in those, you know, thousands of applications within a single organization. And some of the, some of those those systems are meeting very specific business needs, maybe it's for the FX trading desk or the sales people are for IPOs, you know there's really a very broad range and then there's of course the levels. And underneath that of legal and compliance how you do your KYC is your AML your risk management your financial control your regulatory reporting. And then if you take it another step down there's there's common infrastructure that goes across the board to and, and things that you might not think about the corporate real estate has apps software that they need to help manage that you know the banks and the spaces that the bank uses so there are really lots of different areas and functions that they serve, and I have to move along quickly now. So what what does this all mean, you have a big complex industry that provides essential services. There are thousands of technologists working on lots of systems, many of which are solving the same business and technical problems. And what that means is huge opportunities for open source collaboration. So, you can see some of those. So anyways that the financial services industry is collaborating in our landscape which shows you all of our different projects standards and things. And today, you're going to get to hear about a few specific ones. So that's what will be happening through the rest of the presentation and at this point, I'll just hand over to my colleague, James McLeod, who's the director of community. So I can talk a little bit about what some of the challenges are that that you have as you move from, you know, internal working internally in a team and a project to an open source environment. So with that, James. So thank you very much, Tosha. And thank you everybody for being here this afternoon at the Finals mini mini summit as part of OSSE you. I'm James McLeod director of community. And this afternoon I'm going to take 20 minutes of your time to talk through the challenges opportunities of building open source communities in a highly regulated financial services industry. Thank you. Looking through the people who are actually here with us with us this afternoon I can see that, you know, we have many engineers, and we also have people who are very familiar with open source. So it's going to be, it's going to be actually very easy to, you know, communicate that we are living in a world in an instant world of open source technology, where there are products and solutions and ways of methodologies of working that you know, allow us to develop software very fast in a very agile and fast paced environment. However, within financial services. It hasn't always been like that. So from my background, as a financial services engineering leads. I know that there are many teams out there who have been working in a very linear way. So, you know, following almost like an industrial revolution production line methodology of development. You know, your stories or your features and passing them down the production line, all the way through to production, only to find that there's an issue there, and then swinging that particular feature all the way back to the beginning. However, teams are actually moving forward from that now. And I'm really pleased that I'm digital transformation and you know the move towards agile and DevOps has actually taken us to a place where teams are actually moving more fast you know we've got feature teams within banks who are actually sharing you know stories within their feature teams and working together to remove all of the blockers that slow us down from day to day. However, despite the fact that we are actually starting to deliver our features to our banking customers quicker. Moving from you know the corporate goals through the production team so all of the agile ceremonies that we actually go through all of the various different you know DevOps methodologies that we go through passing those containers through you know test uat and then live into production. We are still finding that there are engineering and team silos, forming even around those processes which do speed that team up. So even though you know we're getting, you know prioritized features coming into teams, you know those same teams are actually fixing with their defects and changes so they're coming in from you know product owners and other people. And quite often those teams are actually running the infrastructure, you know whether that's cloud or whether it's you know other form of mainframes. We're fine, you do actually find those teams are still you know very much focused on their specific tasks and on their specific projects, which means that you know we still have duplication of effort running between teams. And although we're communicating very well within our teams, communicating outside of our teams can also be limited. And quite often, you know, as we're looking at items to deliver to our customers, which are very feature and story driven, you know, sometimes we just want to get the job done and so we go through a lot of you know reinventing and re learning the will. From an industry point of view, if you take that on a global scale, and then you multiply that across all of the various different financial services, you know firms and you know companies that we have across the globe, all of those inefficient inefficiencies then get multiplied within all of the various different banks, whether it's retail whether it's investment, you know, maybe even you know FinTech firms finding, you know that they're creating inefficiencies as they start to get bigger. The problem of you know how we actually go from you know that linear process of development into DevOps and then create even more inefficient even more efficiencies out of inefficiencies still needs to be resolved. So, how do we actually do that. Believe it or not, a lot of these problems are actually solved by connecting people and teams together. So the connections between people and teams remove those silos that lead to software development inefficiencies. And so a lot of the processes and arrows and you know all of the various different technical documents that you write, you know that look like they're joining things up. It actually comes down to the human side of connecting people. Now, in order to do that it's actually relatively easy. Now you do need to bring you know your banking stakeholders along with you, you know because you know there's a lot of when you're actually changing things inside an existing structure. You know you need to make sure that the people who can advocate that change, you know are on your side. However, they don't have to be massive corporate changes, you know it can be within, you know, a couple of teams who are opposite each other. And ways in which you can do this are as simple as getting people together for lunch and learns, you know that you can actually do virtually like we're doing here today. And so you might get together as a scrum team every day to talk about your problems, but can you actually visit another team and ease drop on the problems that they're having, and then you know speak to them about how you can help them solve their problems as well. Then we also have the wider open source project meetings and also open source repositories you know across GitHub and get lab and, you know, other places where, you know, technologists and engineers hang out. And then you've also got the online wikis and online forums that you can take part in as well. And so that's ridging the gap through communication, that's not even sharing code. Then, once you actually become very familiar with that, there are also ways in which you can bring those communities together so you can push the boundaries just a little bit further, but from within the boundaries of your corporate firewalls, so you don't have to venture outside of your walls in order to do this. And that's called in a source. So in a source enables internal team collaboration within the safety of your corporate firewalls. Now this is where your infrastructure teams and all of your various different stakeholders will need to get involved because this is sharing code. This is bringing a system like GitHub inside the corporate firewalls and then opening up repositories, you know, and shared libraries for people to start collaborating and solving problems together. So in a source and GitHub, you know, within the corporate firewalls are example mechanisms that enable internal collaboration.  So once you actually become familiar with the internal workings of what you need to do in order to collaborate as a team, open source communities develop and improve software through code contributions, ideas sharing, software fixing documentation writing and continuous education, but this is on the outside of your corporate firewalls. So this is what we're actually doing today, you know, being an OSSE you were actually breaking outside of our corporate boundaries and we're coming together as a big joined up community in order to start developing and sharing ideas and learning together on the outside of our corporate firewalls. Now, as you can see through this, this document, this is where Finos actually, you know, comes into, into light. This is where a lot of, you know, the advantages of being part of an open source foundation. This, you know, here to service the open source community for financial services comes into play. We're a very diverse and with a very rich community of people across, you know, the financial services landscape. And we also have technologists, you know, who actually represent and develop a lot of the DevOps tools that we actually use in order to speed ourselves up, you know, as an engineering team. Plus, we also have technology companies, you know, who have an external perspective of how to solve engineering problems that we can actually bring into the Finos community. You know, that is an open source community to educate each other across the globe across this diverse and rich community, how to do things differently, you know how to solve those problems, how to bring that problem solving capability together. And then also, are there any projects that have been in a source to maybe from within your organization from within your financial services organization, or your technology company that would also be of benefit to other people on the outside of your corporate firewall. So take for instance, which was contributed into Finos is an example of a open source project that was actually developed by a Deutsche Bank team on the inside of Deutsche Bank, that allows engineering architects and, you know, other people in the technology area of Deutsche Bank to log and also communicate the topology of their internal architectures. The Deutsche Bank team, for example, and this is just one example of the Finos member, thought that it would be a great idea to take wards and then contribute that into open source. And so they did. And so they brought that into Finos. And then we also have NatWest markets who aren't a Finos member who are actually using wards on the inside of NatWest to architect and then log the topology of their internal infrastructure using an Apache to licensed open source project that is continuously being updated and modified between NatWest markets wards and other people who are using it. Plus then we also have, you know, special interest groups that come together in order to share ideas. And we also have project teams who are using GitHub and GitHub issues in order to communicate problems and ideas and features, you know, across, you know, the global landscape of the open source community. So I'm from the UK and Tosha is a colleague of mine in the US. And this is how Finos actually works. It bridges the gaps between teams, both within the same firm, plus also across multiple firms within the Finos membership. And so Finos supports and grows a safe and trusted open source community for the financial services industry across the financial services landscape. Now, the Finos community also bridges engineering team silos by solving common financial services technology problems from the collaborative open source vantage point. And so where in a source looks at the problems that you're trying to solve from the inside of your bank Finos and the Finos open source community does that from a global reach. So we have two projects that we actually run within Finos as part of our open source community that not only bring people together to you know talk about their problems and help solve them. You know, as we do within our special interest groups and as we do as project teams, but within Finos we're actually joining things together through all of the various different mechanisms of CI CD as people will be familiar with. Through our open developer platform, which educates financial services engineers on how to be an open source engineer using safe and controlled mechanisms of CI CD development. And so this is where the community aspect of open source and the learning and the bridging the gap between people to people. This is where the rubber hits the road, and you actually bring all of those communication skills together in the open developer platform in order to create that CI CD. You know, how do we take an idea from, you know, conception through to delivery through writing, you know, feature stories through having project meetings from being being able to build, you know, our various different projects, right through to how we actually document within the repository of our projects and then build a microsite for other people to follow, and for other people to read our project documentation. ODP brings together all of that technology that you need to be a successful engineering team with all of the various different, you know, communication that you need in order to communicate as a project team as well. We know within financial services that we need to be careful, we need to be safe, we are regulated, you know, you know, we have the watchful eye of the regulators on us. And so we also provide a project called open source readiness, which bridges the gap between how we engineer and how we deliver features with, you know, governance and the people from within side the banks who need to be, you know, safe and secure, that we're actually doing open source correctly, you know, and even people who haven't got any experience of open source can join open source readiness, because we bring speakers from across the industry into open source readiness to tell their stories of how open source has benefited them, and how open source can also benefit you, and all of the various different, you know, checkboxes that you need to go through to take your firm from not being an open source through to being an open source firm. Plus, we also talk about inner source as well because we understand that collaboration between people on the inside of the bank is just as valuable as collaboration between people and technology on the outside of the bank. So Finos being the FinTech open source foundation provides a safe place to share code and host repositories, plus provides all of the various different tools and mechanisms and people who have the experience in order to do this too. Now, once teams actually start joining Finos, and once you've crossed the threshold of, you know, joining that first call, or, you know, going to github.com forward slash Finos and finding our open source organization in github, you'll notice that we have a lot of valuable projects within our repositories that are actually there for the benefit of everybody within financial services. And also for the benefit of people, you know, who want to break into financial services as well because the Finos community actually helps people who want to become a financial services, you know, engineer, but haven't got that experience and would like to join a team. So, without focusing too much on our projects, I've just put a few examples, you know, up on screen now. So if you want to go to Finos, the Finos organization on github, you'll notice that Goldman Sachs has just contributed legends. We also have perspective for any JavaScript engineers or anybody who builds web assembly you can go in there and see how charts and graphs are actually built by the JP Morgan team. But we have cloud service certification, which we're, you know, putting a lot of energy into in order to create regulated regulatory compliant infrastructure as code across all of the main cloud infrastructures. We also have FDCP as year in AWS. And we've got people from within banks and people within technology companies, helping us with that. Plus, we also have a very active and also successful standards called FDC3, which is about passing across the trading desktop and how you actually do that as financial objects in code. So if you want to join a standard FDC3 is absolutely a community that you should get involved in it's very active and it's very popular. So drawing to the end of my talk. Hopefully, I've convinced a few people here to actually join the Finos community and give us a shot, you know, so if you are within financial services, or if you are outside of financial services, please come to Finos and get involved. And there are multiple ways in which you can do that. You can come and evaluate our software, you know, so just come and take a look at GitHub and, you know, evaluate locally. You can consume our software from GitHub as well and use it, you know, it's Apache T licensed, so you're fully entitled to do that. If you can join a project call or you can take part in any discussion through GitHub issues, you're absolutely more than welcome to do that. Then you can start contributing code back into our repositories and become, you know, a member, a contributing member of a project team. And then as you kind of grow within Finos and within that Finos project. Maybe you would like to lead one so I know that we've got some lead maintainers, you know, coming up later within the mini summit that you'll hear from. So that can be your goal to become a Finos lead maintainer. And there's a link there for you to follow as well to help you so go to HTTPS Finos.org get involved to learn how to get involved. And that brings me to the end of my talk and so feel free to come and find the community. We're on GitHub, we're on Twitter, we're on LinkedIn and go to Finos.org. And with that, I would like to hand over to Rob Underwood, Chief Development Officer of Finos for our next section. Thank you very much. Great James. Thank you so much. Appreciate, appreciate everyone being here and, you know, what a great start to the day, at least for those of us on the East Coast I know folks of you in Europe it's midday so I appreciate everyone being here. I think we have a really great panel coming up and, you know, I'd like to say, you know, for good friends now, who have been part of the journey which will touch on a little bit in terms of the sharing of legend and some of the work that we've done with, with ISDA and with Ragnosis as well. So, would I further ado I'd like to introduce our panel. So, we have four folks to from Goldman Sachs one from Ragnosis and one from ISDA so maybe we could start fee could you just maybe give a quick introduction of who you are and what you do and maybe a little bit contrasts the context that you work in with the area that Pierre does. Yeah, absolutely. So, I've been at Goldman Sachs for 10 years. And the first six years of those I actually spent supporting our derivatives businesses in their trading. And the last four years or the most recent four years I've been within our data management so looking at how we build data models for our financial data and the governance around those as well. And so sort of that distinction between myself and Pierre, looking more on sort of the business side and how we bring that business and engineering connectivity as we look to bring data models into the industry. Great. And Pierre, would you like to introduce yourself. Hi, I'm Pierre de Balin. I'm managing the data model engineering team in Goldman Sachs within data engineering. You know, compared to fee I'm more an engineer like I'm actually coding day to day manage a big team that actually work on tools like legend, but also on tools like data governance but I could also day to day and already enjoy actually programming. We're working in partnership with the business with Finnazos to make sure that we can achieve the banks goods. Great. Thank you. And Nigel from Ragnosis, would you like to say hello and maybe tell us a little bit about yourself. Yes, thank you Rob. So as Rob says I work at Ragnosis where I'm the senior data modeler with my primary responsibility being to partner with ISDA on the development of the CDM. Prior to Ragnosis I was also actually at Goldman Sachs, where I was for 20 years and worked was working with fee and set up the operations data modeling function prior to departing moving across to Ragnosis. Fantastic. And Ian, would you like to introduce yourself. Thank you. Yes. Good afternoon. Good morning, everyone. Yeah, Ian Sloyne, Director for Market Infrastructure and Technology at ISDA. Prior to that I was the AMIA lead for data and reporting, dealing with a lot of implementations and regulations. I've never worked at Goldman Sachs, but I have worked at other banks looking at technology projects, regulatory projects and always in the area of derivatives and how we represent derivatives data. I have seen you at 200 West Street so I know you've been to Goldman Sachs before so. I think I've been on a few of the offices. So for those of you who don't know, I know we've alluded to it a little bit and James mentioned it before. Legend.finnose.org. And we'll talk a little bit about it through throughout the conversation today but it is the modeling language and a modeling workbench and suite of tools that Pierre led the development of within Goldman that's now been open source into Finnose. And all of the people on the panel had a hand in the work, the pilot that we just completed and then the open sourcing effort that just concluded. And a big part of a legend is data modeling and I know Pierre will clarify some of the use of that term too but let's just jump right into it and kind of get into some of the motivations of perhaps the open sourcing of legend but also some of the larger industry issues. Just going to open this up to all four of you. What are some of the current issues with regards to data in the financial industry like why is why is there this focus why is there this discussion on data and data models and common data structures and for the functional programmers in the crowd maybe this looks like type definitions and for the object oriented programmers maybe this looks like these are like classes but whatever your your bent is why is there all this focus on data in the financial industry. Ian maybe you want to start and then then Pierre you can add a little bit and we'll turn it over to Fia Nigel from there. Yeah, I'm going to take a very high level approach because I'm from the trade association and far from any engineering background I ever had. So thinking of is the swaps and derivatives association. So we come primarily backgrounds in derivatives markets. Not everyone thinks of trading interest rate swaps when they open up their stock broker. But but huge market huge huge numbers I think Tasha called out some of the some of the statistics but you know that the interest rate swaps market is around, you know, 500 trillion US dollar notional outstanding at any time. Those those interest rate swaps tend to be, you know, of a maturity profile which means that the contracts might be in in force for many years. You know, of those of those, you know, perhaps 40 40% are kind of short dated one year. But beyond that, you know, there can be anything out to 25 years. The reason being, because these derivatives are underpinning, you know, commercial contracts but also, you know, retail mortgages and risk management over over, you know, pension funds and things like that. So to give you an idea that's the kind of the markets we're talking about. And obviously, with that managing the data for those markets, you know, you have to you have to manage the payments. You have to have to happen every every quarter every month. You know, there's many kind of obvious things to come to mind. But there's other things that that maybe the audience isn't aware of. But you can probably guess from from from the terminology, there's the exchange of margin on the back of these contracts. They have to be cleared. There's other risk management processes and finance and accounting processes that have to happen. And now I'm going to, I'm going to rip off a colleague of Barclays who has said this in public that just one interest rate swap at Barclays, in particular, they did some analysis and they found that it was stored in 15 different places just just when the trade was done within within 24 hours. And that was Dr. Lee brain to give them the kudos there for that analysis. So 15 different locations to manage a trade to his life cycle. That doesn't seem very efficient to me. But that is that is what happens today. There's high values at stake. And the chances for inefficiency and mistakes are obviously there. So how do we mitigate the problem of having the data in all those different places? Well, we've costly reconciliations. And that's how the problems have been solved in the past. True. You know, there are different ways of storing the data, different standards being used or or variations on those standards. There are other problem by reconciliations between systems and those that doesn't really have any value to the to the to the market. And to give you an idea of the cost of these businesses, the CDM project which I wrote, we set forth to a couple of years ago to produce standards for processes that happen to trade through their life cycle. And I'm quoting from a Deloitte paper, which is on the future of post trade, which I'd invite people to take a look at. But we were just sort of, and I believe these are very conservative numbers, but we believe like through the CDM and its implementation on technology, we could, we could see savings of $1.5 billion on the automation of affirmation confirmation, and processing at those processes are, you know, pretty much as they sound, you know, very basic data management processes, maybe presenting the data in a different way for illegal confirmation. It's crazy they are manual as all I would say and having been close to many of these processes in the past, it was always a frustration that we couldn't automate more. You know, and, and, you know, basically in a very laid terms, you know, it's just the case of saying is, is this your trade data is the same standard form. Do you agree to it as a client, and then can we provide it to the regulator. So, just to touch on briefly why some of the reasons for for this state of affairs. Personally it is though we wrote a letter to to the financial stability board. I ask all the international organization for securities commissions, and the Basel committee on banking supervision. And together with the other 700 trade associations. It is our commitment to moving to a digital future for financial markets, but the opening line of it really is the is the is the area and calls out kind of some of the reasons why, particularly for derivatives industry. I believe that the G 20 financial regulatory reforms which are introduced in the wake of the financial crisis about 10 years ago. And fundamentally altered the traditional operating structure of bilateral financial markets firms have implemented these regulations and associated requirements on top of existing infrastructure placing significant demands on it. And I know the reasons why we're in this state regulations but but you know in recent firms or recent years firms about to implement these things and often under a clock and a regulator's watch. But even removing that there's been a lack of golden sources of product data with some exceptions which are actually proved by why they're important. I think that's the future we're kind of aiming at and what the potential can be. So I'll pause there because that was a quite a long way into the first answer, and maybe Pierre will take sort of more of a detailed view on how he sees the problem. Yeah, well, I mean my thinking is not that far like as as you explained like a lot of parties are involved in processing financial data. And they can be found across the industry, but also within a company so it's not because you work within an organization that you're not facing exactly the same problem of having like different step of processing and different hops and different kind of environment where the information is flowing. So, so why is like that like I don't think is that artificial. I think it's because processing financial information will require and requires a lot of special skills or special systems or steps that are you know done by many actors. So, but you know like this graph that you know is not artificial. We have to deal with it. And we have to to manage the difficulties that come with like understanding like what the information is going and how it's flowing and how to smooth this connection. So the first thing that would say we have to do on this graph is to maintain it and make it available, you know, and make it like transparent like to actually all the actors of the firm but also regulators and also like, you know, auditors or anyone that want to understand better what is happening on our side so definitely there's an operational aspect to it like if we understand how the information is flowing in mean that we can better manage our breaks better understand the impact of something failing in our organization. I mean that we will be more in control of actually understanding the information is sort of the right way, which is actually really important for regulators like data lineage and data analytics, you know, ensuring that if we produce a number this number comes from the appropriate source is really important. It's really hard to do that if we cannot maintain actually the graph of information within organization and outside organization. I would say like, you know, on top of this graph, like what we see also is that we have to maintain fairly complex data contracts that enforce data quality across parties. So why again, because you have many, many actors that process information, all these actors get a different view on the data that they're processing a different knowledge that they want to apply so it's totally possible that someone downstream that process data. So we like to enforce some data quality constraints upstream like when information is booked when information is actually entered into the system. So, you know, when you have to manage this complex rough of information, you have to be able to make everyone contribute their vision of data quality in the system so that we can improve or that the flow in improve our information is flowing. The other part, you know, that comes out of this graph being complex is that we have to manage data privacy, data sensitivity. So, you know, when we flow information, you know, again, within a firm, we need to make sure that the right person can see the right set of information and only the set of information that they are entitled to see. You know, it's not possible, for example, a banker to have any information about trading. It's not possible that for some desk to understand the position of another. And it's obviously not possible for people to access private information from our clients or employees. So, you know, like all these concerns are coming out of this kind of fragmentation of information and flow of information. And one last thing also that, you know, I think is important and, you know, different in the financial industry is that we have to milestone our information. Like it is super important for us to be able to reproduce a state of information at one point in time. And it's really important to be able to reproduce compute like in the context of an audit, for example. If someone come and say, you know, you produce this number six months ago, can you explain me why so we will have to rebuild the state of information, the state of data out of milestone information, and actually provide it to people. So, you know, that, you know, for me, like, these are like really the biggest like problems of data that we have to solve actually, you know, day to day in our job. And Fee, what are your perspectives on this and maybe maybe talk a little bit about what it means to have models and structures not only that are common within, within Goldman and that there's some of these issues that Ian touched on around having representations of, you know, what have you have X option, for example, in multiple places but what does it mean to have common data models in the industry and what are some of your perspectives on these challenges from from from your seat within the Goldman organization. Yeah, I think the additional thing I'd add to sort of what Ian and Pierre, what you mentioned is in current sort of world the idea of data is commonly owned within engineering and that sort of how it's developed across the tech industry and also in the finance industry more recently. And that role of strategizing and developing a data strategy is definitely sort of handled within engineering predominantly. And in finance, actually the business are the ones that actually create that data. And we have sort of, perhaps, lacked that communication in some respects between the business that are creating this data, and the engineers that are sort of looking to store and process the data. And I think what we're starting to see and hopefully we'll continue to see is this communication between those two things to get to a much better state in the future as well so I think that's one of the current issue sort of we're working through. So sort of what you were saying on the need for for standardized data models. I think it's about the communication across the industry so as as Ian mentioned sort of regulators are asking for more things we've seen more transparency needed within derivatives markets so through clearing. And all of these things are services that are provided by many different vendors out there, and being able to communicate with them at the moment is a one to one mapping between each of them and if we can standardize that message and that communication. So to quickly reduce those operating costs that you mentioned to the business. Yeah Nigel, yeah Nigel maybe you jump in a little bit with the perspective from agnosis and also just some of the perspectives in terms of dealing with some of the regulatory concerns as well. Well, I would definitely echo what what feature said, you know, from the introduction here. Maybe there's the misconception that there isn't digitization in fact there's huge amounts of digitization in finance and there's massive amounts of data, and it's that lack of standard lack of a standard data model, which limits systems from being interoperable. And I think it's important to to what feature said in order to take data and transform it through the trade life cycle. As it moves from execution through risk management clearing and into trade reporting, having that common standard that allows the enrichment and transformation of that message whilst maintaining the underlying data integrity is critical and that's you know particularly when we think about the reporting which, in many instances, comes later on in the trade life cycle. If you lose that integrity as it goes to the transformations by the time you start reporting to the regulator, you are you know you have issues with your data, and that that translates into having difficult conversations with regulators because you're reporting incorrect information. Something that I think is implicit in in I think everything that you touched on but I like to drill down a little bit more is, is there's something different or special about the the finance industry and the data problem within the finance industry so certainly the tech industry has been facing, you know, the challenge of data and data models and, and all this, you know, going all the way back to the ERP days and, and, but is there something specific about the environment in which the finance industry finds itself in banking capital markets, etc. That that presents some maybe some unique challenges that need to be dealt with. Here. This I think everyone touched on I mean the importance of metadata tracking information about models and metadata around data is really paramount and critical to us. And why is that like because when you look at you know what the final what the tech industry is is working on is deal with enormous incredible incredible amount of volume of data for you know, individual data sets. I would say you know if you look at the problem we're facing like I would say for each individual individual data sets or volume is pretty much medium. Okay. However, we have a lot of data set that assets, they have a lot of depth, and they are interconnected in a really complex way. You know, we, it's not a high volume, simple data structure problem. It's like a medium volume, extremely complex depths of infrastructure that of data structure that work all over the place. So, because of that, the day to day problem that that we solve is not really like, oh, how can I run this super complex calculation massively on an incredible large data set which the tech industry is doing super well with like so many framework and so many good tools. I mean our problem really is more out of this graph of information. Where is the information I'm looking for like it's actually fairly complex sometimes to know even where to actually look at, you know, like the question I would ask, you know, when they find it's like, is it actually the right place like it did the right originating source actually for the information that I had that I'm requested, I'm requesting sorry. And like after people will say but now am I authorized to see it. Okay, so obviously like system control that, but like if someone is looking at the information and cannot find information they'll say, okay, I'm authorized, I should see that. I acquire actually the rights to get the information which is very tricky out of all this can that data set and all this actor that all like different kind of set of information. Like the, then they're like, okay, now I'm untitled, how can I query it. How can I safely get the information. And once we get that like, well, can I store this information can I redistribute this information, because you know, as we saw before we have privacy and sensitivity, you know, constraints in manipulating our data but we also have licensing constraints with actually the vendor that provide information to us. Like, and when you look at, you know what Nigel was touching on about regulators, you know, like when we get this information and we're like, okay, but I see an error in this information, how can I make sure it's corrected at the right place and how can I make sure it's not going to So you see like the kind of problem we deal with seem to be a little bit different than the kind of problem that the tech industry is serving so and to answer and to, you know, be able to maintain all this kind of metadata, you know, around information we process. The emphasis is really put on modeling, you know, modeling, meta modeling so that we can also, you know, manage our models better. You know, as much as possible leveraging data standards and you know data, like data standards that are available outside so that when we communicate inside we can easily communicate outside. So I mean like really like, you know, being also coming from tech, you know, like that's kind of what I feel is really big difference and that's why you know model is actually coming all the time in discussion in finance. So what are some of the complexity we've touched on a little bit but Nigel and Ian any other sort of forms of impacts or types of issues that emerge from all of this complexity. Yeah, sure. And so, you know, developing on what Pierre said and reiterating maybe some of the numbers that Ian had given and Tasha referenced it right at the start. You know, when you when you think about the notional of interest rate swaps that are traded say on a weekly basis, three to four trillion dollars, which is a very big number. That translates into about 30,000 trades. So from a volume of messaging 30,000 trades isn't a huge number of messages to be sending around on a weekly basis. And 60% of those are traded electronically and 90% of those are clear to clear and house. So there's a lot of data that is being sent around, probably in a variety of data formats or not probably definitely in a variety of data formats. And depending on where the platform where what platform the trove is executed on where it's being cleared, etc. And so if data inaccuracies are generated, then there's a huge risk of operational error caused by either incorrect risk management of a position because the economic details are wrong, or incorrect, incorrect payments. So about three trillion dollars of notional decimal point in the wrong place on a price or an incorrect settlement date makes a very makes a big difference. And you regularly see in the news issues that you know certain counterparties experience due to some of these data inaccuracies. The second thing I just talked about is the pace of innovation in the financial services industry. And this is where the development of the data model and the design of the data model is important. You know, any standard that this bill needs to be sophisticated enough to capture the detail that the PS spoke about.  It needs to be flexible enough that it can deal with the composability of financial products which are tailored specifically in many instances to the individual transaction. And that, you know, without the model needing to be continually redefined, but also with the tooling available which sort of segues into what we're going to talk about, but with that tooling available, and the governance in place to extend that data model as required. So the common domain model we think has these characteristics and also provides a common translation layer between the many other standards that already exist to allow platforms to interoperate. Ian, did you want to chime in with something? Well, yeah, maybe just to heart back to one of the points I made at the start. There's another element is that there might be relationship documents you need to reference which are long dated. You might have set up a trading relationship 10 years ago and was that master agreement stored in digital form or is it a proxy for it held in some other static data system? All those things are challenging and it goes to sort of lineage as well, where did this decision come from to make this payment, what's it based on? So that's the only thing I'd add. And it's another dimension to the problem. So yeah, but I definitely echo the idea it's complexity of the data rather than scale and volume. Great. So let's shift gears for a little bit. We've got about a half hour left and I want to make sure to leave some time for questions. So we're here at a summit about open source and probably a lot of folks are interested in where open source fits into all of that, which we've discussed so far. So maybe starting with Phi, so we just spent the four of us amongst a group of about 20, 25 other people. We just went through this effort of doing this pilot of using legend with several other investment banks and other institutions. And now legend is open sourced and part of the open sourcing of the legend code is the fact that now we have these models that are built in the legend language that themselves are open sourced. So maybe Phi, starting with you, talk a little bit about why open sourcing data models, not just the code for the underlying workbench and language but having the models themselves built or being able to be distributed as open source code. Why is that a good thing and what are some of the benefits that we're sort of all expecting and should see within the industry from that. Yeah, thanks Rob. So hopefully, from what we've already discussed, you can sort of tell the need for data models, and they definitely do exist in the financial industry already. Commonly, probably more so within individual institutions, but sort of CDM as we've mentioned, being one of those standards externally trying to standardize the industry as a whole. And so sort of as you said Rob, why open source and I guess that standardization piece is the really important bit that's the piece that's going to bring us our reduction of costs and our improvement in sort of trade processing. And so in terms of open source I think of this in two ways. So one is the visibility and the access to these models and sort of the benefits that that brings but also the development of these models. So from a development perspective, the sort of principles of open source in terms of early and often releases should bring us more speed and agility and that flexibility to improve these models quicker. We should be able to add to and adjust when you use cases come up within the financial industry and these could be from external factors. And we've mentioned regulation is one already, sort of as new regulations come in, definitely more data might need to be added, and all of that sort of thing so that speed and agility to meet those demands and equally internal factors so from the business perspective they're always looking at diversifying across all the banks including with clients. And so how do we sort of meet those demands of new business, and that agility and flexibility to add to models quickly is really important there too. So the other sort of principles that I look at from an open source perspective this inclusiveness community and that collaboration. I think all of that boils down to me to diversity of thought. And how do we actually tap into a lot more diversity that's out there not just within the financial industry but also within the tech industry and other industries that are working with data. I think there's a lot for us to learn within the financial industry in terms of how tech companies are developing and thinking about data. I'd say they're probably one step if not a few steps ahead of us in that space and so I think we'd be silly not to tap into some of that as well. So within the industry side. I think historically working with sort of industry body such as is the lots of the larger banks and larger institutions in the market have definitely been engaged in this this discussion and that idea of standardising and building data models, but perhaps the clients and the vendors and vendors and service providers haven't been able to get so in touch with those conversations and so by open source by that availability by expanding that community. Hopefully we'll get more diversity of thought from across the financial industry. And as I mentioned on the on the outside industry side of things as well. So that's kind of how I see open source helping with the development of these models. And so when I talk about visibility, I guess that comes down to the principle of transparency. So these models are now open, they're available, everyone can access them. And that should hopefully help us speed up the adoption of these models as well. And really it's at the adoption level that we really gain the benefit. It's all well and good as having these data models available but until they're being used. And so I kind of, they are connected that adoption is going to come by having better standards by having more heads at the table when we're building those standards and hopefully that will speed up the adoption too. And finally for me it's governance so I think we've sort of alluded to that as well already through this discussion, but sort of this financial data is going out to regulators it's going on legal confirmations it's requiring how much margin where we're settling and so that governance over the data. Is vitally important in the financial industry to in terms of the open source so the SDLC of code brings us governance in that respect in terms of how we are committing code, who's committing code when it's being committed. And also industry body such as is there have to be there to actually sort of govern who's putting into these, these data models and how they're going to be used and sort of helping to disseminate that across the industry. Great. And Ian or Pierre or any, any sort of other examples in particular and any, any ways in which you see open source models being used out already in the industry. Nigel as well. I'm not sure who wants to jump first. So, I think Nigel mentioned that, you know, there are, there is digital data. We have, you know, standards in the past, such as fpml use for messaging. I believe, you know, the CDM project at its heart is intended to be open source. We are, you know, that's what we've been doing. I think, you know, Nigel has a few examples of the things in particular which, which we probably presented as as recent examples of using and implementing it and that's what, you know, Reg knows that we're working with is the members on. Yeah, sure. Thanks Ian. Yeah. So, so, Reg knows this has been working with with is derived the last three years on the development of the common domain model that's on the Rosetta platform, the DSL of which is is open source. Yeah, as to what Fee said, you know, the expansion of the community that's helping develop the model is is, you know, very gratefully received and the more people that are developing the standard and contributing to it that the greater the penetration will be, which is obviously a virtuous circle. The, you know, there's been a number of announcements recently in the press over the course of the year. Axoni, who are a distributed ledger technology platform are building a solution for the equity stocks market, which uses the common domain model. There's also been recent announcements around digital asset working with Isda on a clearing pilot using their damel language with the CDM as a model underpinning it. So, yeah, and that that's just two examples there are a number of other examples out there of firms that we're working with bilaterally on initiatives to to adopt the CDM. And that's really, as well as, you know, larger industry platforms that that should be using the CDM and solutions coming to market for the same. Yeah, I would add to that actually, you know, CDM is definitely a great effort to to be able to start to get a common language across the industry but I would like to insist on something like it's not only about open sourcing data models. What we want to do is also apply the tools and the SDLC leveraged by also open source project to make it easier, you know, like for different company to collaborate exchange ideas and agree on how to to interoperate like, you know, what we want to do is to have a new model version, you know, created quickly to address like needs of specific companies. Because what we see too often is that a company will have a specific need will not want to go actually to the standard body and say okay can we incorporate maybe in direct time crunch and they actually, you know, don't want to make the investment and they fork and diverge from the language. So what is really important is to smooth this process, learn from, you know, what the open source community has been doing for some time, you know, gathering a lot of developers, or you know, like in this case, a lot of business actors and a lot of technologies to, you know, refine the specification and get, you know, a release of version that is really accelerated, like our field that we want to accelerate the process so that we never are as less as possible diverge from common language is agreed across the industry. So our feeling for that, you know, it's not it's not only about open source the model we also really want the platform to be open source, like, so that we can invite, you know, as many people around the table so that the community can be, you know, more broadly agreed on, and so that you know we can achieve this agreement and not diverge and that is really why you know we felt that we wanted to open source or platform to make you know this acceleration and this kind of community driven modification of model real. I just like to jump in and back up up here just said, and indeed that's sort of the limitations of some of the standards and data standards which we have today. Even our own other standard that is the FPML did development of FPML has seen a lot of people have their own internal fork, their own variation of it. It's not a standard if it's not the same everywhere. And you know the development of some other messaging standards you think of the, the, the life cycle to get the change into swift for, for, for effects transactions. A lot of those standards that the timelines deliver things is just often too slow, and people then make bad decisions around forking and creating their own variations. So that's definitely why it's of interest to is that to see new new standards delivered and developed indeed in this way. So I want to open this up to questions in a second so if, if folks are interested in asking some questions about to any of the folks are all the folks on this distinguished panel. Please use the Q&A feature I see that James is providing some guidance on that in the chat so definitely ask questions so we can start, start getting into those we want to make this interactive. So, you've touched on FPML and, and then there's also been some discussion of sort of the case for open source and, you know, hopefully we have a sympathetic audience today. So, where do you see this going so, so, so, you know, there's the Rosetta DSL there's the legend language as a legend platform that's been open source. I think we're all feeling a groundswell of support for open sourcing clearly Goldman's announcement last week was a big shot in the arm the morpher project which we're going to hear about in 20 minutes is another example. And where do you see this going where we're what's look out, you know, hopefully 12 months we're not all having to wear these things everywhere and and we're all back seeing each other and able to head to the pub but besides that we're looking at 12 to 24 months. So, where do you see this going in terms of open sourcing around data models and and also the adoption of some of the CI CD practices that James alluded to or referred to in his presentation a little earlier and that Pierre touched on. What's the future for open source in this area around data models. And maybe maybe fee if you want to give some perspective first on the, some of the stuff you saw coming out of the pilot and then maybe you can shed a little perspective as well. Sure. I think sort of out of the pilots we wanted to make sure we were contributing to something meaningful in the industry. And I think that's really where the future of this has to go and so in terms of as we look to improve standards more broadly. And that input of thought that I spoke about before, and it's going to be a big, a big player in that but we've also got the opportunity to expand a lot more broadly now so I think we've discussed quite significantly today around sort of this idea of what we would do with the transactional data so sort of that specific trade data that the lifecycle of a trade. There's lots of other areas of data within the financial industry as well whether that's reference data in terms of the actual underlying products that we're trading, whether that's market data in terms of pricing that's available and and how do we get all of these things to communicate actually, and look at the entire lifecycle of a trade from inception all the way all the way through and some of that's transactional as I mentioned a few other data sets as well and so that expansion is going to be really important. I think also considering new use cases and some of the nuances. Often in the financial industry we start with sort of the bigger volume first and as we get through that we're going to end up with some of the more complex exotic pieces. And they're going to start to raise questions of perhaps what we've got already and how are we going to improve what we have there, whether that's adding to or adapting current attributes and current models. So I think that's in terms of sort of improving standards and pushing the industry in that sense. I mentioned before as well this idea of cross industry, I think there's a lot for us to learn about the acceleration of data driven transformation across multiple industries, not just in finance and so I'm definitely excited to see where that is going to go in the future. And I guess that pushes into one final thing for me is the innovation that's going to be available. I think lots of these things and there's been little bits of pockets discussed around in the financial financial industry in terms of new technologies, being able to branch into blockchain smart contracts, but I think actually as we open source and we move further we're going to be able to gain and what's happening in the technology industry and hopefully find better solutions than we can even think of today on how we're going to solve some of these problems that we have. Yeah, I would like to add on that like you know as as as she said and as I answered and even Nigel to like what we want to do is is to accelerate the standard accelerate cbm accelerate like maybe different areas actually a powerful business from a standardization and model perspective, like, and we felt like, you know, to do that to open source the platform so what we would like to do too is make sure that we can try to gather more community in some of the development of the platform like if people are interested like the site is at the end of the talk. And you know like to make sure that we can open contribution that people don't see the project being biased or you know like help a specific company we open source and our phenos like we provide like we gave the code actually to the HOS Foundation that is hosting our code hosting the process of development of our code now. They also host actually our platforms so that different banks can work together into a total neutral environment that is not like specific to a bank like it is part of this organization, you know, which is great like that allows us to work actually together to better and save an easy way. So you know what I really would like to see in the future fully is like acceleration of the model but also acceleration and contribution on the team the platform better so that we can include again the business users and the technologies in building this model that are that are going to be a really, really hopefully transformative in the industry and make things faster and be there and safer in terms of operating financial information. Great. Yeah. Go ahead. Yeah, just just to add like I'm equally excited that the diversity of views that could come along and really, we'll see real innovation. That's very exciting to is that, you know, and also, you know, is this mission is, you know, safe efficient markets, but also trying to make access to those markets a lot easier. And how we do that is by making things, you know, open source is this legal standards the master agreement was essentially an open source document, which is published in the 80s, which made, you know, in straight swap markets which was a bilateral market between a couple of banks, you know, across the Atlantic to go from a few hundred million to the trillions the hundreds of trillions we quoted earlier. And this is the same thing. We give people access to the same technology, the same software that banks can use we can only see good things happen. Yeah, the only one thing I would add is an area of particular focus for for is to run diagnosis is development of digital regulatory reporting. And you've touched on that through this conversation and we think that partnering with regulators to create machine readable machine executable read reporting, we can drastically reduce that cost of compliance. The CDM is a is a core component of that because it provides the common data model to represent the transactions. It's recognized recent energy 20 text print competition. You know, that's that also is a is a good link to the Phinos rec tech work stream, which is focused in this space. So that you know there's crossover between multiple Phinos work streams also and looking forward to working together on on that topic together with Rob and others as the agenda progresses. Nigel, you nailed those talking points. It was great. Just something on that that maybe you that what we just talked about the digital record reporting. I was speaking to a particular sort of large global entity in the financial services, a large sort of regulatory entity might say, and they talked about changing the culture of how we deliver regulation. And I thought that was great phrase to change that, you know, to have these open models which we can all work on together, and also have that conversation with regulators and demonstrate what we mean. When we say your regulation doesn't work or you need to improve the law here because it's unclear to the market we can demonstrate that with data now through models and true platforms like legends and the CDM. Fantastic. So I think we have our first question. So Adam Jones asks, and maybe I'll pose this first to Pierre. How can someone primarily from a technical background, get involved in legend to start leveraging and contributing to the use cases and I'm going to, I'm going to also concurrently send some information that people can see but Pierre. How can folks start to get involved in, in legend and maybe start looking at the models and maybe even doing some pull requests and stuff like that. Yeah, so, so there's a lot of depth and a lot of things to do there so I mean first you know you can look at the code on the GitHub website of the GitHub areas of finance. The project is structured in many modules and there's, there are things to do for all kinds of developers really like the first thing is like studio, which is our like additional environment, where people can, you know, work in JavaScript to improve the way people enter model, manage model, enter code. There's the pure language itself, which is a big language where you know people that really like language can work on modify tweak and there's like the full platform with like the SDLC management where we can add more SDLC plug-in like right now or SDLC backend I would say is GitHub but it's totally possible to add a new backend and integrate with different kinds of SDLC. Like, that's for the area we have today like going forward we're going to open source more code, leveraging the pure language for transformation like when we interface with different data sources like relational database and want to map or model to transform kind of infrastructure, we actually write a lot of transformation code that goes model to model like for example how to transform a pure function into our SQL query so that we can translate a request coming from a business user that is not a technologist into a technology request that will leverage an infrastructure. And that's like, that's a space where you know me and my team spend a lot of time, you know, how can we translate, you know, and leverage models and model to model transformation to be able to access information. I mean that's if people want to contribute like from a leveraging perspective like you know like you can start to leverage the platform to define models that you can transform into different kind of technology of transformation like for example Protobuf, JSON schema, whatever for solidization purpose, going forward you'll be able to use these models and map them to infrastructure and provide a query tool for actually your users. Going forward also will also allow people to translate this query and this metadata that is gathered to acquire information to deploy it in production to a service environments that that's the kind of thing that will operate day to day on our side and that we're going to be able to for us to be contributing to the project. Great. Great. And if folks have any more questions don't hesitate to to ask them I've I also posted some more follow ups with links to add them to your question. The question that we get, or we've been getting and probably bears a little bit of context and explanation. And it's in the read me is, we use the legend project uses get hub and get lab and sometimes people are like, Oh, how, where do they fit in. So, get lab provides the SDLC for the modeling efforts so when you're in Aloy studio and you're working on the models themselves under the hood. There's a get lab instance that's managing the models as effectively open source commits and and and that's abstracted through studio. And as Pierre alluded to a second ago, we then, and the actual underlying code so the, the builds of studio and SDLC and all the components to legend itself happens through get hub, and what's really interesting and I think a real. I know Pierre and I have talked about it. One I want a bunch of times but one of the things that really I'm excited by is the fact that the builds are happening on windows infrastructure on the get hub public repos and so this is really authentic open sourcing this isn't just a case of Goldman having put the code out here and then it's got its own fork. You know behind the firewall and that's where all like the nightly goodness of builds and stuff is happening like the CI CD stuff is actually authentically happening outside the firewall on the public infrastructure on the public Phinos get hub infrastructure and the models are hosted and control through the public get lab infrastructure so it's pretty cool. I would, I would continue on that a little bit so there's a difference where we operate the code of our platform, which is in get up, but the models which is in get lab exactly. It's really important to understand that we need SDLC to operate on models, because you know like the point of the, the, the effort that we're running within our firm and hopefully outside our firm is to make sure that we can drive a lot of information flow through metadata, so that the business can be involved, but that also that this metadata can execute action production flows, and there's no way we can execute in production production flow without without following a proper SDLC. The same way, you know, there's no way we'll be able to accelerate, you know, the collaboration and the work with other entities if we don't follow the tools you know that people for everyday engineering of SDLC so that we can make, you know, a lot of changes really faster but in a super safe way and open way so that people understand who is making the modification at one point we reviewed the information, how for example this information will then be actually published to a standard, you know, like, like CDM, you know, like so the notion of SDLC is really key there, because what we found you know, like looking at the way people manage dictionaries usually is that they are they are managed by business people, but they, they diverge extremely from what's happening in real life in system. So we have this kind of beautiful set of information that people like to communicate about right PowerPoint on and others but when it comes to but what's happening in real life, you have a totally different picture and answer. So you know, like making a language that is like easy to use by a business user that make the business user enter actually the specification and other parties to but make also all that executable, audited and manageable so that we can execute on it and actually get you know what you see what you get effect between what what people communicate on but what is actually happening in real life in system and in data flow. Yeah, so following up on that there's another question in the q&a so with regards to the SDLC and the open models. What steps are taken to test the models themselves how are the, how are the models tested. So, you know, like, there are many strategies actually to test models so we're not using a logic based approach of models. What we're doing is more like something a type system that is closer to object oriented with the functional language applied to it so testing a model is an interesting thing like the first thing that we ask people is to add transference and validation to really specify really clearly what the intent in the context of the model. Now, the test comes to when you map this model to different data sources. And you want to ensure that the question that people are asking are actually accurately answered. So what we let people do is enter model, enter mappings and next to the mapping right a set of steps which are like a set that they would ask with a set of sample data that would actually retrieve information. There's a lot of depth to hear about like generating test data to actually activate models. So we have strategies that that source information from our system safer it like to make it available so that you know we protect that the test data is not actually providing private or sensitive information. But I would say I would say the first thing is to guarantee your model is consistent to refine it with constraints and guarantee that these constraints for tests are violated when they should be violated. The second one is to make sure that when we map actually these models to a different infrastructure and people ask questions they get back what they want. You know, like to give a feel of the number of tests that we operate right now for the models that we have in our, in our premise, we're around like 12 to 13,000 tests that will run for each commit actually because we're in a total continuous continuous development process.  We have time for maybe one more question. So if anyone would like to ask a question please do so now. In the meantime, Ian fee and Angel, maybe just a quick closing thought or two is as we bring this to a close. Any, any final thoughts on our, our glorious future of open sourcing data within financial services. Not really, I think we said, no, I think we're very excited to see the shift. I can certainly test to the fact that, you know, these, these stuffy old financial institutions have really changed their minds and they're starting to see the benefits of open source and a lot of the new technologies in the last couple of years in a way we've been really, really happy to see. Nigel or fee. For me, it's sort of that excitement of where this is going to go next. And I think if anything it's probably a call to everybody to sort of get involved, whether you're finance or not finance there's ways of doing that whether through Finos or other industry bodies sort of start contributing to this and we'll start to see where that innovation takes up. Yeah, I call of that the acceleration that we've seen over the last few months through the Finos pilot work streams has, you know, we've had a huge amount of development in the CDM just over very short space of time so it's really exciting to see and hopefully that will continue. I will test to the lack of stuffiness because I actually put on a collared shirt today for the first time in a year but I know full well that if I were to wear said collared shirt to the 23rd floor 200 West I would be overdressed. So it appears laughing because he knows it's true. So anyways I'd like to thank everyone on the panel this was fantastic. Really appreciate it. If you have any questions about about legend, don't hesitate to ask at legend dash inquiries at the nose.org. There's lots of information, definitely dig in as well on the is the CDM and some of the good stuff happening there and the work that the diagnosis team is doing a Rosetta and which is the DSL that the CDM is represented in. So lots of good stuff happening. Thank you to everybody who's here. So with that I'd like to turn to our next panel and I have to say that the next panel is panel I'm I'm also really excited by the Morpher contribution to Finos was another large contribution this year from Morgan Stanley, and there's actually some really interesting sort of relationships between what the legend contribution from Goldman and some of what's possible in Morpher from Morgan Stanley so without any further ado I will turn this over to Steven Goldbaum from Morgan Stanley. Hey everyone. All right, thank you. Tosha I think. Hi everyone. Thanks so much for joining us today we're very excited to be here and really thrilled to for the opportunity to introduce you to open rectic and the way the financial services industry is leveraging open source to comply with complex regulatory requirements. I'm honored to be part of this panel today along with Steven Goldbaum, executive director at Morgan Stanley and Mark Marin the designer of the boss key programming language and principal research software development engineer at Microsoft. I'm a strategic initiatives manager with finance the fintech open source foundation, which is part of the LF. As you may have heard in the opening remarks earlier today, we are a member based organization, our members include some of the largest investment banks as well as tech firms fintech firms and vendors. And our goal is to enable open source in financial services. And we have a community of hundreds of developers and subject matter experts from financial institutions, tech firms and vendors collaborating on our open source projects and leveraging the efficiency the cost savings and all of the other benefits of open source. We host over 40 active and incubating projects, all of which live on our finance GitHub organization and some of which you will learn more about today. Earlier this year, we launched our open rectic initiative in response to two complementary realities on one side by definition, our projects focus on on technology solutions to common challenges and use cases in financial services. And importantly, solutions that do not provide a competitive advantage. That is to say that our projects target challenges for which many organizations would need to normally build a similar solution. And the idea behind our open source projects is to bring all of those actors together, get them to collaborate on building a solution. And lead to stop reinventing the wheel and wasting time and resources to develop the end iteration of a very similar solution. And at the same time, we're promoting open source in financial services, but we were missing the perspective of a key industry participant, which are financial regulators. And not only were we as a community missing them, but they were also missing out on all of the opportunities and benefits of open source collaboration. Before we launched the open rectic initiative within finance with a two fold objective. First to streamline and utilize regulatory compliance efforts at banks through collaboration and open source projects. And on the regulator side, the goal is to get them familiar and comfortable with open source address the concerns they may have and also show them the potential of open source for regulatory supervision and for issuing regulation. Our very ambitious vision for open rectic is a model in which regulators adopt open source code and best practices and define regulations in open source code form. While retaining full visibility on on their supervisory activities and monitoring. And we're on the other end industry participants collaborate to codify and standardize those regulations and to mutualize the interpretation of regulatory requirements. We know this is a very ambitious and long term goal, but we're very excited about the interest and engagement that we've seen from the community so far. And we're also looking forward and working hard to see this vision become a reality. Where do we stand now. When we launched the initiative earlier this year, we were expecting we'd need to do a lot more work to educate and convince regulators about the benefits of open source, and also to debunk the myths around open source security and vulnerabilities. But we have been very pleasantly surprised by the response from the regulatory community, both in the US and in Europe, who are a lot more familiar and comfortable with open source than we initially thought. And I also think it's safe to say that they're already on the next phase so they're eager and looking forward to identifying use cases and projects to start collaborating on some regulators in the US like the CFPB are really mature open source consumers and contributors and even have an open source first policy so they do all in open source. We are in an ongoing conversations with US and European regulators to discuss potential collaboration opportunities and even some potential open source contributions by regulators, which is really exciting. We have also had air the Alliance for innovative regulation join finance as an associate member recently. There is a US nonprofit focused on promoting innovation in financial regulation. And we will also have representatives from the CFPB and former regulators join our upcoming open source strategy forum on November 12 and 13. And more recently just last week, our board approved the creation of a regulation innovation special interest group, led by ING and the Alliance for for innovative regulation, which will provide a venue for regulators and financial institutions to discuss and identify specific challenges that they like to tackle through open source collaboration. Special interest groups just to clarify that because it's it may not be a very common term. They're supposed to work on the problem space or the definition of the problem or challenge. And then once that's been identified, it would be up to a project to develop a solution through open source software and standards. And the other branch of our twofold effort, the one around identifying projects for financial institutions to collaborate on. We've seen fantastic progress as well. One project we're particularly excited about is more fear, which was recently contributed to the foundation by finance member Morgan Stanley, and which has tremendous potential to drive open source collaboration on regulatory reporting and compliance. More fear is a multi language system built on a data format that captures and applications, the main model and business logic in a way that is agnostic to the technology. So, more fear allows you to have business knowledge available as data and to process it programmatically translating visualizing sharing and storing data and more relevant for our rectic initiative. The team at Morgan Stanley has already used more fear to calculate liquidity coverage ratios as mandated by federal regulations in the US, essentially by turning regulation into code. I won't take any more time talking about more fear because we have the honor to have Steven Goldbaum on the panel today, who's the co creator of more fear and an executive director at Morgan Stanley. Steven, the floor is yours. Thank you itana. So, providing regulations as code. Why would we want to do this. Well, first of all, regulations are incredibly complex. So turning them into running systems is an expensive process. So, having every firm do that across the industry means that that's expense is expanded across the industry. So it just makes good business sense to say, well, maybe we can share the effort we can share the burden and by doing so everybody wins. And in the process, maybe we get even more accuracy. That means a good deal of challenges on the technical side. For one thing we're talking about sharing complex logic. So while the industry is fairly good at sharing data and figuring out how to use data across different technologies. Sharing logic is a much bigger and more difficult problem. And I'm sure that we're not excluding any industry or any firm. So there's a vast amount of different technologies across the industry. We can't really say well we're going to solidify on one technology and everybody's going to have to use that and if you don't already use that technology then you're going to have to do an expensive rewrite in order to support this. That's just not a viable approach to something that needs to be used industry wide. And even more importantly, we don't want to get in the way of evolution of technology. So we all know that technology is evolving very quickly, and we wouldn't want to regulate Tory or regulation is code to stand in the way of firms being able to adopt newer and better technologies. And maybe the biggest challenge of all this is that the whole thing is to be incredibly accurate. And one small mistake can mean financial impact across a number of firms. And so we have to make sure that this is correct. There's no ambiguity, and that there is many guarantees that this is correct as we can possibly get. So given all these technical challenges, how might we approach this? Well, we're going to look at a technology called Morpher that was recently contributed by Morgan Stanley to Finnaz. So Morpher is all about defining a standard for translating business logic across technologies. And so what Morpher does is it provides a data structure called an intermediary representation that we can encode business logic in and then a set of tools to process that business logic into different contexts. So some of those processes might do things like provide real time documentation that that is always up to date or even interactive documentation that users can use to audit results that they might think wonder how they got to that. Similarly, we might want to take that business logic and translate it into other programming languages so that it can be run in different execution contexts. Or we might take that idea even further and if our firm has a standard set of platforms, we could actually generate entire applications from the business logic that conforms to those platforms and regulations. And so when we think about coding regulations, that's exactly what we want to do. We want to be able to say, well, here's the business logic, it's coded up, and here's the tools to either generate the tools that exist or to customize those tools for our firm and our firm standards. And so you might ask, well, how do we code the regulations in the first place? The developer doesn't make any dictate any particular way of doing that. We do offer support right now for Elm, the Elm programming language. We do that because Elm is a very simple language. It's a pure language, meaning that there's no side effects. The developer has to think about business logic and business logic only, and it provides a lot of guarantees in terms of the correctness of the models and making sure that we don't have any errors. And as we mentioned, it's very important that we don't have any errors because that could have some serious financial impact. And so to get an idea of what this looks like in practice, we're going to look at something called the liquidity coverage ratio. And I'm scrolling through this just to show that right now it's provided in hundreds or thousands of pages of very dense pros. And so, you know, wow, imagine taking this and trying to turn that into a computer system when we're looking at something like page like 61,000 or something like that. You know, that would be a daunting task for anybody. So obviously, if that were provided as code, we wouldn't have to do that. And the interesting thing is that if you look at the documentation, it actually looks a lot like code in a lot of places. So you can see how it can naturally translate from, you know, maybe this document could actually be done in code, right. And so we're looking at something right now, the definition of a counterparty. And so a counterparty is limited to this list of values. And we know in programming that that translates to something like an enum or a union type in this case and now it's a union type and you can see how the code naturally flows from the documentation. Similarly, this table actually is a specification in the documentation in the LCR that specifies how do you figure out what maturity bucket something lies in. And so it's presented in this kind of arcane format with a lot of explanation, but really what it turns out to be is very simple code. And so we can see that here in our model. So looking more into like rules and categorization. There's a lot of rules in terms of how do we classify assets and cash flows. And those those rules again are intense pros. And when we look at the actual model, we see that it's actually pretty simple programming language constructs. That's actually something that we want right we want to be able to look at this program and be able to understand it for for for many reasons least of all, I mean most of all maybe because as many people look at it and can understand it. Then we can catch, you know, errors and bugs and make sure that it's correct. And finally, so if you go look up the LCR that probably the first thing you'll find is this, this equation that the LCR is really a mathematical equation of the high quality liquid assets divided by the total net cash outflow. And so the LCR provides this kind of calculation math oriented calculation document as a supplement that we can use to create the same code, right and we can see that it's very, very similar. In fact, if you go to this document and if you go to the LCR example on more for dot examples you'll see that it's basically one to one between the document and the code. Which means that, you know, this is the idea of providing a regulations code is really an achievable process. So at this point you might say, well, that's great. You've got the regulation in code. It's an Elm. We don't run Elm. So what are we going to do with this? Well, that's where more for comes in. So with more for we have a set of tools. One of those tools parses Elm into the more for IR and as you recall the more for IR is that common data format that all the business logic is saved in. So you can see here's some of the concepts that we saw in the model before level one assets level two assets. This is the more for IR. And so now that we're in the more for IR we can then generate from that IR into other languages or other platforms. And so we're looking at the scala generated code from from essentially from what is Elm into more for an into scala. And some of the other things I mentioned that we generate are things like documentation. We can support other languages we've had generators in sequel before. So there's a range of things that we can do with this. And that's where more for helps out the industry by providing a set of tools that are that are already common like the scala generator and then providing tools that different firms can use to customize the output to match their own platforms. And again, that's exactly what we're after. We don't want to make firms to rewrite their platforms. We would rather provide the tools that take the regulation and allow them to adapt that regulation onto their existing systems rather than take the regulation and say, well, you've got to rewrite everything in order to make this work. So I'm going to finish up with, well, one of the things we mentioned is that the regulation has to be correct. And in this case, the LCR provides a number of examples to to ensure that basically everybody's understanding this correctly. And examples are great because we all know we can turn those into unit tests. And so, in our example that's exactly what we've done. So the LCR has a unit testing capability so we can use the capabilities of Elm to unit test our regulation as code. Wow, unit tests are great. And they do catch a certain a lot of bugs. We really want something better than that when it comes to regulations. So, as I mentioned before, you know, if there's even a small error in the regulation that could have pretty significant financial impact. So we want to do whatever we can to make sure that those regulations are correct. And Elm is great in that it catches a lot of errors that a general purpose programming language wouldn't catch. So things like, oh, if you forgot to handle a certain case of enum, it will catch that and it won't compile. And you'll have to correct that. So you can guarantee that there's a certain quality level. And the common saying is that if it compiles, then it's guaranteed to run without runtime errors. And that's true of Elm. It turns out that we can actually do better. And again, doing better is just going to be that much better for the industry. And so next thing we're going to introduce Mark Marin from Microsoft Research to show us how we can use the Bosque language to reduce risk and increase confidence. Oh, great. Thank you very much. As I mentioned, my name is Mark Marin. I'm from Microsoft Research and I'm going to be talking about the Bosque programming language and how it can be used to build high assurance model code in a framework like Morpher. So to start off with the Bosque programming language project. It's a programming language. I've been working here at Microsoft Research. And it's focused on exploring the boundaries of what is possible with building high assurance software using techniques like formal verification, model checking, automated fuzz testing. And what we're doing is we're taking a slightly different approach than usual. And instead of taking an existing language and attempting to retrofit an analysis on top of it, we're actually looking at what things make building one of these analysis difficult and what makes them work really well. And we're trying to build a programming language specifically to get as much as we can out of one of these analysis to take away all the things that make them very difficult to scale or make precise. And in the interest of the fact that this is the open source summit. I also want to mention that all this work is happening public on GitHub open source licensed so this is freely available to everybody who's interested both the core language itself, and then the collaboration we're starting up with Morpher with the support of FinOS. So, as I mentioned, there, this is sort of a reverse of the usual design process usually you build a high level language, and then you build an intermediate representation and then you build tools we're sort of going the other way around so boss key we want to target some tools. And the first thing we're doing is building an intermediate representation that makes those tools as powerful as possible. What comes out here is a lot of the time there are simple things that come out in the intermediate representation, like is it a bytecode based versus register based. How does it expose iterative constructs. And these can have a huge impact on both the difficulty of building these kinds of verification or analysis tools, as well as the final results that they're able to produce. So, we're building this IR specifically to make these tools as powerful as possible. By excluding things like unbounded looping constructs or random a lot of indeterminate behavior. Once we have that, the next question was how can we build on top of this IR, a very friendly high productivity programming experience that developers expect when coming from a modern platform. Right. So we want to have familiar language constructs that allow rapid iteration that allow developers to feel right at home, while still targeting this IR that has supports great analysis tools. We also want to make it easy for developers to feed useful information to these analysis tools by allowing them to easily specify lots of validation constraints and logic directly in source code without having to learn a separate modeling language set of specification tools. And our hope was that this would create a virtuous cycle, where as developers add a little bit of extra constraints, the powerful tools we have make these very useful and encourage developers to add more and more constraints, and these constraints and additional specifications actually make the program easier for the developers to reason about at a high level. So we get this nice confluence of information being more and more useful as we go on. So, without any more high level view us talk about what the boss key language looks like. So this is a simple program, it's a function so it's a function called abs that takes one variable and it returns it in. And as you can see it's got a nice familiar block structure. I can assign a variable multiple times in the flow. I can have conditional if statements and I'll just figure out the right sign and then multiply by that to get the absolute value. So it looks very familiar to most devs coming from a type script or Python or, you know, go type programming language. We also use heavily things that you'd see coming from the functional space so we have higher order functions so all of takes a predicate the checks if something is greater than zero. We support rest and spread arguments. So, like you'd be familiar with coming from JavaScript. So a lot of things that make it very easy to plumb things together quickly without writing a lot of boilerplate code. We also support objects and what you would consider maybe mixing classes or traits, as well as union types so it's very easy to adjust your type system to model the particular domain you're in without having to build a very complex and touchy ontology. And then nice things like switch as expression null coalescing early returns with errors and all this stuff that you would expect if you were coming from a modern web language. So let's go into a demo and show kind of what this looks like in terms of some of the modeling code that we discussed earlier, and how the tooling experience works. So for this demo, I want to zoom in on a small portion of the code, the modeling code we were looking at in more fear written in Elm earlier, and look at how a portion of it might look if you wrote it in in Boston. And in particular this chunk takes some inflows as a list, and some outflows as a list, perform some computation on them returns the result. And from the spec, we can actually know a sort of a high level constraint that whatever the details this computation are that the return value should always be greater than or equal to zero. Now, what our tooling stack allows us to do, and the nuances of the Bosch language, we can actually take this code as written and translate it into a logical model and first order logic. It can be consumed by a solver like sat module theory solver. And I can show the code here. As you can see it's a little hairy there's a lot of low level detail because of the exact logical encoding, but this actually captures every possible execution in a full precision of this code written here. And with that we can go and run our solver and expand this and search for any possible input that would cause that assertion to fail. And as you can see it found one where the list one contains the element zero. And the list two contains the element negative one. And so if the first list contains the element zero, this sum will be zero. And if the second list contains the element negative one, this sum will be negative one, the result will be negative one. And sure enough, our insurers clause will be violated. So this found a counter example that we can go and use to debug our model code, just like if we had found a failing test days. Now we can fix this by actually pinning the result amount to zero, which is the correct fix for this bug. And now if we go back and run our tester and don't ask it to generate a model because now it's going to be correct. It will go, it will expand everything it'll actually find a conflict set to prove that it is impossible for these inputs with this computation ever violate this output clause. This is really exciting because it allows us to add some high level constraints or verification conditions that we always want to hold to the code and be able to effectively check them and get more confidence and more assurance that our computations are satisfying the desire of high level semantics. Now let's jump back to the slides and I'll show a little bit more about how things can be encoded what types of things you can express in these assertions and what features the language has for making this easy to get these concepts in the right place in your code. So now that we've seen how the boss the language in the tool chain allows you to insert conditions and assertions to be checked and either fully verify them, or symbolically generate a counter example that shows a bug in your model. Let's look a little bit more at the range of things that we allow you to specify. So, for support, we wanted to make sure that it was very easy for developers to add these types of higher level semantic assertions and restrictions on what should be happening in the program, or their model.  And we also wanted to avoid the common problem of having a separate modeling language or proof language from the programming language. The language that you write the assertions in is exactly the same as the Bosch programming language and anything you can write in Bosch code can be included in assertion and can be checked at runtime can be checked by the verifier can be checked by the model checker, and can be checked by the tester. So this is all there and can be taken advantage of by all of the tooling so we were very happy that we were able to make this completely transparent. There are several places that you can add these assertions so a common one is that pre and post condition, as you saw in our example, and with all of these we allow you to turn them on either always. If you want to make sure that this condition always holds at runtime and will throw an error if it fails, even in release, or if you only want to have them turned on for say your debug builds, or you only want them there for use by the verifier, you can always you can set the flags that enable all of this. We also have data invariance which are very powerful. So if you look at this we have an entity or class called order it has three fields named quantity and price, and the invariant guarantees that anytime one of these is constructed, the name will always be non empty, and the price will always be greater than or equal to zero. So that allows you to count on this invariant anytime you're using one of these types, and it prevents you from accidentally creating an invalid object of this type. Now interestingly you'll notice quantity is not included in this invariant and we would assume quantity always has to be greater than or equal to zero. But we wanted to make it as easy as possible to sort of have a lot of common conditions expressed in the type system as well. We'll talk more about this later but this is one example where the quantity is declared as a natural number. So that actually guarantees that it's greater than or equal to zero and we don't have to wait until we get to the verifier stage we can actually check and catch errors around this in the type system. Finally, we support ad hoc checks and asserts that you can put anywhere in your code for any condition that you want to have verified or validated. And again here this shows a slightly more complicated bit of code stuck in there where we're checking if the name exists in a collection of existing orders before doing something. Right, so I want to emphasize that, again, the assertion language is arbitrary boss key code, not just simple inequalities or order constraints. So, as I mentioned we have more examples of these numeric types which are very common things you want to validate. And these are also known as unit types and we've borrowed them from other languages but what it allows you to do is say, I have a specific numeric type, in this case, decimal, and I want to make a derived type called us dollars or decimals, and, or sorry, percents, and I want these to be distinct types with distinct operations, and I want the type checker to be aware of that. So for example, if I had a variable payment that was defined to be a type us dollars, and I attempt to assign an arbitrary number to it. That's a type error. I want to create a literal us dollar amount and assign that to it and that's perfectly acceptable. We also through operator overloading allow you to build both overload custom built in operators, and define your own operators that allow you to do type safe operations on these values so for example multiplication. It doesn't make sense to multiply to us dollar amounts together. Right, that's a type error. But if you want to take 25% of an existing payment. This is a totally type safe computation will succeed and will produce the expected type of us dollars. So this is a really powerful feature that allows us to easily create custom numeric types that behave in an absolutely type safe way. We can do verification on, we can use the type checker on, and it also makes your code much more understandable and auditable from a human perspective. Going further with this, we've introduced a new concept previously undeveloped in Bosque called type strings, and we support two flavors of this. One of them is basically reg X validated strings. So for example I can declare a type called zip code, which takes five digits with an optional trailing for, and I can also create a type that has a parse operation with any custom logic in it. Now using these, I can say I can declare a very variable string string of zip code and if I attempt to sign it an arbitrary string okay, this will be a type error because okay is a string but I wanted a type string of zip code. I can say okay I'm going to declare some string called okay a zip code string, but this will fail because it doesn't match the reg X. In fact the only one of these assignments that will be type safe and allowed by the compiler is the one where that zip code string actually is a valid formatted zip code. So this allows us to add a lot of rich semantic information to many interfaces that today would be typed as it takes a string a string and a string and now it's a string that is a username, a string that is a password, a string that is a resource requested, and we can actually expose that to the type checker, making the code more understandable by the human, but also lifting this information so that it's available for the verifier to do a much better job with. So here with the these parsable strings, we can also do the type string literal construction, but it also gives us a way to do string literal objects so the parser allows you to take say a path at source test it will construct a path object for you, without you having to explicitly call a constructor. So it allows you to make this very transparent about what are literal object constructions without having to manually expand the constructor yourself. There's a lot more that we're doing in Bosque both from the programming language feature side and from the tooling side, but I just wanted to give you a flavor of what's going on there. And why we're excited and think this is really a new paradigm in the way the programming languages are built and software is developed. So I just wanted to give this code design principle, the desire to make the code transparent and easy to reason about both for automated purposes but also that really helps humans as well with things like these unit types and type strings, and the way it builds a virtuous cycle between adding more and more value to these high level intentional semantic assertions by having the tools that can leverage them, and then feed that information back to the developer. We're also really excited here, working with more fear and finno s to sort of build on the polyglot capabilities that are in more fear that don't restrict us to having to build a full runtime ourselves we can benefit a lot from all this framework that more fear is always done. And we think it's really exciting to be able to work in this finno s space where these high assurance models are very valuable and give us a chance to show the potential for these leading edge tooling and analysis scenarios. So, I think that concludes the set of things that I wanted to discuss. So I'll pass it back to the next section. Thank you. Thanks so much, Steven and mark this was great I really appreciate you taking time to be with us today. And thanks everyone for joining us today to, to hear about this panel. I'd like to echo something that Steven said before we go, which is that regulations are complex, turning them into code is expensive. And more importantly, sharing the effort means that everybody wins. So, come join us, check out more fear and our other projects at github.com forward slash finance, and get involved. Thank you so much, and have a nice day. I'm going to go. I'm double muted. Don't you love it. We do have Steven and mark on who can answer any questions from from the attendees if you if there's anything in particular you'd like to ask, and I do have Steven and mark you want to say hello put your video on to make sure that everybody can see you. Hello. So I do have a question the first question while we give everybody else a chance to come up with theirs. But Steven, can you talk a little bit we just heard from legend. Just before this and and obviously Rob introduced and I identified that there were some synergies can you talk about any conversations that you had about how the two different systems might be able to interact in the future. Yeah, I think one of the things we're really looking at is that legend is a great platform for modeling data and data interaction and transformation. And it's got a, you know, it's a fair amount of logic as well in terms of calculations and transformations. Morpher is very focused on the logic modeling aspect, and from logic modeling, you need data modeling as well. So it's, it's certainly dependent on having good data models. So if you take the two together. I think you've got a very powerful potential platform. And so that's what we're, we've been looking at. I think, yeah, I mean, I think that's just a great example of these two innovations from what would normally be companies that don't work on innovations together, we can actually look at these together through the finalist program. And it just makes a lot of sense. Great. Thank you. I have another one for you. Can you talk a little bit about how Morpher is used within Morgan Stanley I mean clearly there's the potential around red tech. And, and maybe some of your decisions around choosing to open source, you know that code that was built in house. Yeah, and some of the things that we focus on our increasing development efficiency. So the idea is that, you know, we all as developers like to think, or as application developers like to think our jobs are converting business problems into computer problems. And then we realize that there's all this other stuff that we need to do in terms of, you know, regulatory requirements and, and, you know, working with frameworks and complex things like concurrency, etc. And so some of the things that we focus on our are being able to holistically capture calculations and rules and then quickly turn that into running systems through cogeneration. And I think that's where that's where the opportunity here lies. And when you look at something like boss key that with all those advanced capabilities. Then we can look at a language and choose a language based on the capabilities and what we want them to do. And then have those languages target the morpher intermediate language and then use that to then generate running systems. And so, you know, I think from a business perspective, we tend to look at it in terms of regulations, rules like, you know, categorization and stuff like that and being able to look at a system holistically, which is often difficult when you have logic peppered throughout the system. Absolutely. And Mark, the, you're in the research area of Microsoft and if people wanted to get involved with the boss key language. How do they, you know, how do they go about doing that you've provided links before and, and what what's what are the areas of future development, maybe building on what you touched on earlier. Yeah, so the GitHub page is where we've been doing all this work and we've tried to keep this out in the open from the beginning. You know, right now we're still more in the experimental phase we've been doing a lot of prototyping rapid evolution of the language and so this, this is one reason why it's been great to work with everybody on the morpher team and you know, understand where our good ideas actually address the problems that they had and where some of our clever ideas maybe weren't actually that useful in practice and so, you know, having having their input and that real world experiences with great and helping us in some of these experiments. And so we, you know, welcome anybody who's interested in understanding either more from the theoretical side, who wants to just try some of these things out who we've had some people open some pull requests so it's great to have some community contributions from the code. And so at this point, we've, we've reached, hopefully a bit of a steady state where we've got a lot of the features that actually turn out to be useful. We've nailed down most of the things that we need to do for this verification tooling, and we're really trying to step it up and get to the point where we can integrate effectively with more fear and start providing some of the the value that we'd like to the overall project. And this is where it's great that they've set up this sort of collaboration page for us, or GitHub repo for us with the FinOS to start doing some of this integration in the not too distant future. Great, thank you. We do have a question that's just come in. What compiler does Bosque use and can you enforce catch specific regulations at compile time without being explicit. So, can you catch specific regulations that we will let me start at the beginning so the compiler we use I mean that's been part of the language development process. We converted into this intermediate representation which today we just compile the C++ for easy interop with everything. One of the great things about more fear is we wanted to basically live in this polyglot language environment that sort of dominates modern development environments. So if we're able to plug into their IR, we automatically play nicely with everybody else. So as far as things you can check, check automatically in the compiler and the verifier, you know, pretty much any language feature that comes up like we'll verify array out of bounds in accesses integer overflows if you want any sort of these primitive operations that can go wrong if you're a JavaScript developer you know undefined is not a function we can check for anything like that with that would pop up. Also, like I said we really wanted to make it easy for you to add logic that was specific to your problem area, and sort of these high level things like you know sanity checks about values being positive or not creating invalid object types would be if you're dealing with one of these systems that's communicating across restful APIs with databases with other data stores with arbitrary web services. Data is coming in it's very easy to have these sort of parsing and validation errors. So we wanted to make that easy to have this data validation layer right at the front that we can do extensive checking on and make sure that the rest of your code is going to be protected from the kinds of problems that can pop up there. So I answered the question. If it didn't I'm happy to go in a little more detail on something. Thank you. It's not as easy as you potentially like to enable attendees to speak but there's so if there's, oh, that was great. So, thank you. Another question is boss key supported through visual studio code. To do items we have a basic add in that gives you syntax highlighting support. As you saw in the demo, we, you know, all the tooling runs through the command line now we'd like to hook it up to have a very nice integrated environment so this checking just becomes a routine part of your workflow and really you're like hey it's easy for me to add an assert. And then I automatically checked I get all this great value you know feedback value from it so I just want to enrich the specifications and come up with a very, you know, the end product is something I'm very confident in its correctness, and that it matches the underlying business logic intense. Great. Here's another one. So organizations currently use rules engines to capture business rules. How does more fur and boss key compared to those. Who wants to take it first. I'll let you go first Steven. Okay, yeah, I'll go first so I think one aspect of rules engines is that they capture individual rules and less so holistic rules. And I think, you know, rules engines are really geared at giving users a kind of access to creating rules and then kind of running them undeterministically, which is very different than, than you would find and say like a regulation where it's very precise. And you can't, you can't really run it like that. And that's where the developer provides a lot of value so that's one big aspect and I think the other big aspect of rules engines is that they tend to dictate the runtime environment. So they control the rule creation and then the rule execution. And so in doing that you're locking yourself into a bit of technology which when we're talking about regulations again we we want to avoid that we want to be as open as possible to different runtime contexts.  Yeah, and I think I want to echo this. So a rules engine or even codified rules, you have each rule written independently, and then you hope that all of those implementations of the individual rules, ensure that the intended specification and behavior of the overall system is correct. So I think push of Bosch is to allow you to specify in the same code, some of this high level intent, and then be able to verify verification tooling to connect those individual rules to those high level intents, and make sure something wasn't lost in the intermediate translation or the development there. I'll finalize that anything you can do with a rules engine. I mean a rules engine is a nice UI over programming in the end I think. And you can you can basically accomplish the same thing and then have those rules compiled down to to code that's that's very precise rather than as Mark mentioned very isolated. So you can get the same kind of user effect of users can manage rules without them knowing about the intricacies of programming languages, if you want to get into that kind of UI. Thank you I hope that answers the question if not feel free to pop another one into the Q&A. There's another another question feeding on a little bit from from some of the earlier conversation. How open are more for an boss boss key maintainers so you guys, amongst others for accepting pull requests from the wider open source community and you know I know mark you've answered this a little bit. So maybe you want to touch upon to what, what different types of skills you need to have or different experiences in order to be able to, valuably contribute. Yeah, there is the first question is about openness to accepting those pull requests. Yeah, yeah, I mean I think this is a good time to add it on the morpher side that I'm. Yeah, a community driven. And the reason that we, we open sourced it from Morgan Stanley was that we realized that the community could provide more value than a closed source system. I think what we've seen is that when people kind of get to the concepts of, of automation and cogeneration and that that it opens up a different level of, of innovation. And so we're hoping that with the community we get that same level of innovation and contribution so we're totally open that was the whole reason that we open sourced it and then the final as model itself is very open. I think it's, it's very easy to be able to, I mean there's just one, you know, CLA and then you're enabled to contribute so. And then in terms of what kind of skills, basically anything I mean from from the documentation to to, you know, very complex programming language theory and anything in between. And, you know, from the from the Bosque side we were academics so we love to share and learn together and that's that's the best way to do it so we wanted to start open from the beginning. And, you know, thus far, most of our contributors have been other academics and the model has been they've been more forked off the project, done some independent research on it. You know, share back has been publications or their learnings from this. You know, we've also have a number of people who have had smaller contributions documentation bug fixes feedback on language features in the GitHub repository. And those have all been phenomenal as well particularly for identifying some design choices in the language that were not ideal. So challenging for sort of the more traditional contributions just because we've been in such a rapid state of churn and change and experimentation. But, you know, hopefully as I said we're, we're over the big hump on that and you know it'd be great if people are interested in, you know, compilers type checkers all that sort of stuff. You know, we'd love that we also love people who come in and just give some feedback on trying to build a couple hundred lines 500 line project and how it worked and what didn't work and you know open some some some bugs. That's awesome as well so we're very open to everything. And that is if you want to do something as advanced as, you know, write a paper as part of your PhD thesis to I found a bug, and I just wanted to let you know about it we love all of that. That's great, thank you and that really does. I think epitomize our community that that sense of openness and real desire to collaborate and that's my open sourcing in the first place right. And I would just add that within the open reg tech initiative that that I mentioned that finance launched earlier in the year. We've had, you know, a number of opportunities to present to present this to regulators and with, we're actually quite pleased and surprised with the openness that we've had in response. You know, there are some, we think of regulators and rightly so being somewhat closed off and maybe not as advanced in technology as, as, you know, some other members in the industry but we have been pleasantly surprised at the, you know, the willingness and actually the desire to make changes earlier. Ian was mentioning also the, the digital regulatory reporting and, and I think that, you know, using these open tools and this transparency to, you know, much better to in much better ways define what those implementations are instead of running through that you know, 6,000 pages of the text as you as you showed Stephen, and validate the implementations and so we are really optimistic that through projects like this and the initiative and the openness that we're seeing from the regulars to explore how this can be, you know how they can leverage this work that that will make some strides there too. Are there any other questions or any closing thoughts that you have. Fair enough. So, thank you, Stephen and mark, very much, and, and I Tana, your time and contribution as well. And I think James is going to introduce our next panel. James, do you want to. There he is. Stephen, thanks again. Thank you very much. That's amazing. Thank you very much to the more for team for insightful kind of discussion this afternoon. So for those who didn't see my talk earlier I'm James McLeod director of community at Finos, and I have the great pleasure of introducing our next talk this afternoon. So I'd like to introduce you to Paul Graves senior vice president and lead technical architect city and Andrew Carr, head of consulting for Scott log