DOMAIN:EU_REGULATION:KYC_DATA_RETENTION¶

OWNER: eric ALSO_USED_BY: julian, aimee, hugo, ALL dev agents building regulated features UPDATED: 2026-03-26 SCOPE: KYC data retention rules, GDPR vs AML tension, storage requirements, deletion policies

PURPOSE¶

KYC data retention sits at the intersection of two conflicting legal obligations. AML law requires retaining customer data for years after the relationship ends. GDPR requires deleting personal data when no longer necessary. This page resolves that tension with clear rules for what to keep, when to delete, and how to prove compliance. Applies to both GE's own client records (Eric) and client project implementations.

LEGAL FRAMEWORK¶

Wwft RETENTION (Dutch AML Law)¶

ARTICLE: Wwft Article 33 PERIOD: 5 years after end of business relationship or execution of occasional transaction SCOPE: all CDD data, transaction records, risk assessments, screening results

WHAT_CONSTITUTES_END_OF_RELATIONSHIP: - contract terminated or expired - last service delivered and final payment received - formal notification of relationship end by either party - for GE: project completion + final invoice paid + warranty period ended

START_OF_CLOCK: - retention clock starts on the day the business relationship formally ends - NOT from the date of data collection - NOT from the date of the last transaction - document the precise date the relationship ended

AMLR RETENTION (from Jul 2027)¶

HARMONISED: 5-year retention period across all EU Member States CHANGE: Member States can no longer extend beyond 5 years (some currently allow up to 10) EXCEPTION: competent authorities may request extended retention for specific investigations FORMAT: records must be retrievable in machine-readable format NOTE: AMLR applies directly — no transposition needed

STORAGE_LIMITATION (Article 5(1)(e)): - personal data kept only as long as necessary for processing purposes - must define and document retention periods for each data category

DATA_MINIMISATION (Article 5(1)(c)): - collect only data adequate, relevant, and limited to what is necessary - do not retain more KYC data than legally required

RIGHT_TO_ERASURE (Article 17): - data subjects can request deletion of personal data - EXCEPTION: does not apply where processing is necessary for compliance with legal obligation - during active retention period: erasure request can be refused with documented justification - after retention period: erasure becomes mandatory if no other lawful basis exists

PURPOSE_LIMITATION (Article 5(1)(b)): - KYC data collected for AML compliance may NOT be repurposed - do NOT use KYC data for marketing, analytics, or product development - do NOT share KYC data with teams that have no AML compliance role

RESOLVING THE TENSION¶

LEGAL_BASIS: Article 6(1)(c) GDPR — processing necessary for compliance with legal obligation. DURING_RETENTION: Wwft/AMLR obligation overrides right to erasure. AFTER_RETENTION: GDPR prevails — data must be deleted unless another lawful basis exists. DOCUMENTATION: document the legal basis for every data retention decision. DPO_INVOLVEMENT: involve Data Protection Officer in retention policy design.

WHAT MUST BE RETAINED¶

IDENTITY DOCUMENTS¶

KEEP: copies of documents used for identity verification INCLUDES: passport copies, ID card copies, residence permit copies INCLUDES: selfie/liveness images used for biometric matching FORMAT: encrypted digital copies, originals never retained PERIOD: 5 years after end of business relationship

IMPORTANT: store copies at the minimum resolution needed for verification. Do NOT store higher resolution than necessary (data minimisation). Original biometric templates (facial encodings) should be deleted after match is confirmed. Keep only the match result (passed/failed + score) in the audit log.

VERIFICATION RECORDS¶

KEEP: complete record of every verification check performed INCLUDES: - check type, date, result, confidence score - provider name, session ID, verification method used - reviewer identity (if human review was performed) - decision made (approve, reject, request more info) - reasoning for the decision

PERIOD: 5 years after end of business relationship

TRANSACTION RECORDS¶

KEEP: records of all transactions within the business relationship INCLUDES: - transaction date, amount, currency - parties involved (payer, payee) - transaction description/purpose - payment method and reference - for GE: all invoices, payments received, project contracts

PERIOD: 5 years after transaction execution NOTE: some transactions may have independent retention periods (e.g., tax records: 7 years in NL) RESOLUTION: apply the longest applicable retention period, document the basis

RISK ASSESSMENTS¶

KEEP: all risk assessments performed during the relationship INCLUDES: - initial risk assessment at onboarding - periodic review risk assessments - risk score changes and reasoning - risk factor analysis (country, product, customer, transaction)

PERIOD: 5 years after end of business relationship

