The benefit of the two layers is separation: the large dataset is encrypted once with a fast symmetric key (the DEK), while only the small DEK has to be re-encrypted when the protecting key changes. It also means the system can be designed so the operator never holds a key that can decrypt user data.
How Finlynq uses envelope encryption
Each Finlynq user has their own DEK. That DEK is wrapped by a KEK derived from the user's password using scrypt (a memory-hard key-derivation function) plus a server-side pepper. Sensitive display fields — transaction payees, notes, tags, account names, category names, and budget names — are encrypted with AES-256-GCM. The unwrapped DEK only exists in server memory while you are signed in.
The honest trade-off: numeric amounts, dates, and unique IDs are stored unencrypted because the database needs them for totals, sorting, joins, and indexes. Everything name-like is encrypted with a key derived only from your password — so even the operator cannot read it. The corollary is that if you lose your password without a backup, the encrypted fields are unrecoverable.