What a Bank-Linked Budgeting App Actually Sees About You
When you connect your bank to a budgeting app, the data pulled in is much broader than the transactions on your dashboard. Here is what the aggregator actually receives, who else gets it, and how long it lives there.
When a budgeting app asks you to “connect your bank,” the screen that appears is almost always run by someone else. Plaid, Finicity, MX, or Yodlee handle the actual connection. You log in to your bank through their interface, agree to a permissions list that scrolls past in a few seconds, and return to the app with your transactions populated.
Most people read this as a transaction sync. It is not only a transaction sync. The data the aggregator pulls in that single moment is broader, lives longer, and reaches more parties than the dashboard suggests.
This post walks through what is actually shared in a typical bank link, who holds copies of that data, and why a local-first approach skips the entire question.
The permissions you accepted in three seconds
A standard Plaid Link flow asks for some combination of these scopes, depending on what the app requested:
- Transactions: All historical transactions the bank exposes, often 24 months of history, refreshed continuously
- Account and routing numbers: The full account number and routing number for each connected account
- Identity: Name, address, phone number, and email on file with the bank
- Balance: Real-time balance refreshes on demand
- Investments: Holdings, positions, and transaction history for brokerage accounts
- Liabilities: Loan terms, interest rates, and payment history
- Income: Calculated income streams derived from deposits
A budgeting app that needs only “transactions” sometimes still requests identity and balance because the SDK defaults include them. The consent screen lists the scopes, but the typography is small and the flow is designed to keep moving.
Once you tap Continue, the aggregator stores a long-lived access token tied to your bank credentials. That token is the thing that keeps your transactions syncing in the background. It is also the thing that quietly authorizes daily refreshes of every scope the app requested, not just the ones you actively use.
Who actually holds copies of the data
The data flow looks like a straight line from your bank to your app. It is not.
A successful bank link creates copies of your data in at least three places.
First, the aggregator itself. Plaid, Finicity, and the others maintain their own databases of transactions and identity information for every account they have linked. They use it to power their products, including credit decisioning, income verification, and fraud detection that are sold to other companies.
Second, the budgeting app. The app pulls transactions from the aggregator and stores them in its own backend so the dashboard can load quickly and run analytics.
Third, any subprocessors the app uses. Categorization vendors, analytics platforms, customer support tools, and increasingly language model providers all touch some portion of your transaction data. The privacy policy lists these, usually under “service providers.”
A single bank link, in other words, is a one-time consent that authorizes ongoing data flow into three or more independent systems. Revoking access in one place does not necessarily clear the data from the others.
How long the data lives
Aggregator retention policies are surprisingly long.
Plaid’s published policy retains transaction data for as long as the connection is active, plus a defined period after disconnection for legal and operational reasons. Finicity and MX are similar. The exact windows vary, but the practical answer is that a bank link you forgot about three years ago may still be associated with stored transaction history at the aggregator.
The budgeting app’s retention is governed by its own policy, which usually keeps your data for the lifetime of your account and some retention window after deletion. If the app is acquired or shuts down, that data goes wherever the wind-down agreement sends it.
The bank itself keeps the access token until you explicitly revoke it through the bank’s website, not the app. Many users never do this. Open your bank’s online portal and look for “linked apps” or “connected services.” You may find tokens for apps you stopped using years ago, still authorized to pull data on your behalf.
What the CFPB rule changes and what it does not
The CFPB finalized its Section 1033 rule on personal financial data rights in late 2024. The rule gives consumers stronger rights to access their own financial data and to authorize third parties to access it on their behalf. It also imposes restrictions on what aggregators can do with the data once they have it, including limits on secondary use for targeted advertising and on selling the data outright.
This is a meaningful improvement. It is not the same as the data not being shared.
The rule governs what happens after the data leaves your bank. It does not change the basic architecture: a bank-linked app still requires you to authorize an aggregator to pull your financial history into a system you do not control. The improvements are about constraint and accountability, not about removing the data flow.
For a privacy-minded user, the relevant question is not “is the aggregator allowed to misuse my data” but “do I want this data to leave my bank at all.”
The local-first alternative
A local-first budgeting app does not link to your bank. There is no aggregator in the path because there is no path out of your machine.
You enter transactions manually, import a CSV that you exported from your bank’s website, or use a one-way import that you trigger when you want it. Your bank credentials stay at your bank. Your transaction history stays in a file on your laptop. Aggregators, subprocessors, and forgotten access tokens are all problems that do not exist because the architecture never created them.
The trade-off is friction. Manual entry takes a few minutes a week. CSV imports require a download step. There is no real-time refresh because there is no continuous connection. For some users this is a deal-breaker. For others it is the entire point: the time spent entering transactions is also the time spent paying attention to where the money is going.
What to do if you have already linked your bank
If you want to reduce your exposure without abandoning your current app, three steps help.
Open your bank’s online portal and find the linked apps section. Revoke any tokens you do not actively need. This is the only step that actually stops the data flow.
In each budgeting app you use, check the privacy and data settings page for an option to delete stored historical data. Some apps offer this; many do not. If they do, use it.
Request data deletion from the aggregator directly. Plaid and Finicity both have consumer-facing portals where you can see what is stored under your bank credentials and request deletion. The deletion is not instant, but it is honored.
SelfCapsule’s approach
SelfCapsule has no bank connections, no aggregator, and no server-side copy of your transactions. You import a CSV when you want to, edit transactions when you need to, and the data lives in an encrypted file on your machine. There is no token to revoke, because there is no token in the first place.
If you want a budgeting app where the question “who has copies of my data” has a one-word answer, download SelfCapsule for Mac or Windows.
Related reading: