Guideline 1 — Ongoing customer-information updates (perpetual KYC)
AMLA's first guideline is about keeping customer information accurate and up to date over time through two kinds of review — periodic (time-based) and event-driven (triggered by risk-relevant change) — applied on a risk basis. This page maps each requirement to the Atlas roadmap.
Every capability on this page is planned, not shipped. It describes the target design Atlas builds toward to meet the AMLA draft guidelines on ongoing monitoring (public hearing 2 July 2026, AMLR Article 26). Each capability links to its tracking issue under the AMLA ongoing-monitoring readiness epic (81 features). Interactive roadmap: readiness dashboard.
Engineering/product documentation, not legal advice or a certification claim. The AMLA guidelines are draft; public consultation closes 3 September 2026, final draft expected Q4 2026, with NCA comply-or-explain declarations in Q1 2027. The AMLR itself applies from 10 July 2027.
The review lifecycle we build toward
Periodic reviews
AMLA requires periodic, time-based reviews whose depth and frequency scale to customer risk, with high-risk customers reviewed at least annually — and, crucially, the review must actively re-examine the whole customer file (identity, beneficial ownership, purpose, source of funds, PEP status per para 21), not passively infer no change from transaction analysis. Atlas already carries the review-cadence intent (a risk-tier interval table) but computes the interval and discards it; the roadmap persists it, fires it on schedule, and drives a per-element attestation review.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Persisted risk-based review cadence engine driving companies.next_review_date | 🟡 Planned — extend · delta over #103 | MUST | #583 |
| Review due/overdue portfolio dashboard with escalation and MLRO MI | 🔴 Planned — net-new · delta over #355 | MUST | #584 |
| Periodic full-file review workflow with per-element attestation checklist | 🔴 Planned — net-new · delta over #355 | MUST | #588 |
| Immutable PeriodicReview outcome record (element-level evidence) | 🔴 Planned — net-new · delta over #278 | MUST | #589 |
| Event-driven review-date recalculation and pKYC trigger wiring | 🔴 Planned — net-new · delta over #355 | SHOULD | #587 |
Event-driven reviews & triggers
Beyond the clock, reviews must also be event-driven — triggered by a change in ownership, a new PEP status, a profile deviation, or a beneficial owner relocating to a higher-risk country — with serious triggers forcing a full KYC refresh and minor ones a targeted update, without undue delay. Atlas already has a mutation-queue change-detection engine; the roadmap wires the provider-refresh path through it so changes surface as reviewable events instead of silent overwrites.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Wire provider ingestion through the existing mutation-queue change-detection engine | 🟡 Planned — extend · delta over #355 | MUST | #579 |
| Trigger taxonomy with serious-vs-minor routing: full KYC refresh vs targeted update | 🟡 Planned — extend · delta over #355 | MUST | #580 |
| Automatic risk-profile reassessment on trigger, with 'without undue delay' SLA evidence | 🟡 Planned — extend · delta over #355 | MUST | #581 |
| Inbound change feeds: provider webhooks, registry monitoring subscriptions, scheduled re-pull fallback | 🔴 Planned — net-new · delta over #355 | MUST | #582 |
| Cross-run investigation diffing: machine-generated 'changes since last review' | 🟡 Planned — extend · delta over #355 | SHOULD | #585 |
| Make activate_pkyc real: persisted per-relationship monitoring profile consulted by the trigger engine | 🟡 Planned — extend · delta over #355 | SHOULD | #586 |
Identity documents & digital identity
Identity documents must be handled on a risk basis — an expired passport does not mandate automatic recollection; the decision weighs risk level, issuing country and how long it has been expired. AMLA also confirms document includes eIDAS electronic identification and EU Digital Identity Wallets (AMLR Art 22(6)). The roadmap adds a typed identity-document model with expiry, a risk-based recollection decision engine, and digital-identity verification methods.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| IdentityDocument model: typed ID docs with expiry, issuing country, and holder linkage | 🟡 Planned — extend · delta over #105 | MUST | #603 |
| Risk-based expired-document decision engine with recorded rationale | 🔴 Planned — net-new · delta over #105 | MUST | #604 |
| eIDAS / EUDI wallet verification-method support (AMLR Art 22(6)) | 🔴 Planned — net-new | MUST | #605 |
| Capture structured ID-document metadata at upload (OCR/MRZ or analyst entry) | 🟡 Planned — extend · delta over #105 | SHOULD | #624 |
| Wire ID-document expiry into risk rules and the perpetual-KYC trigger set | 🟡 Planned — extend · delta over #105 | SHOULD | #625 |
Non-continuous relationships
A long-lived relationship with no material change, no new activity and no new services (a non-continuous relationship) may receive lighter, less-frequent periodic review — but only against a documented list of risk factors, never a tick-box. The roadmap adds relationship-activity classification, a versioned eligibility factor list with per-factor evidenced assessment, and an audit trail for grant/renewal/revocation of lighter-review status.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Relationship activity classification (continuous vs non-continuous) on the customer record | 🔴 Planned — net-new · delta over #355 | MUST | #606 |
| Versioned lighter-review eligibility factor list with per-factor evidenced assessment | 🟡 Planned — extend | MUST | #607 |
| Lighter-review workflow template plus depth-selection logic | 🟡 Planned — extend | MUST | #608 |
| Persist next_review_date with an activity-aware interval formula | 🟡 Planned — extend · delta over #103 | MUST | #609 |
| Auditable lifecycle for lighter-review eligibility (grant, renewal, revocation) | 🔴 Planned — net-new · delta over #278 | SHOULD | #626 |
Suspension & restriction (Article 21)
When a customer fails to respond to a CDD-update request, AMLR Article 21 permits an intermediary step before full offboarding: temporarily suspend or restrict transactions/services until updated KYC arrives, subject to safeguards. Atlas today has no post-onboarding lifecycle beyond onboard/reject; the roadmap adds suspended/restricted/offboarded states with a validated transition machine, a CDD-outreach case with a non-response clock, and the Article 21 safeguard assessment.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Post-onboarding lifecycle state machine with suspended/restricted/offboarded states | 🟡 Planned — extend | MUST | #610 |
| CDD outreach case object with contact attempts and non-response clock | 🔴 Planned — net-new · delta over #108 | MUST | #611 |
| Structured Art 21 safeguard assessment gating the suspension decision | 🔴 Planned — net-new · delta over #106 | MUST | #612 |
| Wire portal timeout_hours/max_reminders into the workflow engine with an escalation route | 🟡 Planned — extend · delta over #103 | MUST | #613 |
| Outbound customer-status webhook/API for suspension and reinstatement events | 🔴 Planned — net-new | SHOULD | #627 |
| Suspension aging dashboard with mandatory review deadline and forced resolution | 🔴 Planned — net-new · delta over #355 | SHOULD | #628 |
Traceability
All Guideline 1 features are tracked under the AMLA ongoing-monitoring readiness epic. The periodic-review spine (Phase 1) is the prerequisite for everything else on this page — a cadence that persists and fires, and change-detection wired into the provider-refresh path.