CFPB Section 1033 Featured

CFPB Section 1033 and Screen Scraping: What It Means for Your Bank Login

CFPB Section 1033 examines how financial apps access consumer bank data. Learn why screen scraping can expose login credentials, how secure API-based connections work, and what US account holders should check before connecting an app.

Roy M

29 Aug 2026 • 12 min read

Woman connecting a finance app to her bank login as CFPB Section 1033 replaces screen scraping with secure data access in the US

Typing your online banking username and password into a budgeting, lending, or payment app remains a common way U.S. consumers connect accounts. It also gives a third party the same credentials used to move money.

Screen scraping has not been banned, and CFPB Section 1033 is not currently forcing every bank onto a login-free system. The 2024 Personal Financial Data Rights rule was designed to move the market toward dedicated developer interfaces. A federal court stayed the rule’s compliance dates on October 29, 2025, and the CFPB is still reconsidering parts of the framework. Until that status changes, inspect the connection method in front of you. Do not rely on headlines about “open banking.”

📋TL;DR

CFPB Section 1033 screen scraping debates concern how apps obtain bank data. They do not mean password sharing is already illegal.
Credential-based access still lets a third party log in as the account holder. That raises account-takeover, over-collection, and identity-theft risk even when the app itself is legitimate.
Before connecting an account, confirm whether the app sends you to your bank’s official site, shows a clear consent screen, and lets you revoke access later.
This article covers United States rules only. Verify the CFPB’s current position before treating any 2024 deadline as live.

Is screen scraping being phased out?

No. It is not banned. It is not complete. The market has been moving toward developer interfaces, but that is not the same as a current legal prohibition.

The CFPB’s October 2024 final rule was designed to give consumers more control over financial data and to encourage secure sharing through developer interfaces, rather than through apps that imitate a customer logging into online banking. That was the intended transition.

The current legal status is narrower. On October 29, 2025, the U.S. District Court for the Eastern District of Kentucky stayed the rule’s compliance dates in Forcht Bank, N.A. v. Consumer Financial Protection Bureau. In August 2025, the CFPB opened a reconsideration of key parts of the framework. Do not treat the original compliance calendar as currently in force.

If a company, sales deck, or “1033-compliant” badge states that screen scraping is already dead, treat that as marketing. It is not a substitute for checking how the app connects to the bank.

What Section 1033 actually is

Section 1033 of the Dodd-Frank Wall Street Reform and Consumer Protection Act is the U.S. statutory basis for consumer access to personal financial data. Subject to CFPB rules, covered financial firms generally must make information about a consumer’s own account available to that consumer.

The CFPB used that authority to issue the Personal Financial Data Rights final rule in October 2024. The Bureau published it in the Federal Register on November 18, 2024. The rule was written to do three things:

Make certain account information available to consumers and to third parties the consumer authorizes.
Direct that sharing toward dedicated technical interfaces rather than “type your bank password here.”
Place conditions on third parties that collect, use, and retain that data.

It is a data-access rule. It is not a national refund statute, a scam-reimbursement program, or a guarantee that every budgeting app is secure.

Current legal status of the final rule

As of August 29, 2026, treat the 2024 final rule as issued and published, with stayed compliance dates and an active reconsideration. Do not treat it as a finished nationwide cutover.

According to the CFPB’s Personal Financial Data Rights compliance page, last modified January 6, 2026:

On October 29, 2025, the court in Forcht Bank, N.A., et al. v. Consumer Financial Protection Bureau, et al., No. 5:24-cv-304-DCR (E.D. Ky.), stayed the rule’s compliance dates.
On August 22, 2025, the CFPB issued an Advance Notice of Proposed Rulemaking on possible amendments. The Bureau also said it planned a later proposal to extend compliance dates.

The reconsideration docket, CFPB-2025-0037, asked for comment on four issues: who can act as a consumer’s “representative,” whether data providers should be able to charge fees, data-security costs and threats, and data-privacy threats. Those questions remain open.

