Free, measured and always on: the open banking interface the CFPB proposed and banks could not price

The week

On October 19, 2023, the Consumer Financial Protection Bureau proposed its Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act. Covered data providers would have to make account data available to consumers and to third parties they authorize, through dedicated developer interfaces rather than screen scraping. These included banks, credit unions, card issuers and certain payment providers. They could not charge fees for that access. The proposal set performance expectations for the interfaces and limited third parties’ use of data to what is reasonably necessary for the requested product. It required consumers to reauthorize access annually, and phased compliance by institution size. Institutions without a consumer-facing digital interface were excluded. The bureau also proposed to recognize industry standard-setting bodies whose standards would indicate compliance.

An earlier article in this series looked at how the CFPB’s 2022 outline would reach small institutions as a product bought from their core vendors. The October 2023 proposal changed the nature of the interface for every data provider, whoever builds it. The interface became a service with measured performance, run for third parties the bank did not choose, at a price of zero. That is an unusual product for a bank to operate, and its economics differ sharply by institution size. We look at it in three parts that together describe the bank’s position: what it would have to deliver, what it could not recover, and what it would still control.

What the bank would have to deliver

The proposal required a developer interface that performs at a commercially reasonable level. It proposed specific indicators: a proper response rate of at least 99.5 percent, measured over each month and excluding scheduled downtime, and a response-time ceiling of 3,500 milliseconds. Data had to be at least as current as what the consumer saw in online banking. Downtime had to be scheduled with notice and kept reasonable. Data providers would also have to publish information about the interface, including performance figures, and keep records showing compliance.

Those requirements turn an interface from a project into an operation. A bank needs monitoring that measures response rates the way the rule defines them, not the way an internal service desk does. It needs capacity planning, because aggregators may poll accounts frequently on behalf of millions of users. It needs a change process that does not break third-party integrations whenever online banking is updated. And it needs someone who owns the monthly performance figure and can explain a miss to an examiner.

The performance standard applies however the interface is sourced. Institutions buying it from vendors can write the response-rate threshold, measured to the regulatory definition, into the service agreement and require evidence each month. Banks running their own can treat the figure as an internal service level with an executive owner, reported alongside online banking availability. A miss then becomes an incident with a root cause, rather than a number discovered at examination.

Liability sits underneath all of this. When an aggregator holding data from the interface suffers a breach, or a consumer disputes a payment initiated with account details obtained through it, the bank will still receive the complaint. The proposal left much of that allocation to existing law and private agreements, so the data access agreements a bank signs with large aggregators deserve review by counsel alongside the technical build.

What it could not recover

The proposal barred data providers from charging consumers or third parties for access through the interface. Large banks would bear build and run costs directly. Smaller institutions would pay through their vendors, who would price the new capability into renewals. In both cases, traffic would be generated by aggregators and fintechs whose business models depend on that data, and the bank could not bill for it.

The costs that cannot be recovered through fees can still be managed. Banks can measure traffic by third party and by purpose, which supports capacity planning and gives evidence for any future debate over fees. Interface design also drives cost. Efficient patterns can cut traffic substantially, such as letting a third party request only transactions since its last call, or notifying it of new activity instead of being polled. The proposal left room for these through standards. A bank that contributes to the standard-setting body’s work has more say in which patterns become expected.

There is a defensive saving to count as well. Screen scraping costs money too: credential-based logins inflate authentication traffic, confuse fraud models and generate customer complaints. A well-run interface lets a bank block scraping with less customer harm, and the savings belong in the business case.

What it would still control

The proposal left data providers some discretion. They could deny access to a third party for reasons related to risk management, provided the denial was reasonable and consistently applied. They could authenticate the consumer and confirm the authorization before sharing. And they determined, within the rule’s scope, how account data was represented in the interface.

Using that discretion well requires a policy. A bank should write down the risk criteria it applies to third parties seeking access, how it assesses them, how quickly it decides, and who can approve a denial. Inconsistent or slow decisions would look like obstruction. It can rely on shared assessments where standard-setting bodies or industry utilities offer them, which reduces duplicated due diligence across thousands of institutions. And it can use the visibility the interface provides, which third parties are connected to which accounts, to detect fraud and to give customers a list of their connections. Discretion exercised through a documented policy is what a bank gets in return for an obligation it cannot charge for.

With hindsight

The CFPB finalized the rule in October 2024. The final version kept the ban on access fees and the 99.5 percent response-rate threshold, dropped the specific response-time ceiling in favor of indicators such as consensus standards, and exempted the smallest depository institutions. Bank trade groups sued the day it was issued. In 2025, under new leadership, the bureau asked the court to set the rule aside, and the litigation was stayed. In August 2025 the bureau published an advance notice reconsidering the rule, with whether data providers may charge fees among its central questions. At least one large bank moved to charge aggregators for access that year. As we write, a revised rule has not been finalized, and the economics described here, who pays to run a mandated interface, are the most contested part of U.S. open banking. Interface-based access continued to replace screen scraping under bilateral agreements and industry standards.