SCREENING RECORDS¶

KEEP: all PEP and sanctions screening results INCLUDES: - lists screened against (with version/date) - matches found (including false positives) - investigation notes for each match - clearance reasoning for false positives - confirmed match actions taken

PERIOD: 5 years after end of business relationship

SUSPICIOUS ACTIVITY REPORTS¶

KEEP: internal and external SAR/UTR records INCLUDES: - internal suspicion reports (even if not escalated to FIU) - FIU filings (UTR reference numbers) - investigation documentation - outcome of FIU process (if communicated)

PERIOD: 5 years after filing SPECIAL: SARs may be subject to extended retention if investigation is ongoing WARNING: SAR existence is confidential — tipping-off prohibition applies to stored records too

CORRESPONDENCE¶

KEEP: all correspondence related to KYC/AML compliance INCLUDES: - requests for information sent to client - client responses - internal escalation emails/messages - senior management approvals (for EDD)

PERIOD: 5 years after end of business relationship

WHAT MUST BE DELETED¶

AFTER RETENTION PERIOD EXPIRES¶

DELETE: - identity document copies - selfie/liveness images - biometric data (facial encodings, if any were retained) - detailed transaction records (unless tax retention applies) - raw provider response payloads - document images stored by verification provider (confirm provider deletion)

MAY_RETAIN (anonymised): - aggregate statistics (number of checks, pass/fail rates) - anonymised risk metrics - system performance data (response times, error rates)

DATA NO LONGER NEEDED FOR AML PURPOSE¶

DELETE_IMMEDIATELY: - draft or incomplete verification sessions never completed - test data from sandbox/development environments - duplicate copies of documents - temporary processing files

REVIEW_AND_DELETE: - data collected beyond what was necessary (data minimisation violation) - data from verification providers that exceeded the agreed scope - internal notes that contain unnecessary personal data

PROVIDER DATA DELETION¶

VERIFY: - confirm verification provider's data retention policy - ensure provider deletes verification data per agreed DPA terms - typical provider retention: 30-90 days post-verification (varies) - if provider retains longer: ensure contractual basis exists or request deletion - document provider deletion confirmation

STORAGE REQUIREMENTS¶

ENCRYPTION¶

AT_REST: - all KYC data encrypted at rest (AES-256 minimum) - database-level encryption (PostgreSQL TDE or application-level) - file storage encryption (S3 SSE-S3 or SSE-KMS equivalent) - encryption keys managed via Vault (for GE: existing Vault infrastructure)

IN_TRANSIT: - TLS 1.2+ for all data transfers - mTLS for service-to-service communication where possible

KEY_MANAGEMENT: - encryption keys rotated annually (minimum) - key access restricted to authorised services only - key rotation must not break access to retained data - old keys retained until all data encrypted with them is deleted

ACCESS CONTROL¶

PRINCIPLE_OF_LEAST_PRIVILEGE: - only compliance roles can access full KYC records - dev agents cannot access production KYC data - separate database roles for read/write/admin on KYC tables - no direct database access — all access through application layer

ACCESS_LOGGING: - every access to KYC records must be logged - log includes: who, when, what record, what action - access logs retained for same period as KYC records - access logs are immutable (append-only)

SEGREGATION: - KYC data stored in separate schema or database from general application data - consider separate encryption keys for KYC data - backup and restore procedures for KYC data tested independently

PHYSICAL STORAGE¶

LOCATION: EU data centres only (GDPR territorial scope) PROVIDER: ensure cloud provider has EU region with data residency guarantee BACKUP: encrypted backups with same retention policy as primary data DISASTER_RECOVERY: KYC data included in DR plan with defined RTO/RPO

CROSS-BORDER CONSIDERATIONS¶

WITHIN_EEA: personal data flows freely between EEA countries under GDPR BETWEEN_GROUP_ENTITIES: Binding Corporate Rules (BCRs) or SCCs if sharing KYC data WITH_REGULATORS: mandatory sharing with competent authorities and FIUs (legal obligation)

THIRD-COUNTRY TRANSFERS¶

ADEQUACY_DECISIONS: data can flow to countries with EU adequacy decisions CURRENT_ADEQUACY: UK (until Dec 2031), Japan, South Korea, Switzerland, Canada (commercial), and others SCCs: Standard Contractual Clauses required for transfers to non-adequate countries TRANSFER_IMPACT_ASSESSMENT: required for SCC-based transfers (assess third-country surveillance laws)

