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

The week

Millions of Americans use budgeting apps, payment apps and lending tools that need to see their bank accounts. For years, many of those apps got the data in a way that would make most bank executives wince: customers handed over their online banking username and password, and the app logged in as them, copying what it found on the screen. The industry calls this screen scraping. It works, but it hands a third party everything the customer’s login can do.

On October 19, 2023, the Consumer Financial Protection Bureau set out to change that. It proposed its Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act, a provision of the 2010 financial reform law that gives consumers a right to access their own financial data.

Under the proposal, covered data providers would have to make account data available to consumers and to third parties they authorize. Covered providers included banks, credit unions, card issuers and certain payment providers. They would have to do it through dedicated developer interfaces rather than screen scraping. A developer interface, often called an API, is a purpose-built doorway through which one company’s software can request specific data from another’s, with permission, without anyone sharing a password.

Data providers could not charge fees for that access. The proposal set performance expectations for the interfaces, so they had to be fast and reliable as well as present. It limited third parties’ use of data to what is reasonably necessary for the product the consumer requested, so a budgeting app could not repurpose the information for something else.

Consumers would have to reauthorize access annually, which meant connections would lapse unless the customer renewed them. Compliance would be phased by institution size, with the largest going first. Institutions without a consumer-facing digital interface, such as some very small banks with no online banking, were excluded.

The bureau also proposed to recognize industry standard-setting bodies whose standards would indicate compliance. If the industry agreed on a common format and set of rules for these interfaces through a recognized body, following that standard would count as evidence a bank was meeting the rule.

The headline for banks and credit unions was simple and uncomfortable: build a service, run it to a measured standard, for customers of other companies, and do not send anyone a bill.

The CFPB’s 2022 outline had pointed to an interface that small institutions would buy as a product 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, which made it an unusual product for a bank to operate. Banks are used to running services for their own customers and charging for many of them. They are used to dealing with partners they selected, under contracts they negotiated. Here, the users of the service would be fintechs and data aggregators chosen by the bank’s customers, and the price was set in advance by regulation.

The economics of that product differ sharply by institution size. The bank’s position has three parts: what it would have to deliver, what it could not recover, and what it would still control. A brief tour of the machinery comes first.

Cores, scrapers and tokens

Every bank runs on a core banking system, the central ledger that records accounts, balances and transactions. It is the bank’s book of record. Most small and midsize institutions rent their core from a handful of large vendors rather than building their own.

Online and mobile banking sit on top of the core. They read from it and display the results to customers. When an app screen scrapes, it is logging in to online banking as the customer and reading the pages the customer would see. The bank often cannot easily tell a scraper from the real customer, so the scraper inherits all the customer’s access, including the ability to move money if the login allows it.

A developer interface, or API, works differently. The third party never sees the customer’s password. Instead, the customer goes to the bank, proves who they are, and approves a specific connection. The bank then gives the third party a digital token, like a valet key that starts the car but does not open the glove box, which allows it to request particular data for a particular purpose. The bank knows exactly who is asking and can switch the connection off.

Data aggregators are firms that connect to thousands of financial institutions on behalf of many apps, so that each app does not have to build its own connections. They are the main users of these interfaces and generate a large share of the traffic.

Finally, two terms from the proposal’s performance standard. A response rate is the share of requests that the interface answers properly. Response time, or latency, is how long each answer takes, measured in milliseconds, thousandths of a second.

A service judged every month

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, or three and a half seconds. 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.

To put 99.5 percent in everyday terms, it means that in a month the interface may fail to answer properly no more than one request in two hundred, apart from planned maintenance: a respectable bar, and one that is measured, published and open to examination.

Those requirements turn an interface from a project into an operation. A project ends when the system goes live. An operation runs every day and is judged every month. 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. Polling means asking again and again whether anything has changed. 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. Customers call the institution whose name is on their card. 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.

Heavy users who pay nothing

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.

Here lies the economic tension. In most businesses, a heavy user of a service pays more. Here, the heaviest users would pay nothing to the bank, and the cost of serving them would fall on the institution and, indirectly, on its own customers.

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. A bank that can say exactly which firms generate what volume, and why, is in a far better position in any policy discussion than one that knows only that its servers are busy.

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. Fraud models are the systems that watch for suspicious behavior, and a scraper logging in from a data center on behalf of thousands of customers can look a great deal like an attacker. A well-run interface lets a bank block scraping with less customer harm, and the savings belong in the business case.

The discretion banks kept

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, and a regulator focused on competition would be quick to notice a bank that seemed to favor its own products by stalling rivals.

It can rely on shared assessments where standard-setting bodies or industry utilities offer them, which reduces duplicated due diligence across thousands of institutions. There is little sense in every community bank separately vetting the same handful of large aggregators.

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. That list is a genuine customer benefit. Many people have long forgotten which apps they once linked to their accounts. Showing them, and letting them switch connections off, builds trust in a way that screen scraping never could. Discretion exercised through a documented policy is what a bank gets in return for an obligation it cannot charge for.

Customers, competitors and examiners

The proposal was more than a regulatory cost. For a bank’s board, the larger stakes lay with customers, competitors and examiners.

