FinOpHQ · Financial Operations HQ
Data Retention and Disposal Policy
1. Purpose and Scope
This policy defines how Finophq (the “Service”) retains and disposes of user data. It codifies practices enforced in the Service's database schema and application code since initial release, and applies to all user data the Service stores — including data received from every platform a user connects (accounting platforms, bank connections via Plaid, and field-service/CRM platforms), current and future. It supplements the retention and deletion commitments published to end users in the Finophq Privacy Policy (Sections 5–6).
2. Review and Revision History
This policy is reviewed by the policy owner upon any change to the Service's data handling, and at least annually. The public Privacy Policy's “Last Updated” date reflects the most recent revision of the user-facing commitments this policy enforces.
- v1.0 (July 27, 2026) — initial adoption.
- v1.1 (July 28, 2026) — generalized to cover all connected platform categories (accounting, banking, field-service/CRM) so new integrations are governed without revision; clarified that synced platform data is retained as the account's current dashboard snapshot (replaced on each sync, removed on disconnect) rather than described as session-only.
3. Data Inventory and Retention Schedule
| Data category | Storage | Retained | Disposed |
|---|---|---|---|
| Account identity (email, hashed auth credentials) | Supabase Auth | While the account is active | On account deletion |
| OAuth access/refresh tokens for connected platforms (accounting — QuickBooks Online; banking — Plaid; field-service/CRM — Jobber; additional platforms as support ships) | Postgres, encrypted per-user (envelope encryption; never plaintext) | Until the user disconnects that platform or the account is deleted | Hard row deletion |
| Per-user wrapped encryption keys | Postgres (stored only in encrypted/wrapped form) | While the account is active | On account deletion (cascade) |
| User configuration (settings, budgets, approved lists, review flags) | Postgres | While the account is active | On account deletion (cascade) |
| Synced platform data (accounting reports and figures, bank balances/transactions, field-service/CRM records) | Postgres, as the account's single current dashboard snapshot | While the connection is active — each sync replaces the prior copy; no history of superseded copies is kept | That platform's data removed on its disconnect; entire snapshot on account deletion (cascade) |
| Uploaded files (e.g., CRM CSV exports) | Private, non-listable storage | While the account is active | On account deletion |
| Technical logs (sign-in timestamps, errors) | Operational logs | Short-term, operational use only | Routine rotation |
The Service does not sell, share, aggregate for resale, or retain user financial data after account termination.
4. Disposal Mechanisms (how this policy is enforced)
Enforcement is technical and automatic, not procedural:
- Platform disconnect (self-serve, immediate). Disconnecting a
connected platform in the application immediately deletes the
stored encrypted tokens for that platform — ending the Service's
access — and removes that platform's data from the stored dashboard
snapshot. For bank connections, disconnect additionally calls
Plaid's
/item/removeendpoint to revoke the access token at Plaid before deleting the stored copy. - Account deletion (on verified request). Every database table
holding user data references the user's account ID with
ON DELETE CASCADE. Deleting the account record therefore removes all associated rows — tokens for every connected platform, configuration, the dashboard snapshot, and the user's wrapped encryption key — in a single operation, leaving no orphaned user data. Requests are made to the policy owner's published contact address and verified as coming from the account holder. - Cryptographic disposal. Stored secrets exist only encrypted under a data key unique to each user. Destruction of a user's wrapped key (part of the cascade above) renders any residual ciphertext permanently unreadable.
- Provider backups. Deleted rows may persist for a limited period in the managed database provider's automated backups before expiring on the provider's standard rotation schedule; backups are encrypted and are not used to restore individual user data after a deletion request.
5. Access During Retention
While retained, user data is scoped to its owner: Row Level Security is enabled and enforced on every table holding user data, keyed to the authenticated user's ID. Administrative access is limited to the policy owner, with multi-factor authentication on the infrastructure accounts.
6. Exceptions
Data may be retained beyond this schedule only where required to comply with a legal obligation, resolve a dispute, or enforce the Service's agreements, and only for as long as that purpose requires.