FOR_GE: - GE operates primarily in NL — most KYC data stays within EEA - UK-based verification providers: adequacy decision covers transfers (until Dec 2031) - US-based providers: EU-US Data Privacy Framework covers transfers (verify provider participation) - if client is outside EEA: assess transfer mechanisms before sharing KYC data

FIU_NEDERLAND: - reports filed via goAML (encrypted portal) - FIU may share reports with counterpart FIUs in other EU Member States - Egmont Group facilitates global FIU-to-FIU information sharing - you do NOT control onward sharing by FIU — this is a regulatory function

IMPLEMENTATION: AUTOMATED RETENTION POLICIES¶

RETENTION SCHEDULE TABLE¶

export const retentionSchedule = pgTable('retention_schedule', {
  id: uuid('id').defaultRandom().primaryKey(),
  clientId: uuid('client_id').notNull().references(() => clients.id),
  relationshipEndDate: date('relationship_end_date'),
  retentionEndDate: date('retention_end_date'), // end_date + 5 years
  deletionScheduledDate: date('deletion_scheduled_date'), // retention_end + 30 days grace
  deletionExecutedAt: timestamp('deletion_executed_at'),
  legalHold: boolean('legal_hold').default(false), // blocks deletion if true
  legalHoldReason: text('legal_hold_reason'),
  legalHoldSetBy: text('legal_hold_set_by'),
  status: text('status').notNull().default('active'),
  // 'active' | 'retention' | 'scheduled_deletion' | 'deleted' | 'legal_hold'
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
});

DELETION SCHEDULING¶

PROCESS: 1. business relationship ends → set relationship_end_date 2. compute retention_end_date = relationship_end_date + 5 years 3. compute deletion_scheduled_date = retention_end_date + 30 days (grace period) 4. daily cron job checks for records where deletion_scheduled_date <= today 5. before deletion: check legal_hold flag — if true, skip and alert compliance 6. execute deletion: remove documents, anonymise records, log deletion 7. set deletion_executed_at and status = 'deleted'

WHAT_DELETION_MEANS: - identity document copies: permanently deleted from storage - selfie/liveness images: permanently deleted - raw provider responses: permanently deleted - KYC record: anonymised (remove PII, retain structure for audit) - audit log: retained (contains no raw PII, only actions and outcomes) - retention schedule record: retained (proves deletion was performed)

LEGAL HOLD MECHANISM¶

PURPOSE: prevent automated deletion when investigation or regulatory request is active.

TRIGGERS: - active investigation by competent authority - pending or ongoing litigation - regulatory audit announced - SAR under active investigation by FIU

PROCESS: 1. compliance officer sets legal_hold = true with reason 2. automated deletion skips all records with legal_hold = true 3. when hold is lifted: compliance officer clears flag 4. deletion resumes on next scheduled run

IMPORTANT: legal hold overrides GDPR erasure requests during hold period. Document the hold and reason — defensible if challenged by data subject.

DELETION VERIFICATION¶

POST_DELETION_CHECK: - verify documents deleted from storage (check storage backend) - verify database records anonymised - verify provider has deleted verification data (confirm with provider) - verify backups will be rotated out (old backups containing deleted data) - log verification result

BACKUP_ROTATION: - backups older than retention period must be destroyed - if backup contains mix of retained and deleted data: ensure deleted data is not restored from backup (application-level check on restore) - consider: separate KYC backup cycle aligned with retention schedule

EVIDENCE PRESERVATION FOR REGULATORY AUDITS¶

WHAT REGULATORS MAY REQUEST¶

REGULATORS: DNB (De Nederlandsche Bank), AFM, FIU-Nederland, tax authority (Belastingdienst)

TYPICAL_REQUESTS: - complete KYC file for specific customer(s) - evidence of risk-based approach (policy + implementation) - evidence of periodic reviews performed - evidence of sanctions/PEP screening and results - evidence of SAR filings and investigation - evidence of staff training - data retention and deletion policies - audit trail for specific decisions

RESPONSE READINESS¶

MUST_BE_ABLE_TO_PRODUCE: - complete customer KYC file within reasonable timeframe (days, not weeks) - evidence in machine-readable format (AMLR requirement from 2027) - chronological audit trail of all actions and decisions - policy documentation (current and historical versions)

PREPARATION: - maintain indexed, searchable KYC record archive - test retrieval process periodically (annual drill) - designate compliance contact for regulatory requests - document data locations and access procedures

PROVING DELETION COMPLIANCE¶

WHEN_ASKED: "Show us you deleted data as required after retention period."

