The GDPR Rights That Actually Apply to KYC

When a bank, broker, or PSP holds a copy of your passport, your instinct is that the DSGVO is on your side. It is — but not in the blanket way most people assume. The GDPR rights that apply to KYC are real and enforceable, yet several of them collide head-on with anti-money-laundering retention law, and the right that wins depends entirely on the legal basis for the processing. Knowing which right bites where is the difference between a request that works and one that earns a polite refusal letter.

This is a practitioner's map of the four rights that matter in a KYC context, where each one is strong, and where it hits a wall.

Why the legal basis decides everything

Every DSGVO right is conditional on why an organisation is processing your data. In KYC, the processing almost always rests on Art. 6(1)(c) — a legal obligation: the obliged entity must identify and verify you under the Geldwäschegesetz. That single fact reshapes which rights have teeth.

• Rights that work regardless of legal basis: access (Art. 15), rectification (Art. 16).
• Rights that are blocked by a legal-obligation basis: erasure (Art. 17) during the retention period, objection (Art. 21) entirely.

So before you fire off a demand, ask: is this organisation processing my ID because the law forces them to, or because they chose to? A bank doing onboarding: legal obligation. A marketplace that asked for a passport "for security" with no statutory basis: probably legitimate interest, which is a much softer footing.

Right of access — Art. 15, your reconnaissance tool

Access is the most useful right in KYC precisely because it's unconditional. Anyone holding your personal data must, on request, tell you:

• what categories of data they hold (the ID copy, extracted fields, verification results),
• the purposes of processing,
• the recipients or categories of recipients,
• the envisaged retention period,
• the source, if not collected from you.

Use it as reconnaissance. Before you decide whether to demand deletion or rectification, an Art. 15 request maps the terrain: who holds your ID, why they claim to, and how long they intend to keep it. The retention period they cite is the single most revealing line — it tells you whether an erasure request later will hit a GwG wall or sail through.

A workable request is short:

Under DSGVO Art. 15 I request a copy of all personal data you hold about me, the purposes of processing, the recipients, the retention period, and the source. Please respond within one month.

The controller has one month, extendable by two for complex cases. The first copy is free.

Right to erasure — Art. 17 versus AML retention

This is where the collision happens. Art. 17 gives you a right to deletion — but Art. 17(3)(b) carves out an exception where processing is necessary for compliance with a legal obligation. The GwG imposes exactly such an obligation: obliged entities must retain identification records, typically for several years after the business relationship ends.

The result is a hard sequencing rule:

Situation	Does Art. 17 erasure succeed?
Active business relationship, obliged entity	No — retention duty applies
Relationship ended, within GwG retention period	No — duty persists for the statutory term
Retention period lapsed	Yes — no remaining legal basis
Recipient with no statutory basis (e.g. casual request)	Yes — usually no ground to retain at all

The practical move is not to fight a valid retention duty — you'll lose — but to pin down when it ends and what exactly it covers. A retention duty justifies keeping a record of identification; it does not license reuse, onward sharing, or holding more than the obligation requires. The full boundary, including how to demand deletion the moment the clock runs out, is in retention and deletion of KYC copies.

For recipients with no statutory basis — a landlord, a marketplace, a broker who "just wanted a copy" — Art. 17 is at its strongest, because there's frequently no lawful ground to keep your ID at all.

Right to object — Art. 21, narrow but sharp

Objection is the most misunderstood right in KYC. It only applies where processing rests on legitimate interest (Art. 6(1)(f)) or public task (Art. 6(1)(e)). It does not apply to processing grounded in a legal obligation — which is most AML processing.

So objecting to a bank's GwG-mandated identity check is a non-starter. But objecting to a non-obliged party's "we'd like your passport on file for security" can succeed, because that processing likely rests on legitimate interest, and once you object the controller must show overriding grounds or stop. This is the right to reach for when a recipient is over-collecting under a thin justification rather than a statutory one — and it pairs naturally with pushing back on scope before you ever hand the document over. See which fields to actually share.

Rectification and the quiet fifth lever

Art. 16 — rectification — gets overlooked, but it matters when your documents change. If a recipient holds a copy tied to a superseded passport, an old address, or a former name, you can require them to correct or update the record. In practice this often becomes a deletion-and-resupply: the stale copy goes, a current scoped one replaces it. It's also a clean reason to revisit who's holding outdated data during your annual cleanup.

When a controller pushes back — and what to do

Most KYC rights requests don't get a clean yes or no; they get friction. Knowing the common refusals and which are legitimate keeps you from backing down when you shouldn't.

• "We can't verify it's you." A controller may ask for reasonable identity confirmation before answering an Art. 15 request — that's allowed. But it cannot demand a fresh full ID copy as the price of access; that would be disproportionate. Offer the minimum they need to match you to an existing record.
• "It would take too long." The one-month deadline is firm. A two-month extension is permitted only for genuinely complex or numerous requests, and the controller must tell you within the first month that it's extending and why. Silence past one month is a breach you can escalate to the supervisory authority.
• "We have a retention duty" — in response to an erasure request. Sometimes true, sometimes reflexive. Force specificity: which statutory provision, which retention term, what end-date. A controller that can't name the basis is likely over-retaining.
• "That data is necessary." Against a data-minimisation or objection challenge, this is the standard reply. Push for why each field is necessary, not the bundle as a whole. The line on what's genuinely required is in what banks may actually require for KYC.

The escalation path matters. If a controller misses the deadline, refuses without a valid basis, or stonewalls, you can lodge a complaint with the competent data protection authority — in Austria the Datenschutzbehörde, in Germany the relevant Landesdatenschutzbehörde. A documented, dated request followed by a clear refusal is exactly the record those authorities want to see.

Exercising the rights in the right order

A sequence that holds up:

1. Send an Art. 15 access request to map who holds what and on what retention basis.
2. Sort recipients by legal basis — legal obligation versus legitimate interest. This determines which further rights are even available.
3. For legitimate-interest recipients, object under Art. 21 or demand erasure under Art. 17 — both are likely to succeed.
4. For legal-obligation recipients, don't demand erasure yet; pin down the retention end-date and the exact scope, and diary the deletion for when the period lapses.
5. For changed documents, use Art. 16 rectification to flush stale copies.

This mapping is also exactly the kind of thing that's far easier when you weren't scattering full copies in the first place. The reason ShareKYC holds your verified data in one EU-hosted, AES-256 encrypted vault and shares it via scoped, revocable links is that "who holds what" stays a question you can answer at a glance — and the answer is usually "no standalone copy at all" for anyone without a retention duty.

What this buys you

The DSGVO doesn't give you a magic delete button over your KYC data, and pretending it does leads to wasted requests and refusal letters. What it gives you is a precise toolkit: unconditional visibility through Art. 15, leverage against over-collectors through Art. 17 and Art. 21, and a clean path to deletion the moment a retention duty expires.

Know the legal basis, pick the matching right, and you stop arguing and start getting results. And the fewer uncontrolled copies you've handed out, the shorter that whole exercise gets — which is the working assumption behind ShareKYC.