Final and already in court: sorting open banking work by how much you would regret it

The week

On October 22, 2024, the Consumer Financial Protection Bureau finalized its personal financial data rights rule under Section 1033 of the Dodd-Frank Act, the provision that gives consumers a right to their own financial data. Every time someone connects a budgeting app to a checking account, or links a bank account to a payments app, data moves from the bank to a company the bank did not choose. For years the rules for that movement were mostly informal. The Bureau was trying to settle them.

Section 1033 had been on the books since Dodd-Frank passed in 2010, but for a decade the Bureau wrote no rule under it. The process began in earnest with an advance notice in late 2020. An outline of proposals for small business review followed in October 2022, and a proposed rule in October 2023. In June 2024 the Bureau finalized a separate, narrower rule setting out how an industry standard-setting body could win official recognition. The October final rule was the last and largest piece.

The rule covered banks, credit unions, card issuers and certain payment providers. It required them to make specified account and transaction data available to consumers, and to third parties the consumer had authorized, through a developer interface, without charging fees for it.

Payment providers here meant firms offering what the rule called payment facilitation, such as digital wallets, so the rule reached some nonbanks as well as depositories. The data covered was specific: transaction information, account balances, the information needed to initiate a payment, upcoming bill information, and basic account verification details. It had to be delivered in a standardized, machine-readable format.

A developer interface, usually called an API (application programming interface), is a controlled doorway that lets one company’s software ask another company’s systems for specific information in an agreed format. It hands over exactly what was asked for and nothing else.

The rule set performance standards for that interface, so it could not be slow or unreliable by design. It limited third parties to using the data for what the consumer had actually requested, and it required consumers to reauthorize access every year. It also aimed to end screen scraping, the long-standing practice in which an app takes a customer’s online banking username and password, logs in as if it were the customer and copies whatever appears on the screen.

The duties on the receiving side were as important as those on the banks. A third party could collect, use and retain data only as reasonably necessary to provide the product the consumer asked for. The rule said that targeted advertising, cross-selling and selling the data were not reasonably necessary for any other product. Third parties had to apply an information security program meeting the Gramm-Leach-Bliley Act safeguards framework. When a consumer revoked access, collection had to stop, and deletion was the default. Aggregators acting for an app had to certify that they would meet the same obligations.

The rule also made clear that letting a third party scrape a website did not satisfy a data provider’s obligation. Banks could still deny or limit access for reasonable risk management reasons, a carve-out whose boundaries would matter a great deal. The rule took effect on January 17, 2025, with compliance obligations starting later.

Compliance dates were staggered by size, from April 2026 for the largest institutions to April 2030 for smaller ones. Depository institutions with assets of $850 million or less were exempt from the interface requirements altogether.

Then came the twist. The same day the rule was finalized, the Bank Policy Institute, the Kentucky Bankers Association and a Kentucky bank sued to block it in federal court in Kentucky. A rule that banks had anticipated for years was now final and under legal attack at once. Executives had to decide what to spend money on without knowing whether the rule would survive.

The plaintiffs argued that the Bureau had exceeded its statutory authority. The bank in the suit was Forcht Bank, and the case was filed in the Eastern District of Kentucky. The Bureau, then led by Director Rohit Chopra, defended the rule as a boost to competition and consumer choice. The presidential election was two weeks away, which meant that the agency defending the rule might soon be led by people who disliked it.

The 2022 outline and the 2023 proposal had asked banks for an interface with performance targets, consent and revocation, and left questions of liability unresolved. By October 2024 those questions were settled on paper. A new one replaced them. A final rule was in force and also in court on its first day, with a presidential election two weeks away. The first compliance dates were eighteen months out for the largest banks and further away for everyone else.

In a typical bank’s executive suite that week, the conversation more or less wrote itself. The chief operating officer wants to know whether to start building. The general counsel points out that the rule may not survive. The chief financial officer asks how much is at stake either way. Everyone is right, and nobody can make the uncertainty go away.

