CFPB Open Banking Rulemaking in 2026: What Engineering Teams Should Build Toward

The Consumer Financial Protection Bureau reopened its open banking regulation, the Personal Financial Data Rights rule that governs how consumers authorize third parties to access their financial data. The Bureau finalized that rule in October 2024 and issued an advance notice of proposed rulemaking on August 22, 2025, discussing possible amendments. On October 29, 2025, a federal court stayed the rule’s compliance dates in Forcht Bank, N.A., et al. v. Consumer Financial Protection Bureau. The Bureau also announced plans to issue a notice of proposed rulemaking extending those compliance dates. The final shape remains genuinely uncertain.

Uncertainty about the rule does not create uncertainty about the architecture. The capabilities any version of this framework requires overlap heavily, and most of them constitute good engineering regardless of what the Bureau finalizes.

What Open Banking Regulation Actually Governs

Strip away the terminology and three questions remain.

Who may access a consumer’s financial data? A consumer authorizes a third party. The institution holding the data must honor that authorization rather than obstruct it.

Through what mechanism? A documented interface rather than screen scraping with shared credentials. This distinction drives most of the engineering work.

Under what constraints? Scope limits on what the third party receives, duration limits on how long access persists, revocation that actually works, and restrictions on secondary use of the data.

Every version of an open banking framework, in any jurisdiction, answers those three questions. The versions differ on specifics rather than on structure.

Why Screen Scraping Became the Problem

For years, third-party financial applications accessed consumer data by collecting banking credentials and logging in as the consumer. That approach carries obvious defects.

The consumer surrenders full credentials for what should constitute narrow access. An application that needs transaction history holds the ability to move money.

The institution cannot distinguish an authorized aggregator from an attacker, because both present valid credentials from an unexpected context.

Revocation requires a password change, which breaks every other authorized connection simultaneously.

Scope does not exist. Credentials grant everything or nothing.

A documented interface with delegated authorization fixes all four, which explains why every regulatory framework in this space pushes the same direction.

The Capabilities Worth Building Now

These survive any plausible final rule.

Delegated authorization with scope. A consumer grants a named third party access to specific data categories for a defined duration, without surrendering credentials. Standard authorization patterns handle this, and the work sits in mapping your data model to meaningful scopes rather than in the protocol.

A revocation path that propagates. A consumer revokes access and the third party loses it promptly across every path. Systems that cache authorization decisions aggressively fail this quietly.

An access log the consumer can read. Who accessed what, when, under which grant. Regulators increasingly expect consumers to see this, and building it retroactively across a distributed system costs far more than instrumenting it once.

Data minimization at the interface. Return the fields the scope covers rather than the full record with a filter applied at the client. Over-return creates exposure you cannot audit.

Performance and availability commitments. Frameworks in this space generally prohibit degrading third-party access relative to first-party. An interface that answers slowly enough to frustrate users constitutes obstruction in substance.

The Architecture Decision Underneath

Institutions face a choice that outlasts any specific rule: build the access layer as a compliance artifact, or build it as a product surface.

As a compliance artifact, it satisfies the minimum, lives beside the main platform, and receives attention when examiners ask. It works, it costs less initially, and it accumulates debt.

As a product surface, it becomes the same interface your own applications consume, held to the same reliability standard, versioned and documented like any external contract. It costs more at the start and removes an entire category of future work.

The second path wins whenever partnerships matter. An institution whose data interface works well becomes easier to integrate with, and integration ease shapes which partners build against you. Our banking operations guide covers the adjacent systems.

The Third-Party Side of the Same Rule

Most coverage addresses institutions holding the data. Companies consuming it face a mirrored set of obligations, and those arrive with less warning.

Secondary use restrictions bite hardest. Data collected to power one feature generally cannot fuel unrelated products, model training, or resale. Product teams accustomed to treating acquired data as an asset need an explicit policy about what each authorization actually permits.

Retention becomes a design constraint. When authorization ends, the data associated with it generally must go. Systems that copy records into analytics warehouses, feature stores, and backups discover that deletion spans further than anyone mapped.

Re-authorization interrupts the product. Time-limited grants mean a working integration stops on a schedule unless the consumer renews. A product built assuming permanent access degrades badly the first time a cohort expires together.

The engineering consequence: tag data with the authorization that produced it, at ingestion, and carry that tag everywhere the data travels. Teams that skip this cannot answer a deletion request without a manual investigation, and the investigation grows longer every quarter.

Why This Framework Keeps Returning

Open banking rulemaking has restarted several times across jurisdictions and administrations, which tempts institutions toward waiting.

Waiting has not paid. The direction has held constant across every revision and every jurisdiction: away from shared credentials, toward scoped and revocable delegated access with consumer visibility. Specifics moved. Direction did not.

The pattern resembles data privacy regulation a decade ago. Institutions that built consent management and deletion capability before mandates arrived absorbed each new regime as configuration. Institutions that waited for certainty rebuilt under deadline, repeatedly, at higher cost each time.

Where AI Enters, and Where It Should Not

Reasonable uses. Anomaly detection across access patterns, since authorized-but-unusual access constitutes a genuine fraud signal. Classification of data requests against scope definitions. Regulatory change tracking, which our compliance workflows guide covers.

Unreasonable uses. Authorization decisions themselves. Whether a specific grant permits a specific request answers deterministically from policy, and a model introduces non-determinism into a control an examiner will test. Build that logic explicitly.

The general principle holds beyond this rule: use models where judgment under ambiguity adds value, and use code where a rule exists and an auditor will check it.

What to Do Before the Requirements Settle

Inventory current third-party access. Which aggregators reach your data, through which mechanism, under what agreement. Many institutions cannot answer this today.
Measure your screen-scraping exposure. Volume, sources, and what those sessions can reach.
Define scopes against your actual data model, since this takes longer than implementing the protocol.
Instrument access logging now, because retrofitting it later costs several times more.
Assign an owner. Open banking spans product, engineering, legal, and partnerships, and unowned cross-functional programs stall.

The Takeaway

The rule sits under reconsideration with its compliance dates stayed, and its final form stays uncertain. The capabilities it contemplates, delegated authorization with scope, working revocation, consumer-visible access logs, and minimized data return, describe what a well-built financial data interface looks like regardless.

Build toward those and the final rule becomes a configuration exercise. Wait for certainty and it becomes a program with a deadline attached.