Data Retention and Legal Hold
Two obligations run at the same time on the fraud side: the transaction record must be retained for its statutory window, and a data subject's erasure request must be honoured. The platform does not trade one for the other — it keeps the record and removes the link to the person.
Erasure does not destroy the record. The transaction record — amount, decision, which rule, which moment — stays for the whole retention window. What is erased is the mapping that ties that record to a person.
Retention window
| Record class | Window | At the end of the window |
|---|---|---|
| Fraud transaction events, decision and case records | 120 months (10 years) | Archived — not deleted |
- The window can be shortened per installation but never below 12 months: that floor is enforced in code, not in configuration, and an invalid value falls back to the 10-year default.
- Windows and the current state of the sweep are visible in the panel; reading them requires
fraud:view_reports.
What "end of the window" means
The sweep runs daily and detaches aged-out monthly partitions from the live query path. This is a logical archive: the rows stay exactly as they are, the partition becomes a standalone table, and it can be re-attached if needed.
The sweep never issues a delete, truncate or drop. Data past its window is not destroyed; it is taken out of the query path.
The archive record is written before the partition is detached. In a failure the worst outcome is therefore a recorded partition that is still live — the next pass simply repeats the work. An unrecorded archive cannot happen.
Erasure request
On the fraud side, the raw form of a customer key lives in one encrypted mapping table. Decision records, event payloads, case records, exports and analytics projections carry only a pseudonym — a keyed digest namespaced per organisation, so the same customer id yields a different pseudonym in two organisations.
On an erasure request the mapping row is not deleted: the encrypted raw value is cleared and the row is stamped as erased. The result:
| After the request | State |
|---|---|
| Transaction, decision and case records | Still readable |
| Linking a record to a person | No longer possible |
| Proof that erasure happened | Preserved |
| Later traffic reviving the mapping | Not possible |
Erasure works across three subject kinds: customer id, account id and email address. With no kind given, all three are processed together.
This operation cannot be undone. It therefore has its own permission: fraud:erase_customer. The decision-override permission (fraud:override) does not grant it.
Legal hold
A legal hold freezes the data it covers against both archival and erasure. It can be placed in four scopes:
| Scope | Data covered |
|---|---|
| Organisation | All fraud records of the organisation |
| Customer | One customer's records |
| Case | A single case |
| Time range | Every record overlapping the stated period |
- Placing a hold takes effect immediately. Who placed it, the reason and the time are recorded.
- Releasing is a platform operation. You can place a hold on your own organisation; you cannot release any hold. The subject of an investigation cannot lift the freeze on its own data.
- Hold records are never deleted. A released hold stays in the list with who placed it and when it was released.
- A period covered by an active hold is not archived even after its retention window expires.
| Operation | Permission |
|---|---|
| Listing, placing and releasing holds | fraud:override |
| Reading retention state | fraud:view_reports |
| Permanently erasing a customer key | fraud:erase_customer |
| Resolving a pseudonym back to its raw value | fraud:view_decisions |
When the two rules collide
If an erasure request meets a legal hold, the hold wins — but the request is not dropped.
- If the subject is under an active hold, erasure is refused, the mapping is left intact, and the refusal is written to the audit record.
- The request enters the pending-request queue.
- When the hold is released the request is re-run automatically; no operator has to raise the same request again.
The queue carries no raw identity. Re-running works off the pseudonym, so a person awaiting erasure is not persisted in a second place.
The retention window itself does not block erasure: what must be kept for ten years is the transaction record, not the person's identity. The raw identity is preserved only while an active hold requires it.
Related pages
- Decision Governance — who published a decision and how it is rolled back
- KVKK — retention, destruction and request endpoints on the identity side
- Trust — compliance status and the documents we can share