FINOS

Financial services teams have been consumers of open-source technology for a long time, but now they're starting to dip their toes in the contribution side as well. Things are starting to change as a lot of organizations in the space are beginning to give more weight to the idea of using their resources to help maintain and improve the open-source projects that they use.

FINOS champions open source use in the financial services industry. In this episode, Ben talks to FINOS' Senior Technical Architect, Rob Moffat. Rob tells us how FINOS provides open-source software solutions that help address common industry challenges and drive innovation that benefits all organizations involved. Join in and learn the prospects lying in wait for the future of open-source fintech!

---

I have a very interesting episode planned for us. I have Rob Moffat with me, who works for the FINOS organization. For some background, I gave a talk at an open source conference in Dublin and heard an interesting hour of discussion about FINOS. I’ll hand it over to Rob to give a little bit of background on who he is and the FINOS organization.

My name's Rob Moffat. I work for FINOS, which is a software foundation. It's part of the Linux Foundation. It deals specifically with the finance vertical. We are trying to champion the use and adoption of open source and our contribution to open source within finance. My job within FINOS is as a Technical Architect. I have a couple of what we call strategic projects that I'm trying to push forward within FINOS. My background is in the finance industry. I’ve worked for many years in finance, so I'm well placed to work on those projects and to try and talk to the people within the finance industry who might be interested in contributing.

You've got a pretty extensive background in financial services and software engineering. Are you able to give us a little bit of a quick history lesson in terms of your career that started many years ago? I’m curious to know how open source software and open source projects have evolved within the financial services sector in that time.

That's quite an interesting story. Probably in early 2000, I started working at Deutsche Bank within the risk reporting area and building software for them. I'm a software developer. I have a Computer Science degree. That was my first brush with open source. I was using tools that were available then, like Tomcat, Eclipse, and things like this, which were some of the early open source Java tools. I worked at Deutsche Bank for several years. I worked at RBS following that, but working in the credit risk and market risk parts of RBS. Following that, I took a few years out and became a house husband looking after my young family.

Once my children started back at school, I started contracting and went to work at Credit Suisse. When I was at Credit Suisse, I was again working in risk and P&L. I was building back testing systems for testing some pretty complicated financial calculations. One of the pieces of open source software I used then was a tool called Concordion. It's a bit like Cucumber. It's like a tool that allows you to build unit tests or automated tests but ties the documentation of those tests to the actual tests themselves so you can get an overview of whether they're working or not. I wrote an extension to Concordion that allowed you to build tests using Excel spreadsheets and still produce that documentation.

In the evenings, I was going home and adding functionality to Concordion. In the daytime, I was going and working at Credit Suisse and trying to use this software to improve the tests we were building for this risk calculation. Credit Suisse was getting a great deal out of me at that time. I was doing these two roles. Following that, I got a bit burnt out from all the risk side of things. I went to work at HSBC doing Symphony software development. Symphony is a chat platform that's used quite widely in banks, and it's used because it's super secure. The Symphony team has put a lot of effort into making sure that the messages that get sent on Symphony are encrypted both in transit and at rest.

I built lots of bots and applications on top of Symphony. At that time, I got to know the Symphony Software Foundation. I went to some events where people were showcasing their bots. I met the team from the Symphony Software Foundation, like Gab Columbro and Maurizio Pillitu, who started the Symphony Software Foundation. That eventually became FINOS. That was my first brush with those guys. This was years ago. I left HSBC and went to Deutsche Bank again to set up a Symphony bot practice at Deutsche Bank so that we could help developers at DB get as much out of building bots on top of the Symphony platform.

What I found there when I got there was that I was doing a lot of work over again. I was rewriting a lot of the code that I'd written at HSBC but for Deutsche Bank. That was frustrating. I realized that if I carried on being a Symphony expert and got a third or a fourth job working on Symphony, I would end up repeating myself over my career. It was important to me while I was at DB that I tried to open source the work we were doing there.

