Connecting FINOS with regulators about open source issues

[copiesofcopies]

FINOS is looking to connect with financial industry regulators about open source. We'd like to understand which regulators are looking into open source practices at financial institutions and what their concerns are. And where needed, we'd like to serve as a resource to help educate regulators on how open source is used and managed in the financial services industry.

We need your help answering the questions below. Feel free to answer here or on the Open Source Readiness mailing list (email [email protected] to join).

1. Which regulators' views on open source are you most interested in hearing about?

2. Which specific regulations are you most focused on in developing your open source practices?

[gyehuda]

Thanks. I'd like to understand the relationship between the various agencies and how their guidance flows from one to another and then to the regulated entities. This will help inform who is "upstream" in the process so that we can be most effective in speaking with the right groups who can influence outcomes down the information stream.

For example there was a coordinated press release about open source risk guidance by the FFIEC here https://www.ffiec.gov/press/pr102104.htm and the FIDC here https://www.fdic.gov/news/financial-institution-letters/2004/fil11404a.html both published on the same day. Which entity is the source? When other agencies receive it, do they repackage? can they / do they refine content along the way? If an agency wanted to update their guidance, would they have the autonomy to do so, or would they have to receive guidance from an upstream entity to enable an update?

[copiesofcopies]

Thanks to you both!

@jpmsrh any thoughts on which regulators are most likely to have opinions about these things, besides FFIEC and FDIC?

@gyehuda would it be fair to say the basic concern here is whether entities can expect this guidance to remain unified, or whether it's likely to fragment into multiple overlapping but different standards?

[gyehuda]

What I mean: I believe there's a workflow within the regulatory process itself -- e.g. agency X published guidance intended for other agencies Y and Z to leverage in their guidance directly to their relevant institutions etc. This seemed the case in the cascade of guidance I found in the example above. Thus going to agency Y with a suggestion might land us being pointed to agency X as the guidance source -- with agency X perhaps suggesting that Y might have the autonomy to make changes without them. I don't understand to what extent this is the case, but I do believe there is a relationship between the various bodies we'd speak with (and those differ per jurisdiction). Getting a sense of that workflow and autonomy chain would be ideal so that we can navigate effectively and focus on those agencies who have the ability to issue changes most effectively.

[sultanmeghji]

Hi All -

This is a huge question and one (sadly) without an easy answer. There are nearly 100 different regulatory bodies in the US alone... A non-exhaustive list includes every state's relevant agency, Treasury and multiple 'child' agencies, CFTC, SEC, White House, Law Enforcement, Federal Reserve (itself multiple agencies), OCC (which even though it is technically part of Treasury operates separately) and then the FDIC. There is no Venn diagram that could be represented in 2 dimensions (or even 3) that could show the statutory relationships.

If you're just talking about Banking, it becomes smaller (but still not necessarily straightforward). The 'FBA' (Federal Banking Agencies - Fed, OCC, and FDIC) all have both unilateral authorities, as well as shared. In some cases, those shared authorities are done individually between the 3 groups in a one-off manner (Ex: The AI RFI from earlier this year), while in other cases it is systematized in something like the FFIEC.

As a side note, this complexity is something that has been true for a long time (back to the 1930s) and has nearly a century of legal interpretation sitting on top of that (along with a non-trivial amount of legislation). Everything from the definition of Money, to which agencies have primary authority sits inside of these discussions. In some cases it is very clear - Agency X is required by law to 'own' some piece of regulation, and in many other cases it is shared, and in others, it is a gray area (i.e. can you imagine biometrics or deep learning being put into law in 1933 or 1950?).

Also, there is a lot of debate amongst the agencies on some philosophical questions. One example is: Should the regulatory system regulate directly the technologies of banks, or should the regulatory system ensure that the banks are building risk management programs sufficient to manage those technologies? Even now there are strong opinions on both sides. And the law does not provide the most straightforward answers in some cases.

Finally, an important note is that there are over 4,000 banks in the US, with a huge amount of heterogeneity in that population. From 20 person shops, all the way up to the largest in the world. Some spend 10's of billions a year on tech, others $50k. Some are very mature, thoughtful and execute very high quality tech, others struggle massively and don't use tech from this century.

So annoyingly long preamble, but basically the answer is 'it depends'.

Fundamentally, if the FBA could agree in principle on one or more actions around a specific area (and this happens on a daily basis), the mechanism to get it out there (whether through a formal interagency body or simply in a more one-off manner), is of little concern. In some cases, an agency could do something independently but I find that is rarely the case and generally does not carry enough weight to create change.

What's the outcome you are looking for? I make the case often that Open Source, like AI, is already out there. Every bank in the world is using it to one degree or another... so what are you all looking for?

[copiesofcopies]

As a lawyer, I can't fault anyone else for giving long answers that amount to "it depends" ;)

I'll let Gil speak for himself, but I think what FINOS members are looking for is some way of evaluating whether the practices & controls they put in place around open source management are consistent with regulators' views of what they ought to be doing. And FINOS is interested in helping to bring some clarity here however it can, whether that's through 1:1 conversations with regulators that can inform the efforts of our Open Source Readiness Special Interest Group, or potentially even (dreaming big) convening a working group of financial institutions and regulators to specify best practices for open source management.

[gyehuda]

Thanks both, I appreciate the dialogue and invite colleagues to participate in sharing perspectives to get an even better picture of the opportunity.

