Right to Erasure vs Audit Trail

A user has a legal right, under GDPR Article 17, to ask an organization to delete their personal data. A regulated financial institution has a separate legal obligation to keep customer due-diligence records, the evidence it performed KYC correctly, for a fixed minimum period, typically five years, specifically so a regulator or auditor can check that work later. Put those two requirements next to a single person's KYC record and they appear to contradict each other: delete it, or keep it, cannot both be true of the same record at the same time.

This isn't a Solidus-specific problem, or even a blockchain-specific one (though blockchain's append-only design sharpens it further, see GDPR Article 17's own entry for that angle). It's a structural tension every regulated identity-verification system runs into, because the two obligations come from different bodies of law written for different purposes, neither of which yields to the other automatically.

The resolution is already written into GDPR itself

It's worth being precise here, because the tension is real but the "contradiction" is overstated: GDPR does not actually demand erasure that would violate a separate legal obligation. Article 17(3)(b) explicitly exempts an erasure request where continued processing is "necessary for compliance with a legal obligation which requires processing" under EU or member-state law, which is exactly what an AML retention mandate is. In practice, this means a bank does not have to delete a customer's KYC record on request during the mandated retention window (FATF Recommendation 11 sets the record-keeping baseline; the EU's AMLD Article 40 and Türkiye's MASAK rules implement it nationally); the right to erasure applies once that retention obligation lapses, not before. The two rules don't actually conflict once read together: the harder problem is building a system that correctly tracks when the retention clock runs out for a given record and honors erasure only after that point, for every jurisdiction's own retention period.

Why reusable credentials make the question sharper, not simpler

A traditional KYC record sits inside one institution, which owns the whole erasure-versus-retention calculation for its own copy. A reusable credential complicates that: if a person's KYC credential gets presented to, and relied on by, three different businesses, does an erasure request at the issuer propagate to every relying party's own retention-mandated copy of the check result? Does revoking a credential satisfy an erasure request, or does the underlying data the credential was built from still need separate, per-relying-party handling? These aren't rhetorical questions: they're open design problems a reusable-credential model has to solve that a single-institution KYC record never had to.

Solidus today

Solidus has not built an answer to either version of this question. No Data Protection Officer has been appointed, no Data Protection Impact Assessment has been completed, and no erasure-request workflow, tested against a real retention-window calculation, for any credential type, exists to point to. This entry names the real legal tension and its real legal resolution (Article 17(3)(b)) honestly, and states, equally honestly, that Solidus has not yet built the tooling that would put that resolution into practice for a reused credential.

See also

GDPR Article 17 is the erasure right itself, with the fuller blockchain-immutability discussion. Data Minimisation is the related principle limiting what's collected in the first place. KYC is where the underlying retention-mandated record originates.