Deutsche Bank had open sourced a piece of software called Plexus to great industry acclaim and publicity. There was already a precedent at Deutsche Bank that they were interested in doing open source software and a few other pieces of software and followed along in the same manner. I was able to talk to the open source program office at Deutsche Bank and start working on open sourcing my Symphony tools that my team had been working on.

By and by, we ended up donating those tools to the Symphony Software Foundation, which has now become FINOS. The story there was that they left the aegis of Symphony and then struck out on their own, and eventually became part of the Linux Foundation. I was reunited with these folks from FINOS and was able to work with them to open source what is called the Spring Bot Project, and that lives on inside FINOS now.

I'm old enough to remember the Tomcat and Eclipse days. I got good memories of all of that stuff. Is it fair to say that back in those days, financial services organizations were very much like consumers of open source and, for whatever reason, maybe lack of understanding or concern about legal aspects? Is it fair to say that that shift from being consumers to being both consumers and producers has shifted over time to where it is now?

This is the nub of it, to be honest, because we are at an interesting inflection point now where financial services have long been consumers of open source. At this point, we're starting to realize they're starting to dip their toes into the contribution side of open source as well. This is why I joined FINOS. I was very interested to try and help out with that journey.

We are at a really interesting inflection point now where financial services organizations are starting to dip their toes into the contribution side of open source.

There are pockets of contribution going on in financial services now. Some firms are more advanced than others. Some firms are still trying to figure this stuff out. Nowhere is it particularly ingrained in the culture of financial services. In fact, the culture of financial services, the risk aversion, and the secrecy and compliance elements of financial services don't lend themselves to contribute to open source. There is quite a quite big change of regulations and compliance perspective that needs to happen and everything else needs to change to allow this to become possible. This is a super interesting area, I think.

‍

Was there something specific that happened? Maybe one of the big banks put a flag in the ground and said, “We are going to start doing this,” or is it a function of time? I'm old enough to remember how banks and a lot still do, pay huge license fees to IBM for WebSphere or all this stuff. Whereas if you were an engineer who is 25 years old or something, that notion would be odd and unusual. Did anything significant happen or is it a function of time, do you think?

The Symphony Software Foundation, now FINOS, has been trying to push this for years and they've always had backing from financial services. They have members that pay them an annual subscription to try and bring about this very change of making financial services, engaging more with open source, and getting involved with open source in a bigger way.

They've been pushing on this for a long time. It's like pushing a battleship. It's moving very slowly, but over time, you can see things starting to change in their favor. It is a long process. Every year, more and more companies join FINOS and so they have a bigger set of subscriptions in order to try and push this forward and employ people to make this happen.

If you look at it from the bank's perspective, a bank is a large group of people. There are all sorts of different concerns and opinions within the bank. Certain groups are dead against open source. If you are like a security expert working in a bank, you are with the idea of allowing stuff to start contributing to open source, yet it's another way in which you could lose control of data.

On the other side of the house, if you are part of the engineering discipline within the bank, let's say you are using an open source product and find some bugs in it, you've got two options. You can either take that code and fix it and maintain the fix within your own organization, which can be laborious, or you can try and contribute back. That is obviously the right thing to do, is going to save you time in the long run, be lower effort, and you own less code at the end of the day.

From the point of view of engineers, it's a bonus, but you have to reconcile all of the different concerns and all of the different risks across the organization. None of this is going to work out unless the overall balance of risks for a financial institution works in their favor. It is part of FINOS’ mission to try and persuade everybody that they are better off with open source and trying to embrace open source. There's no one event that's happened that's moving this forward, but over time, things increment.

We had Log4Shell, and that made people very aware of the fact that they had all these open source dependencies and they had to right concentrate on supply chain security. The idea that they have vulnerabilities in their dependencies and that they should be caring about those and sponsoring their development of them and maintaining them looking after them is something that's come to the fore now. It’s events like that that shape the thinking within these large firms.

To talk a little bit about the inception of FINOS as an organization and how it came out of Symphony, can you talk a little bit about that? Does the Symphony project lend itself very well to open source projects and contributions? How did that come about?

