In November last year, we spoke at the Open Source Strategy Forum, to make a case that a collaborative cross-industry regulatory platform - using an open-core model in the cloud - could transform the way the finance industry goes about regulatory compliance, lowering costs while creating new opportunities for differentiation. In this article, we address some of the possible objections regulators might have to the broad use of open source in meeting regulatory requirements.

It opens the door to technical exploitation

Some argue that, by exposing the engine of a systemically important platform to the world, we are  exposing it to attack from bad actors. However, we already use complex open source platforms throughout the industry, including Relational Database Servers like MongoDB, CI Servers like Jenkins, and opencore data analysis tools like ElasticSearch. These are foundations we build our stacks on, and a regulatory stack is no exception. So we are comfortable with this risk, and we have priced it in - the key is having secure boundaries and infrastructure, including, where appropriate, in the cloud. Even if a bad actor knows how your engine works, that will not help him if he cannot get under the hood without an alarm sounding. However, not all problems are caused by outside actors. What about bugs?

It creates a single point of systemic failure

Anyone who’s ever written software knows that all software contains bugs. That is an axiom. No matter how rigorous your quality assurance regime is, testing can only ever be a risk management exercise. It is not possible to release software that is 100% guaranteed bug-free. So, what if a large number of institutions all used one particular open source point solution in their RegTech stack, and a bug creeps in? That bug would not just affect one institution, it would potentially affect all of them - right? Now you have a single point of failure, with multiple points of destruction. Meanwhile, the argument often used in the open source community - that “given enough eyeballs, all bugs are shallow” - has been refuted constantly, with examples such as buffer over-reads in OpenSSL existing for two years before they were spotted.

While this is true, even if bugs might not necessarily get spotted sooner, given a properly funded and designed testing regime they would not get spotted any later. And the open source model, with its larger pool of contributors, would allow them to be fixed sooner. Meanwhile, we are already comfortable with single points of failure being used throughout the industry, such as ANNA DSB. While ANNA is not open source, I would argue that it is not its closed-source nature that puts minds at rest. Platforms like ANNA are rigorously tested, and steered by strong engagement and clear governance - and the lack of such governance would be a serious concern for a regulator.

It might have weak engagement and governance

There is a long-standing perception that open source software is only maintained by part-time contributors at best, with even widely-used projects having a severe lack of resources. Another concern is that open source projects sometimes have poor governance. For regulatory platforms, particularly when used by institutions that are systemically important, both would form an unacceptable risk for a regulator. 

One way to approach these concerns might be pointing out that the biggest contributor to open source is Microsoft, with Google, Red Hat, Facebook, and Intel all not far behind. These organisations fully commit to open source, and divert a great deal of resources and funding to keep important platforms like VSCode, Linux, Android, and React up to date. The key point to make here is that open source software is not free. Like any other important project, success requires engagement, and part of that is proper funding.

As for governance, it is well-known that collaboration is one of the most important and unique selling points of open source. So, the way to manage this risk is to use a collaborative governance model. The foundation model, exemplified by FINOS, is a great example of collaboration and oversight by multiple stakeholders, across multiple organisations - and even the regulator could take part. But could that engagement form a different type of concern for a regulator?

It implies a process blessing by the regulator

Much has been written on the fact that law is ‘necessarily vague’, and financial regulation is no exception to this rule. The argument goes that, by articulating precisely how to comply, you also articulate precisely how to game the system. Regulators might be concerned that their visibility of an open-source regulatory reporting engine - even more so their involvement - might implicitly give a ‘process blessing’, forming a precedent that could cause problems later. 

We would argue that this concern is outweighed by two factors. First, by the transparent demonstration of compliance - that, by knowing the under-the-hood workings of the engine of compliance, the regulator could have real confidence that everyone is playing by the rules. Second, by getting involved in that governance model, the regulator could themselves make the continuous course-corrections needed by inevitable changes in our economy, in a far more timely and agile fashion than the current long and involved process.

Conclusion

To summarise, I would argue that putting a regulator at ease with open source boils down to four points: 

• Take security seriously
• Test rigorously
• Fund and resource the project appropriately
• Apply a suitable governance framework

Meanwhile, the final concern of a regulator - that they might be giving an implicit process blessing - is far outweighed by the benefits, including the ability for the regulator to get involved themselves.

Of course, we have taken broad strokes here, and of course there is a lot of nuance when you get down to the details. But if we get these things right, it would be a big step towards dealing with the sort of concerns a regulator might have, and could significantly enhance the way regulators and regulated entities work together to provide a market that is both safe and efficient. 

I would very much appreciate hearing your thoughts on this topic - feel free to contact me by email at matt@weareadaptive.com.

Matt Barrett

CEO and founder, Adaptive Financial Consulting

This article was originally published on the Adaptive website here.