Lawfare Daily: Open Banking and the Benefits of Interoperability with Alexander Rigby and Chinmayi Sharma

[Introduction]

Alexander Rigby: Perhaps these big behemoths want more than just holding the money or investing the money. Maybe they're about to move into a separate sector, and then all of a sudden, their power might actually become more of a problem than it does right now, because all of those current regulatory structures aren't going to be evident.

Alan Rozenshtein: It's the Lawfare Podcast. I'm Alan Rozenshtein, Associate Professor at the University of Minnesota Law School and Senior Editor at Lawfare, with Alexander Rigby, a law clerk on the Delaware Court of Chancery, and Chinmayi Sharma, Associate Professor at Fordham Law School.

Chinmayi Sharma: You need to use ex-ante tools to decentralize decision making power from those major institutions before you can hope that writing a bit of code is going to solve all the problems.

Alan Rozenshtein: Today we're talking about a new paper that Alex and Chinmayi have published as part of Lawfare's ongoing Digital Social Contract series entitled “Open Banking: A Case Study in the Benefits of Interoperability.”

[Main Podcast]

Your paper is about interoperability in the U.S. consumer finance system, which is a very important topic in its own right. But I think, especially for Lawfare's audience, it'd be helpful, I think, to emphasize the paper's broader framing, which is to use open banking as a case study to think about interoperability more broadly in the digital world. So let's start with that and some definitions. So what do you mean when you talk about interoperability as a general matter? And why is it important either on the internet or some other digital domain?

Chinmayi Sharma: So I joke with people that interoperability is one of the most important and kind of pervasive concepts, even outside of the technology world, but is like the least sexy branding for a very important concept. Broadly, what you mean by interoperability is the ability for two independent systems to work together seamlessly.

And, you know, kind of the physical world I feel like is the best way to visualize it. In the U.S., we have outlets that have been standardized so that all electric products that need an outlet know how to build a charger to interoperate with outlets that are built into homes. Another example would be our cell phones interoperate.

The reason that's important is because it allows us to move from Verizon to T-Mobile to, if you're in a different country, to use Vodafone as a temporary carrier. But kind of the paper that Alex and I wrote focuses on interoperability in the tech space, which is software interoperability, or the building of systems of software in ways that allow two separate systems or platforms to work together. And what that usually means is moving data from one system to another. And there's a lot of ways we can accomplish that, which I imagine we'll get into later.

Alan Rozenshtein: So Chinmayi, let me follow up with you there. Can you then give a brief history of interoperability, whether on the internet or in the broader modern digital world? How has it ebbed and flowed over time, and where would you say we are now? Are we in a relatively closed or a relatively open moment on the part of internet history, or is this one of these kind of n-dimensional questions where it's hard to say one thing or the other --- we're open in some ways and we're closed in some other way?

Chinmayi Sharma: I mean, to kind of lead with the conclusion, definitely the lawyerly answer of open in some ways, closed in other ways --- really hard to quantify exactly what's going on, but I do think it's fair to say that at least right now, we are in a relatively closed world, but I'll take it back to kind of the origins of interoperability on the internet, and it's kind of one of those magical inception stories of how a technology was built, but I think, as many know, the internet was originally a DARPA project that was built by researchers and then handed over to independent academics and---

Alan Rozenshtein: And DARPA, just for those who don't know, it's the Defense Advanced Research Projects agency. I think I got most of those acronyms correct.

Chinmayi Sharma: I'm so glad you tried and not me because I know the acronym, but I almost never know exactly what the acronym stands for. So thanks for jumping on that one. But the internet is basically one computer talking to another computer that's somewhere else.

And what does that mean? That means one computer is sending data, or ones and zeros, to another computer that's somewhere else. And to do that, the same way human beings need to have a shared lexicon to be able to communicate with each other orally or in written language, the internet also needed to have kind of a shared lexicon or some agreed upon protocols to allow information to move from one place to another.

