 Okay, well, hi everyone. Thanks for joining us today for our presentation on the currency reference data project. And so by way of introduction, I'm VJS Chandel. I'm an executive director at Goldman Sachs and I work within our data modeling engineering team. I'm joined here with my colleague, Elaine Fraser, who's also an executive director at Goldman Sachs and works in the product data engineering team. And we'll also have a video of Silesh Pandey, who is an executive director from Nomura working within the data services team. And together the three of us have been co-leading this initiative for the past roughly about a year or so on trying to build out a currency reference database. And so thanks, Elaine. Just going to the first slide. So by way of background and how this project came about, back in early 2020, we were working on the open sourcing of Legend Studio. And I myself led one of the FX-based pilots for the open sourcing with the industry through Finos. And what that entailed was analyzing FX option products and their features. And we were trying to essentially develop the ISDA common domain model, which some of you may have heard a little bit about, just very briefly, the ISDA common domain model or CDN for short. Is a blueprint for representing derivatives and their features. And so the idea with the FX pilot was, we'll try and use Legend Studio to model different products and their features to enhance the CDN that exists. Now, one of the, I guess, interesting discussion points that came up from that work was regarding currency data. And currently out there in the world, currency data tends to be in a string-based format. So obviously you got USD, GBP, and then you have different associated data points to that. So for example, who is the issuing authority of that currency? Now, what we felt was that there's perhaps a gap in the data market for currencies. And that then sparked the initiation of this project and Finos kindly connected us to Nomura, who have been running a broader securities reference database project. And so we started looking into this. Now, the objectives of what we're trying to do here are also, I guess, the benefits to the industry from this work. So the first one is standardization. So what we're trying to do is build a model that standardizes different data points associated to currencies. And you'll see more about that later in the presentation from Elaine. Secondly, we wanna create a central repository for this. So rather than having to go to different sources and pulling data from different vendors, et cetera, we're trying to bring it all together so you have a one-stop shop for whatever currency data that you wish to consume. And thirdly, we want to store this in the cloud because we wanna make it public. So not only from a data consumption perspective, but also from a contribution perspective. And what we mean by that is we want the industry and participants to basically be able to define the data in a common way, but also work together publicly on the workflow behind that data gets approved and added to this reference database. So with that, I will move to the next slide and we have Silesh Pandey, who's recorded a video to talk us through the strategic solution and the workflow behind how this is all going to work. So here we go. Once again, welcome to the session on currency reference data. First of all, thank you Vijay for the great introduction and for setting up this topic today. Vijay and Elaine have been instrumental in shaping up the currency reference data working group and together with the wider community. I feel we have come a long way, especially if I look at the day when we first spoke about the need for modeling currency reference data. Now, one thing we all agreed was that besides modeling, it would be great if we could maintain the currency data in a public store, which could then be accessed by the wider community and something that could serve as a reference for data compliance, et cetera. Now let's take a look at what this proposed workflow would look like or what it can do. So at the heart of the design, it would set a workflow engine which would do all the data processing and decision making. Let's take a simple use case and then run through this model. So consider a new ISO currency that has been introduced in the market and assume that there are two firms, Nomura and Goldman Sachs, that have been considered as data contributors. Now consider a scenario where both Nomura and Goldman Sachs send a request to this currency ref master to add the new record. Let's say that Nomura is the first one to send the request. So first, I want to be provisionally able to check whether Nomura has the permission to contribute or not. Next one is that validation is successful. The engine will do data validation to ensure that there are no discrepancies. If any critical or mandatory attributes are missing or if any validation fails, then the engine will send an error message back to Nomura and the request will be queued up for all the contributors to review and approve. So basically this step is to bypass validations if needed. Now if however the validation checks are successful, then the engine will create an entry in the cloud store and send electronic confirmation to electronic notification to all subscribers of this data. In the scenario we just covered, let's say now Goldman Sachs sends a request after Nomura. The engine will be able to automatically determine that an entry already exists. It will however do a comparison of this incoming record from Goldman Sachs with the entry created by Nomura. And any differences will be analyzed by the engine and will attempt to determine the current value between the two contributors, between Nomura and Goldman Sachs. But let's say if the engine fails to resolve the conflict because we don't expect all entries to be rule-based. So it may not be possible for the engine to resolve the conflict. So in that case, it will policy result for the community to review and approve. Now that kind of summarizes the way we envision this model to work. Now Elaine will talk in great depth about the data modeling but before I hand it over to her, here is a thought for future expansion of this concept. We would like to use the same concept to model other asset classes under the wider security reference data working group. So to give you an example, to illustrate what this future proposal is, let's say when we, let's consider, when we say bond, there's an image in our mind, as to what this bond would structurally look like. For example, it will have an issuer coupon, issue date, maturity date, frequency, et cetera. For every business function in a bank or a financial institution, they normally fetch the bond data electronically from the web data master. Now what if we could define a standard object model to represent a bond? Then now these idea applications that deal with bonds will have to worry about which attributes to fetch or the difference in other semantics or the difference in classifications, et cetera. Of course, there will be a different model to represent different bond types and different functions will have to, will have their own needs or own understanding of what they would need this model to look like. We'd obviously capture everything, all the nuances in the design but fundamentally this will help create a template which could be used by the issuers in the issuance process to promote standardization. Same thing could be used for structured bond product issuance. And so once this objective is made, we could probably deep dive to drive standard classifications. That's the next step. So on this note, I'll conclude my part of the presentation and hand it over to Elaine. Thank you all for your time and we all look forward to engage further on this topic. Thank you very much. Have a great day. Thank you. Bye. My thanks to Salish and to Vijay for the introduction earlier. My name's Elaine Fraser, as Vijay said. I'd like to talk through how we've actually devised the model and the process of our working group. So the first thing I'd like to do is show you if this is gonna work. The discussions that we had initially in our working group were around what requirements we had for currency reference data. And we asked the participants and we had representation from a large number of groups. We asked the participants for their use cases. And the common theme was that people wanted to be able to have the same set of reference data for currency so that it would make it easier to communicate between themselves and regulators and communicate between themselves. Now, this may become clearer when we look at the sorts of things that people wanted in the currency reference data set. So what you're seeing is our draft list of a data dictionary. And you can see that as well as having ISO codes for the currency, we also have an onshore, offshore indicator. And we have things like rounding rules. Now, the ISO currency list will tell you the currencies that are actually issued by countries of the world and used as hard currencies within those countries. But there are other things that you need in a trading context that are not ISO currencies. So the example of onshore, offshore that came up very quickly in our discussions is applicable to countries such as China where the currency that is used internally cannot be used outside the country and a non-ISO currency code is created to cater for that. This also resulted in the need for our item number nine here of vendor codes to be able to actually create mappings between the currency codes used in the ISO list and currency codes used by various vendors or local regulators. So this was our initial list of requirements and from this, we devised our initial model which has since evolved a little bit as you can see from the diagram. So the things we were interested in that I've already talked about, we've got at the bottom here, we have a set of non-ISO codes which would allow us to create mappings from particular issuer data sets such as let's say Bloomberg currency codes back to ISO. We have a data type for rounding so that we can talk about the precision and the direction of rounding. And we also, as we discussed further, realised that there were many more types of issuer than just simple countries. So the ones that we included in our model are obviously countries, but also for things like the Euro, we need to be able to cater for treaty organisations and we also felt because at the time we were still discussing things like crypto currencies and other non-standard currencies that may potentially be issued by organisations that we may need legal entities as issuers. The other thing that came up as we were reviewing the model as well as having an onshore-offshore requirement, there was also a question of whether the currency was actually deliverable. So this is something we are going to revisit because we don't think we've completely understood what it means to be deliverable. But the concern was that, for example, for Brazil and for India, you can use their currency inside that country but if you want to trade that currency, you actually have to do an exchange within the country to another country. So it's not deliverable outside the country. Our next step was to actually look for some sample data. So we started with the ISO list and I think this computer doesn't like my hands because they're too dry or something, there we go. We started with the ISO list and the ISO list, as you may be aware, also has precious metals and test currencies and funds in it. So we started with that and that gave us our first impression of a currency type and right at the bottom of this screen, you can see we have precious metal. We then looked in more detail at this and the ISO list itself has a lot of duplication. So we decided we needed to tidy up this list and make sure that each currency appeared only once. As Salish said in his video, we want to be able to understand uniqueness of currencies. So we needed to do a bit of a tidy up. So we then took the ISO list and we took one instance of each of the currencies and we investigated what we understood to be the issuing country of that currency. So we now have a single list of currencies and for example, Australian dollars, euros, US dollars are actually mentioned several times in the base ISO list. So we just took one instance of each of those and we assigned the appropriate issuing country to them and on this list you can see an example of a treaty organization which isn't the euro. There are a few more in the world than just the euro where multiple countries use the same currency. So we have actually put this data into Legend Studio. We are considering how to store it potentially in the cloud and have it retrieval using other features of query that are available in the tool. So we have stored it at the moment in memory and H2 in this studio project. We can query it locally but we want to be able to use the features that Salish was alluding to allow other people to improve the data set for us by adding extra values and so we haven't actually progressed with a physical store for the currencies yet. The other thing we want to do is we want to improve the model so people have also in our meetings mentioned other things they want to cater for such as understanding the minor units of currencies so the pens for pounds, the cents for US dollars. So once we have our initial set of data stored somewhere persisted and we've actually prototyped the workflow that Salish was describing, we hope to then move on and model other things and create new data sets over this model. And on that note I'd like to hand back to VJ who will describe how other people can get involved in this project, thank you. Back to the slide. Okay, yeah, so final slide just in terms of how you can all get involved and we're obviously keen for more and more participants across the community to take part and contribute to this project. So we run a fortnightly Tuesday meeting, 10 a.m. Eastern time, 3 p.m. U.K. time and so that's open if people do want to get involved definitely reach out. Additionally we do have a mailing list so you can see it on the second point currency-ref-data at finos.org. So any questions, et cetera. And of course the model that Elaine showed within Legend Studio that is all available to anyone who has an account set up with Legend as well so if you want to explore that you can do so and all the discussions and contributions that we're making to the model itself are all done through the studio platform. And finally obviously got a GitHub and issues page as well where you can point out any particular use cases that you would like the group to consider and so we'll be continuing to progress with this project. There's still a few moving parts to it but definitely get in touch with us and on the distros that are available there. And finally I would also just like to give a thanks to Finos who have facilitated this project from the get go and it's been a great experience collaborating with all the other firms that have been involved. So thank you everyone. Hope you enjoy the presentation and I'll open for questions. The model itself is the expectation this will go back into is the CDM and wherever we are let's say using ISO currency would be replaced with this class, new class. So broadly speaking, yes. So right now the way currencies or currency attributes are represented in the CDM is mostly in a string form. So the idea is that with this model once it's fully built out you could essentially create a mapping to the CDM and be able to pass through your data according to the validations and controls that this model will provide for. Now obviously ISDA themselves have been involved in this project as well. So we're ensuring that whatever we are building and what the attributes that we're defining and the standards that we're creating is all in sync with what is expected of the ISDA CDM. So that's the goal that eventually we will be able to plug this model into the CDM. Any other questions? Yeah. So yeah, at the beginning you said that different banks are contributing to this and there's a reconciliation model to decide what goes into your online H2 version, right? But what if the banks fundamentally disagree about the attributes? They have different views on these different things. Doesn't that compromise the ability for your model to be used in all those banks? Yeah, that's a great question and one we've thought about to some depth. So the idea is that a bank can contribute any suggestion that they want and in some cases it will be fairly straightforward in the sense that let's say there's a new currency code that's been published out there and everyone accepts it, that bank will contribute it. It should be fairly standard for the community to accept that. For more, I guess, technical or nuanced use cases where there is a certain view from a certain party, the current kind of short to medium term kind of workflow that we're thinking of is that suggestion can be brought forward and then the working groups that we currently have set up will be used as a platform to discuss that in depth and come to some sort of mutual agreement across the industry. In the longer term, as we built out more of the strategic sort of workflow behind this, the idea is hopefully we can somewhat automate that in the sense that, as Silas mentioned in his video, there'll be notifications sent out to the relevant, I guess, approvers of the data going into this. And then again, if a discussion needs to be had to get more detail, more insights and rationale, then the idea is that we'll meet together to have that discussion. Make one more question, yeah. Yeah, so I have a specific modeling question. Have you thought about modeling the full set of currencies as an enumeration? This comes up a lot in my domain. It has always this like balance between doing it as an enumeration that has advantages. It becomes part of the model itself. So all that negotiation about what currencies are included becomes part of managing the code itself. So it's not a data set that you have to manage separately. We already have tools to manage the code, right? It has come up. And one of the concerns we had when we were developing the model is, as you saw, there are features of the currencies that are important from a trading perspective, such as whether it's deliverable, whether it's the offshore version. If you have an enumeration, you cannot encode that in the enumeration. So when we have talked about this, there is a rationale for having an enumeration. For example, as Vijay was saying, if we want to incorporate the list into other things, such as replacing the string in the CDM, then that is a good context for an enumeration. But we would still need the full model so that people can interpret the data and understand the trading potential of the data because that list in itself is not sufficient to understand the currencies. Any other questions? Yeah. Yeah, where do you draw the line? How do you decide what is and isn't a currency? I mean, is it any crypto? Any commodity could be in there? Or, you know, is the dollar on the same footing as Dogecoin or whatever? Yeah, I'll maybe help you out. You wanna go? Yeah, well, I was gonna pass over to you anyway, but I think the driver is what are people actually trading? So as Vijay said, the origin of this project was talking about FX derivatives. So I'll hand back to Vijay now on that floor. Yeah, so it's a philosophical question that we've discussed as well in our forums, but it's tricky, it's tricky. And I think there's also a different understanding across the industry as to what actually is a crypto, you know, from a regulatory perspective. I know there's sentiment to view it as a commodity from a business side, it viewed as like an FX, others may view it as something else. So in light of, I guess, the blurred boundaries associated to, you know, these different possible, I guess underlying assets, we've taken a sort of phase approach with the project to try and at least define sort of standard fiat currencies as an initial phase and then expand upon that over time and obviously spend the required, I think, level of discussion around those different topics. So yeah, very interesting question. And I'm hoping by the end of this project, we'll have a somewhat of a clear review as to sort of, you know, what exactly is a currency versus not. So yeah, more to come on that. All right, okay, I think that comes everything. So thanks again, everyone for joining us. Thank you.