Skip to content

CFPB open banking rule: the 1033 reconsideration proposal at OIRA since 4 August 2026

The Consumer Financial Protection Bureau (CFPB) sent a proposed rule reconsidering its open banking rule, 12 CFR Part 1033, to the Office of Information and Regulatory Affairs (OIRA) on 4 August 2026. On 22 September 2026, the Federal Register shows no published proposal. Part 1033 test suites keep the published response rate, authorisation, revocation, and data field checks.

What changed in 2026: a proposal at OIRA and a paused appeal

The published rule, its compliance tiers, the October 2025 injunction, and the August 2025 advance notice are on our CFPB Section 1033 page. This post covers three dated steps from 2026 that the page does not list.

  • 30 March 2026, Sixth Circuit. The appeals of the district court injunction (Nos. 25-6164 and 26-5005) were consolidated on 12 February 2026. On 30 March the court granted a motion to hold briefing in abeyance, cancelled the briefing schedule, and ordered status reports on the rulemaking every 60 days.
  • 28 July 2026, status report. In the plaintiffs' status report, the CFPB states that it "is continuing to conduct the rulemaking to reconsider the Personal Financial Data Rights Rule (Rule), with a view to substantially revising it." The CFPB and the plaintiffs asked to keep briefing in abeyance, and the Financial Technology Association, the intervenor, did not oppose.
  • 4 August 2026, OIRA. The Office of Information and Regulatory Affairs (OIRA) received RIN 3170-AB39, "Personal Financial Data Rights Reconsideration", at the Proposed Rule stage, marked economically significant, for review under Executive Order 12866. We read the OIRA review record in a Wayback Machine capture of 26 August 2026 because reginfo.gov refused connections on 22 September 2026.

Status checked on 22 September 2026:

A proposal under OIRA review has no public text. Its content is unknown until the Federal Register publishes it, and a proposal changes no obligation until a final rule follows.

Why an unpublished proposal already matters for 1033 test scope

The CFPB's own words to the court are "substantially revising". The four areas the August 2025 advance notice of proposed rulemaking named are the fee prohibition in 1033.301(c), who counts as the consumer's representative, data security, and data privacy. Of these, "representative" decides who may act as an authorised third party whose requests a data provider must answer under 1033.331(b), and the fee prohibition decides whether a developer interface may meter and bill requests. Both sit directly in API test cases.

A 1033 suite written as a set of hardcoded thresholds and dates breaks in two ways when a final rule changes them: tests fail against a correct build, or tests pass against a build that meets a superseded number. For a data provider building to the published text, a stale 99.5 percent assertion or a stale one-year timer produces evidence tied to a superseded number.

What to change in a Part 1033 test plan now

Our practice is to key every 1033 test to a clause and to hold the clause's numbers and conditions as named parameters with a status date. The table lists the published conditions in four areas: developer interface performance, authorisation duration, revocation, and data fields. Every cell follows the eCFR text as read on 22 September 2026.

ClausePublished conditionParameter to holdTest that reads it
1033.311(c)(1) Developer interface response rateProper responses divided by requests for covered data must be equal to or greater than 99.5 percent in each calendar month.Floor 99.5 percent; window one calendar monthMonthly rate recalculated from gateway logs and compared with the floor
1033.311(c)(1)(i) and (ii) Scheduled downtimeRequests and responses during scheduled downtime are excluded, and downtime is scheduled only if the data provider gave reasonable notice to all third parties with access.Notice record required per excluded windowExcluded windows matched one by one to a notice sent to every third party
1033.311(c)(1)(iv) Proper responseA proper response fulfils the request or explains why it was not fulfilled, follows the data provider's written policies, and arrives within a commercially reasonable time. Messages during unscheduled downtime are not proper responses.Response time limit taken from the chosen consensus standardTimeouts and HTTP 5xx errors without an explanation counted as improper
1033.421(b)(2) and (b)(3) Authorisation durationCollection is limited to one year after the consumer's most recent authorisation. A new authorisation is obtained no later than its anniversary.Maximum duration one year; anchor the most recent authorisation dateCollection jobs run on the day before, the day of, and the day after the anniversary
1033.331(e) Revocation at the data providerA data provider that receives a revocation through a method it offers must revoke the third party's access and notify the third party in a timely manner.Timeliness limit set in the data provider's written policyData request after revocation rejected, and a notification delivered
1033.421(h) and (i) Revocation at the third partyThe revocation method is as easy to access and operate as the initial authorisation. The third party notifies the data provider, any data aggregator, and other third parties that received the data, and stops collecting under the most recent authorisation.Recipient list per consumerRevocation in the app followed by checks on every recipient and on the collection scheduler
1033.211(a) to (f) Covered data fieldsTransactions (24 months deemed sufficient), balance, payment initiation information, terms and conditions, upcoming bills, and basic account verification information.Field list and history depth per categoryField presence and history depth checked per account type

Four steps follow from the table.

  1. Tag each test with its clause and a status date. When the proposal appears in the Federal Register, the diff between the proposed text and the table becomes the list of tests to rewrite. A test with no clause tag cannot be traced to the change.
  2. Keep the fee path testable. If a developer interface returns fee or billing data today, record it against 1033.301(c). The published text says a data provider "must not impose any fees or charges on a consumer or an authorized third party in connection with" establishing or maintaining the interfaces, or receiving requests and making covered data available in response. The reconsideration may change that answer, and the test then flips from a defect to a feature.
  3. Test the authorisation anchor against the date field it reads. The published limit counts from the "most recent authorization", so a job that counts from account link date or token issue date fails on the first reauthorisation. The consent and token refresh guide shows the requests for refresh and expiry.
  4. Keep synthetic fixtures for all six data categories. Payment initiation data under 1033.211(c) includes "an account and routing number that can be used to initiate an Automated Clearing House transaction", which puts real account data into scope if fixtures come from production. Our fixtures use synthetic account numbers.

We run these suites for open banking aggregators as third parties and for data providers through open banking API testing. The consent and reauthorisation flow test suite and the API conformance test results from that service carry the clause tags and status dates above, so a rewrite after the final rule starts from the tagged list of affected tests.

Scope your testing

Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.

Scope your testing