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

The week

Some of the most consequential policy moments arrive bundled with things that seem to have nothing to do with banking. 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. It also created a White House Competition Council to coordinate the agencies’ work and track progress.

Tucked into that long list was a passage about bank data. The order encouraged the Director of the Consumer Financial Protection Bureau, or CFPB, to consider commencing or continuing a rulemaking under Section 1033 of the Dodd-Frank Act. The goal was to facilitate the portability of consumer financial transaction data, so that consumers could switch financial institutions and use new products more easily.

Your record of deposits, payments and balances is useful to you beyond your own bank. A budgeting app can use it to show where your money goes. A lender can use it to judge whether you can afford a loan. A new bank could use it to make switching painless. The order pushed the government toward a rule that would give consumers a clear right to have that data shared, safely, with the services they choose. This idea is often called open banking.

Section 1033 itself was not new. It had been law since 2010, with no implementing rule, meaning the right existed on paper but nobody had written down the details of how it should work. The statute says a covered provider must make information about a consumer’s financial product available to that consumer in a usable electronic form. It also tells the CFPB to promote standardized formats for that data.

The Bureau had circled the subject for years. It issued a request for information in 2016. In October 2017 it published a set of principles for consumer-authorized data sharing, which were not binding. It held a public symposium on data access in February 2020. On October 22, 2020, it issued an advance notice of proposed rulemaking, an early request for public input, on consumer access to financial records. That notice appeared in the Federal Register in November, with comments due in early February 2021.

By July 2021 the comment period had closed and nothing further had been proposed. The Bureau was under acting leadership, and the President’s nominee for director had not yet been confirmed. The executive order added presidential encouragement to a slow-moving effort, without setting any deadline.

The order also touched bank competition directly. It encouraged the Attorney General to work with the heads of the Federal Reserve, the FDIC and the OCC on a review of current practices. The goal was a plan to revitalize merger oversight under the Bank Merger Act and the Bank Holding Company Act.

A second document from the same days bore on the same institutions from a different direction. On July 13, 2021, the Federal Reserve, the FDIC and the OCC proposed joint guidance on managing risks from third-party relationships. It would replace each agency’s separate guidance with one common text, and it named relationships with financial technology companies explicitly. The agencies stressed that a bank remains accountable for activities it outsources, including compliance with consumer protection law. Comments were due in mid-September. The NCUA, which supervises federally insured credit unions, was not a party to the proposal.

The proposal mattered for open banking because a community bank’s connection to any app ran through vendors it had chosen and contracted with. Under the proposed guidance, a bank that relied on a core processor or digital banking vendor was expected to plan, diligence, contract for and monitor that relationship in proportion to its risk. A data-sharing interface built by that vendor would fall within the same oversight.

Read together, the two documents pointed at one tension. Washington wanted consumers to be able to move their data freely. Supervisors wanted banks to answer for the vendors and partners that touched that data.

For large banks, the data-sharing passage was a nudge toward work many had already started. For the thousands of community banks and credit unions across the country, it raised a more awkward question. The technology that would decide how open banking felt to their customers was mostly not theirs.

In 2021, consumers already shared bank data with budgeting apps, lenders, payment services and investment platforms at scale. Open banking was not a future idea waiting for a rule. It was happening every day, mostly out of view.

Their customers were already sharing data, so the question the competition order raised for community banks and credit unions was who would shape that experience, and how much say the institution would have. The answer, for most, was uncomfortable: a great deal of it would be decided by the vendors that ran their technology.

This piece first sets out how data sharing actually worked in 2021 and where the vendors stood in it. It then follows the customer’s experience through 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. It traces one member through all three, sets out the commercial case for acting before any rule, and ends with what that meant for contracts.

How data sharing actually worked in 2021

Most connections between banks and apps ran through data aggregators. An aggregator is a middleman company that connects to thousands of financial institutions on one side and thousands of apps on the other, so that each app does not have to build its own connection to every bank.

Many of those connections still relied on screen scraping. The customer handed an app their online banking username and password, and software logged in as them, read the account pages and copied the data. It works, more or less. But the app now holds credentials that open everything, the customer cannot easily tell what it did with them, and the only way to take access back is to change the password.

