Guideline 2 — Transaction & activity monitoring
AMLA's second guideline deliberately widens monitoring beyond transactions to activity and behaviour, and insists that effectiveness be demonstrated — meaningful detection and timely escalation, not alert volume. The defining design decision for Atlas is what it should and should not own.
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 scope boundary
Atlas does not build a payment monitor. It consumes a partner system's transaction alerts onto the resolved entity and combines them with the entity-side signals it is uniquely good at — ownership changes, adverse media, behavioural observations, and deviation from an expected-activity baseline.
Monitoring framework & the TM boundary
Atlas is an entity-KYB platform, not a payment monitor — and it should stay that way. The proportionate answer to Guideline 2 is an explicit scope boundary plus an integration edge: a documented statement that transaction-level monitoring is delegated to a partner TM system, and a tenant-authenticated webhook that attaches that system's normalized alerts onto the resolved entity so no risk is lost between platforms. The roadmap also closes the silent gap where the EBA matrix's Transaction Risk dimension scores zero for every company because nothing populates it.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Wire the transaction_patterns risk factor to real inputs and stop defaulting it to zero | 🟡 Planned — extend · delta over #362 | MUST | #596 |
| External TM alert ingestion boundary: webhook/API to attach partner-system transaction alerts to the entity risk model | 🔴 Planned — net-new | MUST | #645 |
| Make activate_pkyc persist real monitoring subscriptions and add a transaction_alert trigger type | 🟡 Planned — extend · delta over #355 | MUST | #646 |
| Structured expected-activity / nature-and-purpose profile captured at onboarding and versioned | 🔴 Planned — net-new · delta over #281 | SHOULD | #654 |
| Intermediary-role risk factor and underlying-client population modelling | 🟡 Planned — extend | SHOULD | #655 |
| Per-tenant monitoring coverage register with gap report | 🔴 Planned — net-new | SHOULD | #656 |
Expected-behaviour baseline & deviation
A documented baseline of expected/normal behaviour — who the customer is, why the relationship exists, what activity is anticipated — is the prerequisite AMLA names for all monitoring: without it, unusual for this customer is undefinable. Atlas records who the customer is but never what is expected. The roadmap adds an Expected Activity Profile captured at onboarding and a deviation engine that compares observed evidence against it.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Expected Activity Profile (EAP) captured at onboarding | 🔴 Planned — net-new | MUST | #593 |
| Baseline-deviation detection engine feeding risk matrix and review triggers | 🔴 Planned — net-new · delta over #355 | MUST | #594 |
| Non-transactional relationship baseline snapshot | 🟡 Planned — extend · delta over #355 | MUST | #595 |
| Customer peer-group cohorts with supplement-only semantics | 🔴 Planned — net-new | SHOULD | #600 |
| EAP review-and-refresh step in periodic/trigger reviews | 🔴 Planned — net-new · delta over #355 | SHOULD | #601 |
| Manual/EAP-fed assessment path for the transaction_patterns factor | 🟡 Planned — extend · delta over #362 | SHOULD | #602 |
Activity & behavioural monitoring
Monitoring is not only transaction-centric: activity and behavioural signals count too — documents, instructions, mandates, and conduct observed by staff — and feed suspicious activity reports, not only transaction reports. This is the non-financial sector's primary monitoring input, and Atlas has no way to capture it today. The roadmap adds typed, attributed behavioural-observation capture that bridges into the risk matrix and SAR origination.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Behavioral observation capture: typed, attributed monitoring signals on the company file | 🔴 Planned — net-new | MUST | #614 |
| Manual risk-signal bridge into the EBA matrix and escalation rules | 🟡 Planned — extend | MUST | #615 |
| Activity-based SAR origination: internal referral from behavioral observations (delta to #370) | 🔴 Planned — net-new · delta over #370 | MUST | #616 |
| Company-scoped document and mandate registry with monitoring-signal classification | 🟡 Planned — extend · delta over #105 | SHOULD | #629 |
| Proportionality controls for behavioral data: purpose tags, retention class, restricted visibility | 🔴 Planned — net-new · delta over #369 | SHOULD | #630 |
| Open-signal review queue: internal signals trigger reviews and gate the clear verdict (delta to #355/#103) | 🔴 Planned — net-new · delta over #355 | SHOULD | #631 |
Pre / real-time / post monitoring
There is no prescribed hierarchy between pre-transaction, real-time and post-event monitoring — the choice depends on risk, complexity and feasibility, and must be justifiable per relationship, with genuine constraints (e.g. the instant-payments settlement window) documented and mitigated. The roadmap adds a per-relationship monitoring-timing plan derived from risk, a constraint register with compensating controls, and scheduled retrospective cross-portfolio analysis for cumulative patterns.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Monitoring-timing model: per-relationship pre/real-time/post monitoring plan derived from risk | 🔴 Planned — net-new | MUST | #647 |
| Monitoring constraint register with mandated compensating controls | 🔴 Planned — net-new | MUST | #648 |
| Scheduled retrospective graph analysis for cumulative linkages (delta over #355) | 🟡 Planned — extend · delta over #355 | MUST | #649 |
| Synchronous pre-event decision API (allow/refer/block) with SLA (delta over #282) | 🔴 Planned — net-new · delta over #282 | SHOULD | #657 |
| Implement the WEBHOOK source type: event-driven provider-change ingestion triggering re-evaluation | 🔴 Planned — net-new | SHOULD | #658 |
| Monitoring-effectiveness MI: per-mode coverage, latency and outcome reporting | 🔴 Planned — net-new | SHOULD | #659 |
Alert & case lifecycle
Generating alerts alone is insufficient — AMLA requires a controlled process to assess, prioritise, escalate, close and evidence every monitoring output, with meaningful detection and timely escalation rather than alert volume. Atlas has no alert/case object at all today; findings are terminal report artifacts. The roadmap adds an Alert Case entity with a full lifecycle, evidenced four-eyes disposition, and SLA-driven escalation to the MLRO and SAR hand-off.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Alert Case entity with full lifecycle state machine | 🔴 Planned — net-new | MUST | #590 |
| Evidenced disposition with mandatory rationale and four-eyes closure | 🟡 Planned — extend · delta over #278 | MUST | #591 |
| Wire alert cases into SLA-driven escalation to MLRO and SAR hand-off | 🟡 Planned — extend · delta over #370 | MUST | #592 |
| Risk-based triage queue with priority scoring and aging | 🟡 Planned — extend | SHOULD | #597 |
| Bind case dispositions to an immutable evidence set | 🟡 Planned — extend · delta over #369 | SHOULD | #598 |
| Alert-handling effectiveness dashboard and periodic MI export | 🔴 Planned — net-new | SHOULD | #599 |
Effectiveness testing & calibration
Effectiveness must be demonstrated, tested and tuned — the framework is reviewed and adapted when risks or business change, tools are calibrated (never run on default settings), and a weak legacy system is never the benchmark for a new one. The roadmap adds a pre-publish calibration sandbox, an effectiveness-metrics service (detection, timeliness, false-positive rate, coverage), a calibration-parameter registry, and a backtesting harness.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Pre-publish calibration sandbox: dry-run a draft matrix against the portfolio with side-by-side impact diff | 🟡 Planned — extend | MUST | #641 |
| Effectiveness metrics service and MLRO dashboard (detection, timeliness, FP-rate, coverage) | 🟡 Planned — extend | MUST | #642 |
| Analyst hit-disposition workflow with FP aggregation feeding calibration | 🟡 Planned — extend · delta over #277 | MUST | #643 |
| Calibration parameter registry: externalize hardcoded scoring/matching constants with rationale and approval | 🟡 Planned — extend | MUST | #644 |
| Backtesting harness: replay a labelled golden set against draft matrix/model versions | 🟡 Planned — extend · delta over #365 | SHOULD | #652 |
| Framework effectiveness review cycle: scheduled and event-triggered review records | 🟡 Planned — extend · delta over #103 | SHOULD | #653 |
Monitoring data quality
Weak data weakens monitoring: completeness and attribution must be controlled, and ownership of data-quality deficiencies clearly assigned — especially where advanced tools are used. The roadmap adds an authoritative monitoring-check catalog with a planned-vs-actual completeness gate, a deficiency register with assigned ownership, strict source-attribution quarantine, and a portfolio data-quality dashboard.
| Capability | Status | Priority | Tracking |
|---|---|---|---|
| Authoritative monitoring-check catalog with planned-vs-actual completeness gate | 🟡 Planned — extend | MUST | #637 |
| Data-quality deficiency register with assigned ownership and remediation lifecycle | 🔴 Planned — net-new · delta over #278 | MUST | #638 |
| Strict attribution gate: quarantine and surface unknown-trust-source claims | 🟡 Planned — extend | MUST | #639 |
| Limitation-driven compensating-measure policy engine | 🟡 Planned — extend · delta over #282 | MUST | #640 |
| Data-currency attribution: as-of stamps on decisions and freshness-SLA breach surfacing | 🟡 Planned — extend · delta over #355 | SHOULD | #650 |
| Structured data-gap taxonomy and portfolio data-quality dashboard | 🟡 Planned — extend · delta over #106 | SHOULD | #651 |
Traceability
All Guideline 2 features are tracked under the AMLA ongoing-monitoring readiness epic. The two foundations — the Expected Activity Profile (baseline) and the Alert Case entity (lifecycle) — are Phase 2 prerequisites; the partner-TM integration edge and effectiveness MI follow in Phase 4.