Security & zero data retention — Jemsky bank statement converter

Jemsky is engineered with a strict zero-data-retention policy: statement transactions and account numbers are processed in memory and never stored in a database of ledgers.

Stateless in-memory processing

PDF statements are streamed into volatile RAM, extracted into structured transaction models, returned to you as Excel/CSV/Tally XML, and cleared. There is no ‘download history’ of client PDFs.

What the database actually stores

PostgreSQL holds authentication records (email, Argon2-hashed passwords, role, subscription metrics) and optional Tally party ledger names / mapping rules you save. It does not store bank balances, account numbers, or transaction particulars from converted statements.

TLS and session controls

Browser-to-server traffic uses TLS. HTTP Strict Transport Security, Content-Security-Policy, and X-Content-Type-Options are part of the production header set. Password unlock for locked PDFs is RAM-only and is not written to application logs.

Why this matters for CA firms

Client confidentiality and India’s DPDP Act make leftover statement archives on a vendor disk a policy problem. Jemsky’s product decision is parse-in-memory, verify, export, discard. Details of payments (Razorpay) are on the Privacy Policy — cards are not stored by Jemsky.

Related: Privacy Policy · User Guide · FAQ · Contact