Open Banking in Limbo: What to Build While Section 1033 Is Rewritten
The rule is finalized, enjoined, and under reconsideration. Building to the current text is a mistake and so is waiting. The subset of work that pays off under any plausible version, what to defer, and how to write vendor contracts that survive either outcome.
Section 1033 is finalized, enjoined, and being rewritten at the same time. That combination produces the worst kind of planning problem: a mandate real enough that ignoring it is negligent, and unstable enough that building to its current text may be wasted work.
The two obvious responses are both wrong. Building to the finalized rule risks implementing provisions that will not survive reconsideration. Waiting for certainty means starting from behind whenever certainty arrives, and market direction is not actually in doubt even where the rule is.
The useful question is narrower: which parts of this pay off under every plausible outcome?
Where things actually stand
The CFPB finalized the Personal Financial Data Rights rule in October 2024, implementing Section 1033 of Dodd-Frank. It set a phased schedule running from April 2026 through April 2030, sized by institution.
Read the first tier carefully, because it is widely misreported. April 1, 2026 covered depository institutions holding at least $250 billion in assets, and nondepository providers generating at least $10 billion in receipts. Credit unions are depositories, so a $10 billion credit union sits in the April 2027 tier, not the first one, and no credit union is close to $250 billion. Effectively none were ever in the first wave. Smaller institutions come later still: April 2028 for $3bn to $10bn, 2029 for $1.5bn to $3bn, 2030 below that, with an exemption floor around $850 million. For most readers of this the original date was always years out.
A federal court then preliminarily enjoined the CFPB from enforcing it in October 2025, the Sixth Circuit has held the appeals in abeyance pending new rulemaking, and the Bureau has signalled a fresh proposal is close. Congressional Research Service material covers the statutory basis. The April 2026 date passed without becoming a binding enforcement trigger.
Among the questions genuinely reopened is whether institutions may charge for API access, which the finalized rule largely prohibited. The industry is divided on this in a way that suggests the answer is not settled.
What is uncertain, and what is not
Genuinely uncertain: whether data access can be priced, the precise scope of required data fields, the compliance timeline, liability allocation when a data recipient is breached, and the specific technical standards that will be recognized.
Not uncertain, regardless of rulemaking: consumers will expect to connect their accounts to third-party services. Aggregators will keep operating. Screen scraping is being displaced by APIs on commercial grounds independent of any rule, because it is fragile and expensive for everyone, though institutions without the resources to build will keep relying on it until something forces the change. Connection friction is a market pressure rather than a regulatory one, and it is worth being honest about its size: primary deposit relationships are sticky and almost nobody moves banks over an API. It shows up instead at the margin, in which account gets linked and therefore gets used.
That second list is where the work is.
Build this now
Authorization and consent infrastructure. A consumer needs to grant access to a specific third party, for specific data, for a defined period, and see what they have granted. Every plausible version of the rule requires this. So does basic good practice, and so do state privacy regimes moving independently.
Revocation that actually works. A consumer must be able to withdraw access and have it stop, promptly and verifiably. This is the part most commonly built badly, because it is not the demo path. Test it as a first-class flow.
Auditable access logging. Who accessed what, when, on whose authorization. Required for any compliance regime, invaluable during an incident, and painful to reconstruct retroactively.
Data minimization by design. Serve the fields requested rather than the full record. This reduces breach exposure, and it positions you well if the final scope is narrower than the 2024 text.
A documented data inventory. What you hold, where, in what form. This is the prerequisite for everything else and the thing most institutions have least of. The counter you will hear is that the core provider ships a 1033 module and you map to their schema, which is true and does not remove the need: the module covers what sits in the core, and the fields under dispute are frequently the ones that do not.
None of that is speculative. All of it has value if the rule is repealed entirely.
Defer this
Building to the exact field list in the 2024 text. Scope is among the reopened questions.
Committing to a specific technical standard as though it is settled. Build behind an interface you can re-point. The reasonable objection is FDX, which is the de facto standard and the likeliest candidate for whatever safe harbour emerges, and building to it now is close to a no-regrets move. The distinction worth holding is between building to FDX and architecting as though it is the only thing you will ever speak.
Anything premised on free access being permanent. If pricing is permitted, business models assuming zero-cost data change materially. Do not architect as though that question is closed.
Large integration commitments with aggregators on multi-year terms. See below.
Contracts that survive either outcome
This is where the uncertainty is most manageable, because contract language is cheaper to change than architecture.
Regulatory change clauses. Explicit provision for what happens to pricing and obligations if the final rule differs materially from the current text. Both directions.
Avoid long terms right now. A five-year aggregator agreement signed during a rewrite is a bet on an outcome nobody can call. Shorter terms cost slightly more and preserve the ability to respond.
Pricing contingency. If data access charges become permissible, who bears them. Silence on this means it gets resolved by whoever has more leverage later.
Liability allocation for downstream breaches. If a data recipient is compromised, what is your exposure. Worth settling while the relationship is new.
The position we would take
For most institutions below the largest tier: build the consent, revocation, logging, and inventory foundation over the next two to three quarters. Treat it as customer-experience and security work that happens to have regulatory value, because that is genuinely what it is. Defer field-level scope decisions until the rewrite lands. Keep contracts short.
The institutions that will handle whatever emerges best are not the ones that guessed the rule correctly. They are the ones that built the parts common to every version and kept the rest flexible.
There is a real risk of over-investing here. Some institutions spent significantly building to the 2024 text and now hold work that may not be needed in its current form. The lesson is not that they were wrong to move. It is that under regulatory uncertainty the right investment is in the foundations rather than in the specifics, and the specifics are precisely what a finalized rule tempts you to build first.
For data architecture and integration work in regulated finance, see Banking-as-a-Service integration and payment systems modernization, or book a call.