I was working at HSBC at the time this was all going on. I was able to get a front-side seat to what Symphony was up to and be one of the earlier adopters of Symphony. I wasn't part of FINOS at the time. I don't know all the ins and outs, but I can give you a bit of history on this. Symphony was set up by banks in a consortium arrangement. They had an initial donation of code from Goldman Sachs of a chat platform which they eventually called Symphony. The reason for this was that they were worried about people surveilling the messages that they were sending each other.

By having this ultra-secure chat platform, they were mitigating that risk. You had this consortium of banks. I'm not entirely sure why this happened, but I think the banks themselves asked for part of Symphony to be focused on open source software. They set up the Symphony Software Foundation run by Gab and Mau, as I was talking about earlier.

There was then a difference of opinion about how Symphony should go forward. On the one hand, the Symphony Software Foundation felt that Symphony itself should be open source or that large bits of it should be. Whereas Symphony, having a profit motive and wanting to make money, thought that open sourcing their crown jewels essentially would not help with that action. By and by, those two institutions split apart and the Symphony Software Foundation left and became FINOS. It's interesting that both of these organizations are close to one another now despite that initial rift.

We have lots of projects within FINOS that are donated by Symphony, including the actual UI component of Symphony itself and all of the bot development toolkits and things, including the one I wrote, the Spring Bot toolkit, which is all part of FINOS and part of the landscape now. There's a very strong open source story around Symphony now, which in the past wasn't quite the case. We work very closely with the Symphony guys now. They consume lots of FINOS’ standards and projects, but also donate their own as well. There's quite a nice synergy going on there.

Can you talk a little bit about FINOS itself and the charter that it has or the governance structure and what its goals are?

I can talk a little bit about that. FINOS is all about trying to advance the state of open source within financial services. To that end, we have members and we have three kinds of membership, platinum, gold, and silver. We have associate members as well. You can see all of those on the FINOS website. Members will pay a subscription, so every year, they'll pay their dues. As a result of paying their dues, they get lots of benefits for being members. One of those membership benefits is we have a board that decides where the money of FINOS gets spent, which are our strategic projects, and which projects we're going to invest in for the year.

‍

We also run events and things, so the members themselves get involved in the events and talk at the events, produce expos, or help us with the keynotes. We are trying to advance the agendas of our members as well. We also produce training. As part of the Linux Foundation, there's quite a large library of different training and certifications that you can take part in. We run software. We try and help our members market their projects, collaborate with each other, and collaborate around the industry on open source projects. We are an incubator as well for new ideas and initiatives that the members want to launch.

There are quite a few different strands going on within the organization.

FINOS is very fertile ground. There is a huge amount going on. It's difficult to keep track of all of it and also to try and decide which of the things to focus on hardest and which things matter the most. We spend a lot of time worrying about that and trying to focus on exactly the things that we think are going to make the biggest difference.

From your experience over the years, are you still having the argument with people about those benefits and stuff, or do you feel like the dam's broken a little bit? You said the membership's increasing. That partly answers the question, I suppose.

If you'd said to me years ago, “Are banks ever going to do open source and allow people to contribute to open source,” I would have said, “Absolutely not. This is never going to happen.” At places I’ve worked in the past, it's been like a sacking offense to exfiltrate code out of the organization.

Maybe this is a bit hypothetical, but if you'd found the Log4j vulnerability and submitted a patch to that, you wouldn't have thought about doing that.

If I'd done that on a work machine, in work time, and maybe emailed the patch to the maintainers of Log4j, that would be serious trouble right there, even though perhaps I could have averted an enormous global calamity as a result of it. That would not have gone down well.

It changes between organization to organization. From your experience, the banks you've worked in, has that changed now? If you were to say, “This is going to result in billions of dollars' worth of value destruction, and here are the reasons why,” it's interesting. We're talking about this notion of drive-by PRs. It's like one line of code or a documentation update that's a broken link.

I don't know the technical details for the Log4j, but it was like a single thing that you could do to prevent that exploit. Are those perceptions changing? I can understand. I know some algorithm that makes the bank a lot of money. Obviously, you're not going to be doing that, but are the myths clearing in terms of the classification of these different sorts of things?