Waiting for the courts carried risk if the rule survived. Building exactly to the text carried risk if it changed. The sound approach was to divide the program by how much each piece would be regretted if the rule fell. Every task in a Section 1033 program falls into one of three groups: work worth doing with or without the rule, work that only this rule requires, and work whose shape depends on the terms under legal attack. Each group warranted a different funding decision. First, though, what open banking actually involves.

Aggregators, scraping and tokens

“Open banking” describes a simple idea: your financial data belongs to you, and you should be able to send it to an app or service you choose. When a customer uses a personal finance app to see all their accounts in one place, applies for a loan with a lender that wants to verify income from bank statements, or links a checking account to an investment app, open banking is at work.

The companies in the middle are often called data aggregators. They connect to thousands of banks on behalf of thousands of apps, so that a small fintech company does not have to build its own link to every bank in the country. For a bank, the aggregator is frequently the party actually knocking on the door, even though the customer’s relationship is with the app.

There are two ways that knock can happen. The older way is screen scraping. The customer hands their online banking username and password to the app or aggregator, which then logs in as if it were the customer, often many times a day, and reads the account pages. The bank cannot easily tell the aggregator’s login from the customer’s, or from a fraudster’s.

The newer way is an API with tokens. Instead of sharing a password, the customer is sent to the bank, logs in there and approves a specific request: this app may see these accounts and these kinds of data. The bank then issues the app a token, a digital pass that works only for what was approved and can be cancelled at any time. A token works like a valet key that starts the car but will not open the trunk, and that the owner can deactivate from their phone. The password never leaves the bank.

Why scraping lasted so long

Scraping persisted for reasons that made sense to each party. Apps wanted to reach every bank their customers used, and most banks offered no interface. Aggregators could cover thousands of institutions with one technique that needed no agreement from any of them. Consumers rarely understood that they had handed a password to a company other than their bank. Banks, for their part, found it hard to block traffic their own customers had authorized, however clumsily.

The result was a stable but poor arrangement. Every party carried a risk it did not control. The bank could not distinguish legitimate access from fraud, the app depended on screen layouts that could change overnight, and the consumer had no single place to see or end the access. Token-based interfaces fixed each of those problems at once, which is why the industry had been moving toward them before the Bureau acted.

For any of this to work at scale, banks and apps need to speak the same language: the same names for data fields, the same way of asking for them, the same security handshake. That shared language is called a standard. Industry groups write them so that an app built to one standard can connect to many banks without custom work for each.

Section 1033 essentially told banks to offer the API route, on terms the rule set, and nudged the industry away from scraping. The legal fight was over some of those terms, not over whether APIs were a better idea than scraping.

Who counted as a data provider

The rule’s reach was broader than “banks.” Data providers included depository institutions of every charter, credit unions among them, and nondepository firms that hold transaction accounts, issue credit cards or offer payment facilitation such as digital wallets. A large fintech could therefore be a data provider for its wallet and a third party when it pulled data from someone else’s bank. It sat on both sides of the same rule.

Enforcement differed by size. The Bureau supervises banks and credit unions with more than $10 billion in assets. Below that line, compliance with a Bureau rule is examined by the institution’s prudential regulator, such as the FDIC, the OCC, the Federal Reserve or the NCUA. A $4 billion credit union and a $400 billion bank faced the same text, examined by different agencies on different schedules.

What each party had to do differently

For a data provider, the rule meant a consumer interface and a developer interface, both meeting performance standards, plus policies, records and public disclosures about the developer interface. For a third party, it meant authorization disclosures, a limit on data use, annual reauthorization, deletion on revocation and a security program. For an aggregator, it meant certifying to the same third-party obligations. For a recognized standard-setting body, it meant that following its standards would count as evidence of compliance with parts of the rule.

That last feature changed the economics of compliance. A bank that implemented a recognized standard bought a presumption of sorts, which reduced the risk of building something an examiner would later question. That is part of why standard adoption belonged in the no-regret group below.

How it works inside a bank

Most executives are surprised by how many parts of the bank an open banking program touches. It is far more than a single project in the IT department.