And so these protocols are kind of the foundation of the internet that govern everything from how a computer registers information, how it packages it, how it splits that package up into tiny little pieces to more efficiently send it to a different computer, how that different computer receives it and puts those packets back into an order that is comprehensible to a user.

All of these are protocols, and these protocols were --- because in large part the internet was originally developed by these independent researchers that did not have commercial motivations or profit driven motivations --- these were all open protocols, which meant that once we have established this language or lexicon and set of grammar rules for the internet, I could go on and build my little corner of the internet and know that Alan and Alex from their little corners of the internet, who might be total strangers to me, can still access my corner of the internet without needing kind of permission, without needing a special translation intermediary.

It was kind of the ability for all of us to build a network in this kind of open, collaborative way. You know, in the pendulum swing that generally exists, and there are great books, there's a lot of literature out about this, in worlds that originate with kind of like open origins tend to swing into closed environments.

Because when you have an open environment, that means that certain people are able to use that open environment to build things that are so either innovative, or trendy, or useful, or for whatever reason that thing ends up becoming the thing that everyone wants to use. They become dominant players in those open environments.

And then when you start to kind of have a large space on the internet, it actually behooves you to want to protect that fiefdom by kind of building walls and a moat around it. And so we saw from the open origins of the internet, we moved towards kind of more closed platforms. So for those who are old enough listening to this, the early kind of AOL world, we had one kind of intermediary through which we would interact with everything else on the internet, our chat, our email, our browsing and things like that.

We decided we hated that because one entity was not very good at doing all of those things equally well. We moved kind of a little bit further back in kind of a web 2.0 and a much more interactive web to a more open environment where people were building really interesting websites where users could actually contribute content instead of just consuming content.

But then we saw the rise of like the MySpaces and the Facebooks and that’s kind of swung us back towards the much more closed environment that we're in today. And so where once on Facebook or Twitter ---at one point, Twitter benefited substantially from being more open and allowing third-party developers to build cool stuff on top of it that would make users want to use Twitter more --- once it had kind of a critical mass of users, it shut down all of those collaborations with third parties and really secured its fiefdom so that, you know, to use Twitter, you could only stay in the Twitter world in a protective kind of way, protecting its commercial interest way.

Alan Rozenshtein: So is it correct then to say that what's become closed are the applications that sit on top of the internet?

I mean, presumably the actual internet protocol, right? The part that does the taking of the packets and routing them. And then the various protocols that reassemble them, that has remained open. Applications; it used to be AOL. Now it's Facebook and TikTok and whatever. Those are what's become closed.

Chinmayi Sharma: Yes. No, great point to draw out. Theoretically, I can still build my own Facebook on the internet, but for reasons we'll get into, the fact that I can do that because the internet protocol, the HTML, which is kind of how we create web content, all of those being open is not enough for me to build something that can compete with or provide an alternative to the existing platforms. And so it's, you're right, at the application layer, not the kind of core, how the internet works layer that things have become really closed.

Alexander Rigby: And I think it's worth reminding listeners that this is a long history, and even attempts at technologies like middleware were shot down and confronted by Microsoft in the nineties, and there were some very famous antitrust cases there. So, as we've seen, our economy consolidates and becomes more stratified in terms of power. I think the internet's a really interesting allegory for that as well.

Alan Rozenshtein: So let's talk about the different ways that, from a technical perspective, interoperability can be implemented. Alex, you mentioned middleware. Chinmayi, you were alluding to things that are called APIs: application programming interfaces. Those are just two of the four you identify. You also talk about standard protocols and decentralized architectures. So, I'd love for you two to kind of give an overview of what each of those four means. The paper obviously goes into great length specifically, but just give the listener a sense of what are APIs, what is middleware, what do you mean by standard protocols, and what makes an architecture decentralized.

Chinmayi Sharma: As Alan mentioned we identify four broad categories of how you can accomplish interoperability from a technological standpoint.

So this isn't a corporate executive deciding that they want to do interoperability. It's how do you write out the code that will actually accomplish this. And so the most popular that we see in at least conversation and in regulation that we'll ultimately talk about is APIs, or application programming interfaces.

