The industry calls this account aggregation. A small number of intermediaries sit between thousands of consumer apps and thousands of banks, translating one side to the other. When a payroll app verifies your account, a lender pulls your cash flow, a crypto exchange checks your balance, or a rent-reporting service reads your transactions, an aggregator is usually doing the work.
There are two mechanisms for that work and they have very different consequences.
Mechanism one: screen scraping with stored credentials
The original method, and still widely used, is credential-based access. You give the aggregator your online banking username and password. The aggregator stores them, typically encrypted but necessarily reversible, because it needs the plaintext to log in as you. On a schedule it opens a session against your bank's website or mobile API, authenticates with your credentials, and reads whatever it can reach.
The bank cannot easily distinguish this from you. That is the design. The aggregator is impersonating you, which means it inherits every permission you have, not just the ones the app needed. A budgeting tool that only requires read access to one checking account is logging in with credentials that could also initiate transfers, view statements from every account, and change your contact details.
Multi-factor authentication complicates this rather than preventing it. Aggregators handle it by prompting you to relay a one-time code during setup and then keeping the resulting session alive for as long as possible, or by having you register the aggregator's access as a trusted device.
A single aggregator with credential-based connections holds working logins for millions of bank accounts across thousands of institutions. Nothing about the model limits the blast radius of one breach at that company to one bank.
Mechanism two: tokenized API access
The alternative works the way OAuth-style delegated access works elsewhere. You are redirected to your bank's real domain, you authenticate there, and you approve a specific, scoped request. The bank issues a token to the aggregator. The token grants read access to the accounts you selected, nothing more, and you can revoke it from your bank's own settings page without changing your password.
Four things change. The aggregator never learns your password. The bank knows a third party is connected and which one. Scope gets enforced by the bank instead of promised by the app. And revocation becomes a button you can press yourself.
| Property | Credential sharing | Tokenized API |
|---|---|---|
| Third party learns your password | Yes | No |
| Access limited to selected accounts | No, full account access | Yes, scoped at the bank |
| Bank can see who is connected | Only by heuristics | Yes, by identity |
| You can revoke without a password change | No | Yes |
| Breach of the intermediary exposes | Reusable credentials | Revocable tokens and cached data |
Why the old method persists
Tokenized access requires the bank to build and maintain an API, publish it, and register third parties. Many smaller institutions have not. Aggregators support them by scraping, because coverage sells: an app that connects to eleven thousand institutions beats one that connects to four hundred.
Regulators have been pushing the other way for a decade, with uneven results. In the EU, the second Payment Services Directive required banks to expose dedicated interfaces for licensed account information and payment initiation providers, and tied access to strong customer authentication. In the UK, a 2017 competition order forced the nine largest banks onto a common API standard. In the US, the Consumer Financial Protection Bureau finalised its personal financial data rights rule under Section 1033 of Dodd-Frank in October 2024, requiring covered institutions to provide API access and moving away from credential sharing. Bank trade groups sued almost immediately, and the resulting litigation and reconsideration have left the compliance timeline unsettled. Industry work under the Financial Data Exchange standard has continued regardless, since the technical direction is not seriously disputed even where the mandate is.
The part that survives either mechanism
Both methods end with a copy of your transaction history sitting on someone else's servers. Tokenization fixes the credential problem. It does not answer the questions that follow.
Your transaction history is among the most revealing datasets that exists about you. It contains where you live and where you travel, your employer and salary rhythm, your medical providers, your pharmacy, your lawyer, your church or political donations, whether you use a fertility clinic, whether your income dropped. Researchers have shown repeatedly that even coarse financial records are trivially re-identifying. This is data of the kind data brokers assemble by inference, available here as a direct feed.
So the questions worth asking about an aggregator are the ones about secondary use. Is the data used only to serve the connection you approved, or also to build analytics products sold to lenders, insurers and marketers? How long is it retained after you disconnect? Is it shared with corporate affiliates? In 2022 a major US aggregator finalised a $58 million class-action settlement over allegations that it collected more data than the apps using it required and obtained credentials through interfaces that resembled the banks' own. The company denied wrongdoing. The settlement did not resolve the underlying question of how much a middleman should see.
What to actually do
- Check which mechanism you are on. If the connection flow keeps you inside the app and asks for your banking password directly, it is credential sharing. If it redirects you to your bank's own domain with a valid certificate and returns you afterwards, it is tokenized. The redirect is the tell.
- Audit connections from the bank's side, not the app's. Most banks now list connected third parties under security or privacy settings. That list is authoritative in a way an app's own list is not.
- Disconnect what you no longer use. Aggregator connections outlive the app that created them. A tax tool you used once in 2023 may still be pulling data weekly.
- Prefer a separate account for connections. If an app only needs to see spending, connect a checking account you use for spending, not the one holding savings.
- Treat your banking password as unrecoverable if you shared it. Change it, and make sure it was never reused anywhere, since credential stuffing turns one exposure into many.
The wider point generalises past banking. Any time a service offers to connect to another service on your behalf, the question worth asking is whether it holds delegated, scoped, revocable authority, or whether it is simply logging in as you. Both arrangements are presented with the same friendly button, and only one of them lets you take the access back without changing a password.