At the center is the core banking system, the bank’s master ledger that records every account and transaction. Most mid-sized banks and credit unions do not own their core; they rent it from a core processor, a specialist vendor that runs the same system for hundreds of institutions. Sitting on top is the digital banking platform, the software behind the website and mobile app, which is also usually supplied by a vendor. An open banking interface typically lives at that layer, pulling data from the core and serving it to approved third parties.

Around that technology sit several business functions. The fraud team needs to see who is accessing accounts and how. The customer service team fields calls from people asking why their budgeting app stopped working. The vendor risk team, which already evaluates the bank’s suppliers, now has to decide which aggregators and apps may connect at all. Compliance owns the rule. Legal owns the contracts with aggregators. Finance owns the budget and, if fees ever become allowed, the pricing.

That spread matters for funding decisions, because a dollar spent in one place can serve several of these functions at once. A dashboard that shows customers which apps have access to their accounts helps compliance, reduces service calls and gives the fraud team a clearer picture, all at the same time.

The rule also required a consumer interface, meaning a way for customers themselves to get their covered data in electronic form. Most banks already offered online banking with statement and transaction downloads, so this part was usually a gap check rather than a build. The gap tended to sit in details: which data elements were included, how far back history went and whether the format was machine-readable.

Owners and measures

A workable program names one executive owner, usually from digital banking or payments, with defined roles for the others. Technology owns the interface and its monitoring. Information security owns the authorization flow and the token lifecycle. Fraud owns the signals from third-party traffic. Vendor risk owns the criteria for admitting and suspending third parties. Legal owns contracts and the liability position. Compliance owns the mapping of each requirement to evidence.

The measures follow from those roles. The share of third-party traffic arriving through the interface rather than through credential-based logins is the headline number. Others include active tokens by third party, revocations by customers, interface availability and response times, access denials with their documented reasons, and complaints tagged to third-party connections. Most of these numbers have value under any version of the rule. They tell the bank who is touching its customers’ data and how.

Examiners would ask for the same evidence in a different order. They would want the policy, the mapping of each requirement to a control, proof that the interface met its performance standards, records of denials and the reasons for them, and the disclosures as published. A bank that collected these as by-products of operations would find the exam cheap. A bank that assembled them by hand the week before would find it expensive.

No-regret work: worth doing whatever the courts decide

Retiring screen scraping was in banks’ own interest. Aggregators logging in with customers’ online banking credentials create load on digital channels, blur fraud signals and leave the bank unable to tell a customer which apps hold their data. A tokenized interface fixes all three.

The no-regret list follows from that. Build or buy an interface on a widely used industry standard. Issue access tokens instead of accepting shared credentials. Give customers a dashboard showing which third parties have access, with a working revoke button. Detect and throttle scraping traffic once an interface alternative exists. Put third-party access under the existing vendor risk program, with criteria for granting and suspending access. Every item stands on its own without the rule, and each reduces fraud and support cost.

How scraping is found and retired

Retiring scraping starts with seeing it. Aggregator logins tend to share telltale features. They arrive from data-center address ranges rather than consumer networks, at regular intervals and with automated browser signatures. They also log in to many accounts from the same source. Most digital banking platforms and fraud tools can flag that pattern. The first deliverable is a count of how much traffic it represents and which aggregators are behind it.

The second step is negotiation, not blocking. Several of the largest US banks had signed bilateral data-access agreements with major aggregators years before the rule, moving them onto interfaces by contract. Smaller institutions usually reach the same outcome through their digital banking provider, which offers an interface the aggregators already support. The bank then sets a date after which credential-based logins from known aggregators will be challenged.

The third step needs care. Stronger login security, such as a one-time code at every sign-in, breaks scraping because the aggregator cannot answer the prompt unattended. That is good for security and bad for the customer whose budgeting app stops updating. A bank that tightens login controls before an interface alternative exists will generate complaints, and its customers may blame the bank rather than the app. Sequencing the interface before the challenge avoids that.

