The right to erasure versus the audit trail. The law resolves it; we have not built the workflow

The regulation already resolves this tension. What it leaves behind is a clock, and knowing when each record's retention expires is the engineering nobody does.

Nothing here is legal advice.

The apparent contradiction

A person has a right under GDPR Article 17 to ask an organisation to delete their personal data. A regulated institution has a separate obligation to keep customer due-diligence records (the evidence it did the work correctly) for a fixed minimum period, so a regulator can check later. FATF Recommendation 11 sets that baseline; the EU implements it through AMLD Article 40 with a five-year minimum, and Türkiye through MASAK's own record-retention rules.

Put both next to one person's file and they look mutually exclusive.

The resolution is in the regulation itself

They do not actually conflict, and it is worth being precise about this rather than selling the tension. GDPR Article 17(3)(b) exempts an erasure request where continued processing is necessary for compliance with a legal obligation under EU or member-state law, which is exactly what an AML retention mandate is.

So a regulated business does not have to delete a due-diligence record on request during the mandated window. The right applies once the obligation lapses, not before.

Which means the hard problem is not the contradiction. It is the clock. Knowing when the retention period expires for a given record, in a given jurisdiction, for a given business relationship, and then honouring erasure at that point rather than indefinitely deferring it, is the part that takes engineering, and it is the part that gets skipped.

Why reuse makes the question sharper rather than simpler

A traditional record sits inside one institution, which owns the whole calculation for its own copy. A reusable credential does not:

• If a person asks the issuer to erase, does that reach every relying party's own retention-mandated copy of the result? Those copies are not ours to delete.
• Does revoking a credential satisfy an erasure request? Revocation stops future presentations. It does not remove the data the credential was built from, or the records relying parties kept.
• Whose retention clock governs, the issuer's, or each relying party's, under its own regulator?

These are open design problems for the reusable-credential model. A single-institution KYC record never had to answer them. We have not answered them either, and a page that implied otherwise would be selling past the thing the buyer will actually be asked about.

What our code does today, precisely

Two mechanisms exist, and one of them has the right shape:

• Retention timestamps on the record itself. Identity documents, selfies and voice audio carry a purge time defaulting to 30 days from capture; session recordings to 365 days.
• The purge distinguishes the personal data from the evidence. For documents it deletes outright, stored object and row both. For a session recording it deletes the media and keeps the row, marking when the media went, so the non-personal continuity and integrity verdict outlives the video.

That second mechanism is the shape of the answer: erase the personal material, retain the proof that the check happened and was sound. We are not claiming more for it than that. It is a retention sweep on a fixed timer, not a response to anybody's request.

What is missing, stated as a list

• No erasure-request workflow of any kind. There is no endpoint, no interface control, and no code path in the codebase that deletes a person's data because they asked. Re-verified 2026-07-31.
• No per-customer retention. A retention_days column exists on the organisation record and nothing reads it. Retention is a deployment-wide setting, so a customer cannot configure their own window despite the schema implying they could.
• No per-jurisdiction retention clock. One default window, not five years in the EU and whatever applies elsewhere.
• No propagation mechanism to relying parties, and no defined answer to whether revocation discharges an erasure request.
• No DPO, no DPIA, no independent assessment.

And the purge sweep ships defaulting to dry-run, so a deployment that never enables it retains everything while appearing to have retention.

A correction to our own published pages

Our live security page currently states that account deletion removes all off-chain data within 24 hours, and that no personal data is persisted after a session. Neither is implemented. There is no account-deletion path in the codebase, and identity documents are retained on a 30-day timer with recordings on a 365-day timer.

Those statements are wrong and we are not going to restate them here. Correcting our own copy is the whole reason this section exists, the sceptical standard we apply to competitors has to apply to us first, and a page about erasure that repeated an unimplemented erasure claim would fail its own subject.