Start with customers. People who link their accounts to apps are often among an institution’s most engaged and digitally active customers. When a connection breaks, the app usually shows a message saying the bank is not responding. The customer blames the bank, rather than the aggregator or the fintech. A slow or flaky interface is therefore a customer experience problem with the bank’s name on it, whatever the regulation says.

Then consider competition, which was the bureau’s stated purpose. An interface that lets customers easily share their data with other firms also makes it easier for those firms to offer them loans, savings accounts and payment services. Incumbents may find that uncomfortable, but it is a reality that banks cannot wish away, and the institutions that treat their interface as a well-run front door, rather than a grudging obligation, are better placed to keep customers who could now compare and switch more easily.

Risk is the third dimension. Every connected third party is a place where a bank’s customer data now lives, outside the bank’s own walls. Screen scraping made that risk invisible, because the bank could not see who was logging in. A proper interface makes it visible, which is the first step to managing it. Knowing which firms hold data on which customers is valuable information during any breach, fraud investigation or customer dispute.

Finally, there is reputation with regulators. The proposal’s published performance figures and its requirement that denials be reasonable and consistently applied meant that poor performance, slow decisions or inconsistent denials would be visible and open to question. A bank that can show a documented policy, a measured interface and a responsive process is in a strong position in an examination. One that cannot may find that technical shortcomings are read as deliberate obstruction, a far more serious conversation.

Put together, these make the interface a board-level matter. The cost is real, but so are the customer, competitive, risk and supervisory consequences of running it well or badly.

A regional bank and a community credit union

Take two institutions facing the same rule. The first, a large regional bank, builds its own interface. Its technology team stands up the service, connects it to the core and to online banking, and sets up monitoring. The chief operating officer owns the monthly response-rate figure, which appears in the same operations report as card authorization and online banking uptime. When a software release to online banking accidentally changes how transaction descriptions appear and several aggregators’ integrations break, the incident is caught by monitoring, rolled back, and written up. The bank also tracks traffic by aggregator and discovers that one firm accounts for a large share of calls because it polls every account repeatedly. It raises the issue through the standard-setting body and encourages the firm to move to notifications. Costs fall.

The second, a community credit union, cannot build anything of the kind and relies on its core vendor. Here the work is in the contract. At renewal, the credit union asks the vendor to commit to the 99.5 percent response rate as the rule defines it, to supply monthly evidence, and to pay service credits if it misses. It asks how the vendor will price the capability and negotiates accordingly. It adopts a short third-party access policy, borrowing from a shared industry assessment rather than vetting aggregators itself. Its member service team learns to show members their connected apps. The credit union does not run the machinery, but it still owns the obligation, and its contract and policy are where it exercises control.

Both institutions end up in a defensible position. Neither got there by treating the rule as a one-time technology project.

An owner for the monthly number

Everything starts with ownership. One executive is accountable for the interface’s performance and can explain the monthly number. Measurement follows the regulatory definition, not a friendlier internal one. Traffic is broken down by third party and purpose. Changes to online banking are tested against the interface before release. A written third-party access policy sets criteria, timelines and approvers, and decisions are logged. Data access agreements with large aggregators have been reviewed by counsel. And customers can see and manage their connections.

The usual failures mirror these. Institutions treat the interface as an IT project with a go-live date and no owner afterward. They accept a vendor’s own uptime figure, which may count things differently from the rule. They do not measure who generates traffic, so they can neither manage cost nor argue about it. They make access decisions case by case, inconsistently, inviting accusations of obstruction. They forget that complaints about third-party breaches will still land on their own front desk. And they overlook the savings on the other side of the ledger, the fraud noise and customer frustration that screen scraping causes, which makes the business case look worse than it is.

What a board should know about its developer interface

• Who owns our developer interface’s monthly performance figure, and do we measure it exactly as the rule defines it?
• If a vendor provides the interface, does our contract commit it to that definition, with monthly evidence and service credits?
• Which third parties generate our interface traffic, for what purposes, and how is that changing?
• Do we have a written policy for granting or denying third-party access, with decision times and named approvers?
• Can a customer see, in our app or branch, which third parties are connected to their accounts, and switch them off?

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. It dropped the specific response-time ceiling in favor of indicators such as consensus standards, meaning the speed expectation would be set by reference to standards agreed within the industry. It also exempted the smallest depository institutions.

Bank trade groups sued the day it was issued. In 2025, under new leadership, the bureau said it would reexamine the rule, and in July the court stayed the litigation, pausing the case while the bureau reconsidered.

In August 2025 the bureau published an advance notice reconsidering the rule, with whether data providers may charge fees among its central questions. An advance notice is an early step in rulemaking, in which an agency asks the public for views before proposing specific text. At least one large bank was reported that year to be planning to charge aggregators for access.

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. That should not surprise anyone who read the 2023 proposal closely. The fee ban was always the feature on which the rest of the bargain turned.

Meanwhile, the underlying shift continued regardless of the rule’s fate. Interface-based access continued to replace screen scraping under bilateral agreements and industry standards. Banks and aggregators found it in their own interest to move away from shared passwords, rule or no rule.

The work described here was worth doing under almost any outcome. Measuring interface performance, knowing who generates traffic and why, writing a consistent access policy and giving customers visibility of their connections all make sense whether access ends up free, priced or somewhere in between. Indeed, an institution that has tracked traffic by third party and purpose is the one best placed to make its case, whichever way the fee question is finally settled.