One of the projects I'm working on is called Open Source Readiness. To give you a bit of a flavor of this, what we do is every couple of weeks, we get together. We have a special interest group. This is composed of a lot of our members or a lot of the people who work on championing open source within their organizations. There are people in all these organizations that are bought into the idea of open source and get it and think it's great, but they're trying to unlock the value of it for their organizations. We get together with those champions every couple of weeks. What we are trying to do is document how to change an organization and how to open it up to doing open source.

What we are finding is that there are various different ways to do it. You can get these trial projects where the organization will say, “You've got a board-level agreement. For this one project, you can give it a go. You can try and use open source on it. Maybe we'll see how that works as a sourcing approach. Instead of doing it in-house or going to a third party and getting a proprietary solution, we'll try open source and see how that works and we'll give it a go.”

The other way of doing this is to tackle it head-on and think, “At the moment, within the bank, we have all of these different regulations. We have all sorts of policies which together mean that you can't do open source.” For example, there might be a policy on communication which says we have to store all communications for five years. We might have a policy around private personal information that says, “We are not going to allow people to use social media.”

Policies like this end up meaning things like Slack or GitHub get banned and you can't contribute. You can't meaningfully interact with those things within the bank. That's a well-meaning thing. People are doing that because they're trying to adhere to those policies, but at the same time, as an accident almost, it's stopping open source contribution. What we are trying to do is work with all these policies and understand them and then try and navigate a way through it where people can construct their own policies and change the policy within their bank and allow for open source to be allowed and to get done.

That's like the gold standard of this. Doing it on a small scale is something you try first. You try and do a risk analysis and see where it gets you tested out. When you are ready, the organization can start to think about, “How do we codify this into the ways and workings of the organization and make it something that everyone can do?” It’s early days. To me, that seems like the way forward, that we get to a point where it's part of almost the regulatory framework of an organization that they can contribute in certain areas.

Going back to what you said about the secret source, if you've got some high-frequency trading algorithm or something, you don't want people to stick that on GitHub. That might be a serious money-making thing for you. It's not like we can have one size fits everything. It's not like every project is going to become an open source project, but you should be able to do some risk analysis and say, “We should be contributing a few of these projects. It would be better to collaborate with our peers on monitoring tools or something like this rather than everyone having to build their own,” or, “We should be allowed to contribute back bug fixes to React, Angular, or whatever else as we find them rather than having to hide them behind our firewall.”

It seems like you could argue that maybe things are a little bit backward in that regard because what you're talking about here a lot isn't financial services. It’s more like the bureaucracy of large organizations, which is completely understandable for anyone who's worked in a large organization for any period of time, which doesn't include me because I can't deal with it. It's no one's fault either, is it? It's large organizations, large groups of people. It's like a large ship, like you said. It's interesting what you say because no one's going to go, “I’ve written an algorithm for a high-frequency trading engine that makes us a bazillion dollars a minute. I'm going to go and push that onto GitHub.”

At the same time, what's stopping them from bringing a dependency on an open source tool like Log4j into that project? One of my housemates was working at Chase Bank at the time. They were using Tomcat and things like that. This was many years ago. I think about the XKCD cartoon that I always bring up on this show as well about the big machine with a little thing at the bottom that's run by some guy in the middle of nowhere with no thanks or money. That's been happening in financial services for decades.

The Nebraska problem. You've got this one guy in Nebraska supporting. As you say, for twenty-odd years, we've been using and consuming open source without worrying too much about that. Part of this whole open source journey is we've got ad hoc usage. Everybody's using this stuff, but then you've got to think, “How can I use this stuff in a safe or compliant way within an organization?” That means looking at licenses and understanding the license requirements of the software you're using, looking at vulnerabilities, and making sure you are up to date on vulnerabilities and that you've got processes and controls in place for handling that, looking at software inventory and making sure you know what's in production and that it matches up to what's on your build systems and all this thing.

