Reading the labels: 11,000 words of app privacy
A privacy policy is less a promise than a map of permissions. The useful work is finding which roads the company has left open.
Read five things before linking an account: collection, recipients, purpose, retention, and deletion. In 11 policies totaling 11,084 words, all described broad data collection, 10 allowed service-provider sharing, five mentioned targeted-advertising data, and eight offered a visible deletion path. Length predicted almost nothing about clarity.
A nutrition label tells you what is inside the box. A privacy policy tells you what may happen after you open it, usually in sentences designed to survive every foreseeable business arrangement. Reading one requires less legal training than patience with the words “including,” “such as,” and “may.”
On August 4, 2026, we downloaded the current US privacy policies for 11 budgeting and financial-dashboard apps considered during our testing. We counted 11,084 body words after removing navigation, cookie banners, and regional duplicates. This was a reading exercise, not a security audit: a policy describes permission; it cannot prove technical practice.
1. What enters the basket
Every policy covered identifiers and usage information. Financial apps also described account balances, transactions, holdings, liabilities, and details supplied through an account aggregator. Device identifiers, IP address, browser type, approximate location, clicks, and session timing appeared repeatedly. “Information you provide” was never the full inventory.
Credentials require careful reading. Many budgeting apps rely on third-party aggregation and state that bank login credentials are handled by that provider, not stored directly by the app. That is meaningful architecture, but it does not make the remaining transaction history trivial. A year of merchant names can describe health, religion, travel, debt, and relationships without containing a password.
2. “Share” has more than one gate
Ten policies permitted disclosure to vendors or service providers for hosting, analytics, support, fraud prevention, communications, or account connection. This is ordinary modern software plumbing, yet scope matters. A processor helping deliver a requested feature is different from an advertising partner building an audience.
Do not search only for “sell.” State privacy laws sometimes define sale or sharing narrowly, while the policy separately authorizes disclosure for cross-context behavioral advertising, measurement, affiliates, or “business partners.” Five of the 11 policies discussed targeted-advertising data or an associated opt-out. The exact app names matter less than the reading habit because policies change.
| Label | Policies | Phrase worth searching | Question to ask |
|---|---|---|---|
| Financial and transaction data | 11 of 11 | “financial information” | Is raw history required for the feature? |
| Service-provider disclosure | 10 of 11 | “vendors” or “processors” | Are providers limited by contract and purpose? |
| Targeted advertising discussion | 5 of 11 | “cross-context” or “interest-based” | Is there a universal opt-out link? |
| Visible deletion route | 8 of 11 | “delete your account” | Does deletion include linked financial data? |
| Specific retention explanation | 4 of 11 | “retain” or “as long as” | What remains after account closure? |
| Plain-language summary | 3 of 11 | “at a glance” | Does the summary match the operative text? |
3. Purpose is the hinge
Collection alone cannot tell you whether a practice is proportionate. Transaction data is necessary to categorize spending. It is harder to justify for unrelated ad targeting. Look for a clean connection between each data type and the feature you requested. Broad phrases such as “improve our services” or “for other business purposes” preserve room rather than explain a boundary.
Our 2026 budgeting-app ranking gives privacy and support 5% of the score. That deliberately modest number avoids pretending a policy review can measure security, while still penalizing missing controls, obscure deletion, and unclear commercial incentives.
4. Retention is where deletion becomes conditional
Eight policies presented a discoverable deletion route, usually in account settings, a privacy portal, or an email request. Most also retained exceptions for legal compliance, security, fraud prevention, dispute resolution, backups, or deidentified data. Those exceptions can be legitimate; the quality question is whether they are specific enough to evaluate.
Only four policies offered a concrete retention explanation beyond keeping data “as long as necessary.” Even these generally used categories rather than exact periods. Before closing an account, export what you need, disconnect institutions, initiate deletion, and retain the confirmation. Then revoke any remaining aggregator connection through your bank if the bank provides that control.
5. The policy is not the whole garden
Security pages, state notices, cookie settings, aggregator terms, app-store disclosures, and in-product permissions may carry important details outside the main policy. A polished privacy summary can help, but the operative clauses still govern. A long document can be precise; a short one can omit the question you care about.
Compare this site’s deliberately narrow FundMeadow privacy note: because the site has no accounts, analytics, advertisements, cookies, forms, or financial connections, it has fewer data relationships to describe. An app performing aggregation cannot match that minimalism. It can still make its necessity, partners, controls, and exits legible.
A ten-minute reading method
Start with the effective date. Search for “collect,” “financial,” “share,” “advertising,” “retain,” “delete,” and “opt out.” Read the definitions those clauses depend on. Check whether regional rights apply to you, but do not mistake a rights section for the entire practice. Finally, ask whether the app’s benefit is worth the permission surface.
On August 5, 2026, we repeated the exercise on the shortest and longest policies without their brand headings. The longer document was not harder to score; it had clearer section names and concrete examples. Readability was an editorial decision, not a word count.
The label to carry with you
A good policy lets you trace a line: this data enters, for this feature, goes to these parties, remains for this reason, and leaves through this door. When one part of that sentence is missing, the correct response is not automatic panic. It is a more precise question before access is granted.
Frequently asked questions
Do budgeting apps sell financial data?
Policies rarely describe selling raw bank credentials, but some permit sharing identifiers, usage, and inferred interests for advertising or measurement. Read the app’s definitions, exceptions, state notice, and opt-out section rather than relying on the word “sell” alone.
Can you delete budgeting-app data?
Usually, but deletion may require an account request and can exclude records retained for security, legal, fraud-prevention, dispute, or backup purposes. Disconnect linked institutions, request deletion, save confirmation, and check the connection at your bank.
What privacy clause should you read first?
Begin with what is collected, then who receives it, why, how long it remains, and how to delete or opt out. Search terms make this possible in roughly ten minutes even when the document exceeds 10,000 words.
For a product-level example, our Empower review examines the commercial tradeoff behind a free dashboard.