CFPB Section 1033 Open Banking AI Data Governance Guide

What Section 1033 Requires for Data Access and Authorization

The CFPB finalized the Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act in October 2024. The rule requires covered data providers, primarily banks and other financial institutions, to make consumer financial account data available in a standardized, machine-readable format. It creates a category of authorized third parties that must obtain express, informed consumer authorization before accessing that data on the consumer’s behalf.

The authorization disclosure must specify the data being accessed, the purpose of access, and the identity of the third party requesting it. Third parties may collect, use, and retain data only to the extent reasonably necessary to provide the requested product or service, a data minimization principle that applies continuously, not just at the point of initial collection.

Authorizations expire after a maximum of one year, requiring reauthorization for continued access, and consumers must be able to revoke authorization at any time, with third parties obligated to honor that revocation. The rule also directs data providers to make data available through a dedicated developer API rather than relying on credential-based screen scraping once a compliant interface exists. Compliance obligations are staggered by data provider size rather than applying on a single uniform date.

AI Agents Fall Under Existing Third-Party Obligations, Not a New Category

Section 1033 is technology-neutral. It does not separately define AI agents or automated systems, and it does not create a distinct compliance track for them. Obligations attach to the authorized third party as a legal entity, regardless of whether data access is executed through a human-directed application or an autonomous, AI-driven process.

This means an AI agent operating on behalf of a fintech or financial institution is legally treated as an extension of that entity’s existing authorization, not as a separate compliance actor with its own status under the rule. Accountability for the agent’s data access rests entirely with the organization operating it.

Logging and Audit Trail Requirements for Ongoing Access

Section 1033’s minimization duty does not end once data is received. It extends to how long data is retained and how it continues to be used, which has implications for AI agents that may hold data in memory, embeddings, or application logs well after the original API call.

An examination-ready audit trail needs to log every agent tool call against the open banking API together with:

• The associated consumer authorization ID
• The specific data scope requested
• The stated purpose of that request

This level of detail supports two distinct needs: demonstrating that each individual data pull was tied to a valid, current authorization, and detecting patterns of access that exceed what the stated purpose would justify. Monitoring for anomalous or excessive data pulls relative to purpose should be treated as an ongoing control rather than a one-time scope check performed at integration time.

Retention limits also need to be enforced at the agent and application layer, including any cached context or derived data, not solely at the point where the API gateway hands data to the application.

Regulatory Status and Building Adaptable Governance

The Section 1033 rule’s implementation timeline is not fixed. Litigation and CFPB signals about reconsidering aspects of the rule have introduced uncertainty about final compliance dates and scope. That uncertainty affects timing, but it does not change the underlying architectural principles: authorization scoping, minimization, and revocation are structural features of the rule’s approach to third-party data access, and they are unlikely to disappear even if specific deadlines shift.

Governance frameworks should be built to adapt to changing compliance dates rather than hard-coded to a single version of the rule. Organizations should also treat the deprecation of screen scraping in favor of standardized developer APIs as a governance milestone in its own right, since continued reliance on scraping-based agent access may fall outside the rule’s intended compliant access method once a provider’s API is available.

Runtime governance platforms that separate agent identity from consumer authorization, enforce least-privilege scoping, and maintain tool-call audit logs give organizations a way to meet these obligations regardless of how the specific compliance calendar evolves.