And what an application programming interface is, it’s kind of like if you think of the Googles and the Metas, meaning Instagram and TikToks of the world as like little user and data fiefdoms that they have their user base and they have the information that they're gathering from their user base.

An API is kind of building a door into that and kind of creating like a secret handshake or password. Like, okay: third-party that wants to create a new filter for TikTok. Here is the secret password that you need to give us to prove that you are a reliable party for us to interact with.

And here is how, if you want to have access to certain information, this is the exact format in which we need to receive that request for information, and then this is kind of the format in which the information is going to be provided to you. So it's kind of like a rules of the road blueprint for how can a third-party approach the fiefdom and kind of get access to stuff from the inside.

And so these are very popular in that, for example, you can build a TikTok filter. Back in the day, Twitter had a lot of third-party applications that allowed you to, before Twitter built out these technologies themselves, to stockpile tweets and schedule send them and automate that process.

Facebook had a robust games world where people could build out games that Facebook users could play. Those were all based on APIs, and the big benefit of things like APIs are: they're building doors. They're not holding hostage all the data and access to users that these companies have. They're allowing third parties to come in and say like, hey, I think I can contribute something useful here if you give me some data for me to play with to build this thing. Some of the downsides of that are that it's interoperable, but not as open as some other solutions, because a company still controls the rules of the road.

So the company can decide who gets access to this API, how often they can make requests through it, what kind of information they're even going to make available through the API. So there are big pros and cons there.

Alexander Rigby: And then middleware is a software that sits between an operating system and applications that run on that operating system.

And so I think of it as a translation or something, I guess, maybe like a hub between that allows an operating system application to communicate and work together, even if that application wasn't designed with that initial operating system in mind. So a bit like an open API: if you have middleware, suddenly an operating system that maybe your application wasn't supposed to be on suddenly can work. So it's only open source to developers.

Alan Rozenshtein: Okay, so we talked about APIs and middleware, and one thing that occurs to me is that in both of these you have some level of interoperability, but ultimately it's pretty tightly controlled by the central player, right? So, in an API, the platform that we're trying to get data out of has to provide and run these API endpoints.

And even for middleware, although someone else will usually make the middleware, there's probably an API ultimately between the central platform and the middleware kind of repackages that. The other two techniques that you talk about seem more decentralized in more fundamental way. And so Chinmayi, how does that work specifically with respect to standardized protocols and fully decentralized architecture?

Chinmayi Sharma: Yeah, absolutely. And to kind of go back to the API middleware discussion and kind of draw out the two distinctions of why we even categorize those separately. An API, I, as a user, would need to directly interact with the company and its API. Middleware, Alex kindly comes in and says, “Oh, you want a Meta social media feed? I'm going to build this software that pulls from the APIs of all of these different social media feeds so that you only have to hit one API to get access to all of that.”

So from a burden on the user or third-party developer standpoint, there's a lot of convenience to that. From a control over access standpoint, in both cases companies still maintain full control over what they make available. And in the second case of middleware, you are also beholden to a middleware's decisions on how they're going to structure that software, what they're going to build into it.

It's also very cumbersome, because the minute Twitter changes its API, now the middleware needs to change that overnight as well. So, there's a slight distinction, but you're right to group them both under pretty controlled by these centralized entities.

And then, standard protocols and decentralized architecture, the beauty of them is that they are generally permissionless, which means that a centralized entity does not need to grant you the permission to interact with them. And the reason I'm avoiding saying that they're not controlled by centralized entity is sometimes standard protocols are actually built by governments, and so there can be a very powerful entity that builds the standard protocol.

Let me explain what a standard protocol is. Instead of an API, a standard protocol is, what if I wrote out all of this code, and I'm not talking about a specific implementation. I'm saying: “here's a blueprint to make a house” instead of “I'm providing you with a house” or “a blueprint to make a key and a lock” versus “I'm providing you with a key and a lock.”

