Your bank credentials never reach us
Connections are made through Plaid. You authenticate with your institution inside Plaid’s interface; Plaid gives us an access token, not your username or password. That token is encrypted with AES-256-GCM using a key held only in our server environment before it is written to the database, and each ciphertext records which key encrypted it so keys can be rotated.
Encryption
- In transit: TLS 1.2 or higher everywhere, including between our services and our providers.
- At rest: database volumes and object storage are encrypted by our providers (AES-256). Plaid access tokens carry a second, application-level layer of encryption on top of that.
Accounts and sessions
- Passwords are hashed with argon2id at OWASP-recommended parameters. We cannot read them.
- Email verification is required before the first sign-in.
- Sessions are server-side records referenced by an HttpOnly, Secure, SameSite cookie. Signing out, resetting a password or changing it revokes sessions immediately; there is no client-side session cache to wait out.
- Optional two-factor authentication with an authenticator app (TOTP) and single-use backup codes, set up in Settings. Signing in with Google relies on your Google account’s own two-step verification.
- Sign-in, sign-up and password-reset endpoints are rate-limited per IP; the rest of the API has a global limit.
- Cross-site request forgery is blocked by origin checks on every state-changing request.
Receipts
- Files are checked and processed by our API on upload, then written to private object storage. Nothing is stored until the file type and size have been validated.
- The storage bucket is not publicly readable. Every file is served through our API only after we confirm you own the receipt.
- Photos have all embedded metadata stripped on upload, including GPS location, camera and device identifiers.
- Storage keys are random and unguessable.
Data isolation
Every record that belongs to a user carries that user’s identifier, and every database query is scoped by it at the data-access layer, not left to individual features to remember. Our automated test suite includes cases that attempt to read another user’s accounts, transactions and receipts and asserts they fail.
Logging and monitoring
- Security-relevant events (sign-ins, password changes, bank connections) are written to an audit log you can review.
- Application logs redact tokens, passwords, cookies and account numbers. A test asserts that a Plaid access token cannot appear in log output.
- We log request metadata and counts, never the contents of your transactions.
Engineering practice
- All code changes pass type checking, linting, automated tests and a dependency vulnerability audit before they can be merged.
- Dependencies are monitored and updated weekly.
- Secrets live only in the hosting platform’s secret store. None are in source control.
- Database migrations run as a controlled release step, never at application start.
- Backups are automated by our database provider with point-in-time recovery.
Infrastructure
API: Fly.io. Database: Neon (managed PostgreSQL). File storage: Cloudflare R2. Web app: Vercel. Bank connectivity: Plaid. Each provider maintains its own SOC 2 or equivalent program; their reports are available from them directly.
Governance
Everykept is operated by TiqyTech Inc., a Canadian corporation run by a single person, who is accountable for security and reachable at security@everykept.com. A written information security policy covers roles, access control, cryptography, secure development, vulnerability management, logging, data retention and deletion, third parties, and incident response. It is reviewed at least every twelve months and after any incident, and every account that can reach production requires multi-factor authentication. The policy is kept in the source repository so its history is preserved; a copy is available on request.
Reporting a vulnerability
If you find a security issue, email security@everykept.com. We will acknowledge within two business days, keep you informed, and credit you if you wish. Please give us a reasonable time to fix the issue before disclosing it, do not access or modify other users’ data, and do not run denial-of-service tests. Good-faith research conducted under these rules will not lead to legal action from us.
Incidents
If a breach affects your personal information and creates a real risk of significant harm, we will notify you directly and report to the Office of the Privacy Commissioner of Canada as the law requires, and we will publish what happened and what changed.