Why the exemption did not exempt the work

For community banks and credit unions under the size threshold, the rule imposed nothing. Their exposure did not change. Aggregators kept scraping their customers’ accounts because the customers kept connecting apps. An exempt institution that offered no interface had no way to see those connections, no way to revoke them on a customer’s behalf, and no clean way to separate aggregator logins from attacks. The no-regret list applied to it in full; only the deadline was missing.

Take a regional bank with a few hundred thousand digital banking customers. Its online banking servers see heavy traffic in the early morning hours, when aggregators run automated logins to refresh data for apps. That traffic looks a lot like an attacker testing stolen passwords, so the fraud team either tolerates it, which weakens its defenses, or blocks it, which breaks customers’ apps and floods the call center. Moving those aggregators to tokens lets the bank see exactly who is connecting, serve them efficiently and treat any remaining automated logins as the suspicious activity they probably are.

For most mid-sized banks and credit unions, the interface would come from the core processor or digital banking provider. That made the no-regret task partly a vendor-management task: confirm what the provider would deliver, on what standard and on what timeline, and whether it would meet the institution’s own availability and monitoring expectations.

The contract with that provider was the main lever. A useful amendment specified the standard and version the interface would support, a delivery date, and the performance and availability the provider would meet. It also covered the monitoring data the bank would receive, and the bank’s right to configure which third parties could connect. Without that amendment, a bank’s no-regret plan rested on a provider’s roadmap slide.

Rule-specific work: required only if the text survives

Some obligations existed only because of the rule. These included the specific performance metric for interface response, the published disclosures about the interface, the exact data elements, the record retention and policy requirements, and the duty to make data available without charge. Building them early had little cost for the largest banks, whose dates came first. Smaller institutions with dates in 2028 or later could reasonably sequence them last.

The way to keep this group cheap was to make it configurable, meaning the behavior is controlled by settings rather than written into the software itself. A data-element list driven by configuration can be extended or trimmed without code. Performance reporting can come from monitoring the bank already runs. Disclosures can be drafted but held unpublished. Each can be switched on quickly if the rule holds and set aside if it does not.

Institutions under the $850 million threshold could skip this group entirely, though not the no-regret work, because their customers’ data was being scraped regardless. A small community bank does not escape the aggregators merely because the rule exempts it.

One caution applies: configurable is not the same as unbuilt. Suppose the rule survived with its dates intact. An institution that had deferred everything in this group would then face a compressed build in its final year, competing with every other bank for the same core-processor release slots. Core processors serve many clients from one product roadmap, so when a deadline approaches, everyone lines up for the same scarce development time. A sensible middle path was to design the rule-specific features now, build the ones that are cheap, and secure a written delivery commitment from the vendor for the rest.

How the answer changed by compliance tier

The staggered dates meant the same group of work called for different decisions. The largest institutions, due first in April 2026, had little room to defer anything. Many already ran interfaces and bilateral agreements, so their rule-specific work was mostly a gap analysis against the text: performance metrics, disclosures, data elements and records. For them, the question was how to build it in a way that could be unwound if the rule changed.

Mid-sized banks with dates from 2027 to 2029 had real choices. They could design now and build later, and their main risk was vendor capacity at the end. The smallest covered institutions, due in 2030, could reasonably spend 2024 and 2025 on no-regret work and watch the courts. Their main risk was assuming the rule’s survival or demise too early, in either direction.

Records an examiner would want

The rule-specific group also included policies and procedures and the records to prove them. Those cost little to draft and a lot to reconstruct. A bank could write the policies in a form that described its no-regret controls, such as token issuance, access criteria and revocation, and then add rule-specific sections as they became certain. That kept the documentation honest about what the bank actually did, whatever the legal outcome.

Contested-term work: decisions to hold open

The third group covered terms the litigation and the coming change of administration put in doubt. The most consequential was the ban on fees for data access. Close behind were the scope of liability when shared data led to fraud, the grounds on which a bank could deny access, and which entities could act as a consumer’s representative.

