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

The week

Every time someone links their checking account to a budgeting app, a payment service or a mortgage application, data has to travel from their bank to somebody else. For years, much of that travel happened in a slightly alarming way, and on October 27, 2022, the Consumer Financial Protection Bureau took a formal step toward changing it.

That day the bureau released an outline of proposals it was considering under Section 1033 of the Dodd-Frank Act. Section 1033 gives consumers a right to access their own financial data. The outline was the bureau’s first detailed sketch of how that right might work in practice, the beginning of what is often called “open banking”: the idea that customers, rather than banks alone, control where their account data goes.

The step had been a long time coming. Section 1033 was enacted in 2010, but for years the bureau wrote no rule under it. It issued a request for information on consumer access to financial records in 2016 and published a set of nonbinding principles for consumer-authorized data sharing in 2017. In late 2020 it issued an advance notice of proposed rulemaking, the formal first step toward a rule. In July 2021 a presidential executive order on competition encouraged the bureau to move ahead. The October 2022 outline was the first time the bureau put concrete options on paper.

The release came the same week that the bureau’s director, Rohit Chopra, spoke about the rulemaking at Money 20/20, a large payments industry conference. The bureau framed the effort as a competition measure. If customers could move their account history easily, the argument went, they could switch providers more easily, and banks would have to compete harder to keep them.

The outline described requiring covered data providers, such as banks, credit unions and card issuers, to make specified account and transaction data available to consumers and to third parties the consumer authorizes. The data would flow through dedicated interfaces rather than screen scraping.

The data under discussion was broad. It included settled transactions and deposits, and pending ones that had not yet posted. It also covered scheduled bill payments set up in online banking, information that identifies the account and its owner, and account terms such as fees and rates. Account and routing numbers, which a third party needs to set up a payment from the account, were part of the discussion. Coverage was framed around deposit and prepaid accounts and credit cards. Mortgages, auto loans and student loans were not part of the initial scope.

Those two terms are worth unpacking. Screen scraping is when an app asks for your online banking username and password, logs in as you, and copies information off the screens. It works, but it means handing your password to a third party, and banks cannot easily tell the app from a fraudster. A dedicated interface, usually an API (application programming interface), is a purpose-built doorway between two computer systems. Instead of pretending to be you, the app asks the bank’s system for specific data, with your permission, and gets a structured answer back. The difference is roughly that between lending someone your house keys and a delivery locker that opens only for the right parcel.

The outline 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.

For third parties, the outline floated a set of obligations. They would collect, use and keep only the data reasonably necessary for the product the consumer had asked for. They would give the consumer a clear authorization disclosure, honor revocation, and limit how long access lasted before the consumer had to reauthorize. The outline presented these as options and questions, not settled positions. Much of its value lay in showing which way the bureau was leaning.

Publishing the outline opened the small business review panel process, a step required before the bureau could propose a rule. Its purpose is to hear, early, how a proposal would affect small entities. For thousands of community banks and credit unions, that made October 27 the moment their part of the open banking story began.

The bureau set January 25, 2023 as the deadline for written feedback from other stakeholders, while small entity representatives would meet the panel directly. The panel would then write a report, and the bureau would consider it in drafting a proposed rule. That sequence meant at least a year before any proposal, and longer before any compliance date. For a small institution, the useful question that week was what to do with that time.

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.

Cores, platforms and aggregators

Vendors sit at the center of this story because of how a small financial institution’s technology is put together.

At the heart is the core banking system, often just called “the core.” It is the master ledger: it records every account, every balance, every deposit and withdrawal, and calculates interest and fees. Large banks sometimes build or heavily customize their own cores. Most small banks and credit unions rent theirs from a core processor, a technology company that runs the same system for hundreds or thousands of institutions.

Layered on top is the digital banking platform: the website and mobile app customers actually use. It is often supplied by a different vendor, and it talks to the core behind the scenes. Around both sit other specialized systems: bill pay, card processing, loan servicing, each potentially from yet another provider.

Why a few vendors hold the keys

The core market for small institutions is concentrated. A small number of large providers run the cores for most community banks and credit unions, and core contracts usually run for several years with significant costs to leave early. Converting to a new core is a major project. It touches every account, every branch process and every integration, and institutions undertake it rarely. That gives the incumbent vendor considerable bargaining power over pricing and priorities.

Digital banking platforms are somewhat more competitive, and institutions change them more often. Even so, the digital banking vendor depends on the core vendor for data. Open banking requires both to cooperate, and the institution often has to referee between them. A feature that needs a change in the core and a new screen in the app will only move as fast as the slower of the two roadmaps.

