 Hi, everyone. Morning. I hope you all can see us here. Hi, Nick. I just met Nick last week, or the week before last. And so as Gabb said, I'm Jane Gavronsky. I joined Finos about five months ago. And Nick is even newer to AIR, I think. Yeah, just a couple of weeks in. So I was formerly the director of innovation at the Financial Conducts Authority. But recently joined the Alliance for Innovative Regulation a couple of weeks ago. So I'm new to this space. So forgive my ignorance, I'm here learning today. No, that's very exciting. And I spent my career working in banks delivering technology. So we have kind of two different views of the regulatory and the regulatory tour. And we thought it might be interesting to engage in a discussion. So please, I have a lot of questions for Nick. We're probably going to run out of time. But I'd rather hear your questions as well. So please raise your hands and participate as soon as you can. So my first question to you, Nick, is, as I said, I came from a bank and on the delivery of compliance to regulators, I experienced that banks try to do a really, really good job. But sometimes regulators tell us, well, you didn't quite reach the goal. And there is criticism. And I think Russell referred to the fact that you try to compare yourself off to other banks where the regulators don't quite tell you, but they tell you something. So there is this mystery. And sometimes we use consultancies to help us bridge the gap. What does it feel like from the regulator perspective? What are some of the somatic alignment across the regulations that could help banks be more compliant right away? Yeah, so I think the last couple of speakers touched on this with the reference to some nuts and bolts and standardization or a bit of a shout out to The Box, a really powerful book talking about the role that standardization plays in innovation and drive-in progress. Regulation has not been developed in that way. It has grown up over decades. If you look at UK regulation, it's also the product of multiple mergers of regulators over the years. And there isn't a common underlying taxonomy or set of standards to underpin even regulation in a domestic market, let alone between regulators in different markets. So that just wasn't the method, if you like, of developing regulation, which means that the regulation that exists is largely written in fairly detailed legal form. It is the product of serious intellectual capital in the legal and policy space, not the technology space. And so ultimately ends up with a product that was written in legal prose that then needs to be implemented into code. And so there is that misinterpretation gap that is a real challenge. I think regulators have been a bit blind to it or have perhaps historically just said, well, it's your responsibility as the regulator institutions to find a way through this complexity. But I think increasingly regulators are seeing two things. One, regulation in that form doesn't deliver the outcomes they really care about when it comes to consumer protection, financial crime, resiliency of the system. So they're not getting the outcomes that they really care about. And secondly, the cost of delivering whatever outcome is being achieved is just too high. So the duplication costs, the amount of replication that occurs across the industry, it's just driving cost into the whole system. And what does that mean for a regulator? It means barriers to entry, means lack of competition in certain markets. It means a lack of choice and service for certain customer groups. So I think regulators are starting to see that the form and structure and format of regulation has direct impact on the kind of market that they then oversee. And if they want a more efficient, more open market, they're gonna need to think about the standards and the way in which they constitute regulation. So, excuse me, that's very interesting because that directly to me logically means that, excuse me, that regulated entities should collaborate. Right. So how do the regulators then look at collaboration? With, again, with some caution, I think. Sorry, this is not supposed to be a negative speech, but I guess the reality is they do get a little bit nervous regulators when they see, what tends to happen is they tend to see large incumbents talking about collaborating. And you see that even on the conversations this morning. And the worry that regulators have there is of the sort of antitrust, anti-competitive cartel-like risk that that might lead to. They also have real concerns about liability. And again, the previous speakers have mentioned this. Regulated systems need clear accountability and responsibility. And I think regulators get a bit nervous when they think there's a shared solution, there's a shared endeavor. So who ultimately do we hold to account? And these are some mountable issues of governance and clarity. But I think regulators do worry about that cartel behavior and that question about liability. But I think increasingly regulators are seeing that without collaboration, without community endeavors, without more interagency collaboration, both private and private public, regulators will not get the kind of outcomes that they want in the market. So they will have to find ways of supporting this collaboration and innovation. And so speaking of innovation, what does that mean? How do they look at innovation and what potential for innovation? Have you experienced or what's coming? So I think they probably look at it in three ways. And it's a challenge to lump all regulators into a single bucket. Regulators are very different in their cultures, but also very different in terms of their size, their resourcing, and in some cases, their mandates. But I think what you initially saw predominantly was regulators trying to find ways to foster desirable innovation in the markets that they supervise. So trying to find ways to save the market, you can do new things to serve new customers to provide new product. And so that's where sandboxes and hackathons and opening up regulators to innovators, that's where that came from, was to try and to inject new products, new competition in the market. I think what you then see is a lot of regulators start to see these predominantly FinTech type innovations and think, well, what is the application of that technology into compliance itself? And so regulators start to get into the reg tech space and looking at how technology can deliver more efficient or more effective compliance. And then regulators start to think about, well, at what point do we not only encourage and incite innovation, but do we actually start to innovate and modernize our own way of delivering on our mandate? And again, listening to speakers here, the maturity of regulators on things like open source is woefully low. At the moment, many regulators are just starting to get their own data house in order. They're not even thinking about the technology of the future or the technology to deliver what they need going forward. They just start to think about, how do we come more data-led, more digitally led, more digitally native, and they have a long way to go. But I think they tend to bucket it into those three blocks. What can we do to support innovation in the market? How do we understand how technology can play a role in compliance and then how do we use technology to reform the way we perform our own role and different regulators at different stages on that journey? So what would you suggest then for the regulated entities? How should they think about innovation, knowing or being slightly exposed to what the regulators might be thinking? I think there's a few things. I think one of the things that helps regulators overcome resistance to collaboration and change is understanding genuinely the issues of today in a more granular manner. By which I mean, it's very easy to say we'll stick with the status quo if you've not actually assessed how effective the status quo is. Financial crime is probably one of the strongest examples here where for all the money that is spent by regulated institutions and regulators and law enforcement, there are still trillions of dollars laundered through financial markets. There are still massive drug smuggling rings that launder their money through markets. There are still human trafficking operations that launder their money through regulated markets. So the societal harm still exists. It's not very well-sized. It isn't very well assessed. And there's a moral hazard of anyone individually saying our own systems are not very good at picking this up. But as an industry at large, I think we could do better to evaluate the effectiveness of our own technology implementations and our own way of meeting regulatory requirements. So I think the industry collectively can start to speak truth to powers, probably the wrong phrase, but just be a bit clearer on the downside risks of today's approaches and then call out that actually the industry is keen to mutualize areas of non-competitive advantage and really start to push conversation regulators on that specific point. What will you let us mutualize? What is the downside risk of us standardizing if we do it in an open source manner? Will you be more open to this? And just start to ask those more pointed direct questions of regulators. Most regulators will not have policy answers to that, but they need to be forced to start to develop them. And then I think proving the art of the possible regulators struggle, like most of us, to conceptualize a future where I've seen regulators get on board and be a bit more engaged is where they can start to get their hands dirty. So working in collaborative environments, exploring specific technologies, collaborating with different participants. And perhaps adding others into the mix as well. So I think sometimes just the regulated to regulator relationship can be difficult. You add in some academics, you add in some technology partners. It's a slightly different community. And I think regulators sometimes find those bigger consortia a little bit easier to connect with. So that leads perfectly into my favorite question, which is what can we do, Finneaus and AIR, and how can we help this group to bring this to the fore with the regulators? I think education is a big part of it. I know it might not be the most exciting part, but helping regulators understand actually what is open source, both in terms of the community aspects, the development of shared code, how you as an open source community have thought about managing some of the risks of collaboration, how you have thought about governing the quality of the product, getting regulators to just understand how you use open source in your day to day. Russ's comments really powerful. You know, we use open source everywhere. I don't think that's very well understood to regulators, to be honest. I think they assume open source is a new thing rather than what's new is probably the contribution, the participation, the code development, but the exploitation is not new. But most regulators I think are a bit unfamiliar with that. Regulators will need some help thinking through what their role is in open source. And again, you guys can have some thoughts on that. You know, where do you need an independent regulatory participation? What does that look like? And then I think as you do under Finos anyway, the demonstration through product approved projects is the way to help them. So getting out of the concept into the practicalities, seeing market participants lending and providing assets into the community is a really powerful signal as well of just how the regulated market is thinking about this issue. So I think a lot of it is education, involvement and probably a bit of patience, frankly, because I think this is gonna be quite a challenging journey for a lot of regulators. One thing they might do is associate open source with decentralized finance. You know, they've got similar underpinnings of communities and disintermediation and shared solutions and sort of federated infrastructures. And there is a bit of a regulatory backlash against DeFi generally at the moment, particularly in the crypto space. So I think differentiating open source from decentralized finance is probably also a helpful thing to do. So it's quite a list, isn't it? No, I wanna remind everybody if you have questions, please speak up. Go ahead. Hi, Nick, I'm James. Hi, James. So coming up, folks, myself from Sousa, we're having a conversation yesterday about how engineers in dispell the myths around what can and can't be done. And, you know, because certainly from my experience of working in bank and engineering teams, you know, the reason why things can't be done is often down to the regulators, but people don't know what the regulation is that's stopping it. It's something that's being passed down through the chains of authority from one person to the next. So do you think that there's an appetite for people within the regulators themselves to come together with people from the open source community or within other banks to kind of have a Q and A and kind of discussion, do podcasts or webinars, you know, to ask some questions, like are we actually about to do this type of stuff? To just blow away the grass roots kind of like cobwebs. So I think, yes, is the short answer. There is a growing community of regulators that are prepared to have those conversations, but they're quite finite in number. I think that's part of the challenge is there is just not that many people currently working within regulatory agencies who understand these topics in the kind of detail that you might need in order to have a properly informed debate and discussion. So regulators instead have tried to piggy-in-hole almost those conversations into environments where they have some semblance of control and where they can resource them appropriately. So they've tended to do that through direct engagement, through sandbox experimentation, through specific hackathons on themes that the regulators care about. They're still useful environments to surface exactly the conversation that you're talking about. I think where regulators are probably not quite necessarily is to give a policy pronouncement on things like the security of a certain technology approach, solution, model, method over today's solutions, models and methods, in part because they don't currently assess the effectiveness and capability of today's. So I think, yes, there is an appetite. Many regulators are tiny. So they don't have many folks who can have that conversation, but there is a growing cultural desire to do so. But again, I think the educational piece can really be really important. And regulators are starting to reform their own human resources and capabilities. So it will become easier, but I think there's appetite, but not that many spaces to do it right now. Yeah, I keep thinking about what Liz said about the fact that there were no standards for nuts and bolts in the late 18th century, so. Yeah, exactly. It took a while. We've only got a couple of hundred years to catch up. So I know it's early days for you, Nick, at AIR, but what are some of your thoughts around what you want to do to continue that education process and create the collaborative environments? Yeah, so there's a few bits we want to do. So our ultimate mission is to try and support regulators to become more sort of digitally native in their approach, so to move away from the really manual, analogue approaches of regulators of the past. And to do that, we sort of see both a role for us to play in stimulating and supporting individual regulators to become more conversant, more knowledgeable, more understanding of innovation trends and how to embrace them positively. But then we also see a space for, as has been discussed already, the conversation and development of shared solutions for regulators. Much like the industry has a common need to comply with regulation, many regulators have common requirements in terms of supervising their markets understanding and measuring harm and risk, just working through their own data, aggregation, combination and analytics challenges. There's a whole standardization piece that's missing within regulators. So we want to try and look at working out where the common infrastructure layer needs to exist across international regulation and to start to catalyze communities to help build out those assets. I think there is a space, particularly in emerging markets, for the development of shared solutions. I think more, did I say developed or developing markets? Developing. Developing markets. I think in more developed markets, regulators are nervous about sharing technology and code solutions. But we want to try and push that. So I think there will be some of the spaces, like looking at the common standard infrastructure, be that data standards, be that API standards, be that thinking about the way in which the regulatory system is codified. So you've got projects like the regulatory genome project, they're in that space. You've got pieces looking at the red tech taxonomy and how to codify regulation. So I think there's definitely some work there. We at the FCA had a passion and desire to look at moving all the way to sort of machine executable law. And I still think there's some space to explore there about how do you move from the current expression of policy and law into an ambiguous machine readable, machine coded form, and then potentially for certain areas of regulation, like reporting, could you move to a fully executable form of code being expressed by regulators? There's still a lot of research to be done there. So there's some of the things we want to look at. But at the same time, we'll just be playing a big role in trying to catalyze innovation efforts in different markets. We will run hackathons and projects and programs to try and lift regulators capabilities there as well. See, we had a question over here. Hand gone down. There it is. Yeah. You were just talking about it, but we had something. Yeah, so how far along are we? Bizarrely, a long way along and haven't got very far. So I think the FCA's been looking at it with the Bank of England for a couple of years. I think the challenge has been two or three-fold. Historically, the challenge was there weren't sufficient taxonomies and models to be exploited for a very context-specific scenario like regulation. That has changed as the vendor community has worked to both build applications but also underlying taxonomy standards. So I think we're kind of moving further to having something that could be exploited. I think the challenge still though is that regulators don't know the path to move from their implementations today to a version of the future that looks more machine coded and more machine readable. So I actually think there's probably work to do in communities like this to help regulators know how to make that transformation step, whereas most are looking at machine coded regulation only for new regs at the moment, which is good. Might reduce cost of change, but how do we also sort of retrofit to the existing? I don't think many regulators have really worked out a strategy to do that yet. So again, some of the thoughts you guys have had about how to implement and how to transform and how to move forward with these open source models would be really helpful. So there's still quite a way to go. The FCA Bazaar is a principle-based regulator with 10,000 rules. So there's a bit of a dichotomy there between are you genuinely principles-based or rules-based? Other regulatory systems have even more rules that don't overlap or interact with one another. So there's a lot to be done to codify these specific requirements, but it does feel like an area of great opportunity where we to kind of seize it. But I think retrofit into today is one of the big challenges, knowing how you do that, I think it's still to be worked through. Yeah, so yes, I think is the answer. That feels like the obvious sort of routine is to start standardizing on form, like the language use, the words use lexicon. What we started to find though was that, I have to be careful how I say this, even regulators don't have a common interpretation of what a requirement actually means. And so to codify that in an ambiguous lexicon is quite difficult. Partly that's because the regulation has grown up over decades and the original intent behind it has perhaps got a bit lost in the detail over time. Partly it was, frankly, it was written by an army of lawyers and policymakers who weren't necessarily thinking about the unintended consequences of the draft and when they wrote it. So to get to kind of an unambiguous interpretation is tricky, but if it's tricky for regulators, it's certainly tricky for the industry. So you've got a regulation that's embodied as maybe a thousand rules, as you mentioned. Yeah. And they're not machine executable. They're not machine executable. How for the likes of Deutsche Bank, you must be submitting millions of records that must adhere to these rules. How can you be sure that the rules are being followed if they're not machine executable unless you've got an army of people that are reading the rules and ticking each row? I mean, how does it actually work? Well, precisely. It's far easier for you to say that in those terms than... Was that a question? I mean, that's the reality, isn't it? You've got thousands of rules being implemented by thousands of entities through millions of people codified into thousands of systems, all of which are built bespoke. So what is the likelihood that all of those things together are achieving the things you actually care about? Seems pretty unlikely, doesn't it? See a comment above about anti-money laundering and human trafficking. So how do you... Standards to start with, but potentially even implementations of those standards. Do you see that as a potential step forward for the regulators at least to use some of those standards? They don't have to necessarily endorse them. They don't necessarily make public statements about it, but do you see them comfortable or can that be a way to sort of at least kind of meet in the middle? Yeah, I think it is a way or the way to move the dial forward. I think until you had communities like this that had buy-in and obvious buying and participation of large institutions in the financial markets, until such a community existed, very hard to sort of lean into a standard like that. But I think when they come out of communities like this, then it feels obvious the regulators should embrace them. I think regulators got a little bit stung with the promise of standards in the past. So there have been attempts to try and come up with global standards on certain things, LEI or something like that, that was just dogged with years and years and years to frankly come up with a way of describing in a single code an entity. So, you know, there's a long way to go from LEI to usable data or technology standards to underpin the genuine transformation of financial markets. But I do think communities like this with their multi-party participation and the involvement of big incumbents are an obvious place where those standards can be developed. Yeah. So my last question is for the reg techs who are participating in the space, I think in our audience, it's probably banks and fintechs, reg techs. How can the reg techs participate? How can the banks work with the reg techs and create this collaboration? Of course, through Finno's and Error, but, you know, to move the ball along. Yeah. So, I mean, the reg tech industry has struggled, I think, to kind of achieve the scale and impact that it probably can and will. And I think that's partly because of the proliferation of very small players in the reg tech market, which have developed niche solutions that don't obviously plug into the existing infrastructure of a large incumbent. I think there's something about reg techs probably partnering up or hunting. I think I said to you on the phone before, hunting impacts to offer a more holistic solution to the large incumbents to make it worthwhile to go through the procurement, security, IT integration challenges. It still feels like reg tech is one of those industries where there needs to be a sort of platformization somewhere, an interoperable layer built somewhere, because at the moment, they're just all of these individual, largely cloud native, largely API driven solutions, but there's no simple way of integrating those into many of the large institutions existing stacks. So, is there a play, sort of a middleware play, where I'm just going to, I'm not a technologically stomach accountant. Sort of Lego blocks. Yeah, like a Lego blocks or an app store, where you just go on and you're accusing your reg tech solutions, you're not going to need locked in into the infrastructure build, there's someone playing that marketplace and connection piece. I think there's still a gap in some of the reg tech firms in demonstrating values. There's a lot of promise and concept proving, there isn't a lot of value proof. In part, that's because they can't connect with the large institutions to access the underlying data to show the solution. So, you're seeing a lot of accelerators and indeed regulators now looking at, what is the role of synthetic data to prove the efficacy of a technology solution. You're seeing more digital sort of sandboxing and testing environments for the industry and reg techs to come together in a safe space that isn't on the institution's own stack and start to play with the tools a bit more. But I still think, I think the reg tech industry is probably going to go through a pretty substantial merger and acquisition process to try and deliver more potent, sizable institutions that the big incumbents can work with. But yeah, I think standards will play a role, but it's probably more technology and data standards that underpin reg tech solutions. Again, comment over the back earlier. There isn't a common lexicon, there isn't a common taxonomy for reg tech at the moment. That makes connections quite tricky. So I think there's probably some work to do there as well. That sounds like a lot of potential. I'll see you later, work. Thank you. Thank you, Nick.