New Customer Due Diligence (CDD) Data Points under AMLR
Structural purpose
Section 1 of Chapter III of the AMLR establishes the mandatory data architecture of customer due diligence (CDD).
It prescribes in legally binding form:
- which data must exist,
- when the data must be collected,
- how long the data remains valid,
- when the data must be refreshed, and
- how the reliability and correctness of the data must be demonstrated to supervisors.
Across Articles 19–28 AMLR, CDD is transformed from a document-based obligation into a time-stamped, versioned and auditable dataset, governed by explicit trigger logic, data-age rules and failure-handling mechanisms.
CDD trigger, scope and validity logic
Article 19 AMLR defines the entry points and invalidation points of CDD.
Its core function is to require data points that enable supervisors to determine:
- when CDD must be applied, and
- when previously collected CDD data can no longer be relied upon.
Required data points
- Existence and start of the business relationship
- Occasional transaction values and aggregation logic
- Linked-transaction indicators
- Sector-specific thresholds (e.g. cash transactions, gambling, CASPs)
- Suspicion indicators
- Doubts concerning identification data
- Doubts concerning the authority or identity of interacting persons
Data-age logic
- Once doubts arise, existing CDD data becomes legally stale, irrespective of its chronological age.
- CDD validity is therefore event-driven, not merely time-driven.
Core CDD dataset and demonstrability
Article 20 AMLR defines the substantive CDD dataset and imposes a continuous obligation to demonstrate its appropriateness at any time.
Required data points
- Customer identity data
- Beneficial ownership and control-structure data
- Purpose and intended-nature data
- Sanctions and 50 %-control screening results
- Business activity or occupation data
- Transaction-monitoring outputs
- PEP / RCA determinations
- Third-party beneficiaries
- Authorised representatives
Data-age logic
- CDD data must remain sufficiently current to support ongoing monitoring.
- Article 20 does not prescribe fixed refresh cycles but links data validity to:
- transaction consistency,
- changes in the risk profile,
- doubts, suspicions or anomalies.
- Article 20(4) introduces a continuous demonstrability requirement, necessitating full timestamping, versioning and evidence retention.
CDD failure handling and record evolution
Article 21 AMLR governs situations in which CDD cannot be completed.
Required data points
- Which CDD measure failed
- Reason for failure
- Timestamp of failure determination
- Mandatory consequence applied (refusal, termination, restriction)
- FIU-reporting consideration
- Statutory exceptions (e.g. life-insurance alternatives)
- Professional-privilege carve-outs
Data-age logic
- All records relating to CDD failure must be updated whenever CDD is reviewed under Article 26.
- This creates a mandatory linkage between failure records and ongoing monitoring cycles.
Identity data model and verification evidence
Article 22 AMLR establishes the identity schema for all relevant actors.
Required identity datasets
- Natural persons
- Legal entities
- Trustees and similar legal arrangements
- Other legal organisations
- Beneficial owners
- Senior managing officials (fallback mechanism)
- Virtual-IBAN users
- Trust beneficiaries (including deferred-identification cases)
Data-age and timing rules
- Virtual-IBAN identity data must be retrievable within 5 working days.
- Beneficiary identification may be deferred until payout or exercise of rights.
- BO verification requires register-consultation timestamps.
- Exhaustion-of-means and anti-tipping-off logic must be documented.
Verification timing and freshness constraints
Article 23 AMLR governs when identity verification must be completed.
Required data points
- Verification-completion timestamps
- Relationship-establishment or transaction-execution timestamps
- Lawful postponement justifications
- Safeguards preventing transactions during incomplete verification
Data-age logic
- Verification must normally occur before onboarding or transaction execution.
- Postponement is permitted only under controlled and documented conditions.
- Account opening without verification requires transaction blocking.
- Reliance on registers requires valid or recently issued extracts.
Beneficial-ownership discrepancy governance
Article 24 AMLR establishes a formal register-discrepancy lifecycle.
Required data points
- Register extracts and consultation timestamps
- Discrepancy-detection timestamp
- Discrepancy classification
- Reporting or customer-correction decision
- Customer invitation deadlines
- Escalation and reporting timestamps
Data-age logic
- Discrepancies must be reported within 14 calendar days of detection.
Purpose and intended nature (ex-ante data)
Article 25 AMLR requires an ex-ante understanding of the business relationship or transaction.
Required data points
- Economic rationale
- Expected activity volumes
- Source of funds
- Destination of funds
- Customer business activity or occupation
- Intended use of high-value goods (commercial vs non-commercial)
Data-age logic
- This dataset must exist before onboarding or execution.
- It becomes stale when actual behaviour deviates, directly triggering Article 26 monitoring obligations.
Ongoing monitoring and formal data-refresh cycles
Article 26 AMLR functions as the central data-age engine of AMLR.
Required data points
- Continuous transaction-monitoring outputs
- Full product and service coverage
- Versioned customer profiles
- Group-wide relationship information
Periodic refresh requirements
- High-risk customers: update at least every 1 year
- All other customers: update at least every 5 years
Event-driven updates
Mandatory updates occur upon:
- change in customer circumstances,
- legal contact obligations,
- awareness of relevant facts.
Separate sanctions-verification cycle
Sanctions conditions must be:
- verified regularly, and
- verified immediately upon new designations for credit and financial institutions.
Temporary UN-to-EU sanctions bridge records
Article 27 AMLR introduces a time-bounded recordkeeping regime.
Required data points
- Point-in-time snapshot of funds and assets when UN sanctions are made public
- All attempted and executed transactions during the interim period
Data-age window
Records are strictly bounded by:
- T₀: publication of UN sanctions
- T₁: application of EU sanctions
RTS-driven future standardisation of CDD data
Article 28 (1) AMLR mandates AMLA to issue regulatory technical standards specifying:
- harmonised CDD data requirements,
- permitted simplified due-diligence measures,
- e-money risk features,
- reliable verification sources,
- mandatory attributes for eID and trust services.
Data-governance implication
CDD under AMLR is designed to become fully standardised, machine-interpretable and supervisory-calculable. Obliged entities must therefore already structure their CDD data models to be RTS-ready, even before RTS adoption.
Sources: