Handling DSARs on KYC Records Without Breaking AML Rules

A customer emails: "Send me everything you hold about me, and delete it." Under GDPR Articles 15 and 17, and similar rights in the UK, Brazil (LGPD), and California (CCPA/CPRA), you have a fixed window to respond — typically one month. But KYC records are entangled with anti-money-laundering obligations that can override a deletion request entirely. Handling this well requires knowing which right applies, what you must withhold, and what you are legally barred from erasing. This is general information, not legal advice.

Access Is Not Unlimited Disclosure

An access request obligates you to confirm whether you process the individual's data and to provide a copy plus context: purposes, categories, recipients, retention periods, and the source. It does not require you to hand over everything verbatim.

• Third-party data must be redacted. A beneficial ownership graph, a shared transaction, or an adverse-media match naming other people cannot be disclosed wholesale.
• Tipping-off risk is real. Many jurisdictions prohibit revealing that a suspicious activity report or internal investigation exists. Exemptions for crime prevention let you withhold this material — but you must apply them deliberately, not as a blanket refusal.
• Internal risk scores and rules logic may be provided as outputs and explanations without exposing the exact detection thresholds that would let a fraudster reverse-engineer your controls.

Build a redaction workflow that classifies each field before release. The goal is a complete, honest answer that still protects other data subjects and your monitoring integrity.

Why Deletion Usually Loses to Retention

The right to erasure has explicit carve-outs. Article 17(3) preserves data needed for "compliance with a legal obligation" — and AML statutes impose exactly that. In most regimes, verification records and transaction histories must be kept for five years after the relationship ends, sometimes longer under a legal hold.

So the correct response to a deletion request from an active or recently offboarded customer is often a documented refusal, citing the specific obligation. What you can do:

• Delete data that never had a lawful retention basis — marketing preferences, optional profile fields, abandoned onboarding attempts that produced no reportable outcome.
• Restrict processing so retained records are used only for compliance, not analytics or product decisions.
• Schedule automatic erasure for the moment the retention clock expires, rather than keeping records indefinitely "just in case."

The defensible position is precise: retain what the law requires, for exactly as long as it requires, and delete the rest on time.

Identity-Proofing the Requester

Fulfilling a DSAR for an impostor is itself a breach. Before releasing a dossier of identity documents and financial history, verify that the requester is the data subject — at a proportionate level. Do not demand a fresh copy of a passport you already hold; that expands the data you process. Instead, challenge with information only the genuine customer would know, or use the authenticated channel they already trust.

Chat-based verification helps here. If onboarding happened inside an authenticated Telegram or WhatsApp session, the same authenticated identity can gate the access request, avoiding a new document upload and a new copy of sensitive data sitting in an email inbox.

Operationalizing the Response

Treat DSARs as a repeatable process, not a fire drill:

• Log receipt immediately and start the statutory clock; track the deadline per jurisdiction.
• Run a defined search across every store — verification records, screening hits, monitoring alerts, support tickets, and backups.
• Apply redaction and exemption rules consistently, and record the reasoning for each withheld item.
• Deliver through a secure channel, and keep a minimal audit trail of what was disclosed and when.

Two engineering choices make all of this cheaper: data minimization, so there is less to search and redact, and configurable retention, so deletion happens automatically at term. When you collect less and expire records on schedule, most access requests become short, accurate, and low-risk to answer.