Get in touch with us. We'd love to hear from you.
Brad Levy Discusses Open Source’s Future in Financial Services
EPAM recently sat down with Brad Levy, formerly managing director and global head of loans at IHS Markit and CEO of MarkitServ—the firm’s post-trade service for OTC derivatives—to discuss how open source in financial services is gaining momentum.
- You have been a pioneer and key supporter of open source for many years, citing the phrase ‘it’s the community, stupid’ to support the logic of open source. What led you to be so passionate about this topic?
Open source is an example of the types of community I’ve been involved with for the last 20 years across various industry initiatives – whether it's a trade association getting together to create a common agreement called an ISDA to do derivatives, or a network to confirm swaps, or a consortia of like-minded firms getting together to build out a new platform or product to serve the market or an open source foundation. For me, they're all just different versions of the industry getting together to achieve something. Open source is a pretty natural evolution of being involved in industry initiatives where we get together and solve common problems. This platform happens to be designed as an open source foundation. For me, it's just another version of community building and common problem-solving.
- How do you think open source has changed over the last five years and what does this mean for companies looking to contribute?
Open source in the financial services industry has benefitted us at the infrastructure level. I do think there's a general recognition that open source can also be used above infrastructure, the cloud and really the development environments of the actual business application. It’s a somewhat natural evolution over 20 or 30 years of open source moving up the stack and more to the business function on the competition side. Then there's a general recognition that there are things to do on a common basis that aren't very competitive at all and should just be done once for all of us.
On the other side of that, there are still ways to compete heavily while working together. Twenty years ago or so, in my former life in banking, we talked about co-opetition, which was this idea that we have to compete—it’s the law to compete—but that we cannot be anti-competitive. At the same time, we can cooperate and do things together better to solve common problems through open source and even building greater liquidity to serve the buy-side in a different way. Those competitive elements are always there. People are mindful of them – we have a history of coming together and cooperating while we compete. Open source has, in the last five years, become another version of that. It’s a place where people have decided to spend time cooperating while also competing head-to-head.
- Banks have traditionally been very focused on measurable business cases for all technology investment, which has limited their activity in leading and contributing to open source initiatives. Do you believe anything has changed in this view and why?
I think it's less of a gamble, and it's just more about a horizon line. When I use the word “investment,” I tend to think of it as a minimum multi-year plan. There are times where a big transition or investment is multi-decade. Think of our energy challenges and fossil fuels – that’s a multi-decade investment that needs to be made and measured. It may be less of a problem of investing and more of a problem of investing for long enough to see the payoff. A lot of the time you do need to invest upfront to get more efficient in the future. Part of the challenge of the last five or 10 years is that what people have really thought about was saving their way to prosperity. We're going to save a ton of money when we innovate and reinvest in our businesses and sometimes those are at odds with each other. Everything must be measurable. Everything must ultimately have a business purpose. I might even argue that we haven't done a great job at measuring our technology costs. Are they really adding value to the industry? I think we're going to have to get better at answering that question. As we move to the cloud and implement more robotic process automation to shift people to focus on more high-value tasks, what is the impact?
People are starting to recognize that the horizon line is a bit longer to make these things happen. You have to commit to open source. Open source is a little harder because it’s less “commercial,” but I'd argue it's just part of the evolution of the development and operating environment for technology now.
- Financial services firms face high barriers of regulation and responsibility. Consuming open source software means trusting the code is secure, robust and does the job. How should financial services firms approach open source in their operations and how does FINOS enable trust?
At the core, there's an amount of administration that you have to go through whether you have contributors or you're consuming open source. You have to get comfortable with the environment—whether it's the legal environment you are in or the technical environment—and the types of tools that people need to access to both contribute and consume. There is policy and governance setup required upfront that is a bit of work but it’s worth it. To be active in the space, you must create that foundation.
At the opposite end of the spectrum, one of the reasons I'm personally supportive of open source is that there is no doubt that technology breaks and we're all becoming more and more dependent on it – including the regulators who are concerned about technology moving in the wrong direction or faster than we can understand. When you start to get things into the cloud, they tend to be fixed more easily or course-corrected; whereas if they tend to live in smaller environments with fewer people, it's riskier long-term.
Open source has this self-cleansing mechanism that allows everyone to be more comfortable with the fact that we're utilizing technology more and more. You asked, “if everybody [is] doing what they need to do to be ready for this kind of environment.” FINOS sits in the middle to help with this. In addition to general education, FINOS works with organizations to become more comfortable with contributing, taking back the code into their environment and then creating specific open source projects and programs. It's really at the crux of that administration, as well as the idea that if we all work together, the tech should be better. If the tech is better, the regulator should be comfortable. We all know things break and we have to understand that. Just because it’s open source doesn't mean it can't break, like any software.
- Have you observed any regional differences in the appetite of financial services firms to contribute to and lead open source projects? If so, are there any specific actions that FINOS can take to drive additional support where necessary? Does regulatory divergence play any role in these differences?
I can't say I've seen it. My view is that if you think about privacy at the core and the differences between privacy around the world—whether it's Asia, Europe or North America—as well as technological intellectual property, there are certainly differences globally about how that develops and how it's shared.
The China-US relationship is at the middle of that debate. There are different public and private models where the government is fairly active in the development of financial technology. The US has a robust open source model because there are very robust protections about what isn't open. You can define what is open more easily because there's a robust legal, patent and business framework that defines what is ‘somebody's’ versus what is ‘everybody's’.
The government’s development in technology and Fintech is evolving around the world. For example, as the China-US relationship evolves on technology-sharing or technology transfers, China may create a system that's more robust around protections. Then you could see open source really take off in Asia – I’m not saying it's not relevant today or there's a stark difference, but it really did evolve from the US and North America. As it evolves globally, it will be different. But my guess is that it's tied up in global technology competition, such as the patent and legal framework around what’s really IP versus what just exists and what is developed to exist on open source.
- Some assert that banks are struggling to compete and survive in today’s world of digital transformation, Fintech start-ups, Neobanks and other challenges. With increasing competition from new entrants and lower barriers, why should banks support the challengers and potentially erode their own competitive advantage by making business-specific tools and code available via open source?
There is a push-pull. Open source sounds like everybody's equal on some level, and there's some truth to that. But when you back up and even look at the membership of FINOS today or open source foundations in general, the entities that are involved are anything but equal. These foundations tend to look like Noah's ark versus cat herding – it’s a lot of different types of animals that you're trying to bring together for some common thing now. There are firms that will engage in different projects or programs, depending on their competitive view at that time. There's always going to be a difference between the individual firms engaged in an open source foundation and how much they're really pushing versus pulling or just observing. There is a difference in how people participate that evolves over time, and a lot of that is up against the backdrop of what's going on in the market.
Competition is getting so fierce. It's not that you're going to cooperate on everything in an open source way. But if you acknowledge there are some things that could be done that way, you almost have no choice but to do the things that are common, so you have a shot of competing where you should be. If 33% of a business solution is important and a market differentiation, you would never allow it to be open source. Let’s say that there is 33% that is absolutely not a point of differentiation and the other third falls somewhere in the middle that is questionable on whether it should be competitively preserved or open sourced or neither – that’s the 33% that people will spend their time handwringing and debating, whereas good firms will just focus on that bottom third as it’s a clear candidate for open source. That competitive backdrop will create more momentum in open source. But for the firms that more easily figure out where their line is and don’t walk up to it or over it—that's why it has to be a community because everybody has their different lines. They will find the middle over time where we all can meet and do things together.
- Do you think open source can help companies today in the continuous challenge of finding, recruiting and retaining top talent in tech? Are there other challenges that can be solved through the use of open source?
There are many elements that our industry needs in order to attract more engineering and technology talent. There's no doubt in my mind that having the ability to utilize and even participate in open source is one of those five or 10 things that somebody with a development background wants in their work. It is critical. Many things factor into attracting the right talent. Open source is one of them. Is it the top thing that if you don't have an ability to do, will you have an issue retaining your technology talent? Probably not. But in a world that's getting increasingly tougher to find talent, these things are important and they'll be much more important in three to five years.
Developers and engineers like to build things, and they don't like to ask permission. Our industry is all about giving permission and then figuring out how to create an environment that’s safe for people to do what they want as quickly as possible while retaining a process-driven, robust, regulated environment. It's just another version of where technology in Wall Street needs to sit, and open source is a great place for that because it really brings both to the table if you're doing it right. FINOS has uniquely brought that together for the last three or four years.
- Due to its origins perhaps, FINOS has been very focused on capital markets up to now. Do you see any difference in the potential of open source to support buy-side and retail financial services? What needs to happen to stimulate growth and support in these areas?
There needs to be the view that there are common problems to solve across institutional capital markets, retail financial services and insurance. If you just pull in another related segment or sector, there's no doubt that there are some common elements. If you think of the asset manager world, there are many asset managers that check the institutional retail and insurance boxes in different ways. I would say asset management hasn’t been pushing as much technology innovation in the industry as maybe banks have, but that's changing. With that change, you'll start to see things like FINOS, as the buy-side gets more engaged and thinks more holistically versus institutionally. A lot of the time in the buy-side, people are fairly separate from the asset management world. They tend to think about it more as an asset manager platform. Just as in the infrastructure space, it really started out as solving unique problems at an infrastructure level for certain industries and then it expanded over time when those common problems surfaced.
I would expect FINOS to be relating to, if not specifically expanding into, other related areas with those common problems. The key thing you need are the individuals that would see it that way. If FINOS is going to be across financial services more broadly, you will need an evolution of the community. Then it's just a matter of the chicken or the egg.
The question is do you put the people there who will push this topic or does it naturally evolve and people come around to it? I think we’ve seen several instances of this over the last year or so, where some entities were not pure capital market institutional firms – whether it's the vendor side or the bank side. Capital One is a good example. Some of the vendors that have joined span beyond capital markets or institutional markets as well.
- So far, the FINOS contributors appear heavily skewed towards banks and software product vendors. Do you see any advantages or disadvantages for services providers/outsourcers to participate in the open source arena, given that the IP ownership model is usually quite different for their client-related work?
I do think it's in an evolution period. There are times when people really believe that something is unique, and they want to preserve what they've done uniquely with the vendor. They want either the rights to it because they don't want others to have it, or they just want to control it from a product perspective on some level and not be encumbered with other demands. There are many examples of this in the infrastructure space when some people really wanted to keep that proprietary content, or connectivity, or whatever it is with new engineering that just didn't exist before cyber protection. At one point, those things are pretty proprietary than a little less proprietary and more scalable and then—if it really works for the world in a big way—it can become a bit more commoditized. Even the idea of having unique software code is starting to become a really challenging concept. There are people that believe applications won't even exist. They will be created and extinguished, and you won't have to maintain applications as long or at all. Most people are trying to get out of the “I own my software” mentality and move to the mentality of “it's just up in the cloud and it updates to the new version every time the vendor wants to update it.”
I think all these ideas trend toward not owning your software for life, leasing it and having it evolve more quickly. All these trends lean away from people saying, “I want you to do a deal with me, I own the software and all the IP is locked up in it.” It will be a challenge to get through some of these client discussions. But there will be some people that will just move on from that, and my guess is in five years, they will move at a much higher velocity technologically. Those who think the secret sauce is the software are starting to become less relevant. The secret sauce is the intellectual capital. It’s about what you do with the software versus what the software does.
- The FIX Protocol is an open standard that has been around for some time, but due to platform and internal differences within each bank, it has never been a simple drop-in implementation to connect trading partners. Do you see a risk of fragmentation in the adoption of any future standards, and how could FINOS help to prevent this?
I think it’s more about saying it than preventing it. They can highlight when it looks like it's going too long. When I talk about a standard, there's a document and a document is not a standard until it's in use. Once that document is used by someone to write a line of code or do something, it has a shot of becoming a standard. If most people start to use it in a very consistent way, it is a true standard. If they are just using it, but in a very inconsistent way, where with FIX—which I would argue is not many flavors of ice cream, it's actually many desserts, if not many types of food—there are a lot of things that it could mean. What they got right was that we're going to agree on the tags, but we’re not going to agree on some very generic use cases and it's up to everybody on the planet to really implement.
What FINOS can do is highlight when an implementation looks like it's scalable and standardized in a way that people could benefit versus a concept that you still have a tremendous amount of work to do at the moment you take on the standard. FIX just put it out into the world and said, “Here's what good looks like,” but it was just a document. Whereas, FINOS can show “Here's what good looks like,” and it's really a product implementation that shows a few different community members converging around a common set of code in the real world. If it’s a product, people can take that open source product and weave it into their own products or workflows. FIX never went that far, and rather than saying FINOS can prevent fragmentation, they could just show what good looks like when it's a scalable standard that is replicable—which had not really been how FIX would be described historically. It’s not that FIX is bad—it just evolved at a time where technology was a lot more bespoke. It was harder to develop common everything because so many things were not common 15+ years ago. When I got involved in FIX around year 2000, we tried to push it for fixed income.
- How do you see open source and FINOS developing over the next five years? What will we expect to see? Has the adoption of open source reached the tipping point to become mainstream yet?
I would describe that tipping point as a series of months or years versus a day or a couple of weeks. That's not as fine a tip, but it is on the other side of a downward slope. Just because everyone has another real problem to solve themselves, doesn’t mean the common problem shouldn’t be defined and solved together, whether it's climate or technology evolution. It does feel like the denial is gone and we need to work together, and I think the timing is right.
The idea of being able to trust and run things and not break them when you want to evolve them —just the concept of DevOps where we put an application in environment and it works—that's definitely a concept that has taken hold in our lives. Our industry is going in that direction, and the idea of applications with data working seamlessly in the infrastructure—no matter what that infrastructure looks like to some degree—it's just what the world is demanding. We’re not there, but I think open source is a key component of that.
I think it does unify the infrastructure and the business applications, and that's kind of the point of FINOS to bring it up a level. For FINOS to be that relevant in five years, it has to think of itself as not just a capital market but as open source inside of a FinTech space. It has to think of FinTech holistically—how it fits in the greater world and then put finesse into that kind of a macro framework without losing the detail and the specificity of what we're trying to do. It has to think of itself as in a much bigger play—in the details to get things done in the interest rate swap market, the repo market, the equity market at a granular level. It has to think of itself as very granular, very atomic, very specific, but fitting into this much larger universe and galaxy. I think it's inevitable that open source does that in the next five years in our industry, and FINOS is the game in town to make it happen in a detailed way. But then also fit —you know that galaxy inside of a much larger universe of technology evolution in every vertical depends on finance.
- Anything else we should cover?
I want to talk a little bit about timing and failure or success. Is FINOS a success today or not? If it's not, could it become one? If it is, how could it become even more successful in the future?
It's ultimately—and it's hard to think of it this way—a product company. It's developing an actual product, which manifests as a set of code and standards that we could all incorporate into our product. We think of ourselves as the product. You think of yourselves as a firm that sells a product to help people build platforms. Open source is just over there. But to me, it's a real product and product companies and products take five years to be tangible and probably 10 years to do big things.
We're a few years into this, and we've achieved a lot as a product. It isn't changing anyone’s life yet—and I'm not sure we are going to wake up one day and say that it did that—but if you jump forward another five years and look back at the full 10 years, I think this will be an amazing product at the end of the day that will change a lot of how we work as an industry and our products.
But are we winning or not? What is the time frame? And what are we managing? It gets back to that horizon line thing that I mentioned earlier. We're not all using the right horizon lines in life. A lot of the time, we’re right up against the investment that we're trying to make. When I got into open source, it was about 13 to 15 years ago. At that time, I thought it was going to be a 10-year journey. It turned out to be a little more than that, I've seen products develop over my career and it takes time. This is a product company, and we’re starting to see products. FDC 3 is a product now. In setting that 2025 goal, what do we think we could be doing? I think it could be very big, but it's still early days in the lifecycle of product development, which typically lasts about 10 years.
Learn more about FINOS and Brad Levy here.