These terms decide who pays for the infrastructure and who pays when something goes wrong. If a customer’s data leaks from an app and a fraudster uses it to drain the account, the question of whether the bank or the app absorbs the loss can be worth far more over time than the cost of the interface itself.

For these, the right move was to prepare options rather than commit. A bank could model the cost of serving third-party traffic so it would be ready to price access if fees became permissible, and ready to absorb the cost if not. It could draft access-denial criteria grounded in safety and soundness, which would be defensible under any version of the rule. It could review with counsel how Regulation E error-resolution duties would apply to payments initiated through third parties. Regulation E is the long-standing federal rule that governs consumer electronic payments and sets out how a bank must investigate and resolve a customer’s claim that a transfer was unauthorized or wrong.

The fee ban drew the sharpest disagreement. Banks argued that interfaces cost money to build, run and secure, that third-party traffic could dwarf customer traffic, and that free access subsidized firms that profited from the data. Fintechs and aggregators argued that fees would act as a toll on competitors, letting incumbents price rivals out of their own customers’ data. Both arguments had substance, which is exactly why a bank could not safely assume either outcome.

Why liability outweighed the build cost

Regulation E generally places the duty to investigate and resolve an unauthorized-transfer claim on the institution that holds the account. That holds even when the credentials or data that enabled the fraud were exposed somewhere else, subject to the regulation’s conditions. Whether the bank can recover its loss from an app or aggregator depends on contracts and, sometimes, on network rules. Institutions should confirm with counsel how these duties apply to their own products.

That is why liability terms deserved more attention than interface features. An interface is a fixed cost paid once and maintained. A liability position applies to every future fraud loss that touches a third-party connection. A bank that accepted broad liability in an aggregator contract, to speed up a launch, could carry that cost for years after the rule itself had been rewritten.

Denial criteria as a durable asset

The rule allowed a data provider to deny or limit access for reasonable risk management reasons, applied consistently and without discriminating among third parties. Banks and fintechs disagreed about how broad that carve-out was. Under any outcome, though, a bank needed written criteria: evidence of fraud, a known breach at the third party, failure to meet basic security expectations, or credentials being used outside an authorization. Criteria grounded in safety and soundness, applied the same way to every comparable third party, would survive any version of the rule. Ad hoc refusals would not.

Who may speak for the consumer

The rule let a consumer’s “representative” make requests on the consumer’s behalf. The term mattered more than it looked. A broad reading let aggregators and data brokers access accounts with fewer conditions. A narrow reading, for example one requiring some duty of care to the consumer, would tighten the field. A bank designing its authorization flow could build it to record who was requesting and in what capacity, so that it could apply whatever definition prevailed without redesign.

Long-term contracts with aggregators that locked in pricing or liability terms were the commitments most worth deferring. A three-year agreement signed in a hurry could fix in place exactly the terms the courts and regulators were about to reopen.

Where a contract could not wait, its terms could bend. Useful clauses included a reopener on pricing and liability if the rule was vacated or amended, a term that ended at the bank’s first compliance date, and liability allocation that tracked whatever the final rule required. A right to suspend access for documented security reasons, without breaching the agreement, protected the bank under every outcome.

Consider a mid-sized credit union. Its finance team estimates what it costs each month to answer requests from aggregators: servers, monitoring, support staff time. It does not publish a price list, because the rule says no fees. But it keeps the model current, so that if the fee ban falls it can set a price grounded in real cost, and if the ban stands it knows the budget line it must carry. Its legal team drafts a short list of reasons it would refuse or suspend a connection, such as evidence of fraud or a data breach at the app, framed around protecting members and the institution. And when an aggregator offers a multi-year agreement, the credit union asks for a shorter term or a clause to revisit pricing and liability if the rule changes. These steps commit it to no particular outcome, and each shortens the distance to a decision once the outcome is known.

The case for simply waiting, and against

A reasonable skeptic could argue that sorting was overthinking. A $2 billion bank with a 2029 date could wait two years, let the courts and the election settle the rule, and then build whatever survived. The money saved in the meantime was real, and the rule might never take effect.