Banks and credit unions are not identical here

The vendor dependence is similar for community banks and credit unions, but the surrounding structures differ. Credit unions have a long tradition of credit union service organizations, cooperatively owned firms that provide shared technology and services. Some of them operate shared cores or digital platforms for many credit unions at once. Community banks more often turn to bankers’ banks and state banking associations for collective support.

Oversight also differs. Federal banking agencies can examine the technology service providers of the banks they supervise under the Bank Service Company Act. The NCUA does not have the same authority over credit union vendors, and it has asked Congress for it for years. A credit union relying on a vendor’s open banking module therefore carries more of the oversight burden itself, through contract terms, audit reports and its own testing.

Other institution types fall elsewhere on the spectrum. A large regional bank may build its own interfaces and negotiate directly with aggregators. A bank that provides accounts through fintech partners may already run APIs for those partners and can extend them. A small credit union with a shared core has the least room to act alone and the most to gain from acting with others.

An aggregator is a company that connects to many financial institutions at once and passes data to apps. When a budgeting app shows balances from five different banks, an aggregator is usually doing the collecting.

An API, the dedicated interface the outline favored, is a set of agreed requests and responses. An app might send “give me the last 90 days of transactions for this account, with the customer’s permission,” and the bank’s system replies with a neatly structured list. Unlike screen scraping, nobody needs the customer’s password, the bank knows exactly who is asking, and the customer can, in principle, see and revoke that access.

For a small institution, nearly every piece of this lives in a vendor’s product. That is why the outline was, in practice, a question for the core processor.

One request, two ways

Follow a single request from start to finish. Say a credit union member wants to use a budgeting app. Under a screen-scraping model, the app asks her for her online banking username and password, stores them, and logs in every night as if it were her. The credit union sees a login from a data center in another state, at 3 a.m., many times a week. Its fraud system has to decide whether that is the member’s app or a criminal with stolen credentials. Often it cannot tell.

Under an interface model, the member is sent from the app to her credit union’s own login page. She signs in there, sees a screen explaining what data the app wants and for how long, and approves it. The credit union’s systems issue the app a digital pass, often called a token, that unlocks only the agreed data. The app never sees her password. If she later changes her mind, she can revoke the pass from her credit union’s app, and the doorway closes.

Behind that simple experience sit several moving parts: the login and consent screens, which belong to the digital banking vendor; the token system, which may belong to the same vendor or a third; the data itself, which lives in the core and in other systems; and the monitoring that spots unusual traffic. Every one of those parts is a line in somebody’s product roadmap and somebody’s price list. That is why, for a small institution, the practical questions are commercial as much as technical.

What the interface asks of the institution

Moving from passwords to tokens shifts work onto the institution and its vendors. Someone has to decide which third parties may connect at all, and how they prove who they are. Someone has to set how long a token lasts, how often it can be used and what data it unlocks. The consent screen must say, in words a member understands, what is being shared and with whom. And the whole system needs logs that tie each data request to a specific consent.

The third party on the other end is often not the app the member chose. Many apps connect through an aggregator, which holds the token and passes the data on. The member sees the budgeting app’s name. The institution sees the aggregator’s. A consent screen and a revocation list that name only one of them will confuse members and examiners alike, so the vendor’s design needs to show both.

Fraud monitoring also has to change. Scraping traffic looked like logins, and fraud systems treated it that way. Token-based traffic looks different: steady, predictable requests from known parties. That should make genuine anomalies easier to spot, but only if the monitoring tools are retuned. A vendor that delivers the interface without updating the fraud rules delivers half the benefit.

It also explains why examiners and auditors would care. Once data flows through a formal doorway, the institution is expected to know who has been given access, to what, and whether that access is being used as agreed. Records of consent, revocation and traffic become evidence, and the institution needs to be able to produce them even if the vendor holds them.

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. (Regulation E governs electronic transfers such as debit card payments; Regulation Z governs consumer credit such as credit cards. Borrowing their definitions meant reaching institutions that already deal with those products.)

The outline’s scope had clear edges. Checking and savings accounts, prepaid accounts and credit cards were in. Mortgages, auto loans, student loans and other installment credit were not. For a credit union whose members mainly hold share accounts and auto loans, that meant only part of its product set would be in scope at first. The rest would still be scraped, or not shared at all, unless the institution chose to include it.

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.