Large banks had begun replacing scraping with dedicated interfaces and bilateral agreements with aggregators. JPMorgan Chase, for example, had a data-access agreement with Plaid dating to 2018, according to later reporting on the two firms. Community banks and credit unions mostly had not, because their online banking, mobile apps and account data ran on platforms operated by a small number of core processors and digital banking vendors.

Two definitions help here. A core processor runs the core banking system, the central ledger that holds every account balance and transaction, for many small institutions at once. A digital banking vendor supplies the website and mobile app customers log into. A community bank typically licenses both rather than building them, which is sensible: it would be enormously expensive for a small institution to build and maintain its own. But it means the bank’s digital front door, and much of what lies behind it, is designed by someone else.

The chain between a member and an app

Follow a single data request from end to end. A budgeting app asks its aggregator for a member’s latest transactions. The aggregator reaches the credit union through whatever channel it has: a scripted login to the online banking site, or an interface the digital banking vendor exposes. The digital banking platform, in turn, pulls balances and transactions from the core, often through the core vendor’s own middleware.

Four or five companies stand in a row, and the institution whose name the member knows may have a contract with only two of them. The aggregator’s agreement, if one exists, is frequently with the digital banking vendor rather than with the institution. The app’s agreement is with the aggregator. The member agreed to terms with the app. The institution sees the traffic arrive and the complaints afterward.

Each link adds a place where data can be cached, copied or held longer than the member expects. Each also adds a party whose security the institution cannot directly test. For a bank examiner reviewing third-party risk, that chain is the thing to map. For a member, it is invisible.

Why large banks moved first

Large banks had engineering teams that could build and run their own interfaces, and enough traffic to make the effort pay. Scraping loads their servers, triggers their fraud models and leaves their customers’ passwords in other companies’ databases. A bank with tens of millions of online customers could negotiate one agreement with a major aggregator and move a large share of that traffic onto a controlled channel.

A community bank had none of those advantages. It could not build an interface on a core it did not own. It had little bargaining power with aggregators, which had no strong reason to prioritize a single small institution. Its realistic route to an interface ran through its vendor, on the vendor’s timetable.

What supervisors could see of the vendors

The vendors were not unsupervised. Under the Bank Service Company Act, the federal banking agencies can examine services that a third party performs for a bank. The agencies, acting together through the FFIEC, examine the largest technology service providers and make the reports available to client banks.

Credit unions sit in a different position. The NCUA has long asked Congress for comparable authority to examine credit union service providers and vendors, and does not have it. A credit union’s main tool for shaping what its core and digital banking vendors do is therefore its contract. That raises the stakes of every renewal.

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.

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. That last cause deserves attention. From the bank’s point of view, a program logging into thousands of accounts from the same location looks exactly like an attack. Fraud teams are right to be wary of it. The customer, however, saw an app that said their bank was “unavailable” and often blamed the bank.

Why fraud teams and aggregators collided

The collision had a mechanical cause. Credential-stuffing attacks, in which criminals try stolen username and password pairs at scale, use the same pattern as an aggregator’s scripted logins: automated, high-volume, from data center addresses, often at night. A fraud model trained to block the first will catch the second.

Multi-factor authentication made it worse. Every time a member was asked for a one-time code, the aggregator’s script either failed or had to relay the prompt back through the app to the member. Some institutions loosened prompts for known aggregator addresses to keep connections alive. That trade bought reliability at the price of a weaker control on a channel that attackers could imitate.

Neither side was wrong. The fraud team was defending members against account takeover. The aggregator was delivering a service members had asked for. The underlying problem was a channel that could not tell the two apart, and only a dedicated interface fixes that.

Tokens and interfaces

Moving to a token-based interface fixes most of this. The customer authenticates with their own institution, on the institution’s own screen, and approves access. The app then receives a token instead of a password. A token is like a valet key for a car: it lets the holder do a specific, limited set of things, it can be cancelled without changing anything else, and it never reveals the master key. The connection is made through an application programming interface, or API, a defined doorway through which one company’s software can request specific data from another’s, in a standard format, without pretending to be a person.

The institution gains in other ways as well. Its fraud team can separate aggregator traffic, which now arrives through a known door with its own credentials, from attack traffic arriving at the login page. It can rate-limit the interface separately. Some large banks also began passing tokenized account numbers to apps instead of the real account number, so a leak downstream would not expose the number that moves money.