For the rule-specific and contested groups, the skeptic was largely right, and the sorting approach agrees. Waiting was the correct decision for those groups at that bank. The skeptic was wrong about the no-regret group, because its value did not depend on the rule. Scraping traffic, blurred fraud signals and customers unable to see their connections were problems in October 2024 and would remain problems in 2029. Deferring them saved budget by keeping a known exposure open.

The opposite argument also had force. A bank that built everything to the text might win goodwill with fintech partners and avoid a crunch later. For the very largest banks with April 2026 dates, that was close to the only option. For others, it meant paying in 2025 for features whose terms could change in 2026, which is the outcome the sort was designed to avoid.

How much of the budget was really at risk

Sorting the work this way also gave boards a clear answer to the question they asked: how much are we spending on a rule that may not survive? For most institutions, the honest answer was that the largest share sat in the no-regret group, and only a modest share was at risk.

That answer touches every line a board cares about. On cost, it separates spending that pays for itself through lower fraud losses and fewer service calls from spending that is a regulatory bet. On risk, it moves the bank away from a model in which customers hand their passwords to outsiders, which is a security exposure regardless of any rule. On customers, it delivers something visible: a place in the app where a person can see and cancel every connection, which builds trust. On regulators, it shows examiners a reasoned plan rather than either paralysis or a rush. On reputation, it positions the bank as one that welcomes customers’ choice of apps while protecting their accounts.

It also changes the conversation with vendors. A bank that knows which features are no-regret can push its core processor hard on those, while keeping options open on the rest.

Costs the first estimate tends to miss

Open banking budgets in 2024 often counted the interface and little else. The fuller list includes call-center scripts and training for customers whose apps break during migration, and customer communications before scraping is challenged. It includes legal review of aggregator agreements and the fraud team’s time to tune rules for interface traffic. It also covers capacity and monitoring for peaks in third-party calls, and change fees from the core processor or digital banking provider.

Most of those costs fall in the no-regret group, because they come from moving customers off scraping, which a bank would do anyway. Counting them there makes the at-risk share smaller and more accurate. Leaving them out makes the program look cheaper at approval and more expensive in delivery, which erodes the board’s trust in the sort itself.

Keeping the no-regret label honest

One risk of the method is that “no-regret” becomes a label for anything a team wanted to build anyway. The discipline is to give each no-regret item its own case that does not mention the rule. Token-based access should show a reduction in suspicious login volume or call-center contacts. A connections dashboard should show use and revocations. If an item cannot make its case without citing Section 1033, it belongs in one of the other groups.

The method also requires re-sorting. A term that is contested today may be settled next quarter, and a settled one may be reopened. A short quarterly review, triggered as well by any court ruling, Bureau statement or major vendor announcement, keeps the list current. The owner records what moved and why, which gives the board a running account of how legal events changed the plan.

Freezing, over-building and other ways to misread the rule

A well-run program in this situation kept a single list of every open banking task, each tagged as no-regret, rule-specific or contested. Each tag carried its own funding rule: fund now, design now and build cheaply, or prepare options and wait. One executive owned the whole list, with legal, fraud, technology and finance all contributing. The board saw the list on one page, with the share of spending in each group.

The weaker programs went wrong in the opposite directions. Some institutions froze everything until the courts ruled, which left their customers’ passwords in aggregators’ hands and their fraud teams blind. Others built precisely to the text and signed long contracts on its terms, which tied them to provisions that might not last. Still others treated open banking as purely an IT project and discovered late that the hard questions were about liability, pricing and vendor commitments. And smaller institutions sometimes read the $850 million exemption as permission to ignore the topic, even though scraping of their customers’ accounts carried on.

A further error was common among fintechs and aggregators on the other side. Some assumed the no-fee rule was permanent and built business models that depended on free access at any volume. Others treated the data-use limits as optional until enforced. Both bets were on contested terms, and the regret logic applied to them as much as to banks.

Where the bank stands whatever the court decides

