How PopaDex Encrypts Your Financial Data
What PopaDex encrypts in your browser, what the server processes, and how passwords and recovery affect protection.
PopaDex uses browser-side encryption for account names, balances and financial-record amounts in its encryption-enabled forms. Encryption is part of the account setup and sign-in flows; it is not a separate product you need to create or purchase.
This page describes the web application’s implementation reviewed on 12 September 2026. Availability depends on account setup and the application’s rollout settings. It does not establish that every existing account or imported record has been encrypted.
What is encrypted?
| Data or feature | How it is handled |
|---|---|
| Account names and current balances entered through encryption-enabled account forms | Encrypted in the browser before submission, using AES-256-GCM. |
| Financial-record amounts saved through encryption-enabled flows | Encrypted in the browser, with a separate encryption context from the account balance. |
| Account type, currency, record dates, identifiers and other operational metadata | Available to the server; these are not all covered by browser-side encryption. |
| Sign-in, subscription and billing information | Processed by the application and the services needed to operate your account. |
| Connected-bank data | Retrieved and processed by server-side integrations. Some provider fields and tokens use server-managed encryption, which the server can decrypt. |
| Accounts where encryption setup has not completed, and older data awaiting conversion | May contain server-readable financial values. Signing in alone does not prove that existing records have been converted. |
The app also supports sharing selected accounts with a partner. Shared access deliberately allows the recipient to read the shared information. Browser encryption does not prevent an authorized recipient from copying it.
How setup works
For eligible accounts, the web app attempts encryption setup during onboarding or sign-in. It generates a data-encryption key in the browser and stores a wrapped, encrypted copy of that key. In password-based setup, your password is used to derive the key that protects this copy.
Existing accounts can have data that still needs conversion. If the app shows an encryption setup or conversion prompt, complete it and check that your saved values display correctly afterward. An encryption-enabled account and a fully converted history are different things.
What the protection does—and its current limits
Encrypting a field before submission means its saved value is ciphertext rather than the readable name or amount. This reduces exposure of those fields in stored records.
The current web implementation does not support a blanket zero-knowledge guarantee. Passwords are sent to the server for account authentication, and the web app temporarily caches passwords in browser storage. The recovery-code display also sends the generated recovery code to the application server. These flows mean we cannot claim that passwords and recovery material never reach the server, or that only you could ever obtain access to the decryption keys.
Encryption also does not protect information already visible on an unlocked device, downloaded exports, or data read by malicious browser code. We do not promise that all financial data would remain confidential after a server or device compromise.
See the technical implementation for the key handling and storage details.
Passwords and recovery
Save the recovery code shown during setup in a password manager or another private backup. Account sign-in recovery codes and financial-data recovery codes serve different purposes.
Changing a known password is designed to update the protection around the existing encryption key. A forgotten-password reset can restore sign-in without restoring access to encrypted values. Local checks found defects in the current password-based recovery implementation. Do not rely on a recovery code alone to preserve access: keep any working device session and contact support before resetting a forgotten password.
Read password reset and recovery before resetting a password if you have encrypted financial data. Do not send passwords or recovery codes to support.
Session and device safety
PopaDex has both server and browser session controls, with different timeout paths. Locking the encryption session releases the active key reference while keeping its wrapped copy available for a later unlock. It is not a guarantee that all previously displayed data or browser storage has been erased.
Use your device’s screen lock when stepping away and sign out when finished on a shared device. See session locking.
Hosting and privacy
Encryption and server location are separate properties. This encryption guide does not verify a hosting country or make a Swiss-hosting claim. See the privacy policy for the published data-processing terms; ask support for current hosting details if data location matters to you.