For a community institution, though, the interface is a feature of its digital banking platform rather than something it builds, delivered when the vendor decides, connected to the aggregators the vendor has agreements with, and priced however the vendor chooses.

What the contract actually governs

That makes connection quality a procurement question. What the institution can do is ask its vendors specific questions and put the answers in writing:

• whether the platform offers an application programming interface based on the Financial Data Exchange standard, which large banks and aggregators were converging on. The Financial Data Exchange, or FDX, is an industry group that publishes a common technical format for this kind of sharing, so that every bank’s doorway works the same way.
• which aggregators are connected, and on what terms;
• whether there is an extra fee per connection or per call;
• what uptime and response times apply to the interface, separately from online banking.

Several less visible terms matter as much. One is data scope: which fields the interface returns, such as balances, transactions, account and routing numbers, and statements, and whether the institution can restrict any of them. Another is change notice: how much warning the institution gets before the vendor adds or drops an aggregator. A third is logging: whether the vendor records each third-party access with the aggregator’s identity and keeps it long enough to support a dispute. A fourth is exit: whether the tokens and connection records move with the institution if it changes vendors, or whether every member must reconnect every app.

The last term is easy to miss and expensive to lose. A credit union that converts to a new digital banking platform without it may break every member’s app connection on the same weekend.

Bargaining power differs by institution

Not every institution negotiates from the same place. A community bank with several billion dollars in assets may be among a vendor’s larger clients and can ask for bespoke terms. A small credit union on a standard contract usually cannot. Its bargaining power comes from timing, at renewal, and from numbers: credit union service organizations and user groups can press a vendor collectively for features that no single client could win alone.

Banks also have a resource credit unions lack. If the FFIEC agencies have examined the vendor, the bank can request the report and see how the supervisors judged the vendor’s controls. A credit union must rely on the vendor’s own audit reports and its contract rights.

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.

Take a credit union whose digital banking contract is up for renewal. It can sign the vendor’s standard terms, or it can ask for a written commitment on the interface, the list of connected aggregators, fees and service levels. The second path takes a few extra weeks of negotiation. It also means that when members complain that their budgeting app keeps disconnecting, the credit union has something to point to and something to enforce.

Useful measures to request are simple. They include the share of third-party traffic arriving through the interface rather than through scripted logins, the connection success rate by aggregator, and the number and length of interface outages each quarter. Those three figures tell a board whether the member experience is improving, without anyone needing to read an API specification.

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. Their data might still be flowing to an app they had deleted from their phone long ago.

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. This is often called a consent dashboard.

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.

That matters strategically. A community institution’s advantage is its relationship with its customers. If every digital interaction with a member’s money happens inside other companies’ apps, that relationship thins. A good consent dashboard is a small way of keeping the institution at the center of its members’ financial lives.

What a dashboard needs underneath

A consent dashboard is only as good as the records behind it. The digital banking platform has to keep a register of every token issued: which member, which aggregator, which downstream app, which accounts, which data, when granted and when last used.

The downstream app is the hard part. An aggregator holds one connection on behalf of many apps. Unless the aggregator passes the identity of the requesting app through to the institution, the dashboard can only say that “an aggregator” has access. Such a label is useless to a member who connected three apps through the same aggregator and wants to cut off one. Whether the app’s name comes through is a term of the data-access agreement, and the institution should ask for it.

Revocation has to travel the same chain in reverse. When a member clicks the button, the platform cancels the token. The aggregator should then stop calls for that app and, ideally, stop retaining the member’s data. The first step is in the vendor’s control. The second and third depend on the aggregator’s agreement and conduct.

What a dashboard can and cannot promise

A dashboard can stop future data flowing. It cannot recall data already copied to an app’s servers. Members tend to assume that “revoke” means “delete”, and an institution that implies otherwise invites complaints. The descriptions on the page should say plainly what revocation does and does not do.

The dashboard also touches privacy law. Sharing at a consumer’s direction generally falls within exceptions to the Gramm-Leach-Bliley Act’s notice and opt-out rules, but the institution still owes the member accurate descriptions and safe handling. Organizations should ask counsel to review how their privacy notices and dashboard language fit together.

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;
• reports showing how many members use third-party connections and which apps they use.

