Technical encryption overview

Your financial data is encrypted before it reaches the database.

Mizanek applies authenticated encryption to protected financial values inside the application service before persistence. The database stores ciphertext instead of readable protected amounts or financial details.

  • Application-level encryption
  • Per-household encryption keys
See how the data moves
IncomeProtected

Salary

12,345.67MAD
Frequency
Monthly
Next expected
25 September

From app to storage

Readable in your plan. Unreadable in database storage.

The Mizanek app can display the financial information you provide because the authorized service decrypts it when needed. The persistence layer receives encrypted values.

  1. Mizanek interface

    What the user sees

    IncomeSalary
    Expected amount12,345.67 MAD

    A readable product view for the authorized household member.

  2. Encrypted before persistence
  3. Authorized Mizanek service

    Authenticated encryption

    The value is encrypted and its intended context is authenticated before the database write.

    AES-256-GCM
  4. Ciphertext persisted
  5. Database

    What storage receives

    expectedAmountMinorEncrypted8f3a91…c14e

    No readable protected amount is stored

Application use and database storage are different boundaries: Mizanek can calculate your plan without keeping protected financial fields readable in the database.

Technical architecture

Authenticated, household-scoped field encryption.

The public design is intentionally described without keys, credentials, infrastructure identifiers or operational procedures.

  • 01

    Application-level boundary

    Protected financial values are encrypted in the persistence path before they are written to the database.

  • 02

    AES-256-GCM

    Authenticated encryption protects confidentiality and detects ciphertext or context modification.

  • 03

    A key for each household

    Each household has a separate data-encryption key, keeping cryptographic boundaries household-scoped.

  • 04

    Wrapped data keys

    Household data keys are stored only in wrapped form through the configured environment key-management layer.

  • 05

    Bound to its context

    Authenticated context ties a value to its household, entity type, record, field and key version.

  • 06

    Randomized ciphertext

    A fresh random initialization value means encrypting the same value twice does not produce the same ciphertext.

Protected financial fields

What this encryption covers.

Coverage follows Mizanek’s maintained protected-field registry rather than a broad claim that every database value is encrypted.

  • Income

    Income names, expected values and recorded actual values.

  • Bills

    Protected bill names, expected amounts and actual payment amounts.

  • Balances

    Current-account, cash, savings and period balance values.

  • Savings

    Savings names, balances, corrections and transfer values.

  • Plans and check-ins

    Flexible plans, remaining amounts, allocations, adjustments and financial check-in results.

  • Exceptional activity

    Protected names, amounts, notes and related financial values.

  • Financial history

    Protected close snapshots and month-end financial values.

  • Financial payloads

    Financial audit and idempotency payloads where the registry marks them as protected.

This claim applies to registered protected financial fields. It does not mean every field in every Mizanek database table is encrypted.

Public verification evidence

How can I know this is really encrypted?

The same information has a readable product representation and an encrypted persistence representation. The final schema removes the protected plaintext column instead of keeping a second readable copy.

Purpose-built illustration only. No user record, real identifier or customer ciphertext is shown.

What the user sees

Income

Salary

12,345.67 MAD
What the database stores
expectedAmountMinorEncrypted
8f3a91…c14e
nameEncrypted
b8402a…ff91
expectedAmountMinor
Not present in encrypted-only schema
name
Not present in encrypted-only schema

Encrypted-only protected storage

During migration both columns existed for verification. The final protected schema retains the encrypted column and removes its readable counterpart.

Migration modelexpectedAmountMinorexpectedAmountMinorEncrypted
Final modelexpectedAmountMinorEncrypted

Readable protected amount column removed

Automated verification

Encryption coverage is checked before plaintext removal.

Migration and schema checks validate protected fields before the encrypted-only cutover is allowed to complete.

If verified encrypted coverage is incomplete, the migration is blocked instead of removing the protected plaintext columns.

  1. 01

    Ciphertext coverage

    Every eligible protected plaintext value must have a corresponding encrypted value.

  2. 02

    Authentication

    Encrypted values must authenticate successfully rather than merely exist.

  3. 03

    Value equivalence

    Verification decrypts ciphertext and confirms that it matches the authoritative migration value.

  4. 04

    Registry parity

    Protected-field mappings, migration mappings and encrypted persistence columns must remain complete.

  5. 05

    Encrypted-only schema

    Post-migration checks require registered plaintext columns to be absent and encrypted columns to remain present.

Access boundaries

What each part of the system can see.

This is application-level encryption, not end-to-end encryption. The distinction is essential to an accurate security claim.

Database access

Direct database access and database dumps see ciphertext for registered protected financial fields.

Internal administration

Mizanek’s internal administration tools are designed not to expose decrypted protected financial values.

Authorized application runtime

The authorized backend decrypts protected values when required for user-requested budgets, bills, balances and insights.

Clear limitations

What this protection does — and does not — mean.

Transparency about the boundary is part of the protection model.

What it does

  • Keeps registered protected financial values unreadable directly in database storage.
  • Reduces exposure from a database dump or direct database access.
  • Separates household encryption through distinct household data keys.

What it does not claim

  • It is not end-to-end encryption.
  • The authorized Mizanek backend must process decrypted values to provide the service.
  • It does not make compromise impossible or guarantee absolute security.

No digital system can promise complete security. Users should also protect their password, device and household access.