Ongoing monitoring: what AMLA’s draft guidelines would really change
AMLA’s draft guidelines under Article 26(5) AMLR turn ongoing monitoring into a documented feedback loop across KYC, behaviour, alerts, customer risk and human decision-making. An operational analysis.
By Tom Zielinger

On 3 June 2026, the Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA) opened a consultation on its draft guidelines on the ongoing monitoring of business relationships under Article 26(5) of Regulation (EU) 2024/1624 (AMLR).
The text is still a draft: the AMLA consultation remains open until 3 September 2026, and final guidelines are expected in the fourth quarter of 2026. Treating all 95 paragraphs as settled requirements would therefore be premature. The direction of travel, however, is already clear.
Ongoing monitoring will not be judged by the number of alerts produced, but by the framework’s ability to maintain a current understanding of the customer, detect meaningful deviations, investigate them without delay and evidence why a decision was made.
This matters to banks, PSPs, EMIs and CASPs, as well as non-financial businesses and professions in scope of the AMLR. Above all, it requires components that are still frequently siloed to operate as one system: KYC, screening, transaction monitoring, customer risk rating, enhanced due diligence and suspicious activity reporting.
The starting point: Article 26 AMLR
Article 26 AMLR already requires ongoing monitoring of business relationships to ensure that transactions remain consistent with the obliged entity’s knowledge of the customer, their business activity and risk profile and, where necessary, the origin and destination of funds.
It also sets maximum intervals between customer information updates:
- one year for higher-risk relationships;
- five years for all other customers;
- and, in every case, a review when relevant customer circumstances change or a relevant fact comes to the entity’s attention.
The AMLA draft does not replace those rules. It explains how to operationalise them. Its central message is that a review calendar is not enough: the nature of a relationship can change long before the next due date.
1. Customer review becomes a feedback loop, not an administrative appointment
The draft describes two complementary mechanisms.
A periodic review checks whether identification data, beneficial ownership, representation powers, the purpose of the relationship, source of funds and politically exposed person status remain accurate. Its depth may be adjusted to the customer’s risk and actual activity. For a stable, lower-risk relationship, AMLA accepts a more targeted review based, for example, on registers, PEP screening and adverse media checks.
An event-driven review must take place without waiting for the calendar. Paragraph 27 of the draft refers in particular to:
- changes in identity, residence, legal form, management, authorised representatives or ownership;
- transactional or behavioural anomalies, including unexplained changes in devices, location or professional service providers;
- new adverse information, new PEP status, legal proceedings or a signal from an authority;
- significant changes in financial circumstances, business activity, source of funds or wealth;
- exposure to higher-risk counterparties or jurisdictions.
The important change is organisational: a transaction monitoring alert should no longer remain confined to the monitoring tool. It may need to trigger a KYC refresh, a new risk classification, enhanced measures or an assessment under Article 69 AMLR.
2. Monitoring transactions alone is no longer enough
The draft consistently refers to “transactions and activities”. This recognises business models in which the obliged entity cannot see or control every flow but holds other relevant signals: instructions, mandates, assets, use of a service, logins, device changes, counterparty relationships or changes in behaviour.
AMLA also expects events to be considered together and over time. A single transaction may appear ordinary while the series reveals:
- structuring;
- accumulation followed by transfer;
- connections across several accounts, customers, devices or wallets;
- a network intended to obscure ownership, control or economic purpose;
- a gradual departure from expected behaviour.
For PSPs, EMIs and CASPs, this aggregated view brings monitoring closer to a behavioural profile. In non-financial sectors, it supports a proportionate approach based on documents, interactions and key stages of the relationship when transaction data is limited.
3. Monitoring timing should reflect the ability to act
The draft distinguishes monitoring before and after a transaction or activity.
Where an entity can assess or stop an operation before execution, AMLA expects pre-transaction controls and, where relevant, real-time monitoring. Where the entity does not execute or control the flow directly, the prior control may focus on the mandate, instruction, contract, assets or due diligence information before the service is provided.
Post-transaction monitoring remains essential to identify patterns that only emerge through aggregation. Outputs should be assessed and escalated without undue delay. Legal, technical or business-model limitations may be recognised, but they must be understood, documented and mitigated. They cannot become a generic justification for the absence of monitoring.
4. Manual, automated or hybrid: AMLA remains technology-neutral
The draft does not mandate a specific type of tool. A small organisation with limited volumes may retain manual controls. A fast, complex or high-volume activity is more likely to require an automated or semi-automated system. Either way, the entity should be able to explain:
- why that model was selected;
- which risks, products, services and channels it covers;
- how its rules, scenarios, thresholds or behavioural baselines were calibrated;
- which limitations were identified and how they are mitigated;
- how changes are tested, validated and communicated.
Paragraph 50 contains an important warning for off-the-shelf solutions: default settings should not be used without a documented assessment of their appropriateness. Buying a monitoring engine transfers neither understanding of the framework nor accountability for its outcomes.
5. Effectiveness is not an alert-volume metric
Paragraphs 81 to 86 materially shift the focus of assurance. Alert counts, typology counts and reporting volumes do not, by themselves, demonstrate that a monitoring framework works.
AMLA suggests looking instead at:
- the relevance of the signals produced;
- the speed of assessment and escalation;
- the appropriateness of outcomes;
- recurring deficiencies and potential false negatives;
- the ability to incorporate emerging risks and supervisory feedback;
- data quality, accuracy, attribution and completeness;
- performance stability after a change to a rule, threshold or model.
Queues become a risk in their own right: an accumulation of unresolved outputs should be identified, monitored and addressed. Automated closure should be limited to cases with no unusual, suspicious or material risk indicators, with regular sample-based validation and effective human oversight.
6. AI is accepted, but it must remain challengeable
Paragraphs 87 to 95 are particularly significant. AMLA expects entities to assess whether algorithms, machine learning, artificial intelligence or other advanced analytical tools genuinely improve the identification and escalation of ML/TF risks.
Deploying AI is not evidence of effectiveness. The entity should retain:
- clearly assigned human accountability;
- the ability to review and challenge outputs;
- governance proportionate to the tool’s role;
- an understanding of error, bias, robustness and transparency risks;
- monitoring for performance degradation and drift;
- sufficient information about any third-party provider to explain the tool’s role, functioning and outputs to a supervisor.
The draft does not demand complete technical interpretability of every model. It demands enough operational explainability for the outcome to be understood, assessed and challenged. That distinction is critical for frameworks using generative models.
What Emelero can offer
Emelero is not intended to replace an institution’s KYC repository, transaction engine or case management platform. The proposition most consistent with AMLA’s draft is an analysis, reconciliation and evidence layer above existing systems.
| AMLA draft expectation | Potential Emelero contribution | Control retained by the institution |
|---|---|---|
| Connect alerts, KYC and customer risk | Consolidate context and propose a review, reclassification or EDD | Case validation and due diligence decision |
| Prioritise outputs without delay | Pre-investigate, group and rank alerts by risk and missing evidence | Priority rules, SLAs and escalation |
| Detect review-triggering events | Connect registers, sanctions, PEPs, adverse media, customer history and internal signals | Source selection and materiality assessment |
| Document the reasoning | Produce a timeline, risk factors, sources and an exportable audit trail | Final rationale, approval and accountability |
| Test framework effectiveness | Connect risks, controls, tests, evidence, findings and remediation in a gap assessment | Test plan, independence and audit conclusion |
This architecture follows the logic of AMLA’s draft: the tool prepares, reconciles, explains and records; the analyst retains judgement, challenge and decision-making.
A practical roadmap ahead of 2027
Obliged entities do not need to wait for the final version before beginning useful, reversible work.
1. Map the current feedback loop. Identify where KYC, transactions, alerts, screening, decisions and evidence reside. Document uncovered products or channels and data that only becomes available after execution.
2. Define review-triggering events. Turn the four families in paragraph 27 into business-specific rules, each with a source, materiality level, owner and response time.
3. Connect every output to a decision. For each alert, define the possible outcomes: reasoned closure, information request, KYC refresh, reclassification, enhanced measures, restriction, further assessment or reporting.
4. Measure genuine effectiveness. Track time to action, backlogs, closure rationales, reopened cases, data deficiencies and sample-testing outcomes — not merely the number of alerts.
5. Govern analytical tools. Version rules and prompts, retain the sources used, test changes, monitor drift and require human validation for sensitive decisions.
The real change
AMLA’s draft does not turn ongoing monitoring into an automation race. It turns a collection of tools into an obligation to demonstrate coherence.
An effective framework should be able to answer five straightforward questions: what did we detect, against which expected behaviour, using which data, what decision did we make, and how do we know the system remains effective?
That continuity from signal to analysis, decision and evidence is where Emelero can contribute — integrating with the existing framework while leaving accountability with the compliance professional.
Primary sources: AMLA consultation on the draft guidelines and Regulation (EU) 2024/1624. To prepare an assessment of your ongoing monitoring framework, contact Emelero or talk to the agent.