Do not read the original staged compliance dates as currently binding. Do not wait for the rulemaking to finish before inspecting a login request. The stay and reconsideration are why readers should also verify the CFPB’s current rulemaking and enforcement posture. Dollar Vigil’s explanation of what the CFPB enforcement shift means for fraud victims covers that separate issue.

Credential-based access versus screen scraping

These terms are often used interchangeably. They are related. They are not identical.

Credential-based access is the login. A third-party app or data aggregator uses the consumer’s online banking username and password to reach the bank’s consumer interface: the same website or app the customer uses.

Screen scraping is the extraction. Software reads information displayed through that interface and converts it into structured, machine-readable data. That can include balances, transactions, account numbers, payees, and other fields shown on the page.

Developer-interface access is a dedicated channel. The bank or data provider exposes an interface built for authorized systems, not for a third party imitating a customer in online banking.

Credential-based access and screen scraping often operate together. That is why public debate treats them as one method. Keep the distinction. A service can use credentials without scraping a visual page. A system can scrape displayed data after gaining access another way. A developer interface can still be misused if authorization, token handling, or data retention is weak.

The consumer point is direct: if the app needs the same password that unlocks the bank account, it is acting in the account holder’s place. That is a different risk from an app that receives only a limited, revocable authorization from the bank.

How developer interfaces and tokens work

In the CFPB’s vocabulary, a developer interface is an interface through which a data provider receives requests for covered data and makes that data available in electronic form usable by authorized third parties. The consumer interface is built for the account holder. The developer interface is built for authorized systems.

Token-based authorization, often discussed under labels such as OAuth, is the usual consumer-facing version of that design. The sequence is:

The app asks to connect to the bank.
The consumer is sent to the bank’s own website or app.
The bank shows what the app wants and asks for approval.
The bank issues a token or similar credential to the authorized connection.
The app receives data through that authorized channel instead of storing the online banking password.

That design reduces password exposure. It does not eliminate risk.

An “OAuth” label does not prove that the app is trustworthy, that the permissions are narrow, that the token cannot be abused, that any aggregator in the middle is careful, or that access can later be revoked. Tokens can reduce the need to hand over the master password. They do not remove privacy risk, cybersecurity risk, or account-takeover risk. Treat any claim to the contrary as unverified marketing.

The business side of these connections also uses fraud controls: consent-abuse detection, account-takeover scoring, device signals, and incident response. That is a vendor-and-controls issue, not the consumer login problem this article addresses. Teams comparing those controls can use Dollar Vigil’s roundup of open banking fraud APIs and protection controls.

What the 2024 rule would require from covered providers

The 2024 final rule’s intended design still matters because it is the framework under dispute. It is not, as of this writing, a consumer guarantee that every bank has already implemented it.

Under the final rule, a covered data provider generally would have to maintain both a consumer interface and a developer interface. The developer interface would have to make covered data available in a standardized, machine-readable format. Performance would have to be commercially reasonable. The rule used “consensus standards” from CFPB-recognized standard-setting bodies as evidence that a provider was meeting technical requirements. It did not impose one mandatory private specification.

The security clause that matters to consumers is 12 CFR 1033.311(e)(1): a data provider generally must not allow a third party to access the developer interface using the same credentials the consumer uses for the consumer interface.

Read that limit precisely. It applies to developer-interface access. It does not promise that no intermediary in the broader account-linking ecosystem will ever handle a banking password. The same provision contemplates a service-provider contract in which a provider’s vendor uses consumer credentials against the consumer interface while still presenting a developer interface to authorized third parties.

Authorized third parties would also have to do more than present a checkbox. Under 12 CFR 1033.401, a third party seeking covered data on a consumer’s behalf would need to provide an authorization disclosure, certify that it will meet the rule’s third-party obligations, and obtain the consumer’s express informed consent.

The rule was not written to make screen scraping the official fallback method for third-party compliance. That was the point of the intended transition. An intended transition is not a current nationwide ban.

What Section 1033 does not guarantee

Do not treat the statute or the 2024 rule as a consumer warranty.

