Data Retention and Disposal Policy
What Bifold holds, how long it holds it, and what actually happens when it is disposed of. Companion to the information security policy and the privacy policy, which this expands rather than repeats.
1. Scope and ownership
Covers all consumer data Bifold stores, including everything retrieved from the Plaid API, in the hosted Supabase project (Postgres database and authentication) and on the consumer's own device. Eeshan Kulkarni, sole owner and developer, is accountable for it: eesh.kulkar@gmail.com.
2. Principles
- Collect only what runs the app. There is no analytics pipeline, no data warehouse, no event stream, and no advertising or profiling use. Nothing is retained "in case it is useful later".
- Keep only while the account exists. Retention is tied to the account's life, not to a fixed archival period.
- Disposal is deletion, not a flag. Rows are removed from the database. Nothing is soft-deleted and left readable.
- Credentials are disposed of first. Access to a bank is revoked at the source before the local record of it goes, so a deletion cannot leave a live token behind.
3. What is held, and for how long
| Data | Retention | Disposal trigger |
|---|---|---|
| Sign-in record (Apple-issued identifier, and name or relay email if shared) | Life of the account | Account deletion |
| Plaid access token and sync cursor | Life of the connection, which is shorter than the account | Deleted the moment a bank is disconnected, and on account deletion. Never retained past the connection. |
| Accounts: name, type, last four digits, balances | Life of the account | Hidden on disconnect; deleted on account deletion |
| Transactions: date, amount, merchant, description, category | Life of the account. Deliberately kept after a bank is disconnected so spending history and net worth over time do not develop a hole. | Account deletion |
| Investment holdings and securities | Life of the account | Account deletion |
| Categories, learned merchant rules, manual assets, preferences | Life of the account | Account deletion |
| Sync audit rows (per attempt: item, trigger, timings, counts, error class and code) | 90 days, pruned automatically by the scheduled sync job | Automatic, plus account deletion |
| Institution branding cache (logo, colour, website) | Indefinite | Not applicable: shared reference data about institutions, carrying no consumer information and no link to any consumer |
| Application and database logs | A short provider-managed window on the project's current plan | Automatic expiry at the provider |
| On-device cache (recently viewed figures, logos) | Until sign-out or deletion | Cleared on sign-out and on account deletion |
4. Disposal procedures
Consumer-initiated account deletion
Available to every consumer inside the app at Settings › Delete account, with no request to anyone and no waiting period. The sequence is fixed:
- Every connected bank is removed at Plaid, which revokes the access token at source, and the stored token row is deleted.
- Only once every bank is gone is the sign-in record deleted. The database then cascades the deletion through every table that references it: accounts, transactions, categories, rules, sync audit rows, manual assets.
- If Plaid refuses to release a connection, the process stops and nothing is deleted. A connection orphaned at Plaid would keep a live access token in existence, which is worse than a deletion that can be retried. The consumer keeps their account and can try again.
Disconnecting a single bank
Removes the connection at Plaid and deletes the stored access token immediately. Accounts are hidden and transactions are retained as described above; a consumer who wants those gone deletes the account.
Backups and residual copies
Point-in-time recovery is disabled on this project and no scheduled backup snapshots are retained, so a deletion is not shadowed by a restorable copy that outlives it. Storage-layer replication at the infrastructure provider is operational redundancy, not an archive Bifold can read, restore from, or extract a deleted row out of.
Copies outside the database
There are none. Production data is never copied to the development machine, which runs an isolated local database with synthetic seed data. There is no export job, no reporting extract, no spreadsheet, and no third-party recipient beyond the processors named in the privacy policy. Consumer data is never pasted into issues, pull requests, logs or support correspondence.
5. Verification
A deletion is verified by confirming the sign-in record no longer resolves and that the connections no longer exist at Plaid. Because disposal relies on database-level cascade rather than application code remembering each table, a table added later inherits the deletion automatically; any new table holding consumer data must carry that same cascade, and this is checked when the schema changes.
6. Legal holds and exceptions
There are no legal holds in force and no exception to the above. Should one ever be required by law, the affected data would be isolated, the reason and scope recorded in writing with an expiry, and disposal resumed as soon as the obligation ends.
7. Consumer requests
Deletion and access are self-service in the app. A consumer who would rather have it done for them, or who wants a copy of their data, emails the address above; requests are completed within 30 days, and normally far sooner.
8. Review
Reviewed at least annually and whenever the schema or a data flow changes.
| Date | Outcome |
|---|---|
| 9 September 2026 | Initial version. Retention periods reconciled against the live schema and the scheduled prune; backup posture confirmed as no point-in-time recovery and no retained snapshots. |