The notice on a new connection doubles as a fraud control. A member who receives an alert that an unfamiliar app has connected to their account, and did not connect it, has just told the institution about a possible account takeover.

The reporting item has a second use. It tells the institution which fintech products its members actually value, which is useful for its own product planning. If a large share of members connect the same budgeting app, that is a signal about what they wish their own bank offered.

Different members, different defaults

Institutions serve different populations, and a dashboard designed for one may fail another. A credit union whose members skew older may find that few of them ever visit the page, so the new-connection alert matters more than the page itself. A bank with many small business clients will find that business accounts connect to accounting and payroll software, where cutting off access can break a payroll run. Business revocation may need a confirmation step and a named authorized user, which consumer accounts do not.

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 error resolution duties for electronic fund transfers under Regulation E, the federal rule that protects consumers when electronic payments go wrong, apply when access came through an authorized third party; what the institution’s agreement with an aggregator says about liability, and whether such an agreement exists at all; and who in the contact center knows how to tell a member which app accessed their account and when.

Regulation E in a world of shared credentials

Banks had argued for years that screen scraping blurred responsibility for losses. If a customer handed their password to an app and money later disappeared, who was at fault: the customer, the app, the aggregator or the bank? Tokens narrow the problem but do not settle it.

The regulation’s own logic shows why. Its official interpretation treats transfers made by someone to whom the consumer voluntarily gave an access device as authorized, until the consumer tells the institution that person is no longer authorized. The CFPB’s Regulation E FAQs, first issued in 2021, said that a consumer fraudulently induced into sharing account access information has not authorized the resulting transfers. Between those two positions lies a wide gray zone. An app that was trusted, then breached, does not fit neatly into either.

The practical consequence is that the institution often carries the investigation, and sometimes the loss, while the facts sit with the app and the aggregator. An agreement that obliges the aggregator to share access logs, report breaches promptly and reimburse losses it causes is the institution’s main way to shift that burden. Organizations should work through these questions with counsel and their vendors.

The evidence a dispute needs

A good investigation needs answers to a short list of questions: which third party accessed the account, through which channel, at what times, using which credentials or token, and whether any payment was initiated through that access. Most of that evidence is in the digital banking vendor’s logs. If the logs do not distinguish aggregator sessions from member sessions, or are kept for only a few weeks, the institution cannot answer within the timelines Regulation E sets for investigating errors.

The practical work is operational, and it is the institution’s:

• contact center scripts for data-sharing complaints;
• a fraud playbook that can identify third-party access in the logs;
• a register of aggregator agreements;
• a clear internal owner for data-sharing policy.

Who examines the response

The supervisory audience differs by charter and size. Banks and credit unions above $10 billion in assets answer to the CFPB for consumer compliance. Smaller banks answer to their prudential regulator, the FDIC, OCC or Federal Reserve, and smaller credit unions to the NCUA or their state supervisor. Complaint patterns about connected apps will reach whichever of those reviews the institution’s complaint log, so the log should record third-party involvement as its own category.

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. A member who calls a large bank about a mysterious app connection may wait in a long queue. A member who calls their credit union and reaches someone who can say “that budgeting app last connected on Tuesday, and I can turn it off for you now” has a very different experience.

Following one member through all three moments

Follow one hypothetical credit union member through a year of data sharing.

Say she is a schoolteacher who decides to try a budgeting app a colleague recommended. The app asks her to pick her credit union from a list. Suppose her credit union’s digital banking platform offers a token-based interface connected to the app’s aggregator. She is sent to a familiar credit union login screen, approves access to her checking and savings accounts, and is back in the app in under a minute. If it does not, the app asks for her online banking username and password directly. She hesitates, then types them in, because she wants the app to work. The quality of this connecting moment was decided by a vendor contract she will never see.

A few weeks later the connection breaks. Under scraping, the cause may be a new security prompt at login that the aggregator’s script cannot answer. The app tells her the credit union is “having trouble”. She calls the credit union, and the representative, who cannot see aggregator traffic, has nothing useful to say. Under a token-based interface, the most likely cause is a vendor outage, which the credit union can see on its own status reports and explain.

