Last fall, I wrote about the ongoing struggle to implement a section of 2010’s Dodd‐​Frank Act (Section 1033) that would require financial institutions to give consumers access to their financial data upon request. I contrasted the glacial rollout of these U.S. “open banking” regulations with the speed by which Bitcoin and the broader crypto ecosystem have accomplished key open banking goals—such as decentralization, openness, and default consumer access to financial data—through private innovation.

The push for open banking—the idea that financial data be made portable between different institutions and service providers—is a global phenomenon. And while some argue that Dodd-Frank’s provision (focusing on “access,” as opposed to standardized transfers) is not, strictly speaking, an open banking requirement, it has come to be regarded as one in the American context.

The latest, and typical, fascination in the U.S. open banking story is yet more conflict among stakeholders over the shape of eventual open banking rules. This recently came to the fore again in a series of comment letters responding to the Consumer Financial Protection Bureau’s (CFPB) outline of open banking regulatory proposals. Regulatory intervention instigating zero‐​sum conflict among stakeholders is nothing new. But what the latest disagreement illuminates regarding open banking is that consumers themselves—not regulators in a position to pick industry winners and losers—should be the ones who choose what tools they get to use to share and aggregate their financial data.

When it comes to the problem of herding industry cats into an open banking consensus, the historic divide has been between traditional financial institutions (like banks and credit unions) and fintech companies that collect and aggregate data from those institutions on consumers’ behalf. One of the most controversial subjects in the open banking debate is the use of a data sharing method known as “screen scraping.” In short, screen scraping involves consumers divulging their financial account log‐​in credentials to third parties who extract, aggregate, standardize, or otherwise render useful the data within those accounts for consumers. Generally, financial institutions have been leery of screen scraping because it presents security risks and limits their ability to control the outflow of valuable financial data. In addition, consumer advocates are wary of the practice’s impact on data security and privacy.

Screen scraping has benefits and drawbacks. On the one hand, it’s provided a technological solution for collating consumers’ own financial data from a diverse set of financial institutions. That’s no small feat, and it has moved the ecosystem toward open banking goals. On the other hand, the practice has various risks: turning over log‐​in credentials to a third party can make them a target for hackers and it does not inherently limit what an authorized third‐​party can access within the consumer’s account.

Some take a critique of screen scraping to an extreme, though, calling into question whether consumers should be allowed to consent to the practice at all. While reasonable minds may disagree on the optimal type of notice that a third‐​party service provider should offer to a consumer before she opts into screen scraping, it’s a strong, and strongly paternalistic, position to take that even informed consent is insufficient to permit the practice.

Given the downsides of screen scraping and an arms race between data collectors that employ the technique and data sources that deploy countermeasures to block it, a private consortium of stakeholders, including financial institutions, fintechs, and advocacy groups has sought an accommodation. The result has been industry standard setting for an Application Programming Interface (API), which would allow data sharing between traditional financial institutions, fintechs, and consumers without relying on screen scraping.

There’s something of an emerging consensus that, in an ideal world, such an API would benefit most market participants. The rub, however, is that it’s not an ideal world, and like everything else, deploying an API has costs and tradeoffs. Accordingly, smaller banks, through an industry trade group, the Independent Community Bankers of America (ICBA), have expressed to the CFPB that they generally support “the use of more secure APIs so long as standards are not mandated, which would threaten to disadvantage community banks” who can be more sensitive to implementation costs. While smaller institutions argue that “the industry should move beyond screen scraping,” they don’t necessarily want to see it banned right away. By contrast, larger banks, through another industry trade group, the Bank Policy Institute (BPI), have explicitly called on the CFPB to set a deadline “to ban screen scraping,” arguing that otherwise there may be insufficient “incentive to transition to APIs if screen scraping is allowed to continue, including if it is retained in some form as a fallback mechanism.”

The point here isn’t who’s right, but rather that when rules that could gore somebody’s ox are on the horizon, it’s entirely predictable that stakeholders will advocate for their interests.

One way to avoid this situation is to leave it to consumers, in whose name the open banking rules ostensibly are being written. Consumers should be permitted to choose the data transfer mechanisms they prefer, or at least are willing to tolerate among a constellation of other factors. Institutions with the resources or inclination to deploy an API can do so. Those who are not API early adopters would then have options: they could allow screen scraping, or, to keep up with market forces, invest in APIs. Those that do neither would risk losing market share where consumers find the absence of a data access solution too restrictive.

Private innovation, at its core, produced the competing data sharing methods that allow for consumer data access—by way of screen scraping and APIs alike. Consumers should be the ones to choose which of these methods will suit their needs while simultaneously helping to avoid zero‐​sum stakeholder fights.