The short version
Ekatra never asks for your netbanking password or an OTP, and has no mechanism to use one. Statements are parsed in-flight and the raw file is discarded. The optional Gmail grant is read-only, limited to financial senders you pick, and revocable in one tap. You can export everything, and delete means delete.
Ekatra never asks for bank credentials
Most of the risk in personal finance apps comes from one practice: screen scraping, where you hand over your netbanking username and password so the app can log in as you. That gives the app — and anyone who breaches it — the ability to move money.
Ekatra does not do this. There is no field for a netbanking password anywhere in the product, and no code path that would use one. You sign in with Google. Your bank login stays with your bank.
What happens to a statement you upload
When you upload a PDF, CSV or Excel statement, it goes through a short pipeline: text extraction, then an AI pass that classifies the document and pulls out structured rows, then a mapping step that files those rows into your accounts.
The raw file is never written to disk or object storage. It exists in memory for the duration of the job and is discarded. What persists is only the extracted data: account names, transaction rows, holdings, policy or loan details — the same information you would have typed in by hand.
| What | Stored? | Notes |
|---|---|---|
| The statement file itself | No | Parsed in-flight, then discarded. |
| Extracted rows | Yes | Accounts, transactions, holdings, loans, policies — your data, in your account. |
| A content fingerprint | Yes | A SHA-256 hash, so re-uploading the same file updates instead of duplicating. |
| Netbanking credentials | Never collected | No field, no code path. |
| PDF password you enter | No | Used once to open the document, never persisted. |
The Gmail import, precisely
Connecting Gmail is optional — the product works fully without it. If you do connect it, the grant is read-only, and the search is deliberately narrow:
- Only senders you choose. Before the first scan you pick which institutions may be searched, from a published catalogue of roughly ninety banks, card issuers, insurers and investment platforms. An institution you did not pick is never queried — not merely filtered out of the results afterwards.
- No keyword snooping. The search matches on sender domain only. There is no subject-line or body-keyword matching, so a personal email can never enter the result set.
- Last six months, incoming mail only — sent mail and drafts are excluded.
- A scan opens nothing. It reads message metadata and attachment descriptors. No attachment is downloaded until you approve the import.
- Bytes are read once. At import, the attachment is fetched, parsed and discarded — same as an upload.
- The refresh token is encrypted with AES-256-GCM at rest, and disconnecting revokes it with Google.
The in-app "How email import works" sheet states these same guarantees, and every line in it is mapped to the backend function that enforces it. If a claim on this page and the code ever disagree, the code is the bug.
Account Aggregator vs screen scraping vs statements
Three different things that get talked about interchangeably. They are not the same:
| Method | Needs your bank password? | How it works |
|---|---|---|
| Screen scraping | Yes | The app logs in as you and reads the page. Highest risk; Ekatra does not use it. |
| Account Aggregator (AA) | No | An RBI-regulated consent framework. A licensed entity fetches data over APIs with your explicit, revocable consent. Participation requires regulatory licensing — this is on Ekatra's roadmap, not shipped. |
| Statements & read-only email | No | You supply a document you already have, or grant read-only access to statement mail from senders you pick. This is what Ekatra uses today. |
We would rather say plainly what we are than imply a licence we do not hold: Ekatra is not an Account Aggregator and is not RBI-regulated. It is a tool that reads documents you give it. The roadmap is candid about what comes next.
What the AI sees — and how to turn it off
Parsing a statement and answering a question in chat both involve sending data to a language model. For parsing, that is the extracted document text. For chat, it is a JSON summary of your accounts, cards, loans, goals and recent months, so the answers are grounded in your actual numbers rather than guesses.
If you would rather the AI never read your data, there is a single switch — Pause AI — in settings. With it on, chat returns a fixed message instead of calling any model.
Export and delete
Export: one tap streams every record you own as a JSON file — accounts, transactions, holdings, budgets, splits, all of it. No support ticket, no waiting period.
Delete: deleting your account wipes every financial row in every collection. What remains is a minimal tombstone — your email and name — so the address cannot be silently re-registered; identity fields are stripped, and a fresh sign-up starts clean. Any connected Gmail grant is revoked as part of the same operation.
Where we are not yet strong
A security page that only lists strengths is marketing. Ekatra is early, built by a very small team, and it is worth being clear about the limits:
- Ekatra has not undergone an independent third-party security audit or penetration test. That is a real gap, and an honest one to state.
- It is not an RBI-regulated entity, and holds no financial licence. It reads documents; it does not touch or move money.
- Statement parsing depends on an AI model reading a document correctly. It can misread. Every imported row is editable, and you should sanity-check the numbers that matter.
If you find a security issue, please report it — mail sohan.28sarma@gmail.com and it will be read by the person who wrote the code.
Try it without connecting anything
Explore the whole product with realistic sample data — no sign-in, no upload, no email access.
Explore with sample data →