Take a credit union member who buys groceries on a Tuesday afternoon. The mobile app, which pulls from the card processor, shows the pending charge right away. The core, which updates overnight, still shows Tuesday morning’s balance. If a budgeting app reads from the core, it tells the member they have more money than they do. The member calls the credit union, not the budgeting app, to ask why the numbers disagree. Nobody did anything wrong; the systems simply keep different clocks. Choosing a source of truth in advance is how an institution avoids that phone call.

Size and timing

The outline raised the possibility of staggered compliance dates by size, and of exemptions for the smallest institutions. Those two options carried different consequences. A later compliance date gives an institution time to watch others go first and buy a more mature product. An exemption, if granted, removes the legal requirement but leaves the market pressure. Members would still connect apps, aggregators would still scrape where no interface existed, and the institution would carry the fraud and service costs of that scraping indefinitely.

Choosing a source of truth

The fix for the grocery problem is a simple table, maintained jointly by operations and the vendors. For each data field in scope, it names the system that holds the authoritative value, how often that value refreshes, and who owns its accuracy. Balances might come from the card processor during the day and the core overnight. Bill payment data might come from the bill pay vendor. Terms and fees might come from the product catalog. Once the table exists, the interface can be configured to pull each field from the right place. Member service staff can also explain differences when they occur, instead of guessing.

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.

“Polling” deserves a word. Some apps check for new transactions many times a day, for every connected customer. Each check is a request the bank’s systems must answer. If the vendor charges by volume, a popular app can drive up the bill without anyone noticing. Understanding how a vendor prices traffic matters as much as the headline license fee.

A useful exercise for a finance team is to sketch three scenarios for the first few years: light use, where only a handful of members connect apps; expected use; and heavy use, where a popular app drives large volumes. If the vendor’s pricing makes the heavy scenario unaffordable, that is a negotiating point to raise now, not a surprise to discover in a quarterly invoice.

A budget in four lines

A finance team preparing for the rule could set the cost out in four lines. The first is implementation: vendor professional services, internal project staff and testing. The second is the recurring license or subscription. The third is traffic, whether priced per call, per connected account or in tiers. The fourth is the operating overhead around the interface: fraud monitoring, member service, third-party due diligence and compliance reporting. The first two are usually in the vendor’s proposal. The last two are usually not, and they are often larger than expected.

The other side of the ledger holds savings that are harder to count. Scraping traffic consumes capacity in online banking systems, and some vendors charge for that capacity. Member calls about failed connections and locked accounts cost staff time. Fraud losses from stolen credentials that look like aggregator logins are real, even if they are hard to attribute. A credible business case lists these savings and admits that most cannot be measured precisely in advance.

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.

Who captures the value

A further economic question lay beneath the outline. Open banking moves value around the system. Aggregators and fintechs gain access to data they can build products on. Consumers gain choice. Large banks gain a controlled channel in place of scraping. Small institutions pay for the interface and may see deposits or payments drift to products built on top of it. If no fee can be charged for access, the cost of serving that traffic falls entirely on the data provider. If fees are allowed, some of that cost can be recovered, though small institutions would have little power to set them. The outline did not settle the matter, and it became one of the most contested questions later on.

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.

An institution weighing that option would want answers to a few practical questions. How does the middleware read data from the core, and does the core vendor support that connection or merely tolerate it? What happens to the interface when the core is upgraded? Who holds the tokens and consent records, and can they be moved if the middleware provider is replaced? A middleware layer that depends on an unsupported connection to the core can break at each core release, and the institution will be the one fielding member calls when it does. Asking for the core vendor’s written position on the connection, before signing, avoids that surprise. Some core vendors offer certification or partner programs for exactly this purpose.

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.

Uptime is the share of time the interface is working, and latency is how long it takes to answer a request. If a regulator expects a certain level of both, and the institution’s vendor runs the interface, then the institution needs the vendor’s promise, and the vendor’s data, to show it met the standard.

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. How Regulation E and privacy rules apply once a third party has the data is a question for the institution’s lawyers.

Clauses to look for

• Service levels with real definitions. How uptime is measured, over what period, and what counts as planned maintenance.
• Reporting the institution can hand to an examiner. Availability, response times, error rates and consent records, in a usable format and on a set schedule.
• Volume pricing with a ceiling. Caps or tiers that keep a popular app from producing an unbudgeted bill.
• The vendor’s own use of data. Whether the vendor may analyze or share member data that passes through its systems, and for what purposes.
• Incident notice. How quickly the vendor must report a security incident or an outage, and what information it must provide.
• Regulatory change. Whether changes required by a final rule are included in the fee or billed separately, and by when they will be delivered.

Audit evidence matters as well. Most institutions rely on a vendor’s independent audit reports, such as a SOC 2 report, to show that controls work. Those reports cover what the vendor chose to include in scope. An institution should check that the open banking module, and the systems behind it, are covered.