Technology moves quickly, changes to regulations move slowly. This creates a tension that we all understand is part of the nature of this business. Engaging in the appropriate mechanisms of dialogue to share understandings of technology risks and regulatory controls helps set us up for better resolution. The few examples I pointed to in a comment below suggest an opportunity to improve (and correct) our use of terms. I can read a page from an FFIEC document that both contains the exact definition of Open Source and then on the same page betrays that very definition. This is more than text editing though, it's about ensuring that we don't do the same with other complex concepts like virtual machines, containers, training data, and other terms that require technical expertise to make sure they are used with the precision we'd need to be effective communicators. Doing so helps ensure we can keep aligned.

To enable innovation and encourage modernization of the banking systems, many are looking at a variety of practices (you see them across FINOS projects) such as InnerSource collaboration within a bank, Open Source publications to commoditize and standardize common data handling needs, DevOps and DevSecOps practices to enable us to move faster and safer rather than pose those as exclusive alternatives. Yet these practices face frictions when we find they are blocked or discouraged by a policy (enacted with good intentions, but perhaps in an era before newer mechanisms that address concerns more effectively).

I think it's fascinating to know about the wide spectrum of those entities that are consider banks. I'm sure that opens the challenge that "one-size fits all" often means "this is the size, sorry that it only fits the one reference case we were thinking about." I understand that's a tension too: you don't want too many if/then clauses in a regulation but we can't afford to be anchored by the least technically-savvy in the room. My general bias is that a well managed group with different voices makes the best music. So I'd encourage FINOS to see how to orchestrate a workshop(s) that brings expertise to the table and produces tangible artifacts that the parties can use to keep in alignment while we operate between technology and regulatory change rates.

[gyehuda]

The most recent FFIEC exam guidelines includes a section about Open Source Software (V.C.2(a), page 59 of https://afsaonline.org/wp-content/uploads/2021/07/AIO-IT-Booklet.pdf). The first footnote with lists 20 examples of open source software, yet some are not examples of open source software -- suggesting a confusion between the legal concept and the marketing term. The bulleted list of mitigating controls include "Restricting access to unapproved shareware sites." whereas shareware sites generally provide non-open source binaries (shareware), binary artifact registries generally point to open source binaries. Perhaps we need to clarify a spectrum of project types that people consider in the category to note just how different they are from each other.

• small single-purpose Node.JS modules declared as a project dependency, and occasionally update in harmony with a vulnerabile dependency,
• JARs or other packaged libraries provided by an artifact manager included during the build process,
• small algorithms that solve a problem, posted on a StackOverflow response, often copied into source code,
• tools, utilities, and scripts that help developers or operators do their job, but are never incorporated into a production service (e.g. an open source browser or developer tool),
• vendor products that are based on an open source project such that the open source project is available for limited use and no effective community engagement, but nearly all users pay for commercial licenses,
• shareware (a binary where you cannot see the source code, but might be encouraged to install hoping it provides some benefit -- like telling you the weather) is not an example of open source. It's actually the opposite of open. You can't see the code.
• Browser plug-ins, a more contemporary form of shareware in which you might be able to see the source code.
• an operating system,
• platform technologies that support data storage, processing, or movement -- some of which are supported by a vendor, some only by communities (e.g. many of the Big Data related platforms managed by the Apache Software Foundation). Think of Cassandra, Kakfa, etc.

Notice that each of these might be licensed under an open source license, but present themselves with very different risk profiles and concerns. Calling them a category of "open source software" suggests more similarity between these examples than is reasonable. The security, licensing, patching, vendoring, record-keeping, and asset tracking processes for these examples vary considerably.

Perhaps a better categorization is in order. Some code is used as an individually packaged dependency, some as an inseparable inclusion, some as a tool, some as an entire product. What it is, where you use it, when you use it, who uses it, etc. should drive regulatory consideration. License compliance, versioning, indemnifications, etc. are relevant, but perhaps secondarily relative to the primary organizational categories.

[copiesofcopies]

@gyehuda would it be useful to convene a working group of the OSR SIG to categorize common open source use cases along the lines you describe? And perhaps to define the high-level risks and controls relevant to each?

[gyehuda]

Yes. I think categorizing things as "anything to do with open source" is only helpful when speaking about the scope of an OSPO at a high level. Once you get one level deeper and need to discuss processes, risks, accountability, costs, etc. you quickly realize that you have very different things at play here. But I don't know if we have names for those that help us capture "oh you mean... X" where X is a subset of all things open source. I think such an exercise would help us all and we should see how far we can get with it.

[sultanmeghji]

Hello all! Gab pointed me to this discussion - Sultan Meghji here, Chief Innovation Officer at FDIC... I've been in tech for a long time, including open source stuff in the 90's... Very happy to engage with you all.

[copiesofcopies]

Thanks for joining in, @sultanmeghji! It would be interesting to hear your thoughts on Gil's question above, regarding how the different regulatory agencies are (or aren't) coordinating their approach to guidance on open source management.

[vmbrasseur]

@sultanmeghji Thank you for joining the conversation. Would you be interested in coming to one of our calls in Q1 of 2022 to talk to FINOS members about things like this?

[jstclair2019]

@sultanmeghji is certainly an authoritative source to advance the discussion! From my experience, FDIC and SEC implemented regulatory requirements circa 08 based on the eXentisible Business Reporting Language (XBRL), of which I and reps from Labor, FDIC, and Treasury participated in working groups with XBRL-US. However, the SEC mandated the use of the taxonomy and left it up to filers as to the tools they used, all commercial, not mandate a certain open source adoption.
That's very different than collaboration between regulators to develop an open source project that THEY use as part of their collective regulatory enforcement.