KOSHA is a read-only view of accounts you already have. It exists to show you one number that is true. This page says what it holds to do that, who else touches it, how long it stays, and how to take it back.
It covers the KOSHA application at kosha.money, operated by Srinivasarao Vassadi. Words like “we” mean that operator.
1. The short version
- KOSHA never sees a bank password. Linking runs through Plaid, which handles the credentials; KOSHA receives an access token and nothing else.
- It cannot move money. There is no transfer, no payment and no standing instruction anywhere in the product, and the access it holds is read-only.
- Your data is not for sale and is not shared for advertising. There is no advertising in KOSHA, no analytics, and no third-party tracker of any kind.
- You can take everything out or delete all of it, yourself, from the Connections screen, without asking anyone.
2. What KOSHA collects
To sign you in
- Your email address. It is the account identity and where sign-in links go.
- Your passkeys’ public keys and their signature counters. A public key is public by definition; there is no password to store, because KOSHA does not use one.
- Session records. A SHA-256 hash of the session token, when it was created, when it expires, when it was last active, and whether it is locked or revoked. Not the token itself, so a database leak yields no usable cookies — and no IP address and no user agent.
- Single-use email sign-in tokens and short-lived passkey challenges, both stored hashed or consumed and both deleted shortly after they expire.
From the institutions you link
When you link an account, KOSHA retrieves and stores, per account:
- the institution name, the account name, its type and subtype, and the last digits of the account number as the provider reports them;
- the current balance, the available balance and the credit limit, and a permanent dated history of every balance it has ever observed — that history is the product, and it is append-only by design;
- transactions: date, merchant, category, amount, currency, whether the charge is pending, and the payment method, together with the raw response from the provider.
Provider credentials. The access token that lets KOSHA read those accounts is encrypted with AES-256-GCM under a key held separately from the one that signs your session, and that key can be rotated without touching your data. It is never included in an export.
What you type in yourself
- Off-network holdings — property, gold, an informal loan in either direction — and their values, which are yours alone and which no provider ever sees.
- Loan terms: an interest rate and the period it was quoted for, an instalment, a repayment date, an origination date.
- Preferences: base currency, number format, and whether figures are hidden by default.
If you ask for access and are not yet a user
The request form records your name, email address, the region you bank in, and what you write in the free-text field. It is the only place KOSHA holds information about someone who is not a user, and it is deleted on a schedule — see §7.
Security records
KOSHA keeps an audit log of security-relevant events: signing in, revoking a session, linking or repairing a source, erasing data, and every time a stored provider credential is decrypted. Each row holds the action, what it was about (an account or connection identifier, or an institution name), an IP address, and the time.
It deliberately holds no amount, no email address and no token. A leaked audit log must not be a second copy of the data it exists to protect.
KOSHA also records the notifications Plaid sends it. Those payloads can contain balances, and they are deleted when you erase your data.
3. What KOSHA does not collect
- Bank usernames and passwords. They are entered into Plaid, never into KOSHA, and never reach our servers.
- No analytics and no trackers. No Google Analytics, no pixels, no session recording, no fingerprinting, no advertising identifiers, no third-party cookies. There are no third-party scripts on any page.
- No location, no contacts, no device inventory, and nothing from any other application on your device.
4. Cookies
KOSHA sets two cookies, both strictly necessary, both first-party:
kosha_session(__Host-kosha_sessionover HTTPS) — an opaque random token that is your signed-in session.kosha_privacy— remembers, for the length of the browser session only, whether you have hidden your figures on screen.
There is nothing here to consent to and therefore no consent banner: no cookie KOSHA sets is used for advertising, measurement or profiling.
5. Why KOSHA holds it
To show you your own money, and to keep the account that shows it to you secure. Concretely: to compute your net worth and its history, to categorise and display your transactions, to sign you in and keep you signed in, to detect and rate-limit abuse, to send you a sign-in link, and to meet legal obligations.
Your financial data is never used to train any machine-learning model, never used for advertising or profiling, never sold, and never shared for cross-context behavioural advertising as California defines that term. There is no secondary use. There is nobody else in the room.
6. Who else touches it
KOSHA runs on other companies’ infrastructure. Each of the following processes data on our instructions and for no purpose of its own:
- Plaid — connects your institutions and retrieves balances and transactions. Plaid collects your banking credentials directly, under its own agreement with you. See Plaid’s End User Privacy Policy.
- Neon — hosts the database.
- Vercel — hosts and serves the application.
- Resend — delivers sign-in links and access-request notifications. It handles your email address; it is sent no financial data.
- Upstash — counts rate limits, where configured. It holds request counts keyed by a hash, and no personal data.
Beyond these, KOSHA discloses data only where the law compels it, and only to the extent it compels. It does not sell personal information, and it has not sold or shared any in the preceding twelve months.
7. How long it stays
- Expired sessions, spent sign-in links and used passkey challenges are deleted within about 24 hours of becoming unusable.
- Access requests are deleted 30 days after they are approved or declined. A request still waiting for a decision is never deleted by that rule.
- Your accounts, balances, balance history and transactions are kept for as long as your account exists, because the history is the point — a net-worth line is only as long as the record behind it. They are deleted when you delete them.
- Audit records outlive the data they describe. When you erase your account, the audit rows are stripped of any link to you and kept — including the record that the erasure happened, which is the most important line a security log can carry.
8. Your choices, and how to exercise them
These are controls in the product, not requests to a support queue. All of them are on the Connections screen:
- Export everything. A JSON file of your accounts, balances, full snapshot history, transactions and connections. It excludes raw provider envelopes, which are plumbing, and stored credentials, which are bearer tokens for your bank.
- Disconnect a source. Consent is withdrawn at the provider and nothing is read again. Figures already recorded stay.
- Remove a source with its entire history. Revoked at the provider first, then erased here.
- Delete your whole account. Immediate and irreversible, with no grace period — a grace period would leave your data in a database you believe you have left. Export first if you want a copy.
- Sign out everywhere, which revokes every live session including the one you are using.
Depending on where you live — California, Colorado, Connecticut, Virginia, Utah, Texas and a growing list of other US states — you also have statutory rights to know what is held, to obtain a copy, to correct it, to delete it, and to appeal a refusal. The controls above satisfy most of these directly. For anything they do not cover, including correction and appeals, write to srinivas.vassadi@gmail.com. We will not discriminate against you for exercising any of them, and an authorised agent may act for you.
9. Security
Everything is served over HTTPS. Provider credentials are encrypted at rest under a key separate from the session-signing key. Sign-in uses passkeys, so there is no password to steal or reuse. Sessions live server-side and can be killed. The screen locks itself after fifteen idle minutes and asks for your passkey again. Every credential decryption is logged.
No system is perfectly secure, and this one is small and new. Report a vulnerability to srinivas.vassadi@gmail.com.
10. Where your data lives
In the United States. If that ever changes, this page changes first.
11. Children
KOSHA is not for anyone under 18 and is not directed to children. We do not knowingly collect data from them; if we learn we have, we delete it.
12. Changes to this policy
The date at the top moves when this page changes in substance. If a change materially affects what is held or who it reaches, you will be told by email before it takes effect — not by a quietly edited page.
13. Contact
Srinivasarao Vassadi
GA, USA
srinivas.vassadi@gmail.com
See also the Terms of Service.