EVIDENCE: - retention schedule records showing end dates and deletion dates - deletion execution logs with timestamps - storage verification logs confirming data removed - backup rotation records - provider deletion confirmations

GE-SPECIFIC RULES: ERIC'S CLIENT RECORDS¶

WHAT ERIC MUST KEEP¶

FOR_EACH_CLIENT: - identity verification records (document type, verification date, result) - KvK extract obtained at onboarding - UBO information (declaration or register check) - risk assessment (initial + periodic reviews) - sanctions and PEP screening results (initial + ongoing) - contract documentation (not KYC per se, but part of relationship record) - all correspondence related to due diligence

WHERE TO STORE¶

PRIMARY: PostgreSQL database (admin-ui, encrypted at rest) DOCUMENTS: encrypted object storage (document images, KvK PDFs) AUDIT_TRAIL: kyc_audit_log table (append-only) NEVER: local filesystem, email attachments, chat logs as sole record

RETENTION TIMELINE¶

EXAMPLE: - client onboarding: Jan 2026 - project completed, final invoice paid: Jun 2026 - warranty period ends: Jun 2027 - relationship formally ends: Jun 2027 - retention period: Jun 2027 → Jun 2032 (5 years) - deletion scheduled: Jul 2032 (30-day grace) - all KYC data deleted: Jul 2032

DURING_RELATIONSHIP: "We need this data for ongoing AML compliance." Refuse and document. DURING_RETENTION: "Legal obligation under Wwft Article 33 requires 5-year retention." Refuse and document. AFTER_RETENTION: "Processing and deleting your data." Execute deletion within 30 days. ALWAYS: respond to erasure request within 1 month (GDPR Article 12(3)).

CHECKLIST FOR CLIENT PROJECT IMPLEMENTATIONS¶

When building KYC features for client projects:

[ ] define retention periods per data category in project specification
[ ] implement automated retention schedule with deletion scheduling
[ ] implement legal hold mechanism
[ ] encrypt all KYC data at rest and in transit
[ ] implement access control with principle of least privilege
[ ] implement immutable audit log for all KYC actions
[ ] implement GDPR erasure request handling (refuse during retention, execute after)
[ ] confirm verification provider's data retention and deletion policy
[ ] implement deletion verification (storage + database + provider)
[ ] implement backup rotation aligned with retention schedule
[ ] document retention policy for client's compliance team
[ ] test regulatory audit readiness (retrieval + evidence production)

READ_ALSO: kyc-aml.md, kyc-processes.md, kyc-implementation.md, kyc-for-platforms.md

DOMAIN:EU_REGULATION:KYC_DATA_RETENTION¶

PURPOSE¶

LEGAL FRAMEWORK¶

Wwft RETENTION (Dutch AML Law)¶

AMLR RETENTION (from Jul 2027)¶

GDPR PRINCIPLES IN TENSION¶

RESOLVING THE TENSION¶

WHAT MUST BE RETAINED¶

IDENTITY DOCUMENTS¶

VERIFICATION RECORDS¶

TRANSACTION RECORDS¶

RISK ASSESSMENTS¶

SCREENING RECORDS¶

SUSPICIOUS ACTIVITY REPORTS¶

CORRESPONDENCE¶

WHAT MUST BE DELETED¶

AFTER RETENTION PERIOD EXPIRES¶

DATA NO LONGER NEEDED FOR AML PURPOSE¶

PROVIDER DATA DELETION¶

STORAGE REQUIREMENTS¶

ENCRYPTION¶

ACCESS CONTROL¶

PHYSICAL STORAGE¶

CROSS-BORDER CONSIDERATIONS¶

DATA SHARING BETWEEN EU ENTITIES¶

THIRD-COUNTRY TRANSFERS¶

FIU INFORMATION SHARING¶

IMPLEMENTATION: AUTOMATED RETENTION POLICIES¶

RETENTION SCHEDULE TABLE¶

DELETION SCHEDULING¶

LEGAL HOLD MECHANISM¶

DELETION VERIFICATION¶

EVIDENCE PRESERVATION FOR REGULATORY AUDITS¶

WHAT REGULATORS MAY REQUEST¶

RESPONSE READINESS¶

PROVING DELETION COMPLIANCE¶

GE-SPECIFIC RULES: ERIC'S CLIENT RECORDS¶

WHAT ERIC MUST KEEP¶

WHERE TO STORE¶

RETENTION TIMELINE¶

GDPR ERASURE REQUESTS FROM CLIENTS¶

CHECKLIST FOR CLIENT PROJECT IMPLEMENTATIONS¶