CFPB 1033 for fintech evidence: what consumer financial data rights mean for your record

What 1033 is, in one paragraph

Section 1033 of the Dodd-Frank Act was operationalized by the CFPB's Personal Financial Data Rights Rule, finalized October 2024. It requires covered financial institutions (banks, credit unions, card issuers, digital wallets) to make consumers' financial data available to them and to authorized third parties through developer interfaces, without charge. It is the US functional analog to Europe's PSD2. Compliance dates stage from 2026 through 2030 by institution size, with the largest institutions earliest.

Most legal coverage focuses on the access-and-disclosure obligations on data providers (the “banks must let third parties read” side). The less covered half is the evidence the rule expects from both sides: consent records, access logs, retention limits, revocation enforcement, and downstream-use tracking. For fintechs that consume consumer financial data, that evidence is yours to keep.

Who is covered, and as what

The rule defines two regulated parties:

• Data providers. Entities holding covered consumer financial data. Primarily banks, credit unions, card issuers, and digital wallet providers. The access-and-disclosure obligations are theirs.
• Authorized third parties. Entities that consume covered data on a consumer's authorization. Most fintechs that pull bank-account data, transaction history, or balance data through Plaid, Finicity, or MX fall here. The consent, retention, and downstream-use obligations are theirs.

A fintech that ingests bank-account data is an authorized third party. A neobank with FBO accounts at a sponsor bank that exposes those accounts to other authorized third parties is also a data provider (through its sponsor) and an authorized third party (when it ingests data from elsewhere). Most growth-stage fintechs are at least one side; many are both.

The four evidence requirements

Read past the API mechanics and the rule asks for four things that have to be captured and producible on demand:

• Consent records. Per consumer, per third party, per data category, per time range. When the consumer authorized which data was accessible to which fintech for how long. Every authorization is an event with attributes; the record holds all of them with timestamps.
• Access logs. Which third party accessed which data, when. Every access tied back to the consent that authorized it. Examiners and consumers can ask “show me everything fintech X read about me last month” and the answer comes from the access log.
• Revocation enforcement. When a consumer revokes consent, the downstream third party stops accessing the data and the record shows the enforcement. A consent revoked at T+0 with the third party still pulling at T+1 is the enforcement failure examiners look for.
• Use limitation and retention. What the data is used for must stay within the consent scope. Using data authorized for account-aggregation purposes for credit decisions triggers FCRA obligations. Retention beyond what the consent allows is a separate violation. Both have to be provable on the record.

The compliance timeline, by institution size

The CFPB's staged implementation gives larger institutions earlier deadlines and smaller institutions later ones. The dates have been subject to legal challenges and procedural stays during 2025-2026; verify the current posture with counsel before making architectural decisions tied to specific deadlines. The staging roughly maps as:

• Tier 1 (largest data providers). Compliance expected in 2026, with the largest depository institutions and major card issuers in the first cohort.
• Tier 2 (mid-size). 2027-2028, mid-size banks and credit unions.
• Tier 3 (smaller). 2029-2030, community banks, smaller credit unions, smaller card issuers.
• Authorized third parties. Obligations apply when consuming covered data from a data provider that is itself in scope. As tiers come online, the third parties that consume from those tiers become in scope.

The practical effect for a growth-stage fintech: by mid-2027, most aggregator relationships (Plaid, Finicity, MX) will be operating against 1033-compliant data providers, and the fintech's third-party obligations will be active. The evidence record needs to be in place before that, not after.

What changes with Plaid, Finicity, and MX

The aggregator architecture (a fintech pulls bank data through a third party that handles the connectivity to thousands of institutions) shifts under 1033. The screen-scraping approach that built the consumer-finance aggregation market has been moving toward standards-based APIs (FAPI 2.0, OAuth 2.0) for years. 1033 formalizes that direction.

For the fintech consuming bank data, the practical changes are:

• Higher-quality, more stable data feeds as aggregator relationships migrate from screen-scraping to standardized APIs. The consumer experience improves; the connection breakage drops.
• Formalized consent and audit burden on the fintech's side. The aggregator handles the connectivity; the fintech handles the consent record, the access log tied to it, the revocation enforcement, and the use limits.
• Cross-FCRA implications if the data is used for credit decisions. 1033 does not change FCRA; it makes 1033 evidence the substrate that has to demonstrate the use stayed within consent.

Where this fits in the compliance evidence record

For a fintech that already keeps a single source of truth for fintech risk decisions, the 1033 evidence is a slot on the same record. Per consumer, the record holds:

• Every consent the consumer granted (third party, data category, time range, purpose).
• Every access event under each consent (which API endpoint, which data fields returned, what the access was used for downstream).
• Every revocation event and the enforcement that followed (the access events that stopped, with timestamps).
• The policy version that applied at each consent (because what counts as a permissible use under your privacy policy can change over time, and the record needs to know what applied when).
• A hash chain that proves the record has not been altered after the fact.

FinQub does not produce the consent UI, the OAuth flow, or the bank-data feed. Those are vendor responsibilities (your aggregator, your consent platform, your KYC). FinQub is the record they all land on, so the CFPB inquiry, the FCRA-adjacent review, or the consumer's own request all return the same answer.

A checklist for 1033 evidence readiness

• Treat 1033 as an evidence problem, not just an API problem. The aggregator handles the connectivity; the record holds the obligations.
• Capture every consent as a discrete event with attributes (consumer, third party, data category, time range, purpose). Not as a Boolean “has_consented” flag.
• Tie every access to the consent that authorized it. An access without a consent reference on the record is the violation examiners look for.
• Enforce revocation in the access path, not in a post-hoc batch. The first access after revocation is the test case.
• Pin the policy version. What counts as in-scope use is policy-dependent and changes over time.
• Confirm the record is portable across aggregator swaps. Plaid to Finicity (or vice versa) should not break the consent history.
• Test the consumer-request flow before the rule is enforced. A consumer asking “show me everything you have done with my data” should resolve in minutes.

Frequently asked questions

1033 evidence is one slot on the same record that holds your KYC, your sanctions screening, and your fraud signals. See how the chain holds it together, or book a short walkthrough below.