How a fee question pulled open banking off the rulebook and onto the rate card
By asking whether banks may charge for customer data access, the CFPB’s August 2025 notice moved open banking’s rules from regulation into contracts. Big banks could set prices, smaller ones would inherit them through vendors, and fintechs would redesign around them.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
Two-minute summaryThe dek and the first sentence of each section, quoted from the article
By asking whether banks may charge for customer data access, the CFPB’s August 2025 notice moved open banking’s rules from regulation into contracts. Big banks could set prices, smaller ones would inherit them through vendors, and fintechs would redesign around them.
- The week On August 22, 2025, the Consumer Financial Protection Bureau, the federal regulator for consumer financial products, published an advance notice of proposed rulemaking.
- The moving parts of open banking The vocabulary of open banking hides a fairly simple picture.
- Providers that can set a price Only the largest banks have direct interfaces, heavy aggregator traffic and the bargaining power to price access unilaterally.
- Providers that will inherit a price Most community banks and credit unions do not run their own data interfaces.
- Data users that will pay a price Fintechs, lenders and aggregators sit on the other side of the rate card.
- One fee, three organizations Suppose a large bank announces a per-call fee for aggregators, and follow the effect through three organizations.
- Who gains, who pays, who gets the complaints Money.
- Data access as a product Because the shift is from regulation to contract, the work looks less like a compliance project and more like disciplined commercial management.
- With hindsight The rate card arrived before the rule.
The week
On August 22, 2025, the Consumer Financial Protection Bureau, the federal regulator for consumer financial products, published an advance notice of proposed rulemaking. That is an early-stage step in which an agency signals it is considering a rule and asks the public for input before drafting one. Its subject was the bureau’s personal financial data rights rule under Section 1033 of the Dodd-Frank Act, the provision of the 2010 financial reform law that gives consumers a right to access their own financial data. Anyone who has linked a bank account to a budgeting app, a payment service or a lender’s online application has used the system that rule governs. Behind that simple “connect your bank” button sits a very large question about who owns the right to move a customer’s financial data, and who, if anyone, gets paid for carrying it.
The rule, finalized in October 2024, required many banks, credit unions and other providers to make consumer data available to consumers and to authorized third parties, such as apps the consumer chooses, through interfaces. An interface here is a standardized electronic doorway, often called an API, through which one company’s software can request data from another’s in an agreed format. The rule also barred fees for that access.
The rule had a rocky life. Bank groups had sued the day it was finalized. In 2025 the bureau told the court it considered the rule unlawful, before announcing a new rulemaking in late July.
The August notice asked four questions: who may act as a consumer’s representative, whether providers may charge fees, and whether data security and privacy protections were adequate. Comments were due October 21.
The fee question did not arrive out of nowhere. Weeks earlier, news reports had said JPMorgan Chase planned to charge data aggregators for access. Aggregators are the companies that sit in the middle of open banking, connecting thousands of apps to thousands of banks so each app does not have to build its own link to every bank. If the largest bank in the country charged them, the economics of every app downstream would shift.
That is why a technical-sounding regulatory notice deserved attention from bank boards, credit union executives and fintech founders alike. It reopened who would write the rules of open banking, as well as what they would say.
The August 2025 notice raised the question of who pays.
That question changes where the rules of open banking get written. A no-fee regulation sets terms for everyone. Once fees are possible, terms are set in bilateral contracts, agreements negotiated one pair of companies at a time. The contract, with its price, rate limits, data scopes and liability clauses, becomes the working rulebook.
Institutions meet that shift from one of three positions. Some providers have the scale to set a price. Most providers will inherit a price through the vendors that run their interfaces. And the companies that use the data will pay it and have to redesign around it. Each position calls for different preparation.
The moving parts of open banking
The vocabulary of open banking hides a fairly simple picture.
The provider is the bank or credit union that holds your account. It has the data: balances, transactions, account and routing numbers.
The data user is the company you want to share that data with: a budgeting app, a lender checking your income, a payment service verifying your account.
The aggregator sits between them. Rather than every app building a separate connection to every bank, the aggregator builds the connections once and resells access.
Screen scraping is the old way of getting the data. The customer gives the app their online banking username and password, and software logs in as the customer and reads the screens, much as a person would. It works, but it means handing your password to a third party, and banks cannot easily tell a legitimate app from an attacker using stolen credentials.
An API is the newer way. The bank publishes a secure doorway that hands over only specific data, to an app the customer has authorized, using a digital token rather than the customer’s password. A token is like a valet key: it lets the holder do a limited set of things for a limited time, and it can be revoked without changing the master key.
A call is a single request through that doorway: “what is this account’s balance right now?” Some apps make a call only when the customer opens them. Others make calls on a timer, several times a day, for every connected account, whether the customer is looking or not. That difference turns out to matter a great deal once each call has a price.
The core processor is the company that runs a smaller bank’s central accounting system, the system of record for every deposit, loan and transaction. Most community banks and credit unions rent this from a handful of large vendors rather than building their own, and they often rent their online and mobile banking from similar vendors.
Providers that can set a price
Only the largest banks have direct interfaces, heavy aggregator traffic and the bargaining power to price access unilaterally. JPMorgan Chase’s reported plan to charge aggregators pointed to the heavy volume of automated data requests its systems handled, much of it, the bank argued, automated refreshes rather than requests a customer had initiated.
A per-call price changes behavior on both sides. It gives aggregators a reason to stop polling every account several times a day and to request data only when a customer action needs it. Polling means repeatedly asking for updates on a schedule, whether or not anything has changed. Cutting it can reduce load and fraud exposure for the bank.
A bank that sets a price takes on obligations, too. Paying customers will expect uptime commitments, response-time targets and dispute processes that look like any other commercial service. Once money changes hands, a slow or broken interface stops being an inconvenience and becomes a breach of contract.
The terms that come with a price often matter more than the price. Contracts can specify which data elements are shared, how long tokens last, what security standards the recipient must meet and who absorbs fraud losses. Those clauses decide many of the questions the 2024 rule tried to settle by regulation.
Pricing too aggressively carries its own risk: political scrutiny, complaints when popular apps break, and arguments that the fees entrench incumbents, meaning that large established banks use access charges to make life harder for newer competitors. Banks in this position should know their actual cost per call and be able to defend any price against it. They should also watch the measures that show whether pricing works: request volumes by aggregator, the share of calls tied to customer sessions, and complaint rates when access is throttled (deliberately slowed or capped).
Providers that will inherit a price
Most community banks and credit unions do not run their own data interfaces. Their customers’ data reaches third parties through core processors and digital banking vendors, or through aggregators connecting to those platforms. The 2024 rule exempted the smallest depository institutions altogether, but many of them still face aggregator traffic.
For these institutions, a fee regime is mainly a vendor contract question. If access becomes chargeable, the vendor might bill the aggregator, bill the institution, or both. It might keep the revenue or share it. It might set access policies on the institution’s behalf. Few existing core contracts anticipated any of this, because the market assumed either scraping or a no-fee mandate.
Institutions should read their core and digital banking agreements now for clauses on third-party data access, API pricing, data use by the vendor and the institution’s right to set its own access policies. Contract renewals are the moment to secure those rights. An institution that leaves the question open may find its data priced, and its customers’ apps throttled, by decisions it did not make.
Pricing also interacts with screen scraping. If an interface becomes expensive or slow to arrive, some third parties will keep logging in with customers’ credentials, which is the risk the 2024 rule aimed to end. An institution cannot simply block scraping until a workable interface exists, or it will break apps its customers rely on. The practical sequence is to secure an interface through the vendor, publish how third parties should connect, and then restrict credential-based access with notice. Each step needs a date and an owner.
Data users that will pay a price
Fintechs, lenders and aggregators sit on the other side of the rate card. A per-call fee turns data access from a fixed engineering cost into a variable cost that scales with customers and refresh frequency. A fixed cost is paid once regardless of volume; a variable cost rises with every unit of use.
Products built on constant balance refreshes, such as overdraft alerts or round-up savings, feel that most. Lenders using bank data in underwriting, the process of deciding whether to lend, pay per application, which is easier to absorb.
The engineering response is familiar from any metered service:
- Cache what can be cached. Store recent results and reuse them instead of asking again.
- Refresh on events, not on a timer. Ask for fresh data when the customer opens the app or a transaction needs checking, not every few hours by default.
- Request only the data elements a feature needs. A feature that needs a balance should not pull a year of transactions.
- Price products to reflect the full cost of the data they consume.
Some costs will pass to consumers, and those that are absorbed will squeeze thinner margins first.
The notice’s representative question matters here too. If a future rule limits who counts as a consumer’s representative, some business models may lose a regulatory right to access and depend entirely on negotiated contracts. Data users should know which of their products rely on the rule and which already rest on bilateral agreements. They should also track the litigation and any revised compliance dates with counsel, because the answer to that question decides their bargaining position.
One fee, three organizations
Suppose a large bank announces a per-call fee for aggregators, and follow the effect through three organizations.
The large bank sees that most calls into its interface come from automated refreshes overnight. It sets a price, publishes uptime and response-time commitments, and offers a lower rate for calls tied to a live customer session. Within months, its traffic falls and its fraud team finds suspicious logins easier to spot. It also fields complaints from customers whose favorite budgeting app now refreshes less often, and has to explain the change publicly.
A community credit union has no interface of its own; its digital banking vendor provides one. When the vendor’s renewal arrives, the credit union discovers a new clause allowing the vendor to charge aggregators and keep the revenue, and to set access limits on the credit union’s behalf. Its members’ apps will be governed by terms the credit union did not negotiate. It pushes back, securing the right to approve access policies and a share of any fees. A credit union that signed without reading would have handed those decisions away.
A fintech offering overdraft alerts refreshes every customer’s balance six times a day. Under per-call pricing, that design becomes its largest cost. Its engineers switch to refreshing when the customer opens the app and when a large transaction posts, and they stop pulling transaction history it does not use. Data costs fall sharply, and the company enters its next negotiation with an aggregator from a position of strength.
No regulation changed in any of these cases. Each organization changed a contract, a configuration or a product design, which is exactly where the August notice moved the action.
Who gains, who pays, who gets the complaints
Money. For large banks, data access could become a revenue line and a cost-recovery tool. For smaller institutions, it could become a revenue line for their vendors instead. For fintechs, it becomes a cost that scales with growth.
Risk. Contracts now decide fraud liability and security standards. A bank that does not negotiate those clauses may find itself absorbing losses caused by a third party it never chose. Continued screen scraping, if interfaces are expensive or late, keeps customer passwords in circulation.
Customers. Customers do not see contracts; they see apps that stop working, refresh less often or start charging. Complaints land on whoever the customer blames, which is usually their bank. A customer whose overdraft alert arrives hours late does not care whether the cause was a fee schedule, a vendor contract or an aggregator’s cost-cutting. She cares that she was charged an overdraft fee the app was supposed to help her avoid. Any change to pricing or access limits therefore needs a customer communication plan, agreed between the bank, its vendors and the major apps its customers use, before the change takes effect rather than after the complaints arrive.
Regulators and reputation. Fees invite scrutiny about competition and fairness. Any price needs a defensible cost basis and a clear public explanation.
Data access as a product
Because the shift is from regulation to contract, the work looks less like a compliance project and more like disciplined commercial management. The organizations that handle it well treat data access as a product with a price, a cost, a service level and a customer, whichever side of the table they sit on.
For a bank that can set a price, that means:
- A cost model that shows what each call actually costs to serve, built before any price is announced.
- A published rate card with tiers that reward customer-initiated requests over background polling.
- Written service levels, a named owner for the interface and a dispute process aggregators can use.
- Contract clauses that settle data scope, token lifetime, security standards and fraud liability, reviewed by counsel.
- A plain public explanation of why fees exist, ready before the first complaint.
For a community bank or credit union, it means:
- A summary of what every core and digital banking contract says about third-party access, fees and revenue sharing, kept current.
- A renewal calendar with the data access rights the institution wants to secure written down in advance.
- A dated plan to move third parties from screen scraping to an interface, with notice to customers and app providers before credential-based access is restricted.
For a data user, it means:
- A per-product view of how many calls each feature makes, and what that would cost at plausible prices.
- Event-driven refreshes, caching and minimal data scopes in place before fees force the change.
- A map of which products rely on rights under the rule and which on contracts, reviewed with counsel as the litigation moves.
The costly errors are mostly lapses of attention:
- Waiting for the final rule. The terms are being set now, in negotiations and renewals.
- Signing a vendor renewal without reading the data clauses. This is how a smaller institution ends up with its data priced by someone else.
- Blocking scraping before an interface works. Customers experience this as their bank breaking their apps.
- Pricing without a cost basis. It invites accusations of using fees to shut out competitors.
- Treating data as free in product design. A feature that polls every account on a timer may become unprofitable overnight.
What the bank, the vendor and the app should each ask
- How many data requests hit our systems from third parties each day, what share are tied to a customer actually using an app, and do we know our cost per call?
- What does our core or digital banking contract say about third-party data access, fees and who keeps the revenue, and who sets access limits today: us or our vendor?
- When is our next vendor renewal, and what rights do we want to secure in it?
- How much third-party access still comes through screen scraping, and what is our plan and timeline to move it to an interface?
- For data users: which of our products refresh on a timer, what would they cost under per-call pricing, and which depend on rights under the rule rather than contracts we already hold?
With hindsight
The rate card arrived before the rule. In mid-September 2025, JPMorgan Chase and Plaid announced a renewed data access agreement that included a pricing structure, the clearest sign that access was becoming a negotiated commercial term. Plaid is one of the best-known aggregators, so an agreement between the two was a signal to the whole market about where terms would be set.
On October 29, 2025, a federal court in Kentucky preliminarily enjoined the CFPB from enforcing the 2024 rule while the bureau reconsidered it. A preliminary injunction is a court order that pauses something while a case continues, here stopping enforcement of the rule. The order found the bank plaintiffs likely to succeed on challenges that included the rule’s treatment of third parties and its fee ban.
With enforcement enjoined until the reconsideration is complete, the original compliance dates have not taken binding effect, and we have not seen a final revised rule. Institutions should confirm the current status with counsel.
The positions described here held up. Large banks priced access through contracts. Smaller institutions found their exposure written into vendor agreements. Data users that had already moved to event-driven, scoped requests had lower costs and stronger negotiating positions than those still polling.
Regulatory uncertainty does not freeze a market; it moves decisions somewhere else. While the rule was in question, the real terms of open banking were being settled in negotiations, renewals and engineering choices. Executives who waited for the final rule before paying attention found that many of the important decisions had already been made, sometimes by their vendors. Those who read their contracts, knew their costs and tightened their designs were ready whatever the rule eventually says.
Spotted an error? Tell us and we will check it and correct the article where needed.