Plaid vs. Screen Scraping: Why OAuth Connections Are Safer

Screen scraping means a finance app stores your actual banking username and password and uses software to log in as you, copying data off the bank's website. OAuth means you log in on your bank's own site and the bank hands the app a limited, revocable token instead — the app never sees your password. Plaid supports both, but it has been migrating banks to OAuth for years because token-based connections are safer (no shared credentials, scoped read-only access, one-click revocation) and more reliable (they don't break every time the bank redesigns its login page). If your bank offers OAuth, that is the connection you want.

What is screen scraping, exactly?

Screen scraping is the original way finance apps got your data, dating back to the early 2000s. You typed your bank username and password into the app, the app stored them, and a bot periodically logged into the bank's website pretending to be you. It navigated the same pages you would, read the HTML, and extracted balances and transactions from whatever the page happened to display.

It worked, in the sense that a spare key under the doormat works. But the mechanics should make you wince a little:

• The app (or its data aggregator) holds your real credentials. Anyone who compromises that store can log into your bank as you — with the same powers you have, including moving money.
• The bank can't tell the bot from you. From the bank's perspective, "you" logged in at 4 a.m. from a data center in Virginia. That confuses fraud detection and muddies who is responsible if something goes wrong.
• There's no scope. Your password unlocks everything: transfers, wires, changing your mailing address. A scraper that only wants to read transactions still holds the keys to all of it.
• Multi-factor authentication fights it constantly. Every code your bank texts you is a code the scraper has to somehow handle, which is a big reason scraped connections break so often.

How is an OAuth connection different?

With OAuth, the password never leaves the bank. When you link an account, you're redirected to your bank's own login page — the real one, on the bank's domain, with the bank's own multi-factor prompts. You sign in there, the bank shows you exactly what the app is asking for ("read account balances and transactions for these two accounts"), and you approve or decline. If you approve, the bank issues the aggregator a token: a long, random credential that grants only that access and nothing else.

That one change fixes most of what's wrong with scraping. The token is scoped, so it can read data but can't initiate a transfer — which is why a Plaid-connected app genuinely cannot move your money even if it wanted to. The token is revocable, so you can kill one app's access from your bank's security settings without changing your password or touching any other app. And the bank knows exactly which third party is calling, so traffic goes through a stable, documented API instead of a bot impersonating a customer.

There's a practical bonus, too. Scraped connections break whenever a bank redesigns its login flow, adds a CAPTCHA, or changes its MFA — the bot literally can't find the button anymore. OAuth connections survive redesigns because they never depended on the website's layout in the first place. If you've wondered why your bank keeps disconnecting from a budgeting app, connection type is often a big part of the answer.

Does Plaid still use screen scraping?

Sometimes, yes — and it's worth being honest about why. Plaid connects to thousands of US financial institutions, and they don't all offer the same plumbing. Large banks like Chase, Bank of America, Wells Fargo, and Capital One have moved their Plaid connections to OAuth or dedicated data-sharing APIs. Many smaller banks and credit unions haven't built that yet, so credential-based access is the only way to reach them. Plaid has been steadily migrating institutions to API-based connections, but the long tail is long.

You can usually tell which kind of connection you're getting. If linking your bank bounces you out to your bank's own website or app to sign in, that's OAuth. If you type your bank username and password directly into the link window, that's credential-based access. In the second case the credentials go to the aggregator, not to the finance app itself — what the app receives is data, not your password — which is meaningfully better than the app storing them, but it's still not as clean as a token.

A worked example: what a breach would actually expose

Abstract security arguments are easy to tune out, so make it concrete. Say you use a budgeting app connected to your checking account, which holds $8,400, and imagine the worst case for each connection type.

Scraping scenario: an attacker compromises a system that stores scraped credentials. They now have your actual bank login. They can sign in as you, add themselves as a payee, and start a $2,500 transfer. You may get it back — banks investigate unauthorized transfers — but you're now in a dispute process with money in motion, and you have to change that password everywhere you reused it.

OAuth scenario: an attacker steals the token instead. They can read your balance and your transaction history — a real privacy harm, not nothing. But they cannot log into your bank, cannot see your password (it was never there), and cannot move a dollar, because the token was scoped read-only. The bank or aggregator revokes the token, you re-link, and your $8,400 never moved. Both are breaches; only one puts money in play.

The trade-offs OAuth asks of you

OAuth isn't free of friction, and pretending otherwise would undercut the case for it. The consent that makes tokens safe also expires: some institutions cap authorizations at 90 days or a year, which is why some banks make you re-link periodically. Re-linking is mildly annoying, but it's the security model working as intended — access you granted once shouldn't silently last forever.

OAuth flows also involve redirects, and redirects can fail in specific environments — for example, a bank's OAuth page may hand control back to a web domain rather than deep-linking into a mobile app. And tokens still break for ordinary reasons: you change your password, the bank flags something, consent lapses. A well-built app should tell you loudly when that happens rather than quietly showing stale balances; when it does, fixing a broken bank connection is usually a two-minute re-link, not a support ticket.

One more habit worth adopting regardless of connection type: audit what you've connected. OAuth makes this easy — your bank's security settings list every third party with a token, and you can revoke an app's access there in seconds. With scraped connections, revoking access means changing your bank password, which is blunter but works.

What this means when you choose a finance app

You mostly don't get to pick the connection technology — your bank and the aggregator decide that between them. What you can pick is the app's posture on top of it. Look for three things: the app uses a major aggregator like Plaid rather than asking for credentials on its own login form; the access it requests is read-only, so the worst case is exposure, not theft; and it lets you disconnect and delete your data without a phone call. Seven Financial is built that way deliberately — Plaid connections, read-only by design, delete-in-app — because for a tool whose whole job is reading your accounts, holding your banking password was never necessary.

The direction of travel is good. US banks are moving toward open, token-based data sharing, and credential-based scraping is shrinking to the institutions that haven't caught up. In the meantime, understanding the difference tells you what questions to ask — and if you want the fuller picture of what happens under the hood when you link an account, start with how Plaid actually works.