Six months later she stops using the app. She deletes it from her phone and assumes that is the end of it. Under a token-based model with a good consent dashboard, she can log into online banking, see the app listed with the date it last connected, and switch it off. Under screen scraping, the app may still hold her credentials, and the only reliable fix is to change her password, something she may never think to do. So much for control.

Then one morning she notices a payment she does not recognize. She calls the credit union. Whether the person who answers can quickly tell her which connected services touched her account recently, explain her rights and start an investigation depends on scripts, logs, playbooks and agreements the credit union either prepared or did not. That is the resolving moment, and it is the one most fully in the credit union’s own hands.

Across all three moments, the member thinks of only one organization: her credit union. She does not know the name of the aggregator, the digital banking vendor or the core processor. Whatever goes well or badly, she will credit or blame the institution whose name is on her debit card. That is why the vendor relationship is a leadership concern rather than a technical detail.

The same year at two different institutions

Run her year at two hypothetical institutions of different sizes. The first is a regional community bank with a few billion dollars in assets, a digital team of its own and a recently renegotiated contract. There she connects through the interface, sees the app on the dashboard and reaches a representative who can read the access log. Each of her three moments goes reasonably well.

At a small credit union on a standard contract signed before anyone asked about aggregators, she gives her password to the app, finds no dashboard, and reaches a friendly representative with no tools. The credit union’s staff are more willing to help than the bank’s. They simply have less to work with. The difference between the two experiences was set years earlier, at the contract table.

The commercial case for acting before the rule

It is easy to file open banking under compliance and wait for the rule to arrive. That misses the commercial picture.

Customers judge their bank partly by how well it plays with the other services they use. When a member’s favorite app cannot connect, or connects unreliably, the member experiences their institution as old-fashioned, whatever the real cause. That affects retention, especially among younger customers who live in apps.

There is also cost. Scraping traffic from aggregators can be heavy, and fraud teams spend time sorting legitimate aggregators from attackers. A proper interface reduces both. Fees, on the other hand, can flow in either direction depending on what the vendor contract says, which is one more reason to read it closely.

And there is risk. Every connection is a potential route for fraud, and every dispute is a potential regulatory complaint. Institutions that know which apps their members connect, have agreements with the aggregators that matter, and have trained their staff will handle those incidents better than those that discover the issue one angry phone call at a time.

The institution is a data recipient too

Community institutions often forget that they use the same pipes. When a new member funds an account from an account at another bank, the online account-opening flow frequently uses an aggregator to verify the external account instantly. Lenders increasingly read applicants’ transaction histories to judge cash flow, especially for thin-file borrowers and small businesses.

In those flows the institution is the app. It benefits when other banks’ connections are reliable, and it suffers when they break. An institution that resists data sharing on its own platform while depending on it for account opening and lending holds an awkward position, and its vendors and members will notice.

The case for waiting, and why it falls short

The case for waiting was not foolish. The rule’s content was unknown. Vendors would build interfaces eventually because their larger clients demanded them. Small institutions might be exempted. Spending scarce staff time on contract terms for a market that might change seemed premature. And every new interface is new attack surface that the institution must monitor.

Those points are real, but they share a weakness. They treat the vendor’s roadmap as a public good that arrives for everyone at once. Interfaces, aggregator connections and dashboards were delivered unevenly, and the clients that had written them into contracts tended to get them configured as they wanted. Core and digital banking contracts are multi-year commitments, so a renewal skipped in 2021 could fix the terms for most of the decade. The cost of asking was a few weeks of negotiation. The cost of not asking lasted much longer.

Contracts first, rule later

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.

In practice that meant:

• Writing data-sharing requirements into vendor contracts at renewal, rather than hoping they arrive on the vendor’s roadmap.
• Insisting on a consent dashboard that members can find and use.
• Using connection data to understand what members want.
• Owning the resolution experience: scripts, playbooks, agreements and a named policy owner.

A sequence that fits a small team

A community institution rarely has a dedicated open banking team, so sequencing matters. A workable order starts with an inventory: which aggregators reach the institution, through which channels, and under which agreements. That takes the digital banking vendor’s help and a few weeks.