And then if I, as a developer, choose to use that protocol, then I know that I'm going to be able to interoperate with all of the other entities that are choosing to use that protocol. And so this is great because this harkens back to the origins of the internet of why is it that we had so many different websites that cropped up and figured out whether we wanted just listicles, or we wanted to move towards more interactive websites, it's because anyone could jump in the game with the internet and build things and see what else wanted to interact with their page. The downside, or the limitation of standard protocols is you need a critical mass there. So the reason the internet is open is because everyone already started building on the internet protocol and using HTML.

And so it doesn't make sense to create a completely different protocol overnight, even if it might be better, and there are many that argue that the internet protocol is quite limited in its capacity to handle the amount of traffic on the internet, because everyone was already on it. Whereas if I tried to create a standard protocol, and people are trying to do this, for example, for wallets or identities, everyone else needs to agree to use that as well for it to be useful to me.

So that the kind of network effect needs to be there. And to contrast that to decentralized architectures, standard protocols are kind of like the idea of something that you can choose to implement to create interoperability. Decentralized architectures are just you're actually building this whole ecosystem that is decentralized in nature, and this is everything from blockchain to peer-to-peer systems, again, for those who remember the days of LimeWire and BitTorrent.

These are systems where there is no central governing force, but again, they're still within decentralized architecture's distinctions in how you do that. So, for example, with blockchain, one of the reasons advocates for blockchain like it so much is that it is very resilient to authoritarian takeovers.

The way that it's structured means that every computer has both the exact same amount of authority and a very limited amount of authority to make changes to the ledger that is blockchain. Which means that I can't come in and undo all of the transactions that Lawfare has engaged in in the past 10 years.

But what that also means is that for us to rectify an error in the ledger, I need to get consensus from all of the other nodes on the blockchain, which can be cumbersome. And you contrast that with the Fediverse, which --- to shout out, Alan wrote a great paper on the Fediverse. And it is something that has been around for a long time but really entered the public conscience when Musk took over Twitter and we started to explore other forms of social media. And so Mastodon is a federated form of social media that is the asterisk when I say there's no central governing authority. On Mastodon, you can have a central governing authority in that I can create a Mastodon instance and say these are the rules for my little community of Mastodon users.

I am not going to allow hate speech. I am not going to allow political speech. This is only for conversations about My Little Pony and nothing else. And whoever wants to be in my community is allowed to be in my community, but the reason that it is still highly interoperable is because being in my community does not lock you into my community, you can still gain access to the other communities on this federated system of social medias.

And so, Alex's cricket-based --- this is totally me typecasting him for being a Brit --- cricket-based Mastodon instance can have the rules of the road being we're only going to talk about cricket here, and also we're only going to talk about British cricket and nobody can slander British cricket. The users on that can still access information from my My Little Pony Mastodon instance.

Okay,

Alan Rozenshtein: So, moving from cricket and My Little Pony social media to the putative topic of the paper, which is the open banking case study. So, let's turn to that. So, Alex, can you give an overview, before we jump into open banking itself, what the state of consolidation and openness is, or lack there of, in the banking sector in, let's focus on the United States here.

Alexander Rigby: Yeah, well, I mean, it's tremendously consolidated. And that's been the case since the Great Financial Crisis of 2008, when a number of big banks failed and banks came together. And, you know, I think if you look at the big players, you have JPMorgan Chase, you have Bank of America, you have Wells Fargo, and a few others, but it is a, it is a consolidated landscape for sure.

Alan Rozenshtein: And why do you view that as a problem for consumers? I mean, one might say, well, we want big banks because big banks are more stable banks and they have more in reserve. Why is the current level of consolidation, in your view and in Chinmayi’s view, a problem that needs solving?

Alexander Rigby: Yeah. So, I mean, I think when we approach this problem, antitrust is hot at the minute, right?

And I think rightfully so, because especially in tech, there are harms perhaps outside of consumer welfare that we all feel. If there wasn't such great consolidation of power, would we have had some of the issues in security or elections? I don't know the answer to that myself, but it's something which certainly piqued my interest and so on.