Section 1033 and the 2024 rule do not:

Create one national data-sharing network.
Require every bank or fintech to use Financial Data Exchange, or FDX.
Make screen scraping illegal, “dead,” or already eliminated.
Guarantee that consumer passwords are never handled anywhere in the account-linking chain.
Eliminate privacy, cybersecurity, or account-takeover risk merely because a developer interface exists.
Make every request for banking credentials proof of fraud.
Keep the original compliance dates in force while the stay and reconsideration are pending.

FDX develops technical standards used in financial-data sharing. The CFPB framework allows qualifying industry standards to help providers show they meet applicable technical requirements. In January 2025, the CFPB recognized FDX as a standard setter. Recognition is not a command. Consensus standards are a compliance aid, not a required operating system for U.S. banking.

If a company says “we use FDX, so your login is safe,” ask the direct questions: Where does authentication occur? What data is requested? Who else touches it? How is access revoked later? If those answers are missing, the standard name does not establish safety.

How to identify a safer bank-account connection

Check the connection method before entering credentials.

Safer signs include:

You are redirected to your bank’s official website or mobile app, not a lookalike form inside the third-party app.
The bank itself displays an authorization and consent screen.
You can see what information the app is requesting: balances, transactions, account and routing numbers, payment initiation, or identity details.
You can review or revoke access later through the bank, the app, or both.
The service explains its security, privacy, retention, and deletion practices in clear terms.
The connection does not ask you to send banking credentials by email, chat, text message, QR code, or an unfamiliar web form.
Multifactor authentication and account-activity alerts are available on the bank account being connected.

Warning signs include:

The app wants the username and password used for online banking and never sends you to the bank.
A “support agent,” lender, crypto platform, or recovery helper asks for those credentials in a message thread.
The consent screen is vague, such as “access your account,” with no data list.
You cannot find a way to disconnect the app later.
The site or app resembles the bank, but the URL, app publisher, or spelling does not match.

Not every password request is fraud. Some older aggregators and apps still use credential-based access because that is how they were built. That history does not remove the risk. It makes verification mandatory.

Inspect the connection method before granting access. That is cheaper than reconstructing an account takeover.

Method	What actually happens	Main consumer risk	Safer if
Credential-based access	A third party uses your online banking login to enter the consumer interface	Password exposure, broader data access, harder revocation	You confirmed the company, the bank relationship, and a way to cut access
Screen scraping	Software copies data shown in the consumer interface and structures it	Over-collection of whatever the page displays	The service is known, limited, and not asking you to paste passwords into chat
Developer-interface / token access	The bank authorizes a dedicated data channel after you approve it	Permission creep, token abuse, weak app or aggregator controls	You land on the real bank, see the data request, and can revoke it

How to review and revoke an app’s access

Do not assume the app will remind you that the connection remains active.

Open your bank’s website or official app directly. Do not use a link from the third-party service.
Look for connected apps, data sharing, account aggregation, security, or privacy controls. Names vary. The function does not.
List every connection you do not recognize or no longer use.
Revoke access there first.
Then delete or disconnect the same link inside the budgeting, lending, or payment app.
Change the online banking password if that app ever had it.
Turn on multifactor authentication and transaction alerts if they are not already on.
Watch the account for new payees, password-reset emails, unknown devices, and small test withdrawals.

If the bank has no visible revoke control, call the bank using a number from the card or official site and ask how authorized data-sharing connections are terminated. Do not use a phone number supplied by the app that wants to remain connected.

Revoking access removes the app’s permission to keep pulling account data. Unused connections are a second access path. Close them.

If you typed your bank login into a service you now distrust, treat it as credential exposure. Do not wait to see whether a theft appears.

In the first fifteen minutes:

Open the bank’s official app or website yourself and change the online banking password.
Sign out other sessions or unknown devices if the bank shows them.
Revoke connected-app access.
Turn on or reset multifactor authentication. Prefer an authenticator app or hardware key over SMS if the bank offers it.
Review recent transactions, payees, address changes, overdraft protection, and external-transfer settings.
Save screenshots, URLs, timestamps, and any chat or email that asked for the password.
If money already moved or the account looks hijacked, follow a containment sequence such as Dollar Vigil’s guide to what to do after online banking fraud.

