The Section 1033 rewrite is being covered as a fight about consumer rights. For anyone whose product pulls an account balance, it is something more immediate: a cost-of-goods-sold event, arriving in a line item that has never had a price.
Somewhere in your product there is an API call nobody has ever costed. A cash-flow underwriter pulls ninety days of transactions at application, then refreshes weekly to monitor the loan. A budgeting app syncs every account, every morning, for every user, whether or not they open it. A pay-by-bank flow checks a balance immediately before initiating. None of this appears in a cost model, because none of it has a unit price. It is engineering effort and an aggregator subscription, and both behave like fixed costs.
That is the assumption the Consumer Financial Protection Bureau is now reconsidering, and it is the one worth thinking about before the text lands.
What is actually known, and what is not
The sequence matters, so here it is with dates attached. The Bureau published the Personal Financial Data Rights rule implementing Section 1033 on 22 October 2024, with tiered compliance running from 2026 through 2030. In May 2025 the CFPB moved to set its own rule aside in litigation brought by banking groups. The case was stayed that July as reconsideration began, and by roughly October 2025 a federal court in Kentucky had enjoined the Bureau from enforcing the rule, having found it likely exceeded the Bureau's authority. An August 2025 reconsideration notice reopened four areas — among them, explicitly, whether data providers may charge fees. The first compliance tier, 1 April 2026 for the largest depositories, passed without becoming a binding enforcement trigger. On or around 6 August 2026, a rule titled "Personal Financial Data Rights Reconsideration" went to the Office of Information and Regulatory Affairs for review.
What is not known is the text. It has not been published. Reporting on the rewrite points toward permitting data providers to charge third parties once some number of free requests has been used, and the Bureau has signalled that aggregators should bear costs. That is a direction of travel, not a rule. Anyone modelling a specific price per call today is modelling a rumour.
Which is precisely why the useful work right now is not prediction. It is measurement.
Almost no one knows their calls per active user per month. There was never a reason to. That number is about to become the most important input in the business, and it takes a fortnight to instrument.
A threshold is worse for planning than a price
A flat per-call fee would be unwelcome and straightforward. You multiply, you reprice, you move on. A free allowance followed by a charge is a different animal, and the difference is not obvious until you try to forecast it.
A threshold makes your marginal cost a step function of your own growth. Below it, data is free and every incremental user is pure margin. Above it, every incremental user carries a data cost, and the cost of the users you already had does not go away. Worse, the threshold is likely to be set per data provider, not per fintech — meaning your exposure depends on how your users are distributed across banks, which is a variable you do not control and probably do not track. Two competitors with identical user counts can sit on opposite sides of the line because one skews toward a handful of large institutions and the other is spread across hundreds of small ones.
The planning problem is that the cliff arrives during growth, which is exactly when a company is least able to absorb it and most likely to have already promised the margin to someone.
Visual 1 — How the shape of the cost curve changes, illustratively
How to read it: Illustrative only — no price per call has been proposed and none should be inferred from this chart. The point is the change in shape, not the level. A cost that was flat against growth becomes one that tracks it, with a discontinuity where the allowance runs out. Where your own crossover sits depends entirely on calls per active user, which is the number to go and measure.
Exposure is a function of refresh, not of size
The instinct is to assume the biggest fintechs are most exposed. The better predictor is how often a product needs fresh data, and whether the refresh is driven by the user or by a schedule. Scheduled polling is where the volume hides.
Visual 2 — Data intensity by product pattern
Product pattern | Refresh behaviour | Relative exposure |
|---|---|---|
Account ownership / verification | Once at onboarding, occasionally on change | Low — a lifetime handful of calls per user |
Pay-by-bank at checkout | Per transaction, user-initiated | Moderate, and it scales with revenue rather than with users, which is survivable |
Income and employment verification | Burst at application | Moderate — concentrated, forecastable, chargeable onward |
Cash-flow underwriting with monitoring | Heavy at origination, then scheduled through the life of the loan | High — and the monitoring tail is invisible in most cost models |
Affordability checks in instalment credit | Per application, plus re-checks | High during growth; the re-check policy is usually set by risk, not by finance |
Budgeting, PFM and net-worth tracking | Daily scheduled sync across all linked accounts, whether the user opens the app or not | Highest — cost tracks linked accounts, while revenue tracks engaged users, and those two numbers diverge |
How to read it: The bottom row is the structural problem. Any product where cost scales with accounts linked and revenue scales with users active has a margin that erodes with dormancy — and dormancy is the one cohort behaviour every consumer app has plenty of.
Run this on your own numbers
Calls per active user per month. Total successful data-provider requests divided by monthly active users. Most teams guess low by a factor of three.
Split scheduled from user-initiated. If scheduled refresh is above sixty per cent of volume, your cost base is a cron job, not a product decision.
Dormant-account ratio. Share of linked accounts belonging to users who have not opened the app in thirty days, and the share of calls those accounts generate.
Provider concentration. Distribution of your linked accounts across data providers. Per-provider thresholds reward concentration and punish a long tail.
Model three prices, not one. Cheap, plausible and punitive. The output that matters is not the cost — it is the monthly active user count at which each price forces a product change.
The levers are older than the rule
Everything that reduces exposure is already good engineering that nobody had a reason to prioritise. Cache with a deliberate time-to-live instead of refetching. Move from polling to event-driven updates where the provider supports webhooks. Tier freshness by what the feature actually needs — a net-worth chart does not require the same recency as an affordability decision, and treating them identically is a default, not a design. Stop syncing dormant accounts, and tell users plainly that you have.
One less obvious lever: your contract with your aggregator. If data-provider fees arrive, the commercial question is whether they pass through at cost, at a markup, or are absorbed into a repriced platform fee. That negotiation is easier before the rule exists than after, and almost nobody is having it yet.
The view from the other side of the table
For a bank, this reads as a new revenue line, and it will be modelled that way. It is worth being clear about what comes attached to it.
Charging for data access converts an obligation into a product, and products carry expectations that obligations do not. A fintech paying per call will ask about uptime, latency, error rates and what happens commercially when the endpoint is down for a day — questions that are awkward to answer when the same endpoint has been running as a compliance cost centre. Pricing invites service levels. Service levels invite disputes. Whatever the fee schedule turns out to be, the operating cost of running a paid data channel is materially higher than the cost of running an unpaid one, and that belongs in the business case.
There is also a second-order effect that should trouble everybody at the table. The decade-long push toward tokenised, permissioned API access was largely about ending screen scraping and the credential-sharing it depends on. Pricing the sanctioned channel while the unsanctioned one remains free creates an economic gradient pointing back toward the practice the framework was built to eliminate. Whether the rewrite addresses that directly is one of the more consequential things to look for when the text appears.
And the federal picture is not the whole picture. State-level data-sharing rules have been resurfacing through 2026, which means the plausible end state is not one regime with one price but several, with different scopes. Firms operating nationally should be modelling fragmentation, not a single number.
What to do before the text lands
Instrument the call volume now, while it is free and while nobody is watching it — the baseline is worth more than the forecast. Break the number down by product surface, by scheduled versus user-initiated, and by data provider. Decide, as a product question rather than an infrastructure one, what freshness each feature genuinely requires. Open the aggregator conversation early. And read the proposal when it publishes for the two things that will actually determine your exposure: whether the allowance is counted per provider or per requester, and whether anything is said about the unsanctioned channel.
The rule may land softly. Fees may be capped, or narrow, or years away. But the era in which a fintech could treat bank data as an engineering problem with no unit cost is ending regardless of how this particular draft reads, and the companies that come out of it well will be the ones that knew their own numbers before anybody quoted them a price.
Sources and method. A FinancyHub original. Regulatory chronology drawn from the CFPB's Personal Financial Data Rights rule (published 22 October 2024) and subsequent proceedings as reported by Consumer Finance Monitor (OIRA submission, 6 August 2026; state-level developments, June 2026), PYMNTS (fee reconsideration and aggregator cost-bearing) and the Open Banking Tracker status guide (litigation posture, injunction, tiered compliance dates). Background on the statutory provision: Congressional Research Service, IF13117. The proposal text was not public at the time of writing; no price per call has been proposed and the chart in this article is explicitly illustrative. Journalism, not procurement advice — nothing here is a recommendation to buy, renew or terminate any product, or a prediction of the rule's contents. Corrections will be made openly on this article.