There is a whole side of using open source properly that people are still coming to grips with and all the supply chain security stuff, making sure that when things arrive in your organization, they're properly scanned and vetted. You hope that they're not going to have lots of zero-day vulnerabilities in them malware and whatever else. We are trying to put together processes and practices around this.

There is a whole side of using open source properly that people are still coming to grips with.

It is a bureaucratic problem. These are big organizations. Bureaucracies are self-serving in the respect that they're trying to avoid change and keep themselves the same. This is why something like FINOS is super important because we are an outside agent that can come in and try and instigate change basically and try and show people the way forward to a better way of working. That is why they pay their membership money. They're paying us to try and help them find a new way of working and to change essentially.

Is that a bit like me joining a high-end gym and then thinking like, “It is costing me £100 a week or a month to go to this gym? I better go to the gym.” Is there a little bit of that to it?

I’ve never thought of that before. I do like that analogy. Sometimes you have to pay some money for something in order to get it worked out.

That's the thing. It's like you say. If it was an internal part of the organization, then it would be easy for the bureaucracy to push it and brush it off as like, “There's a lot of people in here needing things.” I don't want to ask for specifics but in terms of the pragmatics of how those things are happening within organizations. I often read these CVs and have no idea what that is technically. The Log4j one seems quite understandable and potentially maybe quite spottable kind of thing. For an organization like a bank, that's a little bit more progressive in this regard. How have they gone about making that possibility that your one line of code patch can get into that code upstream?

On an immediate, simple level, something like Log4j, once that was discovered, there were new versions out pretty much instantly. The banking sector was pretty quick to jump on this and start scanning its environments. They generally have a good idea of their network which are the vulnerable parts, which are outside accessible parts versus internal parts of the network, which are less vulnerable to attack. They can then go and look at those systems, figure out whether they're running dangerously open versions of Log4j and they can go and start patching them and fixing them up. They were pretty quick at leaping on this and turning it around, but that's one issue.

If the same thing happens tomorrow or the next day, you're back with the same problem. You're going to have to do the whole same thing again. The question is, how do you improve matters from there? Going back to the Nebraska problem, one of the things that people understand is that you have to support open source now. Banks are starting to look at, “What are the dependencies we have? Which are the vulnerable dependencies? Which are the ones maintained by the one guy in Nebraska versus those that are part of the Apache Foundation or the Linux Foundation or something?” They are starting to try and analyze whether there is a threat to them through those particular dependencies.

This is an argument for open source within banks. If you can start to make people at the board level aware of these risks, you can start to say, “We have a dependency risk issue here. These are some of the threats that we have to figure out. We should be investing in open source and we should be adding maintainers to these projects to keep track of these things.”

They might have a strategic requirement, like React or some other library, let's say Prometheus or something. You would want developers in the bank to help maintain that code and keep it up to date so that it's there in the future when they need it rather than it getting abandoned. Now we've got to start flailing around, looking for something to replace it, and then reworking all of our systems.

There's that understanding of that dependency risk and the threat that it poses. By looking at these different kinds of risks, you can start talking about the language of the C-Suite. Another example is talent, staff risk. If you have like a critical open source project that you are using, one thing you might think is, “This is a great open source project. Let's hire that guy and get him in the company doing that project for us.” The problem is, if you don't allow him to do open source, he's not going to be able to engage with the project that he's written. He's either going to leave or the project's going to die. Your whole strategy of like, “Let's hire him in anyway,” has failed.

If you want to support open source, you have to start allowing people to contribute. The one I mentioned earlier about forking the code base, you can't fork the entire code base every time you want to change something. You then start having to maintain all these forks. Every time the upstream changes, you have to update your versions and you're in a massive maintenance hell then. That's not an appropriate way to handle open source risks either.

If you want to really support open source, you have to start allowing people to contribute.

