ApidentitybyAdesio
DemonstrationDeclarant identity in this deployment is SIMULATED. No qualified trust service is contracted, nothing here has been identified by anyone, and any certificate issued in this mode is a demonstration rather than an attestation.

Requesting erasure

Removes the name from the record. The record itself has to survive.

Evidence in this system is immutable by design — corrections are new records, never edits, and the audit log can't be rewritten even in principle. For a long time that made a genuine erasure request hard to answer: removing a beneficial owner's name usually meant breaking the very property everything else depends on.

How it actually works

Personal data — a person's name, given names, birth year — is sealed under an encryption key that belongs to that one person alone. Erasure destroys the key, not the row it protects.

Afterwards, the row is still there: the ownership chain still counts the same owners at the same percentages, the audit trail is untouched, every foreign key still resolves — and the name is gone, in this database and in every backup taken before the request, which deleting a row could never have achieved. What survives was never personal in the first place: a percentage, a legal basis, a country code, a shape of ownership.

What this protects against, and what it doesn't

This is containment against a copy of the database — a stolen backup, a snapshot handed to the wrong person. It is not a defence against a compromise of the running service itself, which still holds the key needed to decrypt on read. The trust centre states that limit explicitly rather than leaving it to be assumed.

How to ask

There's no self-serve button for this yet. Email bertier@ades.io with what you're asking to have erased and who's asking — the same route the trust centre's documents page uses for anything else that isn't already public.