Why community banks’ open banking experience sat with their core vendors

The week

On July 9, 2021, President Biden signed Executive Order 14036, Promoting Competition in the American Economy. It set out 72 initiatives across more than a dozen agencies, on subjects from airline fees and hearing aids to noncompete agreements and broadband pricing. For financial services, it encouraged the Director of the CFPB to consider commencing or continuing a rulemaking under Section 1033 of the Dodd-Frank Act to facilitate the portability of consumer financial transaction data, so that consumers could switch financial institutions and use new products more easily. It also encouraged the banking agencies and the Justice Department to review their bank merger guidelines. The CFPB had issued an advance notice of proposed rulemaking on consumer access to financial records in late 2020. Section 1033 itself had been law since 2010, with no implementing rule.

In 2021, consumers already shared bank data with budgeting apps, lenders, payment services and investment platforms at scale. Most connections ran through data aggregators, and many still relied on screen scraping: the customer handed an app their online banking username and password, and software logged in as them. Large banks had begun replacing scraping with dedicated interfaces and bilateral agreements with aggregators. Community banks and credit unions mostly had not, because their online banking, mobile apps and account data sat on platforms run by a small number of core processors and digital banking vendors.

That fact shaped what the competition order could change for their customers. Whatever rule eventually emerged, the experience a credit union member had when connecting an app would be built largely by a vendor, under a contract the institution had signed years earlier. The experience breaks into three moments, each with a different degree of institutional control: connecting, whether the link to an app works; controlling, whether the customer can see and revoke what they have shared; and resolving, what happens when something goes wrong.

Connecting: reliability is a vendor roadmap item

The first moment is the one customers notice most. A connection either works or it breaks. Screen-scraped connections broke when login pages changed, when multi-factor prompts were added, or when an institution’s fraud controls blocked the aggregator’s traffic as suspicious. The customer saw an app that said their bank was “unavailable” and often blamed the bank.

Moving to a token-based interface fixes most of this. The customer authenticates with their own institution, approves access, and the app receives a token instead of a password. For a community institution, though, the interface is not something it builds. It is a feature of its digital banking platform, delivered when the vendor decides, connected to the aggregators the vendor has agreements with, and priced however the vendor chooses.

That makes connection quality a procurement question. What the institution can do is ask its vendors specific questions and put the answers in writing. Does the platform offer an application programming interface based on the Financial Data Exchange standard, which large banks and aggregators were converging on? Which aggregators are connected, and on what terms? Is there an extra fee per connection or per call? What uptime and response times apply to the interface, separately from online banking? A digital banking contract renewal in 2021 or 2022 was the moment to secure those terms. Waiting for a rule meant waiting for the vendor’s schedule instead of the institution’s.

Controlling: the consent dashboard decides trust

The second moment is control. Under screen scraping, a customer who stopped using an app had no reliable way to cut off its access short of changing their password. Many did not remember which apps they had connected years earlier. Token-based access allows something better: a page inside online banking that lists every connected app, what data each can see, when it last connected, and a button to revoke it.

That page is one of the few places where data sharing becomes visible to the customer inside the institution’s own channel. Done well, it turns a regulatory topic into a trust feature: the institution is the place where the member sees and governs their data. Done badly, or not at all, the customer manages permissions through dozens of separate apps, and the institution has no part in the relationship.

Here too the community institution depends on its vendor. Its influence lies in setting requirements: revocation that takes effect immediately, plain-language descriptions of what each app can access, notices when a new app connects, and reports showing how many members use third-party connections and which apps they use. The last item has a second use. It tells the institution which fintech products its members actually value, which is useful for its own product planning.

Resolving: the part the institution still owns

The third moment is when something goes wrong. A member’s account is drained after their credentials leak from a third-party app. An aggregator pulls data more often than agreed and slows online banking. A connected app initiates a payment the member says they never authorized. The member calls the institution, not the app.

These cases raise questions vendors cannot answer for the institution. How do error resolution duties for electronic fund transfers under Regulation E apply when access came through an authorized third party? What does the institution’s agreement with an aggregator say about liability, and does such an agreement exist at all? Who in the contact center knows how to tell a member which app accessed their account and when? Banks had argued for years that screen scraping blurred responsibility for losses. Tokens narrow the problem but do not settle it. Organizations should work through these questions with counsel and their vendors.

The practical work is operational. Contact center scripts for data-sharing complaints, a fraud playbook that can identify third-party access in the logs, a register of aggregator agreements, and a clear internal owner for data-sharing policy all sit with the institution. Of the three moments, this is the one where a well-run community institution can outperform a large competitor, because its service model is built on reaching a person who can help.

Seen this way, the competition order mattered less as a starting gun for a rule than as a prompt to look at contracts. Institutions that came out of the next few years with a good data-sharing experience mostly treated their core and digital banking vendors as the first audience for their open banking plans.

With hindsight

From 2026, the rule has had a long and unsettled path. The CFPB proposed its Section 1033 rule in October 2023 and finalized it in October 2024, requiring covered institutions to provide data through developer interfaces, barring fees for access, and phasing out screen scraping. The final rule exempted depository institutions with total assets of $850 million or less, so many community banks and credit unions were never directly covered, though their members still expected connections to work. Bank trade groups sued the day the rule was finalized. In 2025 the CFPB, under new leadership, began a new rulemaking, a federal court barred enforcement of the existing rule, and some large banks began seeking fees from aggregators. The CFPB is rewriting the rule, including the fee question, so institutions should confirm its status with counsel. The CFPB recognized the Financial Data Exchange as a standard-setting body in January 2025. Through all of this, the vendor dependency described here has not changed.