Once you've got to this point, you start to think, “These are good arguments for us doing open source.” The other great one is the strategic element. Companies like Google, with things like Kubernetes, Chrome, and Android, are super good at doing open source and it's a strategic investment for them to have these projects. What if somebody in the banking industry comes along with a strategically vital open source piece of software and changes the banking industry and you are not even doing open source? You can't get on the ship and start helping steer that. You're like a passenger. This is a strategically compromised position. This is another thing you can start to use as a tool to say, “These are all good reasons for doing open source and contributing back.”

There are also a number of actual projects in and of themselves that are part of the FINOS foundation. Are you able to talk a little bit about those and maybe some of the origin story of 1 or 2 of those? Have they all come out of member organizations?

I'm going to talk a bit about the FDC3 Project, which is one of the ones I work on. This is a big project for FINOS. It's super popular with our members. FDC3 is like a desktop inter-op project. The idea is it provides a standard to allow different applications to interoperate on the desktop. Let's imagine you are a trader and you have 10 different windows open on your 6 monitors or whatever. Maybe you're looking at the Tesla stock in one of those windows. What FDC3 allows you to do is propagate that context to all the other windows as well so all of your other windows will update to display Tesla too.

You might be able to click a button and say, “Start chatting to the Tesla dealer,” or, “I want to share this piece of Tesla research with somebody who tends to buy Tesla,” or something like that. As you change your context, if you went to an Apple stock or a Google stock or something, it would all update for you and you'd get the whole desktop working as one. This is a super big project for FINOS, and we had a hackathon. We had about 100 people show up for the hackathon. I can't remember, but maybe we had 20 to 30 different projects. Out of them, about a quarter were all about FDC3 and 3 out of the 5 winners were FDC3-related projects.

It's a big thing. There are always loads of FDC3-related software products, tools, and vendors showing up at our events. This was a project originally contributed by a company called OpenFin, which was one of the first desktop agent vendors. Everybody else in the industry is bought into this and we have lots of big banks now bought into FDC3 and lots of their developers are all building FDC3 apps. They're all able to work together. All these apps play well together and people don't have to go and talk to their colleagues and say, “I need you to feed me this data in this format now.” The standard already exists, and it's FDC3. You can use that standard and everything works together.

That's interesting. This is a common theme that's come up several times in the past from talking to people on this show. Whether you call them plugins or some pluggable architecture, it is projects that lend themselves well seem to have this turbocharged aspect of people contributing to them. It makes sense that that's the case, but that's interesting from a FINOS point of view because that's a very powerful validator of the idea, especially in the context of financial services.

It's like if one of your engineers has built an FDC3 adapter to whatever an application and there's no real strategic value to that, but it's easy and succinct. Maybe it's only ten lines of code. It's easy to contribute to the project. It's easy for legal or security to go, “That's fine. There's no high-frequency trading algorithm in there.” Is that a fair analysis?

I think so. We do start to see that where people are making little contributions. This is what you want to get to, that whole thing you were talking about earlier of like the drive-by PR where somebody sees something wrong and thinks, “I'm going to fix that,” and then move on with their lives. People like to do this because it looks good on your CV. You can start to say, “I contributed PRs to these projects and all these finance industry luminaries were happy to accept my contribution. Look how cool I am.”

I still think this is the tip of the iceberg at this point because if we had all of these developers in all the different banks that use FDC3, if they were all able to contribute to open source, then FDC3 would be in a very different place now than it is because we would suddenly see people fixing all the spelling mistakes, emissions or whatever else that they might discover.

Whereas at the moment, there are a lot of people using it behind their firewalls and not able to contribute back. They're not even able to engage with us on social media or the GitHub issues or anything. Some of them will get dispensation to be allowed to attend our meetings, but generally speaking, their policies don't allow them to get involved. We want to get to that point where everyone's contributing all over the place. Over time, we will. Unfortunately, there's a long way to go in allowing people to make these contributions.

What does the foundation have planned? A large part of it keeps pushing the very heavy large boat. Eventually, inertia is a physical reality. That's a great strategy. I like that strategy if you carry on doing it. Do they have any other projects or initiatives to try and help move that forward?