But when it comes to banks, you know, the banking industry is itself actually quite regulated. Maybe not through antitrust, but you have the Fed, you have FDIC requirements, which work with the DOJ. And, you know, there's a lot of structures that make sure that banks are run correctly. I started to read --- and I'm in corporate law right now at a court that does a lot of litigation of M&A --- I started to read about pickups of little fintech firms. And so it was intriguing to me to think, “hm, perhaps these big behemoths want more than just holding the money or investing the money.” Maybe they're about to move into a separate sector, and then all of a sudden that power might actually become more of a problem than it is right now, because all of those current regulatory structures aren't going to be evident. So that's what really drew our interest to this topic initially.

Alan Rozenshtein: Sure, but I'm curious if you could just say more specifically what the problem is, right? I go to a bank. I open up a checking account. I get some extremely lame level of interest. Should I care whether the bank has a hundred million dollars, a billion dollars, a trillion dollars in assets?

What, what is the kind of concrete problem that we're solving, especially for the consumer, since the things your paper focuses on is especially consumer focused?

Alexander Rigby: Yeah, well, I mean, it's been shown that in monopoly or in oligopoly, prices are higher. So to begin with, you get a higher price and worse quality service. There's no incentive for firms to compete across their product vertical, whether that be a better interface, whether that be better tellers, whether that better be better payment services across borders. If they're not being challenged, then they'll stick a high price on it and you'll struggle to get the service you want.

Alan Rozenshtein: So we've established that there are some problems associated with the consolidation of the banking sector. Open banking is presumably a solution here. So what is it, and can you give some examples of its current state?

Alexander Rigby: Yeah. So open banking itself is a very broad term that's thrown around to meet both the technologies that underlie how banks are becoming more open, but then also, as we discussed in the paper, policy objectives. So I guess the best example I can use is how European banks have required that their banks, under the payment services directive, have standardized dedicated APIs, payment, and ways to authenticate users that can be accessed between different banks so that if you need to send money between Santander to Monzo and then Monzo to Lloyds, it's a very seamless process because they all share that same centralized structure.

Chinmayi Sharma: And to kind of add to that, it has allowed for the growth of a ecosystem of third-party fintech companies. So because these banks need to have shared APIs, not only are the interactions between these major existing players now more seamless and consumer friendly --- where before it was better for banks to not play nicely with other banks, because it means that you're stuck doing all of the things that you need to do money-related with one bank --- but now we have apps coming up that can help you do things like manage your finances across all of your different financial institutions. So in one dashboard, you can see this is the amount of money I have in the various accounts at banking institutions. This is the amount of money I have in my Venmo account. This is the amount of money I have in various gift cards. And the only way a central, a new third-party fintech company would be able to do that is if they can get your specific information from all of those existing financial institutions to be able to show it to you in one place. And why is that consumer friendly? Because there is no shortage of research that shows that our lack of insight into our finances is one of the biggest things that prevents us from making sound, responsible financial decisions. And when you give people more access to information, and as Alex said, in a actual user friendly way, not in a completely confusing interface that many banks have, people are more empowered to make better decisions with their finances.

Alan Rozenshtein: So, we clearly have some level of open banking, right? I use one of these online services that helps me budget by taking all my financial information, and I find that quite useful. Where do you two view there to be more work to be done, right? Where in particular do you think there needs to be more openness that we're not seeing?

Alexander Rigby: I think on a meta level that there hasn't been yet standard setting within open banking as controlled by, by, by the CFPB. I think a few weeks ago they said that they're putting together their values for what they want the standards to be. But what we would like to see is open protocols, open APIs, where the walls are really broken down so that rather than it be like a pay to enter or a “you need a license to do this” or “we have to agree to integrate with your platform,” those sets of protocols are open for free development.

