Retention and Deletion of KYC Copies: What the Other Side May Do

You finished the onboarding, the account is open, the deal is done — and somewhere on the other side sits a copy of your passport. The question practitioners actually need answered isn't "do I have a right to deletion" but the sharper one: how long may the recipient keep this KYC copy, and when are they obliged to destroy it? The answer is a negotiation between two laws that point in opposite directions, and knowing exactly where they meet is what lets you demand deletion at the right moment instead of the wrong one.

This is the retention-versus-deletion boundary, mapped for the side that's actually holding your data.

Two laws, opposite directions

KYC retention sits on a fault line between anti-money-laundering record-keeping and data-protection minimisation.

• The Geldwäschegesetz (GwG) obliges obliged entities to keep identification records for a defined period after the relationship ends. The point is auditability: a regulator must be able to reconstruct who was verified and how.
• The DSGVO obliges everyone to delete personal data once its purpose is fulfilled, and grants you an erasure right under Art. 17.

These don't actually conflict so much as take turns. While the GwG duty runs, it overrides erasure (DSGVO Art. 17(3)(b) explicitly preserves legal-obligation retention). The moment that duty lapses, the override falls away and the DSGVO's delete-by-default rule reasserts itself. The whole game is knowing which phase a given copy is in.

What the retention duty actually covers

A retention obligation is narrower than recipients often act as if it is. It permits keeping a record sufficient to evidence the identification for the AML purpose. It does not grant:

• a licence to reuse your ID for unrelated purposes (marketing, profiling, scoring),
• a right to share the copy onward to parties without their own basis,
• a justification to retain more than the obligation requires (a full unredacted scan where extracted fields plus a verification log would satisfy the duty),
• indefinite retention — every retention term has an end.

This matters because the most common over-reach isn't keeping a copy too long; it's treating "we're allowed to retain identification" as a blanket permission to do anything with it. It isn't. The broader map of which DSGVO rights bite, and when, is in the GDPR rights that actually apply to KYC.

How long is "long enough"?

Exact terms depend on the document type and jurisdiction, so treat the table below as the shape of the rule rather than a citation. Across the DACH region, AML record-keeping settles into a multi-year window — commonly cited as roughly five years after the end of the business relationship, extendable in defined cases.

Recipient type	Basis	Realistic retention
Bank / obliged entity, active relationship	GwG identification duty	Duration of relationship + statutory term
Obliged entity, relationship ended	GwG record-keeping	Several years post-termination, then delete
PSP / regulated intermediary	AML duty (varies)	Comparable multi-year window
Marketplace, landlord, broker (no AML duty)	None / legitimate interest	Until purpose fulfilled — often immediately after

The line that separates the top three rows from the bottom one is the one you exploit. A party with no statutory retention basis has no clock to wait out — their lawful retention often ends the moment the verification purpose is satisfied.

When a recipient must delete — and how to demand it

There are two clean trigger points where deletion becomes demandable:

Trigger one: no retention basis ever applied. If the recipient isn't an obliged entity and collected your ID under a thin "for security" rationale, the purpose was fulfilled when the check completed. Demand erasure under Art. 17 now. A workable request:

The purpose for which you collected my identity document on [date] is fulfilled. As you are not subject to a statutory retention duty for this data, I request its deletion under DSGVO Art. 17 and written confirmation. If you assert a retention obligation, please cite the specific legal basis and the retention end-date.

That last sentence is the lever. It forces the recipient to either delete or commit, in writing, to a specific statutory basis and end-date — which converts a vague "we keep records" into a dated obligation you can diary.

Trigger two: the retention term has lapsed. For obliged entities, you wait out the clock, then strike. Once the statutory term expires, the legal-obligation override is gone and continued retention needs a fresh basis the recipient usually doesn't have. Diary the end-date from your access request and send the same Art. 17 demand when it arrives.

The records you control versus the ones you don't

There's a category these requests can't reach: copies you sent as raw attachments or messenger images. You can demand their deletion, but you can't verify it, and you can't force it. This is the practical argument for never creating an uncontrolled copy in the first place — the only retention you can truly govern is the retention of a copy that never left your control.

A scoped, revocable link inverts the default. Instead of demanding deletion of a copy someone holds, you simply revoke access to a copy that only ever lived in your vault. The recipient never had a file to retain; when their purpose is fulfilled or the relationship ends, you cut the link. The mechanics of doing this — and what a revoke does and doesn't reach — are in revoking access after sharing.

What "delete" must actually mean

When a recipient confirms deletion, it's worth knowing what a complete deletion involves — both to judge a confirmation and to push back on a half-measure.

Real deletion reaches every place the data lives, not just the primary record:

• the working copy in the main system,
• replicas in search indexes, caches, and data warehouses,
• backups (here practice is nuanced — backups are often allowed to age out on their normal cycle rather than be surgically edited, provided the data isn't restored into active use),
• onward copies the recipient shared with processors or third parties, which they must instruct to delete in turn.

A recipient that deletes the visible record but leaves your ID in a data lake or a third-party processor hasn't fulfilled the obligation. You're entitled to ask, in your erasure request, that they confirm deletion including from backups and any recipients to whom the data was disclosed. Anonymisation can be a legitimate alternative to deletion — but only if it's genuinely irreversible, which a lightly redacted ID scan is not.

This is also where the gap between controllable and uncontrollable shares bites hardest. For a copy in your own vault, "delete" is unambiguous and instant: you revoke and the access ends. For a copy scattered across someone else's systems, "delete" is a promise you're trusting them to keep across infrastructure you can't see. The asymmetry is the whole argument for not creating the scattered copy in the first place — see revoking access after sharing.

Folding it into a routine

Retention end-dates are useless if you forget them, which is why deletion belongs in a recurring process, not a one-off. Each year:

• pull or update the retention end-date for every obliged-entity copy via an access request,
• fire Art. 17 demands at every non-obliged recipient whose purpose is fulfilled,
• diary the next batch of expiring retention terms,
• revoke every link tied to a finished relationship.

That cadence is the backbone of a proper KYC hygiene routine, and it's where retention rules stop being abstract and start clearing your data out of systems on schedule.

This is also the model ShareKYC is built around: your verified data held AES-256 encrypted in an EU-hosted vault, shared through links you revoke when the purpose ends — so for every recipient without a retention duty, the answer to "what are they holding?" is simply "nothing standalone."

The boundary, stated plainly

A recipient may keep your KYC copy exactly as long as a statutory duty compels — no longer, for no other purpose, and never more than the duty requires. Outside that, the default is deletion, and you can demand it. Know which side of the line each copy sits on, diary the end-dates, and the other side's retention stops being indefinite and starts being a clock you're watching.

The cleanest version of this is to never hand over a standalone copy at all. That's the default ShareKYC exists to make easy.