For credit unions, the 1033 outline was a question for the core processor

The week

On October 27, 2022, the Consumer Financial Protection Bureau released an outline of proposals it was considering under Section 1033 of the Dodd-Frank Act, which gives consumers a right to access their financial data. The outline opened the small business review panel process required before a proposed rule. It described requiring covered data providers, such as banks, credit unions and card issuers, to make specified account and transaction data available to consumers and authorized third parties through dedicated interfaces rather than screen scraping. It covered which data would be included, performance expectations for the interfaces, how third parties would be authorized, and limits on their use and retention of data. It also asked about the burden on smaller institutions and about timelines that could vary by size.

Earlier in this series we saw that by the time the 2021 competition order called for open banking rules, the largest banks and aggregators had already built many of the interfaces. That held at the top of the market. Thousands of smaller banks and credit unions were in a different position, since most run on a handful of core processors and digital banking platforms. For them, the question in the outline was never whether to build an API. It was what their vendors would build, when, at what price, and on what terms.

The outline was written for exactly this audience. A small business review panel exists to hear how a proposal would affect small entities before the bureau proposes a rule. For a community bank or credit union, that review turned on three decisions it could actually make. They were which parts of the coverage applied to it, what the vendor-delivered capability would cost, and what its contracts needed to say about performance and liability.

Coverage: what would apply, and when

The outline suggested that coverage might follow existing definitions in Regulation E and Regulation Z, reaching institutions that hold consumer deposit accounts or issue credit cards. It asked about compliance timelines that varied by size, and invited views on whether some small institutions should be treated differently.

For a small institution, the first job was to map its products against the outline’s data categories: transaction history, balances, account and routing numbers, terms and fees, upcoming bills. Some fields would be straightforward from the core. Others, such as pending transactions or bill payment details, might sit in separate systems run by other vendors. That map showed which vendors were in scope and how many integrations the eventual rule would require. It also exposed freshness problems. Many cores post some transactions in overnight batches, so an interface fed from the core may show a different balance from the one the customer sees in the app. Deciding which system is the source of truth for each field avoids disputes and confused customers later.

Timing followed. If small institutions received longer timelines or exemptions, they would gain time but lose the chance to shape their vendors’ products, which would be built first for larger clients. Some institutions decided to stay close to their vendors’ early programs for that reason.

Cost: buying compliance as a product

A core processor or digital banking provider would deliver the interface as a module or an upgrade. Its price would land in the institution’s budget, in a sector where technology costs already weighed on small margins.

The economics had several parts. One-time costs covered implementation, testing and staff time. Recurring costs covered the module’s license and the traffic it would carry, which could be large if aggregators polled accounts frequently. Indirect costs included fraud monitoring for a new access channel and customer service for questions about connected apps. Against that, an interface could reduce screen-scraping traffic that already loaded online banking systems and confused fraud models with logins from aggregator servers.

Institutions had more bargaining power acting together. Credit union service organizations, bankers’ banks and user groups for each core could ask vendors for common pricing, delivery dates and features. They could also submit evidence of cost to the review panel, which was the purpose of the process.

Some institutions looked at a third option: an API platform from a fintech middleware provider that sits on top of the core and presents a standard interface. That could arrive sooner and work across more systems. It also added another vendor holding customer data, another contract and another party to blame when something broke. The choice depended on how closely the core vendor’s roadmap matched the institution’s timeline, and on whether the institution had staff to manage one more critical supplier.

Contracts: performance and liability by agreement

The outline discussed performance expectations for interfaces, such as availability and response times. For a small institution, those standards would be met, or missed, by its vendor. The contract needed to carry them: committed uptime and latency, reporting the institution could use to demonstrate compliance, remedies when targets were missed, and notice of changes in how the interface worked.

Liability was the more contested question. If a third party misused data or a fraudulent payment followed from data obtained through the interface, the outline left open who bore the loss. Large banks negotiated bilateral data access agreements with aggregators that allocated some of that risk. Small institutions were rarely parties to such agreements. Their exposure would depend on the rule, existing payment law and whatever terms their vendor negotiated on their behalf with aggregators. Asking vendors whether they would sign aggregator agreements for the institution, and on what terms, was a practical first step. Organizations should check with counsel on how Regulation E and privacy rules interact with third-party data access.

Consent features belonged in the contract too. If customers were to see and revoke third-party access from their bank’s app, the digital banking vendor had to build that screen. An institution that did not ask for it would get whatever the vendor shipped, and on the vendor’s schedule.

With hindsight

The CFPB proposed a rule in October 2023 and finalized it in October 2024. The final rule excluded depository institutions at or below the Small Business Administration’s size standard, then 850 million dollars in assets, and phased compliance by size from 2026 to 2030. Banking groups sued the day it was finalized. In 2025, under new leadership, the bureau began reconsidering the rule, publishing an advance notice in August that asked, among other things, whether data providers may charge fees. In October 2025 the court barred enforcement of the rule until the reconsideration is complete. By mid-2026 a rewritten rule had not been finalized. For smaller institutions the outcome so far has been longer runway rather than a different problem: core and digital banking vendors still decide most of what their open banking capability looks like and costs.