Where your data goes
The honest version of “bank-level security” is architecture, not adjectives. This page describes the actual data boundary, so you can verify the claim instead of trusting it.
Stays in your browser
- The PDF file and its bytes
- Rendered statement pages
- Every transaction row, description, date, amount, and balance
- Your corrections and flagged-cell decisions
- The generated CSV or Excel file and its file name
Reaches our servers
- Your account identity (managed by Clerk) and email address
- Credit balance and purchase history (Stripe payment references)
- Conversion metadata: a random conversion ID, bank and layout ID, parser version, page and row counts, verification status, flag counts, and a duration bucket
- Support messages you send us (we ask you never to attach statements)
How local processing actually works
When you choose a file, it is opened by PDF.js inside a Web Worker in your browser tab. Text extraction, bank detection, parsing, reconciliation, and CSV or Excel generation all run in that tab. The download comes from a blob created in memory on your machine. You can watch the network panel while converting: no request carries the document or anything derived from it.
When you pay for an export, the server checks your credits and issues a short-lived grant. What it receives in return is a completion event with the conversion ID, bank and layout ID, row and page counts, verification status, and timing bucket. It never receives rows, filenames, balances, or the exported file.
Statement state is held in memory only. It is cleared when you press clear, close or refresh the tab, sign out, or after 30 minutes of inactivity. Nothing statement-related is written to localStorage, IndexedDB, or cookies.
Application controls
- A strict Content Security Policy, HSTS, nosniff, and restrictive referrer and permissions policies on every response.
- Payments run on hosted Stripe Checkout; card details never touch this application.
- Every backend function requires a verified Clerk session; Stripe webhooks are signature-checked and replay-safe; credit grants are idempotent.
- The analytics event schema is an allowlist that cannot contain document content, and tests fail the build if a forbidden field name appears.
- No chat widget, session replay, or heatmap script runs on the converter or any signed-in page.
- Because statements never reach us, support staff have no statement viewer. We could not produce your document if asked; that is the point.
Related reading: privacy policy, accuracy methodology, and the guide on what a statement converter should store.