Building AI Agents for Open Banking While the 1033 Rule Is Enjoined

The Rule Is Enjoined. The Demand Is Not.

The CFPB finalized the Personal Financial Data Rights rule under Section 1033 of Dodd-Frank in October 2024. A year later the Bureau changed its own position on it. After first defending the rule, the CFPB told the Eastern District of Kentucky in mid-2025 that it now viewed the rule as exceeding its statutory authority, and the court enjoined enforcement while the agency reconsiders. The Bureau then published an advance notice of proposed rulemaking, Personal Financial Data Rights Reconsideration, on August 22, 2025. The compliance date that the largest data providers had been building toward did not arrive the way the original rule scheduled it.

If you run engineering for a bank or a data recipient, the temptation is to stop. That is the wrong read. The demand for account data sharing is a market fact that predates the rule and does not depend on it. Aggregators, personal-finance apps, and lenders that pull cash-flow data were doing this before 1033 and are doing it now. The rule was going to standardize the interface and the duties. The injunction removed the deadline, not the customer who wants to connect their account to a budgeting app or the lender who wants twelve months of transaction history to underwrite a thin-file borrower.

So we build for open banking on the assumption that some version of these duties returns, and we design the AI agent so the parts most likely to change are the parts easiest to change.

Where an AI Agent Touches the 1033 Pipeline

There are two distinct roles, and an agent behaves differently in each.

When the bank is the data provider, an agent sits behind the request. A consumer, or an authorized third party acting for the consumer, asks for covered data, and the agent has to decide what to release, to whom, under what authorization, and for how long. The hard problems here are authorization and scope, not generation.

When the bank or lender is the data recipient, the agent consumes the data. It reads the transaction history to answer a borrower's question, to triage a hardship, or to feed an underwriting step. The hard problems here are use limitation and retention, because the recipient duties in the original rule restricted using the data for anything beyond what the consumer asked for.

Most of our customers are on both sides at once, which means the agent has to enforce provider duties on outbound requests and recipient duties on the data it ingests, in the same workflow. We keep those two duty sets in separate policy modules so that a change to one does not silently alter the other.

Designing for the Four Questions the Reconsideration Reopened

The reconsideration ANPR asked for comment on four areas, and those four are exactly the parts of the architecture we treat as configurable rather than hard-coded, because they are the parts likely to move.

The first is who counts as a "representative" authorized to make a request for the consumer. We do not bake a single definition into the agent. Authorization runs through a policy module that checks the requester's status against a configurable rule set, so a narrower or broader definition is a configuration change and an audit-log entry, not a re-architecture.

The second is fees. The original rule limited what a data provider could charge. The reconsideration reopened whether and how fees apply. We meter and attribute every data-access request at the agent boundary regardless of whether a fee is charged today, because you cannot price or rate-limit what you did not measure, and turning metering on after the fact is how programs lose a year.

The third is data security, including the threat picture and the cost-benefit of specific controls. We hold this to the floor described below and treat the rule's eventual security text as a possible tightening, never a loosening.

The fourth is privacy, specifically the threat picture around secondary use of shared data. On the recipient side, our agents carry a use tag with every field of ingested data that records the purpose the consumer authorized, and the agent refuses to use a field for a purpose outside that tag. If the final rule narrows permitted secondary use, that is a tightening of a constraint we already enforce.

Scoping Data Access in the Agent

The failure mode we design against is over-disclosure. An agent acting as the data provider, asked by an authorized third party for "account data," should not return the full account record by default. It returns the covered fields in scope for the specific authorization, and nothing the requester is not entitled to.

We implement this as a deny-by-default field policy. The agent starts with no fields releasable and adds only the covered data elements the authorization grants. Retained data the consumer did not request, internal risk scores, and anything outside the covered-data definition stay behind the boundary unless a rule explicitly releases them. We log the field set released on every request, which gives the privacy team a record of exactly what left the building and which authorization permitted it.

On the recipient side, the mirror control is retention. Ingested data carries a time-to-live tied to the authorized purpose, and a scheduled job purges fields when the purpose expires. An underwriting pull that the borrower authorized for a single application does not quietly become a permanent feature in a marketing model.

The Developer Interface Standard We Hold Ourselves To

The original rule pushed providers toward a developer interface and away from credential-based access. Even with the rule enjoined, a machine interface is the right engineering answer, so we hold our own interface to operational targets rather than waiting for a regulatory number to force them.

We set an availability target for the data-access interface and alert below it, because a recipient agent that cannot reach the provider degrades the consumer's experience and, under any future rule, risks an availability finding. We cap and monitor error rates on data requests and treat a sustained rise as an incident. We version the interface so that a schema change is a planned migration with a deprecation window, not a break that strands recipients. These are the same disciplines we would apply to any production API that another party depends on, which is the point. The rule, when it returns, is likely to formalize numbers we should already be meeting.

Killing Screen Scraping Without Breaking the Workflow

Credential-based screen scraping is the practice the open-banking framework was built to retire, because handing a third party a banking password and letting it log in as the customer is the least safe way to share data. The cutover is the hard part operationally, because real customers have live connections that scrape, and breaking them to make a security point is its own consumer-experience failure.

The pattern our customers run is a phased migration. New connections go through the tokenized interface only. Existing scraped connections get migrated cohort by cohort, with the agent handling the re-authorization conversation with the customer so the connection re-establishes on the interface rather than on stored credentials. We track the percentage of data access still flowing through scraping as the migration metric and drive it down deliberately. The agent is useful here precisely because the migration is a high-volume, low-complexity conversation that would otherwise sit in a call-center queue.

The Security Floor That Does Not Move

Whatever the 1033 rewrite does, the security obligations under the FTC Safeguards Rule (16 CFR Part 314) and the Gramm-Leach-Bliley Act do not move with it. Those duties attach to the data because of what it is, not because of which CFPB rule is in effect this quarter. So the floor we build to is the Safeguards Rule floor: access controls and least privilege on the systems that hold or move customer financial data, encryption in transit and at rest, multi-factor authentication on the interfaces, an inventory of where the data flows, and a written incident-response plan that names who acts when shared data is exposed.

We treat the agent and its data stores as in-scope systems under that program, which means the prompt store, the retrieval indexes, and the request logs all sit inside the same access-control and monitoring regime as the core. An AI agent that touches customer financial data is not a side system that gets a lighter security posture because it is new.

What We Are Building For

The honest state of play in 2026 is uncertainty. The rule exists on paper, cannot be enforced, and is being rewritten, and a thoughtful engineering leader could reasonably wait. We do not, because the cost of building the configurable version now is small and the cost of retrofitting authorization, metering, scoping, and retention into a shipped agent after the rewrite lands is large. The design principle is narrow: hard-code the security floor that the statute fixes, and make configurable the four areas the reconsideration put back in play. That is the version that survives whichever way the rule comes back.