Then continue:

Call the bank using an official number and report the credential exposure even if no theft is visible yet.
Ask whether the account should be frozen, closed, or replaced.
Place a credit freeze with the major consumer reporting companies if identity data may have been exposed with that login.
Use IdentityTheft.gov if the exposure looks like identity theft, not only a bad app connection.
Do not send the same password, one-time code, or remote-access permission to anyone who messages you offering to “secure the account.” That is a common follow-on scam.

A legitimate app asking for a bank login is a risk decision. A stranger asking for a bank login in a text thread is credential theft.

Frequently asked questions

What is screen scraping in banking?

Screen scraping is a method of collecting financial information displayed through a consumer’s online banking interface and converting it into structured data. It has often been paired with credential-based access, where a third-party service uses the consumer’s banking credentials to access the account. The CFPB’s Section 1033 rule was designed to encourage a transition toward dedicated developer interfaces, but the rule’s compliance dates are currently stayed and parts of the framework remain under reconsideration.

It is riskier than authenticating at the bank itself. Some established apps still use credential-based access, so the request is not automatically fraud. It does mean the third party, and often a data aggregator behind it, can act in the account holder’s place. Prefer a redirect to the bank’s official site, a visible consent screen, and a revoke control. Never send banking credentials through email, chat, text, or a form you cannot attribute to the bank.

Did CFPB Section 1033 ban screen scraping?

No. The 2024 Personal Financial Data Rights rule was written to reduce reliance on credential-based screen scraping and to require developer interfaces for covered data providers. A federal court stayed the rule’s compliance dates on October 29, 2025, and the CFPB began reconsidering parts of the rule in August 2025. As of August 29, 2026, screen scraping has not been banned and has not been eliminated.

What is the difference between screen scraping and an API?

Screen scraping copies data from the consumer-facing online banking display. A developer interface or API is a dedicated channel for authorized data exchange. Scraping reads the page the consumer sees. An API requests approved fields from the bank’s systems. APIs can still be misused. They remain the lower-risk architecture when the bank authenticates the consumer and access can be revoked.

Do banks have to use FDX?

No. FDX is an industry standard-setting organization. The CFPB framework lets qualifying consensus standards help firms meet technical requirements. It does not require every bank or fintech to adopt FDX as the only legal method of sharing data.

How do I disconnect an app from my bank?

Revoke it in the bank’s security or connected-app settings, then disconnect it in the app. Change the banking password if the app ever had it. Watch the account for new devices, payees, and transfers. If you cannot find the control, use an official bank number and ask for data-sharing revocation. Do not use a phone number supplied by the app.

What if I already gave my password to a service I do not trust?

Change the password at the bank, revoke connections, enable multifactor authentication, and review transactions immediately. Report the exposure to the bank even before a theft appears. If funds moved or the account was taken over, contain the account first and document everything. Treat unsolicited “recovery help” as a follow-on scam until proven otherwise.

Regulatory-status note and sources

Status check date: August 29, 2026. Regulatory status can change; check the primary sources below for updates before relying on this information.

Primary official sources:

Cold Truth

The password box is an access-control decision. CFPB Section 1033 was designed to move U.S. account linking toward a model in which apps receive a token and the consumer keeps the login. A court stayed the deadlines. The Bureau reopened the rule. The market did not pause, and neither did anyone who profits from a copied login.

If an app needs your online banking password, you are not looking at a completed open-banking transition. You are using the older, higher-risk method. Confirm which method is in use before you enter the password.

⚠️DISCLAIMER
This article is for general educational information only. It is not legal, financial, or professional advice, and it does not guarantee that money will be recovered. Scam refund rules vary by country, payment method, bank policy, evidence, timing, and case details. If you need advice about your specific situation, contact a qualified legal, financial, or consumer-rights professional in your jurisdiction.