There is an increasing rate of new projects and new initiatives coming through to FINOS. It is hard to keep track of now. On the one hand, we've got like me pushing on the OSR stuff, trying to document the best practices and all this stuff and make it easy for banks to follow a golden path of how to get there in terms of contribution.

‍

On the other hand, lots of the rest of the people in FINOS are dangling the carrot of these exciting collaborative projects where the bank and organizations can get together and work on different things. There are lots of those on the go as well. One of the big ones was the CDM, the Common Domain Model, which is a way of modeling financial instruments. It's difficult to describe, but you model them in terms of the cashflows in an agnostic way.

It means that as new financial instruments get invented, they can be modeled in the existing CDM language. This is exciting because this opens up lots of ability for banks to send data to one another in a common format. It offers lots of possibilities for regulators to consume data in a common format. That in itself offers the possibility of, “Maybe we should be doing regulation in an open source way.”

If somebody asks for a new regulatory model or calculation, can we have an open source version of that? Everyone amortizes their costs by collaborating together on building it. These are juicy exciting prospects. As someone who's worked in risk before, I can tell you that a lot of money gets spent on regulatory projects. It's an extremely expensive part of banking. The idea of anything reducing that cost is super exciting and tantalizing for people.

That's another good example. There are some interesting projects like Legend in FINOS as well. Legend is like a data modeling framework originally contributed by Goldman Sachs. This is like a tool that other banks are now looking at. The great thing about Legend is we can start using things like the CDM inside Legend. We can pull out queries across all of our data sets in these common formats. Maybe we should be adopting these projects. They're phenomenally intricate large-scale projects that it's expensive for one bank to try and consider doing on their own. When you start to share the cost amongst all the other banks, it starts to become possible to roll it out.

It's interesting you mentioned regulation because from what I’ve read, it’s very expensive now, isn't it? It's a huge amount of spend across financial services and it’s a crosscutting concern. It lends itself perfectly to that open source world.

We've got to get people to buy into that idea. We've got some regulations that people have contributed to already, like the LCR regulation or Liquidity Coverage Ratio. That's been donated to FINOS. If we can get a few different banks to start rolling that out, then we have a compelling case study of how they've managed to save costs essentially.

Rob, it's been a super interesting discussion. Before we finish up, if there are people reading who want to get their employer involved, want to learn more, or maybe want to start contributing, what are the best ways they can do that?

I would go check out the FINOS.org website and also our FINOS Organizational GitHub. That would be at GitHub.com/FINOS. Both of those are good places to start. You can talk to help@FINOS.org via email. If you have any specific questions for me or anyone else on the FINOS team, we'd be happy to answer them. Yes, we are a very chatty organization. We love setting up meetings and chatting with you about open source. If anyone reading wants to get an introductory discussion going on with some people in their organization, then please reach out to us. It would be super good to talk to you.

You have face-to-face meetups as well, right?

Yes. We had a whole event in London. We had an open day and we had a member meeting as well following that. It was at the JPMorgan offices on Victoria Embankment, which is cool. There are lots of interesting chats there. We've got staff in London and New York, so if you work in either of those locations, it's super easy for us to come and meet and talk to you. We do events in both London and New York. The next big event we've got going on will be in November 2023. We've got the Open Source In Finance Forum on the 1st of November in New York.

I believe tickets are free for members and they cost money for non-members. As I said earlier, we have quite an extensive membership. A lot of the people reading, if they're working in the finance industry, might already be working for a FINOS member, so it's worth checking out our website whether you are a FINOS member or not. You can come along and say hello and listen to some in-depth talks on some of the topics I’ve been rambling on about.

Rob, thanks again for your time. That's been super fascinating. It's great to hear seemingly how progressive a lot of organizations are being around this stuff. Thanks again.

Thanks, Ben. That's been good fun. Cheers for having me.

‍

Important Links

• FINOS
• Spring Bot Project
• Open Source Readiness
• FDC3 Project
• Legend
• GitHub.com/FINOS
• Help@FINOS.org
• Open Source In Finance Forum
• Open Source Podcasts (featuring FINOS' podcast and Craft of Open Source Podcast)