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
Sign-in recordings
masked first; pictures sealed under your key
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 beyond the providers that help run the service, or let staff browse it. Staff see a sign-in recording only through a grant you create. 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.
Sign-in recordings: masked, sealed, and on a schedule
To learn how to sign in to an account for you, we ask you to sign in to it yourself, twice, in a secure browser, and we record each sign-in. Sign-in recordings are masked before they are saved, their pictures and page contents are encrypted under your own key, they are read only by the people and AI agents you or this policy allow, and they are deleted on the schedule below.
What is saved
For each screen, a recording holds a picture of the screen, a description of the buttons and boxes on it, a cleaned copy of the page’s code, and where you clicked.
For what you typed, it holds only how many characters you typed and how quickly, never the characters themselves.
Before anything is saved, every text box in every picture is blacked out, whether or not you typed in it, and so is any text with four or more digits in a row.
In the descriptions, every run of four or more digits is replaced with dots, and every email address is masked. In the page code, every run of four or more digits is replaced with dots, and the values of form fields and the contents of inline scripts are removed.
Who reads it
Three AI agents read recordings: a scout, an author and a supervisor, which together build and check the sign-in for your account. Each gets its own access to one account’s recordings for one run, and that access expires within 24 hours.
Our support staff cannot open a recording unless you give one named support person access, for one support ticket, for 24 hours at most. Being on staff opens nothing by itself.
On a team, admins who manage accounts can view recordings; read-only members see only small previews.
The automation that fetches your statements never reads a recording.
Every read of a recording is written to an access log.
Recordings are processed by our AI providers, with personal information masked first: what you typed is never recorded, and text boxes and long numbers are blacked out before a recording is saved. Only the masked version of a recording is ever sent. A picture can still show other things on the screen, such as your name on a welcome page.
How long we keep it
We keep the current recording for each account until you finish recording that account again, remove the account, or delete your StatementKeep account.
When you finish recording an account again, we delete the recording it replaces 30 days later.
A recording you start but do not finish is kept until you remove the account or delete your StatementKeep account.
When you delete your StatementKeep account, we delete all of your recordings with it and destroy the encryption key that protected them.
We keep the access log for as long as you have your account, plus 1 year after you delete it, and then delete it. The log says who read a recording and when; it holds no pictures and nothing you typed.
The pictures, descriptions and page code in each recording are encrypted with that recording’s own key, and that key is locked with your account’s own encryption key in our secrets vault, so one customer’s recordings are cryptographically separate from another’s. Click positions and typing counts, which contain nothing you typed, are stored without that extra layer of encryption. Sign-in recordings are not the session snapshots described above. Snapshots stay sealed to your passphrase, and we cannot open them. Sign-in recordings are encrypted under your account’s key instead, so that the AI agents that build your sign-in can read them.
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.
Sign-in recordings: each recording’s pictures, descriptions and page code are sealed with AES-256-GCM under the recording’s own data key, wrapped by your per-customer key in the vault’s transit engine, which is destroyed when you delete your account; click coordinates and typing counts are stored in the database without that envelope. Agent and support access uses per-reader grants that expire within 24 hours, and every read lands in an append-only access log.
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.