What a serious GDPR data export looks like in a budgeting app

A GDPR export is not a compliance trophy. It is one visible surface of a larger system: lawful basis, retention, deletion, processors, and security. Still, most finance apps fail even the visible part — they email a vague PDF or a broken CSV. This essay walks through what a serious Art. 15 / Art. 20 package should contain for a local-first budgeter, using Viridel’s on-device export as a concrete example, without pretending a ZIP file equals full GDPR compliance.

Machine-readable and human-readable, together

Portability wants structured, commonly used, machine-readable data — JSON and CSV beat screenshots. Transparency wants a plain-language summary a non-engineer can read. Viridel downloads both: a full JSON export and an HTML companion that lists categories, purposes, retention, and rights without dumping raw blobs into the first screen.

If your “export” is only a marketing email saying “we have financial data about you,” it is not an export.

Categories, purpose, and legal basis

Dumping database columns is not enough. Group data the way a person thinks: identity, financial ledger, preferences, household membership, subscription/purchases, consent evidence, device tokens, sync metadata. State why each exists (contract for the budgeting service, legal obligation for consent evidence and tax-adjacent billing, and so on).

Viridel’s export includes those category rows plus retention notes mirrored from the Privacy Policy — active account while open, 48-hour soft-delete then purge within 30 days, billing via the payment provider, consent evidence typically retained for evidence after closure.

An export that cannot explain purpose will not survive an auditor’s first question.

Consent evidence is not a checkbox screenshot

Record privacy and terms acceptance with timestamps and document versions. Keep an append-only audit log for clear/delete confirmations. Do not hide acceptance only inside prefs blobs that also sync for UI state — surface consent once in the export and strip duplicates so the file stays readable.

If the HTML summary says “0 consent events” while timestamps exist in legal_consent, that mismatch is an own-goal. Counts must reconcile.

Soft deletes and tombstones

Multi-device sync needs tombstones (`deleted: true`) so offline devices do not resurrect rows. Those rows are still personal data while retained. A serious export either includes them with an explanation or documents the purge lifecycle. Viridel includes them and states they purge with account deletion — not as a forever archive.

Deletion path must match the product UI

Telling users “Settings → Delete account” when the real path is Settings → Data → Delete account (`/settings/data`) is how trust dies. Copy in exports, privacy policy, and in-app chrome must match.

Erasure still needs a real pipeline: leave household cleanly, wipe personal cloud rows, revoke tokens, and purge within the published window. The export only points at the button — the lifecycle code must do the work.

What an export cannot prove

RLS correctness, processor DPAs, international transfer safeguards, backup purge, and admin access controls do not live inside a user ZIP. Treat the export as necessary and insufficient. Read Viridel’s Privacy, Security, and DPA pages for the rest of the map — and demand the same honesty from any budgeting vendor.