Chinmayi Sharma: Yeah, and I think part of why we don't have that and why existing open banking regulations are not, we think, going to accomplish their stated goals is because the way that they are mandating openness is going to either impose regulatory or compliance burdens on the kind of smaller third parties that we want to use this new openness to create competitive products or complimentary products, or, and this is more often the case, the existing dominant players are just going to benefit more from this openness than any new kind of scrappy startup that's creating a new product. And Alex can definitely talk more about kind of why antitrust is failing a little bit here or has at least failed in the past, but the way it benefits these dominant players is a story that we've already seen played through where these big social media companies having very open APIs that allow these third parties to build useful add-on apps that made these social media companies more useful, brought users to them. So there were more users flooding to these social media companies because they had open APIs that made their platforms better because other people were building cool stuff for them. But once they got all the users that they wanted, the benefit of having an open API was outweighed by the cost of it, and so instead they started closing down these APIs and just started to provide those same services internally. So they just started kind of copying what competitors were doing, building out those features themselves, and we no longer had kind of an open ecosystem in the tech world. And the reason why Alex and I postulate this is going to happen in the finance world is banks already have the existing resources to build out these FinTech solutions.

So instead of using whatever app you're currently using for budgeting right now, Alan, like what if, you know, Deutsche Bank's provided its own app because it has a massive R&D team that can figure out exactly what consumers want and build it out. And two, because there's entrenched legitimacy to familiar names.

And so there is a concern that if you kind of just allow people to pick between different players, they're going to go with the name that they recognize. And we won't actually see the competitive marketplace that open banking is trying to achieve.

Alan Rozenshtein: So how do we avoid that? I mean, how, how, if you're a policymaker, do you encourage through regulatory mandates or persuasion or whatever tools you have at your disposal, interoperability in a way that actually decentralizes these consolidated, in this case, banking, but we can imagine other examples --- you, Chinmayi, you mentioned antitrust. Is that the key? What else can we do?

Alexander Rigby: Yeah, I mean, I think initially, I think ex post enforcement is always a quite clunky and cumbersome way to achieve policy goals. So when we think about the CFPB's rollout of the personal financial data rights rules and, in contrast to how FTX and the industry has set the standard out so far, what we would like to see in broad strokes is leveling the playing field through reciprocity and data sharing. Regulating the fees so that smaller companies can get licenses in a much more easier way considering their resources.

But part of it is also when you develop the standards and the APIs, when you create the standards body, should it be run by the people who would benefit from the open banking increasing their market share in different sectors? So those are some ideas we've thrown out and hopefully the CFPB can do something like that.

Alan Rozenshtein: Before we finish our discussion of open banking in particular, I'm curious what limits you think there should be, if any, on openness and interoperability. And I ask because one can imagine certain costs here. Security costs, privacy costs, just the costs of small, hungry startups using people's information in ways that doesn't help them.

I think of all the new gamified investment platforms, which strike me as just an atrocious idea if you know anything about how to do investing or just long-term personal finance. If interoperability means a million Robinhoods, maybe it's not such a good idea.

So I'm curious where you all draw the line and who in particular you think should be drawing those lines in open banking.

Chinmayi Sharma: I can kind of take a stab at it and shout out my own paper that I wrote with the Data Transfer Initiative, which is a data portability, independent organization that tries to improve interoperability and data transfers across systems.

But basically, I don't think that we have enough empirical information to make these decisions yet. Because for example, I definitely don't want a proliferation of scammy apps that trick people into basically like Lottery World investment decisions. But on the other hand, we have that in all industries.

For example, there is a massive proliferation of totally bogus supplements that are advertised as anti-aging and will make you immortal. And we just kind of accept that that is a cost that we're willing to pay for the ability for companies to present to the public useful health products. I'm not saying that's the right calculus, but I'm saying that it's not that bad actors taking advantage of a system is like a unique thing to interoperability. And so what I write in my separate paper for DTI is that there should be a period of basically trial and error, like create the laboratory of innovation, have different forms of interoperability implemented, see which kinds --- how bad does permissionless interoperability get, are APIs that are, as Alex alluded to, designed by the very centralized entities that we're trying to take power away from, are those the only way to go about accomplishing our goals? We need to have some more information that we gather, because another big open question here is we might create interoperability, but what do users want? What is the effect on them if we do this all in the name of the public interest? So I think that interoperability is a really, really, really well supported theory that will accomplish good things for the public by making things more interoperable. But, as we harp on in our paper quite a bit, interoperability can be accomplished in a lot of different ways, and so figuring out the right way is a complicated question for which we need a lot more information.

