Hire by Technology
SERVICES
Contents
Share this article
Key Takeaways
Section 1033 is finalized, but governance is still up in the air.
As of mid-2026, a federal court has enjoined enforcement while the CFPB rewrites the rule, and the April 2026 deadlines were suspended.
So what does that mean from an engineering point of view?
You now have the opportunity to prepare so that you don’t have to rush when deadlines are finally decided. Selectively, you can almost completely build many of the parts that will be right regardless of how the rewrite lands.
Let’s look at what you can do in August 2026.
To ensure these components are created as efficiently as possible, make sure that you have fintech experts with production experience on your team. We can assist.
Let’s take a look at the Section 1033 timeline, so you have a better idea of where things stand right now.
The CFPB finalized the Personal Financial Data Rights rule, with a phased compliance schedule for data providers running from 2026 to 2030 depending on institution size.
The rule also formally recognized the Financial Data Exchange (FDX) as a standard-setting body.
Under new leadership, the CFPB reversed its own position. It informed the court that the rule likely exceeded its statutory authority.
In July 2025, it asked to stay ongoing litigation so it could rewrite the rule, and in August 2025 published an Advance Notice of Proposed Rulemaking reopening four specific areas:
A federal court in the Eastern District of Kentucky enjoined the CFPB from enforcing the rule.
The court agreed that it was likely to have exceeded the Bureau's authority.
However, the rule was enjoined, so it is still on the books, codified in federal regulations. The rule just isn't currently enforceable.
The case was appealed to the Sixth Circuit and is stayed while the CFPB works through its rewrite.
The first tiered compliance deadline arrived and passed without becoming a binding enforcement trigger.
The rewritten rule hasn't been published yet. While we are seeing a lot of speculation about timing, nothing has actually been confirmed.
Treat any specific date you see for a new rule as a rumor until the CFPB's own rules-under-development page or the Federal Register shows otherwise.
However, regardless of what happens during the rewrite, the underlying direction will probably stay the same: consumers authorizing third parties to access their financial data through standardized APIs instead of screen scraping isn't seriously in question.
Banks and aggregators are already striking commercial data-access agreements.
We can sort every piece of 1033-related engineering work into one of three buckets.
| Bucket | What Goes Here | Why |
| Build now | FDX-shaped APIs, consent infrastructure, access controls, observability | Correct regardless of how the rule lands, and valuable even if it never does |
| Design for, build later | Fee metering, authorized-party eligibility rules, data-scope specifics | Architect so it's addable without a rewrite, but don't build against unsettled details |
| Wait | Final fee mechanics, final authorized-third-party definitions, final data-scope rules | Genuinely dependent on the rewrite; building now risks building the wrong thing |
The "build now" bucket is the majority of the actual work, and it's worth doing to have a competitive open-banking product even in a world with no rules at all.
The regulatory uncertainty really only affects the edges, so treating the whole project as frozen until the rewrite lands is just going to waste time and put your engineering teams under pressure later.
Let’s take a deeper look at everything you can build now, so your developers can set you up for success before the rule is finalized.
The market has converged on the Financial Data Exchange (FDX) API as the standard for regulated data access, moving away from screen scraping.
Even the CFPB itself recognized FDX as a standard-setting body when it finalized the original rule. This recognition stands independent of the enforcement question.
What to build: RESTful, consumer-permissioned data-access endpoints modeled on the FDX API surface (accounts, transactions, balances, account details), with a clean separation between that access layer and core banking or ledger systems.
You're exposing a controlled read surface only. Version the API from day one, since this spec will keep evolving regardless of what happens with the rule.
If the rule vanishes entirely tomorrow, FDX-shaped APIs are still what aggregator partners actually want to consume.
Consumer-permissioned access means consent is the genuinely load-bearing component here, and it's durable regardless of exactly how the reopened questions get resolved.
What to build: a consent ledger recording who authorized what data, for which third party, when, and for how long, as an immutable, queryable record.
Ensure that you create granular scopes at the account level and data-type level.
You also need revocation that actually propagates, so a consumer withdrawing access cuts it off downstream in a way you can verify happened.
The reopened questions include exactly who can be an authorized third party, which you can't build the final answer to yet.
But a consent system with granular scopes and clean, verifiable revocation is correct under essentially any version of the rewritten rule.
What to build:
Whatever the final rewritten rule ends up saying about audit and reporting specifically, you will need to prove who accessed which consumer's data, under what authorization, and when.
Speaking from experience trying to retrofit these systems into our clients’ products, it is far easier and less expensive to build that evidence trail now.
What to build: per-request attribution tying together the consumer, the third party, the data scope, the consent reference, and a timestamp, held in tamper-evident, retained storage.
The real test is whether you can answer "show me everywhere this consumer's data went" for a regulator if one asks.
The original rule set real availability and performance expectations for data-access APIs specifically. The reasoning was that an access right that's frequently unavailable isn't much of a right.
It is highly likely that a rewrite will carry something similar.
Build toward a real availability target with monitoring that can prove you're hitting it.
Also include graceful degradation with clear error semantics aggregators can actually work with, and enough capacity for aggregator traffic patterns specifically, which tend to be bursty and machine-driven rather than shaped like ordinary human usage.
In August 2025, ANPR reopened four specific areas. For each of these, it’s sensible to get started on design without completing the build. This lets you get ahead, while still staying flexible.
The original 2024 rule barred data providers from charging for access, but that’s now subject to reconsideration. Some banks, however, have already begun striking commercial data-access agreements with aggregators independent of what the final rule says.
We recommend that you design your access layer so you could meter and bill per request or per consumer, but don't build a full billing engine since the fee structure doesn't exist yet.
Metering is genuinely cheap to add early and expensive to retrofit.
The definition may well tighten from where the original rule left it, so you should design third-party eligibility as an updatable policy layer, like a checkable allowlist or accreditation gate.
Secondary-use restrictions and broader privacy obligations are likely to be part of the reconsideration.
Since the specifics are to be determined, design your system to tag data with its permitted-use scope at the access layer itself, so a new restriction becomes a policy change rather than a re-architecture.
Specific security mandates could shift. You can still build a strong baseline now, and keep the specific controls configurable rather than hard-coded.
The skill set for 1033 readiness is very specific.
You will need API engineers who've genuinely built external-facing, versioned, high-availability APIs since the failure modes are different when the caller is outside your organization.
The developer will also need to know FDX, or they will need the ability to ramp on it fast. While the spec itself is learnable in days, the domain context often needs production experience.
When hiring, look for real consent and authorization experience, and OAuth implemented properly at scale with revocation that verifiably works.
Most fintech software development companies, like Trio, can staff this.
Build now, durable regardless of the rule:
Design for, build later:
Wait for the rewrite:
Make sure that you recheck the "wait" bucket against the CFPB's own rules-under-development page every quarter or so.
In our experience, the moment the rewrite actually publishes, most of the middle bucket's open policy questions get filled in, and because the mechanisms are already built, that becomes a configuration sprint rather than a re-architecture.
Building a durable core while the rule settles is the right move, and getting the right people on your team through a reputable fintech software development company can set you up for success.
At Trio, we pre-vet senior fintech specialists, so you can connect with the right people in as little as 3-5 days, at $40-80/hr, all-in, with placement typically running 3-5 days.
Expertise
Subscribe to our newsletter
Related
Content
Continue Reading
