 We will attempt to get started. I mean, you guys are all spread out all over the room. Feel free to come in. We're going to keep it pretty informal for this. We talked about it earlier and we thought it might actually be good to start with maybe some feedback for those of you who have been in the previous session or some questions. The title of the session is kind of stories from the trenches, what to do, what not to do, stories about regulatory compliance, implementation, technology, open source, whatever you guys want to talk about really. We started talking about it as preparation and we couldn't shut up. So we're going to try not to do that before we hear from you guys. So I just kind of, if you guys want to say anything to open the floor, maybe there's some comments or questions that you guys would like us to cover first. Okay, so that might be, that might spark some conversation. Hi, hi everyone. So let me briefly introduce myself. So I was not in the session that you guys held earlier. I've only been invited as the diversity token, as you can see, which is great, means society is improving. But anyway, so I'm the CEO founder of Ragnosis. We are a regulatory technology, a rake tech company. What we provide is a low-code collaborative platform for regulatory reporting. So in a nutshell, you have all those financial institutions that have to comply with the same rules by the same deadline. And they're all rushing to their implementation. So what we provide is just a way for them to work together to achieve that goal. If all of them just do a part of the interpretation and code it into a functional language, and they can all share the output. And as part of this journey, we are actually in the process of contributing the core part of our platform to Phoenix. So that's one of the reasons we are here today. But as part of what we've been doing recently, we are working on a production implementation of a new reporting regime that's coming live in the US. So all firms operating in the US market will have to comply by the end of the year. And it's effectively the new US CFTC regime. So as part of that, we have many firms, many financial institutions using our platform, collaborating on our platform to effectively deviate the work of interpreting the rules. And as part of that journey, we've also had a number of interactions with regulators under the auspices of can us as regulators deliver rules as code and machine executable regulation, however you want to call it, but effectively like taking interest in what we have done so far. So that's in a nutshell why I'm here. I'm going to channel Francesca for a second, which was, I will not even attempt to British accent, which was to start with maybe what feels painful in that process. I could also start with defining the outcomes or the problems maybe that you set out to solve originally, but from a regulator perspective, former regulator, I just clarify. I think some of the pain points are maybe felt equally on both sides of that border, which is a lack of resources to get the state of the regulatory system in a position to be able to accommodate that type of modernization. I don't know if that's the right word. And the level of effort that's needed to get there is not necessarily worth the result yet, at least from a US perspective, potentially. And there's still this kind of lingering question of who is pushing or pulling the data. And then what implications does that have? If you are, what did we say earlier, starting off from a pushing perspective? Yes. So those are some challenges. I'm just going to throw that out there and see if that ignites any comments or thoughts, or we can go in a completely different direction. Unless, Anna, you want to jump in. See that any potential comment in an issue or a request on an open source repository would be subject to audit, then they can't allow anybody to do that, or then have to screen scrape it all and maintain every single comment while another bank under the same regulatory regime has a single form of developer sign off on it and then they can go forth and do. So clearly there's some misunderstanding. What can be done to kind of unify that and set an even set of expectations? Well, I know, I know, but I've developed regulatory policy for 10 years, so I can't avoid getting involved in it. And I mean, this is where obviously the Gates Foundation are interested in markets where there really aren't particularly in digital financial services where the markets are still so new, there's really not a ton of regulations, and actually a lot of them are. I wouldn't say they're model regulations, but very similar movements have been made because the business model, i.e. mobile money is quite similar in terms of, so we have great opportunity in flushing this stuff out at an early stage for these markets where if you are, if you aren't clear on outcomes or expectations, then this could create like a new cost for industry, which is one that could be much more easily solved through technology rather than kind of individuals. But you know, I'm a conduct regulator for years, that's what I did. And I know you're working in areas where the quant side of it is much more prevalent in terms of outcomes and can be easier for red tech. But I think for me, what we need to understand from the community is the issues that could make it easier or less easy for them to do. So there is definitely a feedback loop that needs to be established where regulators can understand that. Now, what regulators will tell you is there's this term kind of regulatory uncertainty, which was one of the reasons we set up the Innovation Hub in the UK, right, and we wanted to try and cut through that and make it easier for new entrants that we thought were doing something that could benefit the industry to get the message direct from the regulator, you know, you don't need to do this or you do need to do that. But it demonstrates that there's a lot of intermediate activity, particularly in markets where compliance departments have grown significantly since the financial crisis of layering on top. And some of that's about the regulator, some of that's about the regulation, some of that's about the relationship between the regulator and their supervisor and conversation. So not all of this is written, is even written down and certainly isn't all written down in it. So I think the sources for the behavior aren't simply from rules and regulations. Speeches, for example, that would always be cited as a, oh, well, we saw this speech from this CEO. So we thought we'll go down this. I mean, the greatest example I ever heard from a CEO was around behavioral biases. That's a big piece of work. I don't know if you remember around economists in regulation thinking about, hey, look, maybe our regulations are based on like disclosure and transparency. And we're assuming too much that individuals based their financial decisions on rational decision making. If you give them the right information, they'll do the right thing. But you know what, there are other reasons why people do things and maybe the industry could be exploiting some of these biases and this could be what's creating the problems. We didn't really ever at the FCA create rules out of it, but we put out quite a lot of opinion pieces. A CEO told us that he had basically stopped certain products because he was like, I can see down the line, they're going to go down this route and we're going to create rules internally. So for me, there needs to be a feedback. We need to understand where that uncertainty might be. For me, algorithmic underwriting is a really critical space where we need to actually have a really good conversation about that because actually even normal credit products based on normal credit reference bureau processes are being interpreted differently by different companies for different products. So it's not just the regulations that guide behavior. There are all sorts of other things that guide it. But I think understanding from the tech community and the open source community where those differences lie and why it's causing problems and where that might be creating cost or inefficiency is a loop that I think needs to be established from my perspective. What I wanted to add to that is and that's kind of doing a plug for open source in general. But I think it needs just more safe spaces between the regulators and the regulated entities to exchange on those topics. And on some of them, Phinos, and generally open source is a great way to create a forum where those concepts, ideas can be put on the table where a better understanding of the practices, like on the example you mentioned, a better understanding of the practices in the trenches of how people do things may alleviate regulators' concern about how you need to retain those for 10 years or whatever, just having that understanding and then would create an easier path for complying and maybe not having a requirement at all. So I think this is definitely a part where Phinos has a big role to play in being one of those venues in which the regulated entities and the regulators can convene an exchange without any adversarial approach. So I have bad news in the US, right? The data retention policies will vary by agency. They go off of the federal models, of course, recommended by the executive agencies, at least financial regulators. So that might be part of some of the whack-a-mole if you're trying to engage with US financial regulators. What I found, when I worked within the system, that was really valuable is if there are other agencies who have models where they are already operating in an open source way, and there are, they will have data retention policies around their open source activities and that is something that is open and available and could be shared with an agency where perhaps you have a really great executive sponsor internally that's willing to kind of help do that work and that culture, provide that kind of change leadership that's needed, helping connect them with those models or the people in the other agencies that sponsor the open source work is a really great starting point and it will accelerate the conversation. It just de-risks it, right? Because, oh, well, so-and-so is doing it. So they've gone through a thoughtful process. We trust their analysis, et cetera, et cetera. So maybe I'm thinking also, Phinos, this is a great space or I don't know how interested the Gates Foundation, but if there was even just a correlated place where the agencies globally that are participating in open source activity and how do they manage that from a data retention and policy perspective would be really valuable. Those are templates for people to go to. And I think templates is a good way of putting it. I mean, we kind of tried to do similar things, for example, in the OSPOS space. So I think in the open source program office, some of what you're saying actually is not, it's a regulation that refers back to that rather than, let's say, financial regulations specifically, but data retention is one of them. And what we see are people coming together from different institutions and saying, oh, we do this or how do you do that? And how do you weave in this other jurisdictional thing on top of it because you have multinationals and that's the other trick. And if you go to the union of all, that's kind of really hard. But to continue on the plug of open source and save spaces, I would say the same thing we're trying to do with the compliant financial infrastructure project, which is we took a standard, which is the EDM council standard for data in the cloud. And we're trying to implement that standard in terms of code so that you can, anyone who puts data in the cloud can evidence compliance with that standard. Now, that's a standard that a lot of companies came together and developed not financial industry specific. And as far as I know, no one, no regulator has blessed it. And I also understand that a regulator is not going to officially bless any standard. However, if you have a standard that many, many people are using and that begins a conversation, then a regulator might be able to be enabled to say, oh, look, you're missing this one thing added. Everybody adds it. And what's also nice about that is then you have the accounting firms using that standard as well to, because when you get your auditors, your external auditors coming in and auditing you against that and they can use the same standard, that's huge. That's a huge savings for everybody in terms of work and understanding starting that conversation. So I think if we, if we added on top of it, like, like, you know, a menu or a code, like a codified sort of template of rules and then maybe that's another way. Part of what I'm asking myself and the community is, how do we bring the regulators to the table? How do we make it understood that open source is really a safe space for doing that? It takes very, there's no setup costs. There's no agreements that need to be made. Everybody just participates. And maybe that's how we started. But I think the standard at the core of it is, is part of the solution, part of the answer. Can I ask a question? Go ahead. Policy itself, as an actual entity, can be interpreted in a different way. We're vanishing the same way. I, what do you guys think, you know, I think I heard the regulation of the code. Do you recommend that? How can we make use of this in order to paradigm kind of solution? What do you recommend? I'll just start from where I'm at at the moment. But I'm kind of open, and that's why I'm here to learn. You know, for me, natural language processing is probably a better place to start in terms of the kinds of problems that I'm seeing, the kinds of issues I care about, which are much more like, they're much more in the kind of stress testing situation like, what's the norm? What's the range? Where do I prioritize my action? If I was doing it as a regulator, I think as a firm you do that as well. You'd be like, okay, how big is the problem? What's great? What's terrible? What's in the middle? Where are my outliers? That seems to me a bigger priority in terms of getting ahead of some of the problems like I was talking about, like fraud or terms and conditions of products or firms coming into the market that aren't regulated and kind of defrauding people. And when I talk to my partners on the ground, that seems to be the technology they would most like to use from a conduct perspective for the regulators. They just have tons of information. It's mostly written down. It's board papers, product papers, all sorts of unstructured, crazy places. And they just kind of want to get ahead of it, social media analysis. So that's where I'm at, rather than codifying, but that's a particular focus on emerging markets and a particular focus on consumer protection, market conduct issues, rather than transaction monitoring and wholesale markets or whatever. So that's what I'm hearing and seeing from my perspective. Yes, on the Policias Code, I think the regulators need to be very clear-minded about what can be applied in this way and what cannot to put it very simply. It's the difference between principles-based regulation and rules-based regulation. So you only want to codify the ones that are on the extreme side of this, but principles-based regulation are here for a reason. They are useful and they need to stay. But even in the context of principles-based regulation, you may have certain parts of it, for instance. Does this rule apply to me? That could be in itself codified, even if the rule itself remains principle-based. So I think it's a matter of being clear about where you want to apply that. One obvious use case, which happens to be the one that we focus on, is whenever the regulators are looking to collect large amounts of data, and as much as possible, this data needs to be comparable between many, many firms. When you want to have that consistency, that's where Policias Code makes a ton of sense because it's also self-interested from the regulator's standpoint. The more accurate the data they're going to collect, the more omniscient they're going to be about it. So I think that's definitely an area of application of that, but not all of it is. I just want to say, from a regulator's position, when it comes to the actions that a regulator takes, and it's very rarely based on rules. It's much more around the general principles. Now, that could be a point in time aspect of market conduct regulation, but the rule-breaking can be, I guess, indicators. They can be a way of assessing it, but generally it's a principle-based thing that certainly in the UK perspective are the issues that they go after most, the most serious ones. I totally agree with your perspective and I think it's a really important framework for us to think to, and I really love the link between it could be principles-based, but there could be. Does it apply to me or not? Like a binary, yes or no? But I think in terms of where executive committees make decisions, it's 90% of the time from a principles-based point. Yeah, we have a project for that too. We're really trying. So less so specifically on emerging markets. So the effort that we started with Jennifer, for example, around digital currencies, that's one place where we're really trying. Another place where we've started and haven't done enough yet, but we should do more is, for example, Mojulu Foundation is an associate member of ours. So when I talk about our REG Innovation Special Interest Group, in general, how we position our SIGs versus projects is SIGs deal with sort of the problem space, discussing what people want to do, what are the problems people want to solve, and then convert them into projects. And that's the most exciting part because then you create a collaboration on something very specific. So we have the tools. We don't always get to everything because we're a very small team, but it is this community. If you come to the REG SIG and you raise these issues and you have like-minded peers, it doesn't take very many to start a project or even to do an exploration. And one of the things, so for example, Leo and some other, and the Morgan Stanley team just did a hackathon on something so you could do it in a sort of trial way very quickly and see what happens or even narrow down the idea to something very specific. So we have tools for that, and I have to say I wish we would do more, so come and tell everybody what you think we should do. I guess David, who's the co-founder from AIR, they are looking at emerging markets as well. So one of the co-founders of your group has got a focus. He co-leads the SIG. So there is a specific interest and he has links to other things. So I think it's great advice and good opportunities. I don't know if this is value add, but just to pick up on what Jane said around the Open Digital Currency Initiative, I do think where we are right now in this moment of time and being able to rethink the structure of money and the end users of money, the infrastructure that moves money, there's a space that has not been created before for emerged markets, it's developed markets to learn from emerging markets. There is a massive amount of innovation to your point that's happening and is meeting the needs and removing barriers for citizens in a way that we haven't been able to unlock in the West, and it is an opportunity to learn in the very early design phases of this future ecosystem. So it's a specific use case, but I think it's a valuable one that will elevate emerging markets' perspectives and the knowledge and expertise that they can bring to the conversation for the West. Maybe just to... I have one minute as an indicator. I just wanted to talk about another thing which is like the sandbox idea. A lot of regulators around the globe have started sandbox initiatives and a lot of those are in emerging markets because they realize the gap between the need to bridge financial inclusion versus the fact that their own markets were not as developed. And I think a lot of those ideas are being tested out of that, so I think it creates that space for collaboration between the fintechs and the regulators. So one way to encourage that is to take success stories of sandbox being realized in certain countries and trying to encourage or nudge the regulators in others to adopt similar approaches. And that's where I think Finos can play a role as well in promoting that. Yeah, and actually our third partner, Daniela, who's Executive Director of the Hyperledger Foundation and she could make it here, but she would have been on this panel as well talking exactly about that. Hyperledger spends a lot of time working with and talking to different parts of different governments in different countries and helping them experiment with blockchain technology and then kind of what we're trying to do is bring all the pieces together and that's why we started this digital currency initiative is to pull together all of this information and our hope, our next step is to again have a round table kind of conversations, bring participants together and say, right, so what would you like to learn? Would you like to do an experimentation case? Just elevate your knowledge or would you like to try something out and bring in different players to work on that? I guess before we close, but the Atlantic Council has a CBDC tracker that you can it's brilliant, actually it's probably the most comprehensive one I've seen and you can sort by technologies and I bring it up because I think it was Karen with Hyperledger who pointed out that three out of the seven technologies that have been chosen globally are Hyperledger based technologies so if you want to go a little bit down a rabbit hole and see who is using open source globally as they're thinking about central bank digital currencies how that pairs with what type of economy they are etc. It's a wonderful resource so it's the CBDC tracker with the Atlantic Council. We were given the sign that we're out of time so thank you all for coming and engaging with us and please do visit all the resources that we mentioned and we'd love to see you participate and voice your opinions. Thank you.