Next comes the contract calendar. Most institutions have one or two major renewals in any three-year window. Each should carry a standard schedule of data-sharing terms drafted in advance, so the request is ready when the window opens.

Third, the operational pieces: scripts, playbook, complaint category and log retention. These cost little and depend on no one else. Last, a short annual report to the board on the three measures of connection quality, the dashboard’s use and the disputes handled. That report turns a technical topic into something directors can oversee.

Who owns it

Ownership tends to fall between chairs. Digital banking teams see it as a vendor feature. Fraud sees it as a threat. Compliance sees a pending rule. Marketing sees a member experience. The institutions that did well named one owner, usually in digital banking or operations, with fraud and compliance as required reviewers.

The usual errors include waiting for a final rule before engaging vendors and treating aggregator traffic purely as a fraud nuisance. Others are assuming the vendor’s default configuration reflects the institution’s values, and leaving contact center staff without guidance when a member asks about a connected app.

Where members’ data actually goes

1. How do our members’ apps connect to their accounts today: through an API with tokens, through screen scraping, or both?
2. What has our digital banking vendor committed to in writing about data-sharing interfaces, connected aggregators, fees and uptime?
3. Can a member see, in our online banking, every app connected to their account, and switch one off immediately?
4. Do we have agreements with the aggregators that reach our members, and who keeps track of them?
5. If a member says a connected app moved money without permission, what do our staff do, and has counsel reviewed that process?

With hindsight

The CFPB proposed its Section 1033 rule in October 2023 and finalized it in October 2024. The final rule required covered institutions to provide data through developer interfaces, barred fees for access, and phased out screen scraping. The destination looked broadly like the token-based model described above.

The details reached further than many expected. The rule covered checking and other accounts under Regulation E, credit cards under Regulation Z, and certain payment facilitation products. It limited third parties to using data for what the consumer had asked for, and required them to seek reauthorization at least once a year. It recognized standards issued by recognized industry bodies as a way to show compliance. Compliance dates were staggered by size, starting with the largest institutions on April 1, 2026 and running to April 1, 2030 for the smallest covered ones.

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. Their members still expected connections to work. That gap between legal obligation and customer expectation is exactly where the vendor relationship mattered most: an exempt institution’s members were connecting to the same apps as everyone else, and judging the experience the same way.

The path since has been long and unsettled. Bank trade groups and a Kentucky bank sued in federal court in Kentucky the day the rule was finalized. In 2025 the CFPB, under new leadership, told the court it now regarded the rule as unlawful and wanted to reconsider it. In August 2025 it published an advance notice seeking comment on who may act for a consumer, fees, data security and privacy. The court then barred enforcement of the existing rule.

The fee question moved in the market before it moved in regulation. Some large banks began seeking payment from aggregators, and in September 2025 JPMorgan Chase and Plaid were reported to have agreed a data-access arrangement that included fees, with amounts undisclosed. The April 1, 2026 compliance date passed without becoming enforceable. In August 2026 the CFPB sent a proposed reconsideration of the rule to the White House Office of Information and Regulatory Affairs for review. Institutions should confirm its status with counsel.

One thread held steadier. The CFPB recognized the Financial Data Exchange as a standard-setting body in January 2025, reinforcing the technical standard that large banks and aggregators had already been converging on. Whatever the final rule says about fees, the interface itself has largely settled. For a community institution, that means the technical question it would ask a vendor in 2021 has a clear answer, even while the legal one stays open.

The supervisory side also hardened. The banking agencies finalized their joint third-party risk management guidance in June 2023, built on the proposal from the same week as the competition order. It made the bank’s accountability for vendors and fintech partners explicit across the three agencies, replacing the separate documents each had relied on for a decade or more. The NCUA still lacks authority to examine credit union vendors directly.

Through all of this, the vendor dependency described here has not changed. Rules have been proposed, finalized, challenged and reopened, and the fee question has shifted. Yet for a community institution, the experience its members have when they connect an app is still largely built by the companies that supply its core and digital banking platforms. If fees between banks and aggregators become normal, the vendor contract will also decide who pays them and who collects.

The practical conclusion is to stop waiting for regulatory certainty before acting. The contract, the consent dashboard and the resolution process are within the institution’s reach regardless of which version of the rule eventually applies, and they shape what members experience today.