Open banking is an active regulatory and product-planning issue for US fintechs, but the CFPB's Personal Financial Data Rights rule under Section 1033 is not currently operating on its original compliance schedule. The CFPB finalized the rule in October 2024, but a federal court stayed the compliance dates in October 2025 while the CFPB reconsidered parts of the rule. Fintechs building consumer financial data products should still design for consent, data-use limits, security, and auditability, but they should avoid treating the original phased compliance dates as currently enforceable without confirming the latest status.
For fintechs building on consumer financial data, this rule creates specific engineering and security obligations that most teams have not yet fully addressed. This article covers what Section 1033 requires, what the security implications are for your product and your compliance program, and where fintechs are finding the most significant gaps.
What Section 1033 Actually Requires
The core of Section 1033 is the consumer data right. Consumers can direct covered financial institutions and other covered data providers to make covered account data available to them or to authorized third parties through secure interfaces, subject to the rule's requirements and any applicable compliance dates.
For fintechs that access consumer financial data through these APIs, the rule creates several specific obligations. Consent scope must be granular , consumers must be able to authorize specific data types rather than blanket access to all their financial information. Revocation must be immediate , when a consumer revokes access, your system must stop accessing their data without delay. Audit trails must capture every consent event, documenting what was authorized, when, and by whom. And data use must be limited to the purposes the consumer authorized.
Section 1033 does not just create data access rights. It creates data use restrictions. Accessing consumer financial data for purposes beyond what the consumer authorized is a compliance violation regardless of whether the data was legitimately obtained.
The Security Implications for Your Product
Open banking APIs create new attack surfaces that your security program needs to address. Every API endpoint that provides access to consumer financial data is a potential target. API security controls are not optional in this environment , they are a regulatory expectation and a security necessity.
API Authentication and Authorization
Your API security controls need to ensure that access to consumer data is authenticated, authorized against the specific consent scope the consumer provided, and logged in a way that can be audited. Token management is critical , access tokens must be scoped to the specific data types authorized, rotated appropriately, and revoked immediately when consumer consent is withdrawn.
Data Minimization
The consent framework under Section 1033 requires that you access only the data the consumer has authorized for the specific purpose they authorized. This means your data access patterns need to be auditable against consumer consent records. A fintech that accesses broader data than the consumer authorized , even unintentionally , has a compliance problem as well as a security problem.
Third-Party Risk in an Open Banking Environment
If you use third-party services to process or analyze consumer financial data accessed through Section 1033 APIs, those vendors inherit the compliance obligations. Your vendor contracts need to specify data use restrictions consistent with consumer consent, and your vendor risk management program needs to verify that vendors are honoring those restrictions. This is an area where many fintechs have significant gaps.
What Your Compliance Program Needs to Address
Section 1033 compliance requires your information security program to be updated in several specific areas. Your data classification framework needs to specifically address data accessed through open banking APIs and the consent restrictions that apply to it. Your incident response plan needs to address what happens when consumer data accessed through Section 1033 is compromised, including both the technical response and the notification obligations. Your vendor risk management program needs to flow consent restrictions down to any vendor that touches Section 1033 data. And your audit logging needs to capture consent events with sufficient detail to demonstrate compliance in a regulatory examination.
The Timeline for Compliance
The Section 1033 final rule includes a phased compliance timeline based on the size of the financial institution holding the data. However, for fintechs accessing consumer data through these APIs, the obligation to respect consumer consent and data use restrictions applies from the point you begin accessing data under the rule. There is no grace period for data use compliance.
Fintechs that are building open banking features now should build Section 1033 compliance requirements into their architecture from the start. Retrofitting consent management, data use controls, and audit logging into an existing product architecture is significantly more expensive and time-consuming than building them in from the beginning.