# What does ‘bank-level encryption’ mean in a finance app?

> Understand AES-256-GCM, authenticated encryption, per-user data keys, envelope encryption, protected-field coverage, and the limits every finance app should disclose.

- Canonical URL: https://www.worthi.app/guides/what-bank-level-encryption-means
- Author: Vlad Poncea
- Published: July 15, 2026
- Last reviewed: July 15, 2026

## Short answer

Evaluate a finance app by asking what is encrypted, where encryption happens, which algorithm and mode are used, how keys are separated and rotated, who can decrypt the records, and which threats remain. AES-256-GCM with context-bound authenticated data and per-user data keys can protect sensitive fields before database storage, but it does not make a server-decryptable application zero-knowledge or immune to compromised sessions, applications, devices, or key infrastructure.

## Threat model at a glance

| Scenario | What field encryption does | What still matters |
| --- | --- | --- |
| Database-only exposure | Protected fields remain ciphertext without the required keys | Key separation, backups, and incident response |
| Changed ciphertext | Authentication should fail instead of returning silently altered plaintext | Error handling, monitoring, and recovery |
| Ciphertext copied to another user or field | Context-bound authenticated data should reject it | Correct user scoping and authorization |
| Stolen signed-in session | Does not stop the application from serving data to a valid session | Session security and account recovery |
| Compromised application or wrapping key | May no longer protect data the running service can decrypt | Secret management, least privilege, and detection |
| Unencrypted operational fields | Provides no protection to fields outside the encrypted set | Data minimization and documented field coverage |

## ‘Bank-level’ is not enough information

The phrase does not tell a reader which fields are protected, whether encryption happens only at the storage layer, whether ciphertext is authenticated, how keys are separated, or whether the provider can decrypt records.

A useful statement names the algorithm, mode, key model, field coverage, trust boundary, and important limitations. It also distinguishes encryption from authentication, authorization, monitoring, backups, and device security.

## Separate encryption in transit, at rest, and in the application

HTTPS protects data while it moves between a device and the service. Storage or disk encryption protects the underlying storage media. Application-level field encryption transforms selected values before ordinary database storage.

These layers answer different threats and can be used together. Application-level encryption can keep selected fields unreadable in a database-only exposure, but the running application still needs a controlled way to decrypt them for an authorized user.

## AES-256-GCM provides confidentiality and authentication

AES identifies the block cipher, 256 identifies the key size, and GCM identifies an authenticated-encryption mode. NIST describes GCM as encrypting plaintext into ciphertext and generating an authentication tag over the ciphertext and additional authenticated data.

That tag matters because decryption should fail if the ciphertext, tag, or authenticated context changes. Secure use also requires a unique initialization vector for each value encrypted under the same key. An algorithm name without nonce handling, key management, or authenticated context is incomplete.

## Ask exactly which fields are encrypted

A database can contain encrypted personal descriptions beside plaintext identifiers, timestamps, amounts, flags, or shared reference data. Saying “data is encrypted” can therefore overstate the actual coverage.

worthi currently encrypts sensitive strings including:

- Account names, institutions, and notes.
- Transaction merchants, descriptions, and notes.
- Recurring-rule names, payees, and notes.
- Asset names, notes, and valuation notes.
- Holding symbols, names, and exchanges.
- Financial-history breakdown labels.

Numeric balances, totals, currencies, operational identifiers, and other fields are not all covered by this application-level field-encryption set.

## Per-user data keys create useful separation

A data encryption key, or DEK, encrypts the protected fields. Assigning a distinct DEK to each user means an individual DEK is not reused across the entire user population.

This can reduce the scope of one DEK compromise, but it does not remove shared dependencies. The application, authorization layer, database access, and wrapping-key infrastructure still require protection. Per-user keys are one containment layer, not proof that no common secret or service can affect multiple users.

## Envelope encryption wraps each user data key

Storing a plaintext DEK beside encrypted fields would undermine the design. Envelope encryption instead encrypts each user DEK with a separate key encryption key, or KEK, and stores the wrapped result.

worthi stores a wrapped DEK for each user and supplies the master wrapping key separately from the database and source control. That master key remains a critical shared secret: compromising it together with the required data and application access can affect more than one user. Key storage, access control, rotation, backup, and recovery are therefore part of the security model.

## Bind ciphertext to the correct context

GCM can authenticate additional context without placing it inside the encrypted plaintext. worthi binds encrypted fields to metadata containing the user identifier, model, field, and encryption version.

Ciphertext copied into another field, model, or user context should therefore fail authentication. The versioned envelope records the algorithm, key identifier, initialization vector, authentication tag, and ciphertext needed to interpret the stored value.

## Server-decryptable encryption is not zero-knowledge

In a zero-knowledge or end-to-end encrypted vault, the provider is designed not to possess the material needed to decrypt user content. That can create a different trust boundary, but it complicates account recovery, server-rendered views, scheduled processing, and cross-device access.

worthi is not a zero-knowledge vault. Its server decrypts protected fields to operate the authenticated dashboard and official mobile product. Application-level encryption protects ordinary storage and adds contextual integrity; it does not prevent the authorized running service from accessing plaintext.

## What field encryption does not solve

Field encryption does not replace user authorization, secure sessions, least-privilege database access, secret management, dependency updates, monitoring, backups, incident response, or a protected endpoint device.

A valid stolen session may still request decrypted records. A compromised running application or wrapping-key environment may access data the service is designed to decrypt. Encryption narrows some exposures; it does not make an online product impossible to breach.

## Questions to ask any finance app

- Which fields are encrypted before database storage?
- Does authenticated context bind ciphertext to the correct user and field?
- Are data keys separated per user, and how are they wrapped?
- Can the provider decrypt records during normal operation?
- How can a user export or delete data?
- Which threats are explicitly outside the encryption model?

Also ask whether bank credentials or ongoing institution access are required. Avoiding bank linking removes one data-access path, but it does not automatically make cloud storage zero-knowledge, offline, anonymous, or perfectly secure.

## Where worthi lands

worthi uses HTTPS in transit and application-level AES-256-GCM envelope encryption for its documented sensitive finance fields. Each user has a separate DEK; the database stores a wrapped version; and encrypted values use unique initialization vectors plus authenticated context tied to the user, model, field, and version.

The product does not require bank, brokerage, or card login credentials. It remains authenticated cloud software whose server can decrypt protected fields for authorized product operation. Exports are currently handled through support rather than a self-service download, and no online service can be guaranteed perfectly secure.

## Sources

- [Recommendation for Block Cipher Modes of Operation: GCM and GMAC](https://csrc.nist.gov/pubs/sp/800/38/d/final), National Institute of Standards and Technology.
- [Recommendation for Key Management: Part 1 — General](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), National Institute of Standards and Technology.
- [Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), OWASP Foundation.

## Important limitation

This guide explains worthi's documented implementation and general cryptographic concepts. It is not an independent security audit, penetration test, certification, or guarantee that any online service is perfectly secure.

## Related documentation

- [worthi security](https://www.worthi.app/security/index.html.md)
- [Track net worth without linking bank accounts](https://www.worthi.app/guides/track-net-worth-without-linking-bank-accounts/index.html.md)
- [Private finance dashboard](https://www.worthi.app/private-finance-dashboard/index.html.md)
- [Manual net worth tracker](https://www.worthi.app/manual-net-worth-tracker/index.html.md)
- [worthi privacy policy](https://www.worthi.app/privacy/index.html.md)