Where the vendor is not the only party

Third-party risk management adds another layer. In June 2023 the federal banking agencies issued joint guidance on managing risks from third-party relationships. It applies to the banks they supervise, and it expects oversight proportionate to how critical the relationship is. An open banking module that carries member data to outside parties is likely to rank as critical. Aggregators and fintechs that receive data are a different kind of third party. The institution may have no contract with them at all. Counsel should advise on how far the institution’s duties extend to parties it has not chosen but must serve under a rule.

How a loss would actually travel

Payment law gives a sense of where losses land. Under Regulation E, a consumer’s liability for unauthorized electronic transfers is limited, and the institution holding the account generally absorbs the rest. If data obtained through an interface is used to set up a fraudulent ACH debit, the member can dispute it. Under Nacha’s operating rules for the ACH network, the member’s institution can return an unauthorized consumer debit within 60 days of settlement, based on the member’s written statement. The bank that originated the debit, and through it the merchant or fintech that requested it, then bears the loss.

That chain works when every party is identifiable and solvent. It works less well when the fraud runs through a small fintech that has disappeared, or when it is unclear whether the member authorized the original data sharing. Each such case costs staff time to investigate, and some losses stick. A contract that obliges the vendor to supply logs tying a data request to a specific consent shortens those investigations. It also gives the institution evidence when it seeks recovery from another party.

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.

Two institutions, two outcomes

Consider two hypothetical institutions of similar size.

A small community bank read the outline, noted that small institutions might get more time, and filed it away. Two years later its core vendor announced an open banking module with a price, a feature list and a delivery date, all designed around larger clients. The bank had no say in the consent screen, no clear answer on who handled aggregator agreements, and a recurring fee it had not budgeted.

A credit union down the road did something different. Its operations lead built the product-to-data map in a few weeks and found that bill payment data lived with a separate vendor. Through its core’s user group, it joined other credit unions in asking for written roadmaps and pricing models, and it sent cost evidence to the review panel. At its next core contract renewal it wrote in uptime targets, compliance reporting and a member-facing consent screen. When rules eventually firmed up, it was negotiating details, not starting from zero.

The case for waiting

The community bank’s approach had a defensible logic. Small institutions might well be exempt, and some were later excluded from the final rule entirely. Vendor first releases are often immature. Spending scarce staff time on a rule years away, with its shape still uncertain, competes with exam findings, fraud and day-to-day operations.

The flaw lay in treating the rule as the only reason to act. Members were already connecting accounts through scraping, with the fraud and service costs that came with it. Vendors were already designing products, and their early design choices would shape what everyone else could buy. The credit union’s work cost little: a data map, a few user group meetings and some contract language at a renewal already on the calendar. It would have been useful even if the rule had never arrived.

Sequencing the work

For a small institution, the order of work matters more than its speed. The data map comes first, because it shows which vendors are involved. Conversations with those vendors come next, ideally through a user group, because they reveal roadmaps and pricing models. Contract changes follow at the next renewal, because that is when the institution has the most bargaining power. Implementation comes last, when the vendor’s product and the rule are both stable enough to build on. Each step is cheap compared with the one after it, and each makes the next one better informed.

What the board should see

A short set of measures would let a board follow this work without legal briefings. They include the number of members with connected apps, and the share of that traffic arriving through a dedicated interface rather than scraping. The board should also see member complaints and service calls about connected apps, the vendor’s attainment of its service levels, and the total cost of the capability per connected member. Most of these figures come from the vendor. Asking for them in the contract is what makes them available.

The contrast points to a handful of avoidable errors:

• Assuming “the vendor will handle it.” The vendor will handle what it is asked to handle, at the price it chooses.
• Treating an exemption as a solution. More time is useful, but customers still link accounts, and screen scraping continues until something replaces it.
• Ignoring data freshness. Mismatched balances generate complaints and erode trust in both the institution and the app.
• Negotiating alone. A single small institution has little bargaining power with a core processor; a user group or service organization has more.
• Leaving liability vague. Who pays for fraud should be settled in the contract before any occurs.

Who keeps the customer relationship

Open banking can sound like a niche compliance topic, but it decides who owns the customer relationship. When members connect their accounts to outside apps, they are deciding where they manage their money. An institution that makes that connection safe and smooth stays part of the picture. One that makes it clumsy, or leaves members handing out passwords, risks becoming a utility that holds deposits while the relationship moves elsewhere.

