How PopaDex Encrypts Your Financial Data
What PopaDex encrypts in your browser, what the server processes, and how passwords and recovery affect protection.
PopaDex encrypts selected account names, balances and financial-record amounts in your browser when encryption setup is complete and the relevant flow supports it. This reduces exposure of those saved values. Account identity, linked metadata, bank processing, billing, sharing, support, measurement and some integration records remain server-readable. Password and recovery handling also limits protection against server access. Older or imported records may still need conversion.
Covered financial fields are encrypted on your device; all personal information is not E2EE. Email, billing and operational metadata have separate server-side handling. Credential separation and recovery safeguards are deployed in server release 6569bba1, validated by browser tests and isolated physical iPhone journeys on 8 October 2026. Account enrollment remains controlled; this is not a verification of every production account or historical record.
What is encrypted?
| Data or feature | Verified handling |
|---|---|
| Account names and current balances in eligible browser forms | AES-256-GCM encryption before submission, after encryption setup and unlock. Other entry paths and older values can remain readable. |
| Financial-record amounts in eligible browser forms | Browser encryption; a separate Rails encryption layer uses server-held keys. A numeric legacy amount remains readable by the server. |
| Email and some support content | Reversible encryption with server-held keys. Email is deterministically encrypted for lookup; it is not anonymous. Pending email changes and some contact copies lack this protection. |
| Account types, currencies, dates, source, identifiers and other linked metadata | Server-readable personal information. Operational use does not make it non-personal or establish that server access is unavoidable. |
| Connected-bank data and credentials | Automatic sync requires provider and temporary backend access in the current architecture. A pending-import client encrypts supplied names/balances after vault unlock. The enabled-vault Plaid import blanks stored numeric balances, but retains readable provider names and currently passes an empty pending balance. Selected credentials use server-managed encryption; some duplicate tokens remain readable. |
| Public Reports client forms and Sankey chart builder | Can be used without signing in and are separate from the private portfolio vault. Submitted Reports and saved chart information is server-readable; signed-in chart saves can be linked to the user. Result/share links disclose information to their holders. |
| Billing, support and analytics | Have separate server and third-party processing. They are not covered by financial-field browser encryption. |
Bank information reaches the provider and backend before the browser can encrypt it. That temporary access is an operational exception for the implemented automatic connection. Later browser encryption protects the resulting covered account value; it does not establish that every provider copy or log has been removed or encrypted. The import and retained-copy details are recorded in the technical documentation.
Public tools do not use a signed-in portfolio’s encryption key. They have their own processing and sharing scope. Being available without login does not make submitted names, contact details or financial information anonymous.
Read the field inventory and explicit exceptions table for fields, recipients, current controls and required minimisation. It distinguishes necessary functions from implementation gaps; a listed exception is not an approval to retain unnecessary data.
The sharing workflow controls selected account access, but cross-partner key exchange and decryption have not been established by the available implementation or tests. An authorised recipient may copy information they can read. Do not treat a sharing permission or an encryption-enabled flag as proof of end-to-end protection.
How setup works
Password-based signup and sign-in can initialise a browser-generated data-encryption key (DEK). The server stores its encrypted wrapper, salt and derivation parameters. Enrolled version 1 accounts locally derive independent authentication and financial-wrapping secrets from the entered password. Rails receives only the authentication credential, which cannot directly unwrap the financial key. Existing accounts retain their legacy password submission until explicitly migrated. Eligibility depends on rollout configuration; initialisation does not convert all existing data automatically.
OAuth users have additional vault-password and native iOS Keychain paths with different device and recovery requirements. Browser reloads and navigation use opaque device wrappers with non-extractable keys in IndexedDB; the native app retains its user-scoped Keychain bridge. Readable password caches have been removed. Native random-Keychain vaults do not automatically gain the password account’s recovery path. See the technical key trace.
Existing accounts can still contain readable names and amounts after initialisation. Conversion must cover each record and every duplicate, including provider copies. A successful new-account check does not prove that historical data has been converted.
What the protection does—and its current limits
Browser encryption saves ciphertext instead of a readable covered value. In a database-only exposure, correctly encrypted values require their decryption key or a way to recover it. Password strength, stored derivation settings, server-held encryption keys, unconverted values and other readable copies affect the protection available.
For enrolled version 1 accounts, the entered password, financial wrapping key and encryption recovery secret stay on the client in the intended flows. Changing login credentials alone cannot decrypt existing financial ciphertext. A login-only reset retains the old financial wrapper, so existing data still requires its original unlock or recovery material. Legacy password accounts continue sending the password to Rails until migration; a server obtaining that password can reproduce the legacy wrapping derivation. Migration cannot undo past secret exposure.
The authentication credential remains replayable for login, and password guessing remains possible. Logs, error reporting, provider copies and other server-readable records still require their own minimisation controls. Credential separation does not extend field coverage.
Encryption does not protect values visible on an unlocked device, plaintext downloads, or information read by malicious client code. Compromised application delivery can change JavaScript to capture secrets or plaintext. A non-extractable browser key restricts export but does not stop code from invoking decryption. There is no breach-proof guarantee.
Passwords and recovery
A login-reset token or account sign-in recovery code authorises authentication recovery. It does not itself derive the financial DEK. To read existing ciphertext, a device needs the original DEK, its original wrapping secret, a correctly paired financial recovery secret, or the applicable native Keychain key.
New setup wraps the same financial key for password and encryption recovery. Password changes and recovery verify the existing key before committing a replacement wrapper, with revision checks and atomic authentication updates. Tests verify that unchanged historical ciphertext decrypts afterward, including on a fresh client. Replacement recovery keys remain visible until the user acknowledges saving them, before native financial unlock proceeds.
Older recovery wrappers created from zeroed bytes are not repaired by deployment alone. Preserve the original unlock credential or a working device, and regenerate recovery material while the original key is accessible. Never send passwords, recovery codes or bank tokens to support.
Read password reset and financial-data recovery and recovery keys for the precise distinction and current limitations.
Session and device safety
Locking clears the manager’s active DEK reference while preserving its wrapped cache. Logout clears runtime keys, browser device wrappers and password scratch memory. Legacy native vaults can retain a primary Keychain key that is their only normal unlock path. These actions do not erase screenshots, downloads or every displayed value. Use your device screen lock and keep exports private. See session locking.
Hosting and privacy
PopaDex’s published operator information places the business in Switzerland. That is separate from server location, encryption and third-party processing. Repository deployment configuration identifies a Hetzner host and Cloudflare; it does not establish a datacentre country. Previous AWS Frankfurt and Swiss-hosting claims are unsupported by this configuration.
The privacy policy describes processing categories and unresolved retention details. The technical implementation records the evidence and required changes.
Design objective awaiting implementation
All personal information should be end-to-end encrypted except the minimum needed to operate the service. Each exception must be justified, minimised and protected; authentication email should be pseudonymised wherever its function permits. This is the design objective, not the current verified state. Protection must extend to linked metadata, imports, provider copies, sharing, integrations, logs and backups before broader claims are justified.