AMLA ongoing-monitoring readiness

On 2 July 2026 AMLA held its public hearing on the draft guidelines for ongoing monitoring and transaction monitoring of business relationships under AMLR Article 26. This page — and the two that follow it — map those guidelines, requirement by requirement, to the Atlas roadmap.

Roadmap status — not yet implemented

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.

Not legal advice · consultation status

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 readiness picture in one line

Atlas is a strong onboarding-time KYB engine, but the ongoing half of the customer lifecycle is largely unbuilt, and the review cadence that should drive it is computed and then thrown away. A 14-lane gap analysis produced 81 tracked features: 37 capabilities fully absent, 44 partial; 49 rated must for compliance.

Dimension	Count
Total tracked features	81
Fully absent (net-new)	37
Partial (extend existing)	44
Must for compliance	49
Overlap existing issues (scoped to the delta)	49

The one strategic decision

Atlas should not build a payment-transaction monitoring engine. It is entity-KYB, not payment flows. The proportionate, technologically-neutral answer AMLA would accept for Guideline 2 is a documented scope boundary plus an alert-ingestion integration: a tenant-authenticated webhook that attaches normalized alerts from a partner transaction-monitoring system onto the resolved entity, so no risk is lost between platforms. Everything under Guideline 2 is scoped around that boundary.

The five load-bearing gaps

Eighty-one features, but almost everything hangs off these five. Fix these and the rest is incremental.

1. The review cadence never fires. The risk-based interval is computed then discarded — companies.next_review_date exists as a column but is never written, there is no Temporal Schedule, and schedule_review / activate_pkyc are log-only stubs. The spine of perpetual KYC is inert.
2. No expected-behaviour baseline. Atlas records who the customer is but never why the relationship exists or what activity is expected, so deviation is undefinable — the prerequisite AMLA names for all monitoring.
3. Change-detection is built, then bypassed. A real mutation-queue engine exists, but the provider-refresh path bypasses it, so an ownership change or new PEP flag is silently merged. Wiring it is the highest-leverage quick win.
4. No alert / case lifecycle. Findings are terminal report artifacts — no case entity, no state machine, no evidenced four-eyes disposition.
5. Transaction-risk silently scores zero. The EBA matrix's transaction_patterns factor is default_score: 0 with no data source, so every company scores that dimension green.

Delivery roadmap

Phase	Theme	Features	What it unlocks
1	Make perpetual KYC real	9	The review spine — a cadence that persists and actually fires, and change-detection that is no longer bypassed.
2	Baseline & case lifecycle	15	What monitoring needs to mean anything — an expected-behaviour baseline, deviation detection, an alert/case lifecycle, and closing the transaction-risk-scores-zero hole.
3	Lifecycle, signals & governance	34	Article 21 suspension states, staff observation capture, identity-document risk logic, human challenge of the AI verdict, and the business-wide risk assessment that gates configuration.
4	TM boundary & effectiveness	23	The integration edge to partner transaction-monitoring systems, retrospective cross-portfolio analysis, effectiveness MI, calibration, and monitoring data quality.

The two guidelines

• Guideline 1 — Perpetual KYC — periodic and event-driven reviews, expired documents and digital identity, non-continuous relationships, and the Article 21 suspension/restriction step.
• Guideline 2 — Transaction & activity monitoring — the TM scope boundary, activity & behavioural monitoring, the expected-behaviour baseline, monitoring timing, the alert/case lifecycle, effectiveness testing and monitoring data quality.
• Broader AML-package obligations — the wider AMLR / AMLD6 / AMLA-RTS obligations beyond Article 26 that Atlas tracks to stay compliant-by-design.

Cross-cutting: governance, technology & proportionality

Three requirements run through both guidelines — automated-tool governance and the right to challenge a machine verdict, and the business-wide risk assessment that must precede any monitoring configuration.

Automated-tool governance & explainability

AMLA will only endorse automated tools where safeguards exist first: tools are defined, tested and calibrated, and humans can challenge the output — explainability here means accountability and justifiability to supervisors and audit, not full technical transparency. Responsibility always stays with the obliged entity. The roadmap adds an analyst challenge/override workflow for the LLM assessment verdict, a pre-activation evaluation gate and calibration record for prompts/models, a retained decision-evidence pack, and an automated-tool register.

Capability	Status	Priority	Tracking
Analyst challenge-and-override workflow for LLM assessment verdicts	🟡 Planned — extend	MUST	#620
Pre-activation evaluation gate and calibration record for prompts and model configs	🔴 Planned — net-new	MUST	#621
Retained decision-evidence pack per AI assessment (input, prompt ref, raw output, trace link)	🟡 Planned — extend · delta over #365	MUST	#622
Audited configuration change log and endorsed-config enforcement for all LLM settings	🔴 Planned — net-new · delta over #278	MUST	#623
Automated-tool register with endorsement lifecycle and periodic review	🔴 Planned — net-new	SHOULD	#634
Quality-score thresholds with human-review triggers and judge governance	🟡 Planned — extend	SHOULD	#635

Accountability & proportionality

Monitoring configuration must follow a prior, documented business-wide risk assessment — adopting default settings without one is explicitly poor practice — and accountability must be clear where agents, intermediaries or group entities are involved, including the risk of a customer that itself acts as an intermediary. The roadmap adds a per-tenant business-wide risk assessment record that gates configuration, a risk-tiered monitoring policy layer, and intermediary-role modelling.

Capability	Status	Priority	Tracking
Tenant business-wide risk assessment record gating monitoring configuration	🟡 Planned — extend	MUST	#617
Model customer-as-intermediary role with dedicated risk factors	🟡 Planned — extend · delta over #281	MUST	#618
Per-tenant risk-tiered monitoring policy layer consumed by perpetual KYC	🟡 Planned — extend · delta over #355	MUST	#619
Compliance role model with four-eyes approval and concern-escalation routing	🟡 Planned — extend	SHOULD	#632
Responsibility and reliance register per tenant (group/third-party arrangements)	🔴 Planned — net-new	SHOULD	#633
CASP segment and crypto-asset exposure risk factors	🔴 Planned — net-new	COULD	#636

How this relates to the existing AMLR work

This roadmap is additive to the EBA / AMLR compatibility design and the AMLR compliance milestone (issues #271–#284). Where a feature overlaps existing tracked work — the perpetual-KYC epic #355 anchors much of Guideline 1 — the issue is scoped to the AMLA-specific delta, not the whole of the parent issue.