Transcript
Minty: I first talked about the use of open source software in finance at a tech meetup probably about five years ago. It was one of those common situations, we'd arranged to have a number of speakers come along to do some short talks, and one of them had had to drop out. The organizer asked me if I'd be willing to step in at the last minute and just talk about something that I was interested in. I said, yes, and I talked about open source in finance. After the talk, a couple of people came up to me, and they both said the same thing. They were really surprised to hear that the financial industry was interested in open source. They thought there was something different about what we were doing that we wouldn't be interested in it. This really took me by surprise. It wasn't what I was expecting to hear. I talked with a few friends who worked in technology, but in different industries, and quite a few of them had the same reaction. Why is the finance industry interested in open source? This encouraged me to get involved in promoting the use of open source, particularly in the finance industry. That led me to get involved in FINOS, the Fintech Open Source Foundation. I've been lucky enough to be part of FINOS while it's grown from a relatively small community into a really large, vibrant part of the Linux Foundation. I wanted to talk with you and answer some of those questions I was asked at the meetup all those years ago about why open source is so important to us. Also, to talk about the role of FINOS.
Profile, & Overview
My name is Elspeth Minty. In my day job, I'm a managing director at RBC Capital Markets, where I help develop reusable application components and platforms. I'm also a member of FINOS. I'm part of the Technical Steering Committee. I'm also a co-lead of one of the special interest groups. I am a developer. I am not part of an open source program office. I am not involved in developing open source policy. I write code for a living. This is my personal take on open source within the finance industry.
What I wanted to talk to you about is to talk about where we use open source and how we use it, and why it's so important to us. I want to talk about some of the benefits of open source, but also some of the problems and concerns that the industry has with open source. I want to talk about FINOS, why it's so important and where it fits into the equation. I'm going to talk about some of the projects that are going on inside FINOS, and some of the things that we're working on within the special interest groups, just generally what's going on inside the community. Then I also want to spend a bit of time talking about what's the next big thing, because there's some really interesting work going on with FINOS that is potentially really transformative for our industry. I want to spend a bit of time on that.
Importance of Open Source
Technology is absolutely core to the financial industry. Not just the technology divisions within the financial industry companies, but all across the business as well. Talking with one of the traders I know, at one of the major banks, he told me that they wouldn't consider hiring anyone as a trader who didn't know Python. That is a huge change from 10, 15 years ago, where people were typically coming into the industry with finance degrees. Now, even on the business side, they're looking for people with computing related degrees, technology related degrees. The role of technology within the business and within the finance industry is really critical. That doesn't really necessarily answer why open source is so important. Why is it? The answer is pretty much the same as it is for every other industry. There is really no difference for us within the finance industry and how we use open source than what most people do, and why we're interested in it. The quality is really high. For most projects that we work with, there is a really high standard of peer review and testing. Doing development in public really makes you take care of what you're making available, what you're putting out there. We know exactly what the code is doing, what functionality it provides us with, and also what it doesn't do, so we can just go and look at the source code. We can hire people who have not only experience in using the libraries, or other open source platforms, but also have experience in developing them. That is a huge benefit to us. It helps with retention as well, learning open source projects, working on them. It gives people skills that are useful in their future career, and that is only good for staff retention.
There's often a lot of people involved in individual projects, an active community that's contributing code, solving problems, looking at each other's code. That has a lot of benefits to the quality of the code. Over a long period of time, you have a lot of people putting eyes on the code. It's a good thing to help develop the code into a really reliable platform. The documentation is often significantly better than anything we write for internal code. Knowledge bases like Stack Overflow are just invaluable. It's really hard to ask an original support question on Stack Overflow now, because so many of them have been answered. There's a lot of really positive aspects to open source for the industry.
There are some challenges to us using it. The fact that we are a regulated industry is a big deal. Our security requirements are often very high, and different from other parts of the industry. There are issues around us using it. Underneath the technology stacks that we're using are not significantly different from what anyone else is doing.
There are some things that we have to think about, though, with open source, particularly around supports and maintainability of the open source projects that we use. I love this xkcd cartoon. It makes me laugh and wince at the same time. Because it sums up perfectly some of the really scary situations of using open source, where there is one random person who is supporting a project that is key to a whole host of different related projects. One of the things that we have to think about when we use open source libraries, is how are we actually going to get support. It is not the random person in Nebraska's job to keep your company in business. We have to make sure that we have a good story on how we are supporting any software that we put into production. There's often some hard conversations that happen about, this project has this really cool functionality that we want to use, and how is it going to be supported? Again, those are probably fairly typical across the industry.
How Do We Use Open Source?
How do we use open source? There are three areas really where we are engaged with open source. We consume it. It is very difficult to think of any parts of the technology landscape across the financial industry that doesn't involve open source software at some point. It is in the code that we write, the libraries that we use, the applications we develop. It's the compilers that we compile it with, and it's the runtimes and operating systems that we run it on. It's everywhere. We also collaborate on open source projects, providing functionality, providing bug fixes on existing projects that we use. If a project is core to our business, it makes sense for financial industry companies to get involved in working on that project. We also contribute our own projects to open source. It makes sense in many areas where there's a lot of stuff that we do that is not particularly business critical that is common across different firms. It makes sense for us there to contribute the code and share it and work on it together. I should say here, though, that different companies are at different levels of adoption. Not everyone is doing the same thing. Not everyone is comfortable with the same level of open source as other companies. Some companies are very engaged in open source, contributing their own code, actively engaging with open source projects, whereas others are still very early, and possibly only consuming open source.
The important thing, though, is open source is a journey. It's not something you switch on overnight and suddenly start doing in the entire. There is a number of steps that you need to go through to adopt open source. You need to educate your senior management on why open source is important. You need to understand the risk and how to mitigate the risk. You need to educate the users. You need to make sure you've got the right policies and controls in place. There is very much a journey that companies go through in order to adopt open source. The journey is different for different companies. When I think about it, I think about it from left to right across the slide. You start consuming open source, then you collaborate, make a few minor bug fixes, then you start contributing your own code. A couple of weeks ago talking with a colleague at a PR company, who's involved in open source policy there, and he had a very different view. From his perspective, it was easier to argue that the company should invest the time in contributing their own software than it was to spend the time setting up all the controls and everything that would be needed to make that mythical one-line bug fix. Different companies have a very different approach and a different way of looking at open source, but for everyone, it is a journey, and most of us are still on that journey at different stages of maturity.
Open Source Adoption
Banks or financial institutions by nature, are very risk averse. That is a good thing, if this is really what you want from your banks. It has historically made it quite hard for us to engage with open source communities. There is a balance between what we see as risk and what we see as benefits of open source. Different institutions see the tipping point in different places and have different levels of comfort with open source. Some things are very clearly benefits and other things are very clearly risk. For example, the ability to hire someone who has worked on a project is clearly a benefit. The potential for leaking sensitive data is very clearly a risk. Other things are much more of a gray area. Reputational concerns is a very gray area. I've heard it said from some companies that they are concerned that developers put out code that is not very good. I've heard other companies concerned that if they don't get involved in open source, they will look like an old-fashioned company, and that's not the image that they want to project. There's a lot of room for interpretation how companies see some of the issues that are part of open source adoption, and where the balances can be very different, and particularly the tipping point can be very different from company to company. It's often not a straightforward story about how much open source engagement is wanted.
How do we increase the engagement? For me, it all comes down to collaboration. We need to collaborate to support people through open source adoption. Every individual, financial institution that is on the journey to adopting open source is going through the same steps. We make the business case for why open source contributions should be encouraged. We agree on open source policy. We put controls in place to make sure it can be done safely. We train our staff on how to follow best practices once we've actually decided what those best practices are. We can collaborate on all these things. The companies that are further down the road in a particular area can share, how did they approach making the case for open source. What facts and figures has come out of their usage that we can use to support wider open source adoption? We can share best practice, policies. There are differences from firm to firm. At a broad level, a lot of our best practices and policies should look the same. We can use our experience in setting up controls, and even show the code that has been written to help support it. Training material for our developers, again, we can share that and make it available. All of these things are at least at a high level common across the industry. Providing support for how we can encourage open source adoption across the industry is really important. We increase our engagement and we increase the level of collaboration by working together.
Enter FINOS
This is really where the Fintech Open Source Foundation, FINOS, come in. The purpose of FINOS is to encourage adoption of open source software, of open source standards and best practice. This is very tied in to this idea of us working together to adopt open source as well as making software available. There's a lot of companies involved in FINOS. I've taken this from one of the FINOS slides. It just shows the range of companies and organizations that are involved. There's financial services companies. There's technology companies. There's vendors, standard organizations. There's a really wide group of people who are involved and engaged in open source through FINOS. FINOS is really important for me, not just because it provides a way to make open source code available. It's really important to me because it provides a forum for that community to grow. It gives us a safe space where we can talk with each other. We can share experiences. We can collaborate and just learn from each other. For me, that's really the core of what FINOS is about. It does host a lot of different projects. I'm going to talk about some of those later. This idea of providing a forum for discussion, whether it's about adoption, or whether it's about any specific technologies. There's a number of ways in which these collaborations can work, but the forum to support these collaborations is really important.
The Linux Foundation and FINOS
FINOS is also part of the Linux Foundation. It's been a member of Linux Foundation since early 2020. The Linux Foundation is home to a number of very significant projects within open source. As the name implies, Linux is home to the Linux kernel. It's also home to the Cloud Native Computing Foundation, which supports Kubernetes, OpenTelemetry, and a host of other projects. It's a really interesting organization in what they provide. There are some really fascinating projects in there. Their vision of open source is very similar to what FINOS is doing, in providing this community ground as well as the hosting of projects. We've got a lot of benefits out of FINOS being part of Linux Foundation. There's other groups that are related to some of the work that we are doing. For example, the TODO Group, in terms of open source adoption, and there's collaborations that are going on, on there. It's also raised the profile of FINOS. It's also given us a lot of practical support, through things like training material. Access to training material, but also access to the people who develop the Linux Foundation training material to provide training on our own projects. Insights and dashboards give us a lot more insight into what people are doing, and where contributions are happening. It's really taken, I think, FINOS to a new level being part of the Linux Foundation.
FINOS Areas of Interest
I want to talk about some of the areas of interest for FINOS. There are a wide number of these. I am only going to touch on a very small corner of what FINOS is doing, largely driven by the areas that I'm interested in. I'm going to go through a few of them and just talk about some of the areas. Open source adoption, it is really the bread and butter of what FINOS does. It is absolutely core to the FINOS role, to provide support for companies going through this adoption. There's two special interest groups that support this, the Open Source Readiness group and the InnerSource group. These are both very close to my heart. I'm a former co-lead of the InnerSource group. I'm now lucky enough to be the co-lead of the Open Source Readiness group, along with colleagues from Morgan Stanley, Fannie Mae, and Red Hat. The OSR is looking to provide support, practical advice, documentation for companies who are approaching open source and who are going through the process of getting more involved in open source. One of the things that we provide is the maturity model. This is a way that companies can gauge where they are on the adoption journey. When you're doing this kind of adoption, it's important that you know not only where am I now, but where do I need to get to. The maturity model provides people with an outline of what that journey should look like and what good looks like at the end of it.
The other things that we're working on this year, is a body of knowledge. This is providing persona-driven documentation to different areas of open source adoption. You have the view from the OSPO, the Open Source Program Office. You have the view from the point of view of the developer. You have the view from the point of view of cybersecurity. It gives you a tailored path through the documentation. One thing that's also done within the OSR are member roundtables for OSPOs. These are held under Chatham House Rules, which gives us a very safe space where we can talk about some of the challenges that we're having, share approaches for addressing them. Just generally exchange ideas and experience. This is hugely beneficial for us. InnerSource, I think is also very important, as companies are adopting open source. There is more to open source than pull requests on external GitHub projects. To me, open source is a mindset. Open source adoption often involves trying to change the mindset of the way code is developed. I think this InnerSource model, where you're taking open source practices and applying it to code that's internal to the firm, is extremely important as a step towards open source adoption, because it starts to change the mindset of how you're doing things.
Another area that FINOS is involved in is best practice. The finance industry is very highly regulated, and this has impacts on a number of areas. A couple of them that I wanted to talk about are DevOps and cloud infrastructure. The regulations that we operate under have an impact on both of these. The DevOps automation forum provides a forum for SDLC related discussions on DevOps. There's both discussions, engineering solutions that are coming out of that group that are starting to, again, share knowledge about how best to approach creating a strong SDLC DevOps environment within a heavily regulated industry. Similarly, on the cloud side with the Compliant Financial Infrastructure. They're looking at collaboration on cloud controls. They're providing infrastructure as code that has been vetted and is ready to use by financial services companies on their cloud deployments.
A project that's been around for a while is FDC3. It's one of the earlier FINOS projects. It is providing a standard for how financial desktops interact with each other, so interoperability on the financial desktop. This is really about providing standardization in which desktop components communicate with each other. This can be standardization of APIs. It's standardization of the verbs that you use to describe the actions and the intents of what's being done. Sharing context between applications, and also identifying applications. This is one of the areas where we have worked with the Linux Foundation to provide an FDC3 training course through the Linux Foundation. These projects and groups that I've been talking about, they're what you would expect FINOS to be doing. They are contributed by the organizations that are involved in FINOS. At least at the starting point, FINOS supports them, helps manage the communication, hosts the software, and helps the projects develop.
Changing The Game
I wanted to talk also about the next steps, and the next things that are going on. To me, this is interesting, not just because of the work that is being done, but also because it's changing around the way things are working. This is something which is coming out of FINOS, and it's really being driven by FINOS. It's got the potential to really change how the industry works. It's a huge project, and it's still fairly early days. There's a lot of really innovative work being done in this area, but it's still fairly early days. The area that I'm talking about is regulation. I suspect that's probably not what most people thought I was going to say. This is an area where there is a lot of innovation going on, and FINOS is really leading the way on this. Let me explain why regulation is so interesting. Every financial institution that operates in a particular business area or a particular location, we are all subject to the same regulations for that industry and that location. These regulations are very complicated things, and they take a lot of effort to implement correctly. Also, while they are absolutely core to every business, there is no competitive advantage in regulations. This area is ideal for collaboration. There is no business benefit for one of us doing this better or differently from another of us. We all have to do the same thing in the same way.
Let me talk through how regulation works at the moment. The regulators define the regulations, and they provide a set of documentation which describes those regulations. This documentation is very comprehensive, and very lengthy. Once those documents have been released, each financial institution or vendor interprets those regulations independently and implements support for them. Either the financial institution implements it themselves, or they buy a vendor solution to it. The approach that we're looking at with FINOS starts the same. The regulators are still absolutely the people who define the regulations. Rather than providing them in terms of documentation, they get involved in open source projects to support the implementation of those regulations. The industry no longer independently builds their own solutions. Instead, we collaborate across regulators, financial industry, technology companies, vendors, to come up with a consistent interpretation and implementation of these regulations. This has benefits for everyone. It provides a consistent view of how these regulations are being reported to the regulators. This is really valuable to the regulators. They no longer have to figure out what different companies are doing and why there's slight differences. There is a much more consistent view of the data that's being reported. Obviously, there's benefits on the financial industry in the vendor side, because there's collaboration and a common platform for managing and developing the solutions to implementing these regulations. We're no longer all reinventing the wheel on this.
There is an open source project within FINOS, the Open RegTech Initiative, which is helping drive this. It's looking really to provide open source software, so real software that companies can use, and standards around this to help change the way that financial regulations are implemented. It's bringing together financial institutions, technology companies, vendors, and regulators to all work together on this. It needs all of those people involved to be a success. It's standardizing the interpretation of the regulations into a common data model. It's no longer a case that you would get massive big documents. Instead, you get a data model that encapsulates the requirements for the regulations. As well as the model, it's also providing a platform to interact with the model, and to support business adoption of the model, which is equally as important.
I want to go through some of the projects that we are working with to support this model. One is Legend. Legend is a data modeling platform that was developed and contributed by Goldman Sachs. It's really providing a common vocabulary for data modelers. How you interact with the data, and how you can manipulate it. These models that support the regulations are extremely complex. These are not short, simple models. They are very complex, often graphs of information and collecting data. Working on these and developing these is a really tricky thing to do. Having a common platform for interacting with this is a huge value on both sides of the financial institutions and the regulators to be able to work on these and discuss these using a common language as they develop and evolve.
The graph format is very complex. It's not something that is easily queryable. Legend also provides tools that will flatten the graph into a format that's queryable and the APIs that can be used to do those queries. In addition to having the platform you need the model as well. FINOS announced just last month, that they teamed up with three financial organizations to launch the Common Data Model project. This means that models from ISDA, the International Swaps and Derivatives Association, ISLA, the International Securities Lending Association, ICMA, the International Capital Markets Association, are all getting together to launch a common data model and to launch the data model project. This gives us the tooling for being able to manipulate the data model through Legend, but also the actual data models themselves. This contribution of the data models from ISDA, ISLA, and ICMA is a really important, a very significant milestone for OpenReg Tech.
The third part of this is, how do you model this within the business? If you look at code that has developed over a long period of time, what you typically see is that the business logic gets very intertwined with the technology, which makes it very hard to change the business logic. What's been provided for this is a project called morphir, which has been contributed by Morgan Stanley. Morphir is a way to model the business logic in a way that is technology agnostic, and that is a very natural way to express the business logic. It uses functional programming, Elm, to express the business logic. Once you have that, you can use it to automatically generate code in other languages. Java, Python, the usual languages, as well as SQL. It gives you a real separation between the business logic and the technology platform, and that makes it a lot simpler to manage and implement not just regulatory requirements, but business logic as a whole in general. It's a very powerful platform. When you combine this with the data models, and with Legend as the data modeling platform, the three aspects of this together really give us the core for a very powerful and very transformative way of approaching how we manage regulation in the financial industry, in an open source way. There is still an awful lot of work to do here. We need to develop more data models with a broader range of regulators, and also develop the platforms themselves, make them more integrated, add additional functionality. We are very much at the start of this work. It's a really interesting and potentially very transformative piece of work.
Where Next?
Where does this go next? The role of FINOS, I think just continues with this central focus on providing the projects and providing the space to collaborate. I think we are all seeing, increasingly, the benefits to collaborating as an industry as well as just consuming open source. The potential in the regulatory space, I think is just really starting to be tapped. Once we see that develop, I think it's going to be interesting to see where else that goes and other areas where there are similar opportunities. The core mission of FINOS remains the adoption of open source. The special interest groups are absolutely key to this. They provide ways for us to work together. The knowledge sharing and the experience is really how we keep open source adoption moving forward. FINOS is a very active community. I've only touched on a small number of the projects, and the initiatives that are live at the moment. There are new projects coming on board all the time. There's development on a lot of the projects happening continuously. There is an awful lot going on.
Resources
If you're interested in finding out more, there's a few resources here, the main Finos site, https://finos.org. The State of Open Source in Financial Services report from 2022, which is a really interesting read of the state of where we are, and some of the discussions that are going on, https://finos.org/state-of-open-source-in-financial-services-2022. The Open Source Maturity Model, https://survey.osmm.finos.org/551476, and the CDM, https://github.com/finos/common-domain-model, are also available.
See more presentations with transcripts
