How Tally handles your data

Tally has no central service and no shared database across installations. Every instance is operated independently by whoever deployed it, on infrastructure and a database they control. That operator, not the authors of this software, is the party responsible for the data an instance stores.

If you are using an instance someone else operates, the operator of that instance is who this policy should identify. Operators publishing their own policy should replace the placeholders below with their own contact details and fill in anything specific to how they run their deployment.

An instance stores, in its own Postgres database, only what's needed to run the application:

• Your account email and a bcrypt hash of your password. The password itself is never stored.
• Data from any financial institution you connect through Plaid: account and balance information, transactions, investment holdings, and credit liabilities, exactly as Plaid returns them.
• Data you create directly: budgets, categorization rules, and category assignments.
• An encrypted Plaid access token per connected institution, used to fetch the data above. It is never exposed by any API response.

Data is used only to render the application's own features for your account: net worth, transaction history, budgets, recurring-payment detection, and investment and liability views. Every query is scoped to the signed-in user. There is no cross-account aggregation, no advertising, and no resale of data to any third party.

Connecting a financial institution is handled by Plaid, which is necessary to retrieve data from your bank, card issuer, or brokerage. Plaid's own privacy policy governs what Plaid itself collects and how it's used; connecting an account means you're also subject to Plaid's terms for that connection.

Beyond Plaid, the application makes no calls to third-party analytics, tracking, or advertising services, and sends no financial data to a third-party AI or LLM provider.

Passwords are hashed with bcrypt and never stored or logged in plaintext. Each Plaid access token is encrypted at rest with AES-256-GCM under a key the operator controls (MASTER_KEY) and is decrypted only at the moment it's needed to call Plaid's API.

Beyond that, security depends on how an operator runs their instance: whether the database and backups are encrypted, whether the deployment is served over HTTPS, and how access to the underlying infrastructure is controlled. None of that is enforced by the application itself.

Signing in sets a single session cookie containing a signed JSON Web Token, used only to keep you signed in. No tracking, advertising, or third-party cookies are set by the application.

Data persists until it is explicitly deleted. Disconnecting a financial institution removes that institution's access token and all of its locally stored accounts, transactions, and holdings.

The account settings page also offers a full data wipe, which disconnects every connected institution and deletes all financial data for your account. It does not delete the account login itself; removing that requires direct access to the database, since the application doesn't expose that action in its own UI.

You can disconnect any institution or wipe your account's financial data at any time from Settings. Because each instance is self-hosted, requests beyond what the application exposes directly (such as deleting the account login itself) should go to the operator identified above.

This document describes the software's default behavior as of the version an instance is running. An operator who modifies the application, adds integrations, or changes how data is handled should update this page to match, since it stops being accurate the moment the software's actual behavior changes.