Consider the member experience over time. A member who links an account and has it work without trouble for years rarely thinks about the institution behind it. A member whose connection breaks every few weeks, or who is asked to re-enter a password repeatedly, often blames the bank or credit union, whatever the actual cause. Reliability of a doorway the institution may not even run becomes part of its brand.

Data flows both ways

Open banking is often discussed as a threat to smaller institutions, but the same rights work in their favor. A credit union can be a data recipient as well as a data provider. With a member’s permission, it can pull transaction history from the member’s other accounts to speed up account opening or to underwrite a loan on actual cash flow rather than a thin credit file. It can make it easier for a member to move a direct deposit or recurring bills from a larger bank. Those uses depend on the same interfaces, consent screens and vendor capabilities discussed above.

Few small institutions planned for that side of the rule in 2022, which is understandable given how much work the provider side implied. Their vendors’ roadmaps focused on compliance as a data provider. An institution that asked its digital banking and lending vendors about inbound data, alongside outbound, was positioning itself to compete for members rather than only to defend against losing them.

Where fraud enters

Data sharing creates particular fraud risks. Account and routing numbers shared with a third party can be used to originate payments if they fall into the wrong hands. Credentials stored by apps can be stolen in a breach and used to take over accounts. Token-based access removes the credential risk, but it does not remove the risk that a third party’s systems are compromised. Nonbank firms that hold consumer financial data are generally subject to the Federal Trade Commission’s Safeguards Rule, which the FTC strengthened in 2021, with most of the new requirements taking effect in 2023. That rule sets expectations, but the institution will still hear first from a member whose money has gone missing.

There is risk on the other side too. Every new doorway into customer data is a new place for fraud to enter and a new set of questions from examiners. And there is cost: technology budgets at small institutions are already stretched, and a new module with traffic-based pricing can grow faster than expected. Getting coverage, cost and contracts right is how a leader keeps those three forces in balance.

Where the vendor decisions sit

• What have our core and digital banking providers told us, in writing, about their open banking roadmap, pricing and delivery dates?
• How would we be charged for API traffic, and what happens to the bill if a popular app polls our members’ accounts many times a day?
• Are we working with a user group, credit union service organization or bankers’ bank to negotiate together?
• Will our vendor sign aggregator agreements on our behalf, and who bears the loss if data is misused?
• When is our next core contract renewal, and what open banking terms do we want in it?

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.

The final rule kept the outline’s basic architecture and settled several of the questions it had raised. It barred data providers from charging fees for access through the required interfaces. It limited third parties’ secondary use of data, including for targeted advertising, cross-selling and data sales, and required consumers to reauthorize access at least once a year. It also created a process for recognizing industry standard-setting bodies. In January 2025 the bureau recognized the Financial Data Exchange, an industry group, as a standard setter under the rule.

For an institution just above the 850 million dollar line, the final tier meant a compliance date years away. Its vendors, though, had to build for their largest clients first, on the earlier dates. The smaller institution would receive whatever had been designed for those clients, much as the outline had implied. Its main choices were about timing and terms, not design.

For many community banks and credit unions, that exclusion looked at first like the end of the story. But members still linked accounts to outside apps, and the question of how that data traveled, and on whose terms, did not go away because a rule did not apply.

Banking groups sued the day the rule 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 late October 2025, the federal court in Kentucky hearing the banks’ challenge stayed the rule’s compliance dates. By mid-2026 a rewritten rule had not been finalized.

The fee question did not stay theoretical. Large banks argued that the cost of serving heavy aggregator traffic should not fall on them alone. In 2025, reports that at least one of the largest banks planned to charge aggregators for data access drew strong objections from fintechs. The debate played out at the top of the market. Its outcome will flow down to smaller institutions through their vendors’ products and pricing.

The question of fees is a telling one. Whether an institution can charge third parties for data access changes the economics described above, turning a pure cost into something that might be partly recovered. It is also exactly the sort of term that would flow through vendor products and contracts rather than being set by each small institution on its own.

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.

What held up best was the view that the vendor relationship, not the rule text, would decide most of what a small institution experienced. What held up less well was any expectation that the rule would soon set a stable timetable for replacing screen scraping. Four years after the outline, compliance dates had been set, stayed and reopened, and screen scraping had not disappeared. Institutions that had used contract renewals to secure interfaces, reporting and consent tools had something in place regardless. Those that had waited for the rule were still waiting.

Whatever the final rule says, a small institution’s open banking experience will be shaped largely by its vendors. The institutions best placed are those that know where their data lives, negotiate alongside their peers, and treat each contract renewal as a chance to write down what they need, rather than waiting for a rule to tell them.