—Security
What actually protects this.
Not a badge wall. Here is how JOURNY is built, what that genuinely buys you, and where the limits are.
Last updated 11 August 2026. Written and maintained by Jagesh Pandey, who built JOURNY.
It never touches your bank
JOURNY has no connection to any bank, card or brokerage. It does not ask for net-banking credentials, it does not use an account aggregator, and it cannot move a rupee. Everything in it arrived because you typed it, spoke it, or imported a file yourself.
That is worth saying first because it removes the largest risk in this category entirely. There are no banking credentials here to steal.
The database refuses to mix people up
Every record carries the ID of the person it belongs to, and every table has a rule attached that only returns rows matching whoever is asking. This runs inside Postgres, underneath the application, so it holds even if the code above it has a bug. A query that tried to read someone else’s transactions would come back empty rather than successful.
There is also a database trigger that switches this protection on automatically for any new table, so a future feature cannot ship without it by accident. That is the part most likely to go wrong over time, so it was automated rather than trusted to memory.
Nothing on the server does maths on your money
This one is a deliberate architectural constraint, and it is unusual enough to be worth explaining. Every total, average, projection and insight is worked out on your own device. The server stores rows and returns them. It never computes over your balances.
The immediate benefit is that there is no system anywhere that reads your financial life in order to do its job. The longer-term one matters more: because no server logic depends on being able to read those columns, JOURNY can move to end-to-end encryption later without rewriting the product. Every data path already goes through a single seam built for that. It is not encrypted end-to-end today, and this page will not imply it is.
Analytics cannot receive an amount
If you allow analytics, JOURNY sends a short list of product events. Every single property passes through one function that keeps only what is on a small approved list, then throws it away again if the key reads like money, identity or free text. Amounts, balances, merchant names, notes, category names, account names and investment symbols can never get through.
The reason to trust that sentence is not that I wrote it here. It is that the rule is a unit test running against a realistic Indian transaction, so breaking it breaks the build. Automatic click capture and session recording, the two features most likely to photograph a screen full of rupee amounts, are both switched off.
Full detail is on the privacy page.
Your AI key stays in your browser
AI narration only runs if you supply your own Google Gemini key. That key is kept in your browser’s storage and is never sent to any server of mine. When narration runs, your browser calls Google directly, and it sends summaries rather than your ledger. Settings never displays more than the last four characters back to you.
The ordinary things, done properly
- Sign-in is handled by Supabase Auth. Passwords are hashed by them and JOURNY never sees one.
- Every product screen sits behind a session check. Signed out, there is nothing to look at.
- Changing your password requires proving you arrived from a real reset link, not merely having a session open. Someone at your unlocked laptop cannot silently take the account.
- The whole site is HTTPS with strict transport security, so browsers refuse to load it any other way.
- A content security policy limits what the page is allowed to load or talk to, which is the main defence against an injected script.
- The site cannot be embedded in a frame, which rules out clickjacking.
- Deleting your account runs a database function that can only ever name your own ID, and the removal happens by cascade rather than by a list someone maintains by hand.
Where the limits are
A security page that only lists strengths is marketing. These are the honest edges.
- Your data is not end-to-end encrypted yet. It is stored in ordinary database columns, isolated per person. The design keeps encryption available as a later change, and I would rather say that plainly than let the architecture imply more.
- JOURNY has not been independently audited or penetration tested, and holds no certification. It is an early product built by one person.
- Your device is part of the security model. JOURNY keeps a local copy so it works offline and opens fast, so anyone with your unlocked device can read it. A screen lock is worth having, and an app lock is on the roadmap.
- If you allow analytics, the two vendors involved do receive event names and a random account ID. Never an amount, but not nothing.
Found something?
If you have found a security problem, please write to hi@jageshpandey.com before telling anyone else, and give me a reasonable chance to fix it. I read every message and I would much rather hear it from you. There is no paid bug bounty, so I will not pretend there is, but I will credit you if you would like that.