Data retention and disposal policy

• Financial data is kept only while the bank connection it came from is linked.
• Disconnecting a bank permanently deletes that connection’s data within 30 days.
• Either member can have everything deleted, on the same basis.
• This policy is reviewed once a year.

Account and transaction data — while the connection is linked. History is retained for as long as its bank remains connected, because comparing this year’s spending against previous years is the point of the application. There is no separate expiry: the connection’s lifetime is the retention period.

Data imported by hand — until deleted by a member. Older history imported from a file predates any connection and is not removed when a bank is disconnected, because it did not come from that bank. It is removed by the delete-everything path, or individually.

Categories, rules and corrections — until changed. These are the household’s own work rather than bank data, and they survive a bank being reconnected so that history does not have to be re-categorised.

Bank access tokens — while the connection is linked. Deleted as part of the same purge, after the instruction to forget the connection has been sent to the banking provider.

Operational records — rolling. Records of when data was last synchronised, and of notifications received, are kept to diagnose failures. They contain no transaction detail.

When a member disconnects a bank, three things happen:

• The banking provider is instructed to forget the connection, so no further data can be retrieved and billing for it stops.
• That connection’s accounts, transactions and stored access token are permanently deleted from the database within 30 days.
• The household’s own work — categories, rules, manually imported history — is left alone, because it is not the bank’s data.

This is a real deletion, not a flag that hides rows from the interface. It is the only hard delete in the application: everywhere else, clearing something hides it reversibly.

Either member can have the entire household’s data deleted. This removes all accounts, transactions, categories, rules, alerts and tokens, and instructs the banking provider to forget every connection. The same 30-day limit applies, and in practice it completes immediately.

The constraint lives in the database rather than in application code. Deleting a transaction is refused outright unless it happens in one of three declared contexts, two of which are the unlink purge and the delete-everything path.

The effect is that there is no way to quietly delete financial history by mistake, and no way to perform the permitted deletions without declaring which one is happening. A policy enforced by a constraint survives a developer forgetting it; a policy enforced by convention does not.

Backups are encrypted and are not retained indefinitely. A purge applies to live data immediately; any copy of the deleted data inside a backup ages out within the 30-day window, which is why the commitment is expressed as 30 days rather than as instant.

Stated plainly, because a policy describing unwritten code as though it were running would be misleading:

• In place: the database constraint that refuses undeclared deletes, and the retention periods above.
• Not yet in place: the code that performs the unlink purge and the delete-everything path. The structure that makes them enforceable exists; the action behind the button does not. This closes before the application handles real bank data.

Reviewed once a year, and whenever what is collected changes. A review confirms that the periods above still match what is actually done, that the purge still removes everything it claims to, and that the privacy policy still describes reality.