Data Retention & Deletion Policy

1. Purpose

This policy describes what data Copivia (the "Application") stores, where it is stored, how long it is retained, and how it can be deleted. It is intended to complement our Privacy Policy and Information Security Policy with specific, practical detail about data lifecycle.

2. What Data Is Stored

The Application stores the following categories of data:

The Application does not store your online banking username or password, your full bank account or routing numbers, or your Social Security number.

3. Where Data Is Stored

All data described in Section 2 (with the exception of future Stripe billing metadata, which will live in Stripe's systems) is stored locally, on the user's own computer, in the per-user Windows application data directory associated with the Application. Specifically:

• A local SQLite database file, containing manually entered and Plaid-synced financial data, and encrypted Plaid access tokens.
• A local encryption key file, used to encrypt and decrypt Plaid access tokens, stored separately from — but on the same device as — the database.
• Local log files, containing application and backend diagnostic output.

No financial data is currently stored on any server we operate. We do not have a cloud database, and we cannot access your financial data remotely, because it never leaves your device under the current architecture.

4. Local Database Retention

• Data in the local SQLite database is retained indefinitely on the user's device, for as long as the Application remains installed and the user does not delete it, because the Application is designed to give users a persistent, ongoing view of their finances rather than a temporary session.
• There is currently no automatic expiration or purging of old transactions, balances, or other synced data. Historical data (e.g., older transactions) remains available locally unless manually deleted by the user or removed as part of disconnecting an institution.
• Manually entered data (budgets, goals, notes, etc.) is retained until the user edits or deletes it within the Application, or deletes the underlying database file directly.

5. Plaid Token Handling

• When a user links a financial institution, Plaid issues an access token that the Application uses to request updated account data. This token is encrypted (AES-256-GCM) before being written to the local database, as described in our Information Security Policy.
• The token is retained for as long as the associated institution connection remains active.
• When a user disconnects an institution within the Application:
• The Application calls Plaid's API to revoke the access token (best-effort — if the revocation call fails, for example due to no internet connection, the failure is logged but does not block local removal).
• The encrypted token is deleted from the local database.
• Previously synced account and transaction data associated with that connection is not automatically deleted at the time of disconnect, so the user retains their historical view; it can be separately deleted as described in Section 7.

6. Log Retention

• Application and backend logs are written to a local log file in the user's application data directory.
• Logs are retained locally for troubleshooting purposes. At present, log rotation and maximum retention size are governed by the defaults of the logging library used by the Application; there is no automatic time-based purge of old log entries.
• Logs are not transmitted anywhere automatically. If a user voluntarily shares a log file with us for support purposes, we retain that shared copy only as long as needed to resolve the reported issue, and then delete it.
• We recommend users avoid sharing full log files containing anything they consider sensitive without first reviewing the contents; while logs are not designed to capture full financial details, application error messages can sometimes include fragments of surrounding data.

7. User Deletion Requests

Because Copivia is local-first, users already hold the primary ability to delete their own data directly, without needing to contact us:

• Within the Application: individual accounts, transactions, budgets, and goals can be deleted through the relevant screens where the Application supports it.
• Disconnecting an institution: removes the encrypted access token and revokes Plaid's ongoing access (Section 5).
• Deleting the local data folder: removes the SQLite database, encryption key, and logs entirely. Uninstalling the Application removes the installed program files but, depending on Windows configuration, may not automatically remove this per-user application data folder — users who want a full removal should delete this folder manually after uninstalling.
• Contacting us: if a user is unsure how to fully remove their data, or believes something was not deleted as expected, they may contact the Owner/Lead Developer (Section 10) for guidance. Because we do not hold a remote copy of local data, we cannot remotely delete it on a user's behalf today — our role in a deletion request is limited to guidance and, where applicable, ensuring any voluntarily shared support artifacts (like log files) are deleted on our end.

8. Account Disconnect Process (Summary)

1. User selects "disconnect" for a linked institution within the Application.
2. The Application calls Plaid's /item/remove API to revoke the access token with Plaid and the underlying institution.
3. The Application deletes the encrypted access token record from the local database.
4. The institution no longer appears as an active connection, and no further syncing occurs for it.
5. Previously synced data from that institution remains in the local database until the user separately deletes it (Section 7), so users don't lose historical records simply by disconnecting.

9. Future Cloud Deletion Policy

The Application does not currently offer cloud synchronization, so there is no server-side copy of user data to delete today. If and when cloud sync is introduced:

• We will publish an updated version of this policy describing server-side retention periods and deletion timelines before the feature is enabled for any user.
• Users will be able to request deletion of any server-side copy of their data, and we will commit to a specific, disclosed timeframe for completing such requests (to be defined alongside the cloud sync design).
• Backups of any future server-side data (see Section 10) will also be addressed explicitly in that update, including how long deleted data may persist in backup systems before being purged.

No such cloud deletion process exists yet, because no cloud storage of user data exists yet.

10. Backup Policy

• We do not currently operate any backup system for user financial data, because that data is not stored on any server we control. All backup responsibility for locally stored data currently rests with the user (for example, via their own Windows file backup solution, OneDrive folder sync, or similar tools they choose to use independently of the Application).
• The Application does not currently include a built-in backup or export-and-restore feature beyond CSV export of certain data views. Users who want protection against data loss (e.g., hard drive failure) should maintain their own backup of their application data folder.
• Once cloud sync is introduced, this section will be updated to describe our backup practices for any server-side data, including backup frequency, retention, and encryption.

11. Secure Deletion Procedures

• When data is deleted within the Application (individual records, an entire institution connection, or the local database as a whole), deletion is performed through standard file and database deletion operations provided by the operating system and SQLite.
• We do not currently perform cryptographic erasure or forensic-level overwriting of deleted data on disk. As with most consumer applications, deleted data may be technically recoverable from the underlying storage medium using specialized forensic tools until that disk space is overwritten by normal system activity. Users with heightened security needs (for example, before disposing of or selling a device) should use full-disk wipe tools appropriate to their operating system and hardware.
• The local encryption key used for Plaid access tokens is deleted along with the rest of the local application data folder if a user performs a full manual removal (Section 7); without this key, any residual encrypted token fragments that might otherwise be recoverable would not be decryptable.
• We do not retain copies of deleted data on any server, because deletion happens entirely on the user's own device under the current architecture.

12. Contact Information

Questions about this policy, or requests for guidance on deleting your data, should be directed to:

Anniston Kruger Founder • Owner • Lead Developer, Copivia
Email: krugeranniston@gmail.com

For security-related aspects of data handling, you may also contact:

Seth Norton Co-Developer • Infrastructure & Information Security, Copivia
Email: Snort84@wgu.edu

This policy reflects the current, local-first architecture of Copivia during its beta phase. It will be revised before any cloud synchronization, user account system, or hosted backup feature is introduced.