Alan Rozenshtein: So, before we finish our conversation, I want to now zoom out from the open banking context.

And I want to go back to our original question, which is what are the lessons that you all take from your analysis of open banking? And so what are they? I mean, if we want to improve interoperability in the social media context or in the development of AI and helping different research teams talk to each other or use the same data or have AI's interoperate, we can imagine a million different contexts.

What broader lessons do you take either for policy advocates or folks in industry or for policymakers themselves?

Alexander Rigby: Yeah, for me, if there's two lessons from this study that lend for me is one, our inquiry was about financial data and about banking. But when we thought about the greater concerns, they played into the larger notions across the internet technology of privacy of security.

I mean, it's not far-fetched to think that some financial data in the hands of big, powerful aggregators suddenly becomes non-financial data and can be used in quite pernicious way. So I think there should be generally for policymakers and advocates serious concern about data security and about in whose hands data falls.

And then secondly, I don't want to sound too doom and gloom, but our economy and society moves in many ways towards plutocracy and oligopoly in all sorts of sphere of our lives. And so as we see cross sector moves for more consolidation of power, I just think we all need to be quite concerned about what that actually means, because money is power.

And if more people have more money and people have more control, that can mean all sorts of things for security and health in general.

Chinmayi Sharma: Yeah, I completely agree with Alex that interoperability is a good thing to have when it is being introduced in an environment that has the right conditions to make it successful.

And our whole paper says that an already extremely consolidated marketplace of very big financial players is not the right environment with the right conditions to make interoperability succeed at all of its goals. So you need to use ex ante tools to decentralize decision making power from those major institutions before you can hope that writing a bit of code is going to solve all the problems.

And on top of that, because I'm an academic and we like these words, but it's not just because we like these words; we like these principles. I think that cross-disciplinary, public-private partnerships are really valuable in this space. I think it is concerning when the institutions that are making APIs to improve openness are the private sector companies that have a commercial interest.

I think that you want --- the reason the internet proliferated in the way it did is because a bunch of researchers came together and were like, “it's in all of our best interests to create something to agree on these rules of the road so that we can all use them, and we're going to allow anyone else to come in and use them as well.”

And internet standards organizations today operate in largely the same way, like the standards organization at the IETF that runs HTTP and the other core kind of internet protocols. They run by rough consensus. You or me, we can show up to a meeting if we want to, we can share our thoughts if we want to, we can vote if we want to, no one is left out.

I think that there's a democratic legitimacy or a public choice kind of thing, reason to have the way in which interoperability is even implemented also be very open.

Alan Rozenshtein: Well, I think that's a good place to end it. Thank you, Chinmayi and Alex for the discussion, and in particular for writing the paper.

It's a great piece and I really urge listeners to take a look at it. Even if you don't think you're interested in consumer finance, the area itself is really fascinating and it's so obvious that there are many, many lessons. And I think because a lot of these debates on interoperability are happening in the consumer finance space, it's a really, really useful case study. So, thanks so much.

***

The Lawfare Podcast is produced in cooperation with the Brookings Institution. You can get ad free versions of this and other Lawfare podcasts by becoming a Lawfare material supporter through our website, lawfaremedia.org/support. You'll also get access to special events and other content available only to our supporters.

Please rate and review us wherever you get your podcasts. Look out for our other podcasts, including rational security. Chatter, Allies, and the Aftermath, our latest Lawfare Presents podcast on the government's response to January 6th. Check out our written work at lawfaremedia.org. The podcast is edited by Jen Patja, and your audio engineer this episode was Noam Osband of GoatRodeo.

Our theme song is from Alibi Music. As always, thank you for listening.