Sealed, not just stored.
You are handing us the portal credentials for every account your close depends on, so a diligence reviewer deserves specifics instead of a stock photo of a padlock. Here is how the data is protected, including the part most vendors skip: what we can see, and what we never do with it.
Statements and CSVs
sealed under your key
Portal credentials
unsealed in memory only
Session snapshots
open with your passphrase, nothing else
Encrypted on the way, encrypted where it lands
In flight
Every connection travels through an encrypted tunnel: the browser to us, and us to the institution's portal. Anyone listening on the network hears static, which is the polite word for nothing.
At rest
Statements, CSVs, and credentials are encrypted before they ever touch a disk, and each customer's files are sealed under that customer's own key. A stolen hard drive would be a very boring prize.
One key per customer. Yours is yours.
Every customer gets their own encryption key, held in a hardened vault. Your statements, CSVs, and portal credentials are sealed under your key, not one big company key. Only your signed-in account can download your files; staff accounts have no download path around that.
Portal passwords get one extra rule on top: they are unsealed only in memory, for the few seconds a sign-in actually takes, and are never stored readable anywhere. The automation doing the sign-in holds narrower vault permissions than the web app, so even our own robot cannot go rummaging.
The honest part
We can briefly open your statements on our servers. Converting PDFs into spreadsheets is literally the job; software that could not read your statement could not convert it. Plenty of companies bury that sentence. We would rather print it.
What we never do: sell your data, share it, or let staff browse it. Every staff action is permission-gated and logged.
A lock even we cannot pick
Sometimes the robot keeps snapshots, pictures of what it saw while fetching your statements, so you can see exactly what happened on your behalf. Those pictures can show real account screens, so they answer to one thing only: a passphrase you set.
You set a passphrase
It lives in your browser and never leaves it. We do not receive it, store it, or have a way to guess it. It is yours in the fullest sense.
Snapshots are sealed to it
When the robot takes a snapshot, it is encrypted on the spot to a key that only your passphrase can open. We can take the picture. We cannot look at it.
There is no back door
No master key, no recovery desk, no quiet exception for admins. Forget the passphrase and past snapshots are gone for everyone, on purpose. Your statements and your account are unaffected; they use different keys.
If you do reset the passphrase, a fresh key is created and we tell you, in plain numbers, how many old items just got sealed forever. We think a lock you can genuinely lose the key to is worth more than a lock with a spare under the mat.
Letting support in, on your terms
Sometimes you want a support engineer to look at one snapshot to figure out what went wrong. That is possible, but only through a grant that you create, you scope, and you can end.
01
You grant
You pick one snapshot and one reviewer. Your browser re-encrypts that single image to that single person. Nothing else opens.
02
They see one item
The grant covers exactly what you shared. Not your account, not your other snapshots, not your statements.
03
The clock runs
You chose the window when you granted it: 24 hours, 3 days, 7 days, or 30 days. No open-ended access exists.
04
It ends
The grant expires on schedule, or the instant you revoke it. Revoking takes one click and takes effect immediately.
Every grant, every revoke, and every view lands in an append-only audit log: the kind of record that can be added to but never quietly edited.
Three more rules the robot lives by
It cannot spend
A payment guard blocks any money-moving request at the browser level while our automation is signed in. We fetch paperwork. We cannot pay bills, move money, or change your settings, even by accident.
It masks before it looks
Sensitive fields are pixel-masked before a snapshot is even taken. If masking fails for any reason, no snapshot is taken at all.
It fails honestly
When a download does not happen, we tell you it did not happen. No silent skips, no optimistic checkmarks over missing files.
Found something? Tell us.
If you believe you have found a vulnerability in StatementKeep, write to security@statementkeep.com with the details and, if you have them, the steps to reproduce. A person reads that inbox and will acknowledge you.
Please report privately and give us a chance to fix it before you publish. Do not test against another customer’s data or against a bank portal; if you need an account to work against, ask us for one.
For vendor diligence
Security questionnaires, architecture questions, and data processing details go to the same address. We answer them in writing, and we would rather answer twenty than have you guess.
We are not SOC 2 certified. When that changes, this page will say so, with the report type and date, and not before.
For the technically curious
Per-customer keys live in a hardened secrets vault; statements, CSVs, and credentials are envelope-encrypted so each customer’s material is cryptographically separate. The fetch worker operates under narrower vault permissions than the web application.
Snapshot encryption: your passphrase derives a key inside the browser, which wraps an X25519 keypair; each snapshot is sealed in an AES-256-GCM envelope to the public half. A support grant re-encrypts one item’s envelope key to the reviewer’s key with an embedded expiry.
Every grant, revoke, and view event is recorded in an append-only audit log: entries can be added, never edited or removed.
Paranoia, professionally applied.
Connect an account and let the robot fetch the statements your close ties to. It cannot spend a cent, and it works under your key.