Data retention and deletion
What is kept, for how long, why, and exactly what happens when you delete it.
Version 2026-08-06.2 · Last updated 1 August 2026
The principle
Meridian exists to compare this month against previous months and previous years. A short retention period would defeat the product; deleting three-year-old transactions would remove the only basis for saying whether spending has drifted. So the honest default is to keep transaction history until the owner deletes it, and to make deletion easy, immediate and complete rather than to promise an expiry that would never be wanted.
Everything that is not the financial ledger is a different matter, and each of those does expire on a timer.
The schedule
| Data | Retention | Why |
|---|---|---|
| Transactions and balances | Until deleted (current setting) | Multi-year comparison is the purpose of the application |
| Classifications, rules, notes | Until deleted | These are your corrections; discarding them would silently un-do your work |
| Monthly closes | Until deleted | An approved month is a record you chose to keep |
| AI analyses | 400 days | Prose over figures that can be regenerated; no reason to keep it forever |
| Security log | 365 days | Long enough to investigate an incident; removed automatically by the database |
| Sessions | Maximum 720 hours | An expired session is removed; there is nothing to keep |
| One-time codes | 10 minutes | A live code is a live credential; it should not outlive its use |
| Plaid access tokens | Until you disconnect | Deleted from the database at disconnection, and the Item is removed at Plaid |
| Consent records | Kept, including withdrawals | The one genuine exception — see below |
Automatic expiry is enforced by the database itself, through time-to-live indexes, rather than by a cleanup script somebody has to remember to run. The transaction-history rule, when enabled, is applied by pnpm retention:apply, which the scheduled worker runs daily.
The one retention exception
Consent records are not deleted when consent is withdrawn — the record is marked withdrawn and kept. It holds no financial data: a version number, a timestamp, and the list of categories and purposes that were displayed at the time.
It is kept because it is the only evidence that consent was ever given, and that it was later withdrawn. Erasing it on withdrawal would leave no record that either event happened, which serves nobody — least of all the person who withdrew. Deleting the account entirely removes everything, including these.
What deletion actually does
Four scopes, each irreversible, each requiring both a typed confirmation and a fresh verification code:
| Scope | What is removed |
|---|---|
| One connection | That institution's accounts, their transactions, their classifications and balance snapshots, and the connection itself — including the stored access token |
| Imported transactions | All raw transactions, classifications, recurring series, monthly closes and import batches. Accounts and connections stay, so syncing can resume. |
| All financial data | Everything above, plus accounts, connections, AI analyses and classification rules. Consent is marked withdrawn. The login remains. |
| The account | All of the above, plus the owner account, the profile, and every session. The instance returns to needing a fresh first-owner setup. |
Disconnecting a bank calls Plaid's /item/remove, so Plaid stops holding the connection on Meridian's behalf. Deletion inside Meridian is immediate; how long the underlying providers retain backups is governed by their own policies, listed in the privacy policy.
Why the bank's record is never edited
Meridian keeps two layers. The bank's record is append-only and is never modified by anything, including a re-import; your corrections live in a separate layer that the import pipeline is not permitted to overwrite. A transaction the bank retracts is marked removed rather than destroyed, and is excluded from every calculation — because a retraction is itself a fact worth keeping.
Deletion is the exception: when you delete, both layers go. Soft-deletion applies to what the institution retracts, never to what you asked to remove.