The questions below are built to have useful answers under any legal outcome. The first two test the no-regret group: whether the bank knows who is accessing its customers’ accounts, and whether its provider has committed to an interface in writing. The third tests whether the sort itself has been done and costed. The last two test the contested group, where the expensive mistakes lie: liability for losses and contracts that lock in terms still under dispute. A bank that can answer all five, with documents rather than impressions, has a plan that survives the court’s timetable.

• Which apps and aggregators are accessing our customers’ accounts today, and how many of them are logging in with customers’ passwords?
• What exactly will our core processor or digital banking provider deliver, on which industry standard, by what date, and is that in writing?
• Which of our open banking tasks would we do even if the rule disappeared tomorrow, and what share of the budget do they represent?
• If a customer loses money through an app we let connect, who bears the loss under our current contracts and under Regulation E?
• Are we about to sign any long-term agreement that fixes pricing or liability terms the courts or regulators may change?

With hindsight

In January 2025, shortly before the change of administration, the CFPB recognized the Financial Data Exchange as a standard-setting body under the rule. That gave banks and apps an officially recognized common language for their interfaces, which helped the no-regret work: an institution that had built on a widely used standard was already heading in the right direction.

Sorting the work by regret proved useful, because the contested terms were the ones that moved. The pieces that were worth doing anyway kept their value; the pieces tied to terms under attack were the ones left exposed.

Under new leadership, the Bureau told the court in 2025 that it would reconsider the rule. In August 2025 it issued an advance notice, an early formal step in rulemaking that asks the public for views before a new proposal is drafted. Among other things, it asked whether banks could charge for access, after large banks had begun seeking fees from aggregators. The no-fee provision, one of the contested terms, was squarely back in play.

The advance notice asked for comment on four subjects, and three of them mapped onto the contested terms named above. It asked who should count as a consumer’s “representative,” including whether the term implies fiduciary duties. It asked whether the fee ban was the best reading of the statute. It also asked about data security and data privacy, including how often consumer financial data is licensed or sold. The comment period closed on October 21, 2025, and drew more than 13,900 responses.

The fee question had moved from theory to market practice. In mid-2025 JPMorgan Chase told aggregators that it intended to charge for access to customer data. Banks that had modeled their cost of serving third-party traffic were better placed to join that conversation, or to explain why they would not charge.

In late October 2025 the Kentucky court barred enforcement of the rule until the Bureau finished its reconsideration. The first compliance date, which a court-ordered stay had already moved from April to June 2026, passed without becoming an enforcement trigger.

The litigation had taken an unusual path to get there. In May 2025 the Bureau asked the court to set aside its own rule. In July 2025 it said it would reconsider the rule through new rulemaking, and the court stayed the case. An earlier order had pushed every compliance date back by 90 days. The October 2025 injunction then froze enforcement until a new rule was complete, and the Bureau indicated that review of the comments could run into 2026.

Some planning assumptions failed. Institutions in the top tier that had built rule-specific features to the April 2026 date found the deadline gone. Spending that served no-regret ends kept its value. Disclosures and metrics written to the original text had no use until a new rule said what it required. Smaller institutions that had waited on everything, including scraping, lost the most ground, because the problem they had deferred did not wait with them.

Meanwhile, interface-based access kept displacing screen scraping through bilateral agreements and industry standards. The market kept moving toward tokens and APIs even while the legal requirement was frozen, because banks and apps had their own reasons to prefer it.

That rewarded banks that had treated standard adoption and scraping retirement as no-regret. Their interfaces served partners and cut fraud noise whatever the rule’s legal status, which is the test the sort was built on.

Banks that had built the no-regret pieces kept their value. Work tied to the no-fee regime was the work most exposed. The lesson carries over to any uncertain rule. When a rule is uncertain, the question is not “should we comply or wait?” but “which parts of this would we be glad to have done regardless?” Funding those first, keeping the rule-specific parts adjustable and refusing to lock in contested terms is a way of making progress without betting the budget on a court’s timetable.