The European Union’s new AML/CFT framework is moving from legislation to implementation. One of the areas where that transition will be felt most directly by financial institutions is transaction monitoring.
On 3 June 2026, the EU Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA) launched a public consultation on its draft Guidelines on ongoing monitoring of business relationships under Article 26(5) of the Anti-Money Laundering Regulation (AMLR). The consultation ran until 3 September 2026 and is expressly intended to test whether the proposed principles can be applied effectively by obliged entities in practice.
AMLYZE contributed its regulatory and technological perspective to this process through the Lithuanian Fintech Association, focusing in particular on the practical implementation of transaction and activity monitoring.
This is an important consultation. The Guidelines will influence not only how financial institutions write their AML/CFT procedures, but potentially how monitoring systems are designed, what data they are expected to use, how customer behaviour is modelled, when monitoring takes place, and how monitoring results interact with decisions to intervene in transactions.
Our central message is straightforward: effective transaction monitoring needs sophisticated technology, but regulation should define the outcomes technology must achieve rather than prescribe the technology itself.
From AMLR to the monitoring system
Article 26 AMLR establishes ongoing monitoring as a core part of customer due diligence. AMLA’s draft Guidelines seek to translate that principle into operational expectations. They cover two closely connected areas. Guideline 1 addresses keeping customer information up to date, while Guideline 2 establishes principles for transaction and activity monitoring.
Two connected areas under Article 26 AMLR
| GUIDELINE 1 – Know | GUIDELINE 2 – Observe |
|---|---|
| Keeping customer information up to date | Transaction and activity monitoring |
| CDD data, purpose and intended nature of the relationship, expected activity, customer risk score | Actual transactions, behavioural patterns over time, deviations, connected identifiers |
| → Sets the baseline against which behaviour is assessed | → Can show the baseline itself needs revisiting |
The two areas operate as a loop, not as separate compliance exercises: what an institution knows frames what it looks for, and what it observes feeds back into what it knows.
That connection matters.
A modern monitoring framework should not treat KYC, customer risk scoring and transaction monitoring as isolated compliance exercises. What an institution knows about its customer provides the baseline against which behaviour can be assessed. What it subsequently observes through transactions and activities can, in turn, indicate that the original customer information or risk assessment may need to be reconsidered.
Our consultation response therefore supports AMLA’s move towards monitoring customer behaviour and patterns over time, rather than looking only at individual transactions in isolation. The submitted response describes this more structured approach as potentially having a positive impact on monitoring processes and controls.
But turning that principle into a workable regulatory standard requires care.
-
Regulation should specify the monitoring outcome, not the technology
One of the most important issues raised in our contribution concerns the boundary between a regulatory expectation and a technological prescription.
Paragraph 44 of the draft Guidelines refers to identifying behaviour across accounts, customers, devices, wallets and other identifiers, as well as recognising network relationships. These are potentially powerful analytical capabilities. They can help institutions move beyond simple transaction-by-transaction rules and identify relationships and patterns that would otherwise remain hidden.
The difficulty arises if such examples are understood as minimum technological requirements for every obliged entity.
Our submission therefore proposes that AMLA clarify that these are monitoring outcomes rather than mandatory technological capabilities. Their relevance should depend on the institution’s business model, the information lawfully and reasonably available to it, and the nature, scale and complexity of its activities.
This distinction is particularly important because the AMLR applies far beyond large banks and payment institutions. A horizontal EU standard needs to work for obliged entities with very different products, data environments, transaction volumes and technological infrastructures.
The objective should be effective detection — not requiring every institution to build the same machine.
-
Customer profiles should evolve with actual behaviour
AMLA also proposes that monitoring should be calibrated against customer profiles based on CDD information, including the purpose and intended nature of the relationship and, where relevant, expected transactions, activities and resulting behavioural profiles. Conceptually, this is a strong direction. Transaction monitoring becomes considerably more meaningful when behaviour is assessed in context.
But there is an important distinction between verified facts and expectations. At onboarding, expected turnover, transaction frequency, counterparties or geographical exposure may partly reflect customer declarations or forecasts. They are not necessarily facts capable of independent verification. As the relationship develops, actual observed behaviour can provide a much richer basis for understanding the customer. This is why monitoring should not remain permanently anchored to a static onboarding snapshot. The baseline itself should be capable of evolving.
The same logic appears in our comments on customer information updates. We argued that ongoing monitoring may itself provide relevant evidence that circumstances remain unchanged. For example, a stable lower-risk customer’s continuing transaction pattern may support the conclusion that there has been no material change, without automatically requiring the institution to contact the customer or consult an external database merely to prove that a review took place.
The broader principle is important: good ongoing monitoring should make use of what the institution actually learns during the relationship.
-
An unusual transaction is not automatically a suspicious transaction
Another important issue is what happens when monitoring identifies a deviation. Transaction monitoring systems are deliberately designed to identify activity that deserves attention. But a deviation from expected behaviour is not, by itself, evidence of money laundering or terrorist financing.
This distinction matters enormously in practice. A monitoring event should only begins a further analytical process which includes understanding the activity flagged, assessing it against the customer’s profile and other available information, determining whether the existing CDD remains adequate, collecting additional information and establish whether reasonable grounds for suspicion exist. So between monitoring event and STR submission there might be a few analytical steps. Without that intermediate analytical step, regulation can unintentionally encourage a mechanical compliance model in which alerts automatically lead to customer reassessment or suspicious transaction reporting. That is neither genuinely risk-based nor necessarily effective.
The purpose of monitoring is not to maximise the number of alerts. It is to identify meaningful risk and enable the institution to distinguish explainable activity from activity that genuinely warrants escalation.
-
“Continuous” does not necessarily mean “real-time”
The draft Guidelines use several concepts that have significant technological consequences: ongoing monitoring, continuous monitoring, real-time monitoring and pre-transaction monitoring. These concepts should not become interchangeable.
Our submission highlights that if “continuous monitoring” is interpreted as requiring capabilities materially different from existing risk-based ongoing monitoring, institutions using periodic, event-driven or other proportionate arrangements may need to introduce new automated processes. Similarly, pre-transaction and real-time expectations can require systems capable of analysing transactions within very short execution windows.
There is an important regulatory principle behind this technical question. The appropriate monitoring method depends on the risk, product and business model. Some activities require immediate assessment. Others can be effectively monitored retrospectively or through event-driven controls.
Technology can make real-time monitoring possible. That does not mean that every monitoring obligation should automatically become a real-time obligation.
-
Detecting risk and stopping a transaction are different legal questions
Perhaps the most important distinction concerns what happens after a monitoring system detects something. A system can identify a transaction as unusual. It can assign a risk score. It can generate an alert. Technically, it may even be capable of placing a transaction on hold. But technical capability does not itself create a legal power to delay or refuse a transaction.
This becomes particularly important for payment service providers, where AML/CFT requirements interact with payment-services legislation governing execution times, refusals and other aspects of payment processing.
The Guidelines should therefore maintain a clear distinction between two stages:
Monitoring: identifying unusual or potentially suspicious (based on known transactional patterns that indicates “suspicion”) transactions or activities.
Intervention: determining whether the transaction should be delayed, suspended, rejected, reported or otherwise acted upon under the AMLR and other applicable Union or national law.
That distinction helps avoid a situation in which transaction-monitoring guidance indirectly creates transaction-intervention obligations that the Level 1 legislation itself does not establish. It also matters enormously when systems are being configured. A monitoring engine and an execution-control mechanism may interact, but they do not perform the same legal function.
Why AMLYZE participates
AMLYZE sits at an intersection between AML/CFT regulation and the technology used to implement it. As a RegTech and SaaS provider, AMLYZE develops solutions covering real-time and retrospective transaction monitoring, customer risk assessment, AML/CFT investigations, and sanctions, PEP and adverse-media screening. Its team includes professionals with backgrounds at European and national regulatory bodies and financial institutions.
That combination makes implementation questions tangible. A sentence in a regulatory guideline can translate into a new data field. A reference to a behavioural profile can affect scenario logic. A requirement to recognise relationships can mean a completely different analytical architecture. A loosely defined expectation of “continuous” monitoring can determine whether an institution needs periodic processing, event-driven controls or real-time infrastructure.
For a RegTech provider, contributing to regulatory consultations is therefore not simply a policy exercise. It is an opportunity to bring implementation experience into the rule-making process. This is also not the first time we have done so – earlier this year we set out a similar position on AMLA’s draft RTS on business relationships and linked transactions, where the same question arose: when a definitional choice in a regulatory text becomes a configuration decision in a monitoring system.
From regulatory principle to working transaction monitoring
The direction of EU AML/CFT regulation is clear: transaction monitoring is becoming more contextual, behavioural, dynamic and interconnected. This is also where technology can provide real value.
AMLYZE’s transaction-monitoring solution supports both real-time and retrospective monitoring and provides configurable monitoring scenarios, a no-code rule editor, alert grouping and deduplication, and rule-performance tracking. AMLYZE states that its transaction-monitoring library includes more than 200 predefined scenarios, while scenarios can be adapted to an institution’s own risk policies and regulatory requirements.
More importantly in the context of AMLA’s Guidelines, transaction monitoring does not need to operate in isolation. AMLYZE’s broader platform connects transaction monitoring with fraud monitoring, customer risk assessment, investigations, customer screening and payment screening. Its customer-risk functionality supports dynamic profiles, while screening results can feed into customer scoring and payment-screening results into transaction monitoring and investigations.
That integrated architecture can become particularly useful as AMLA’s framework moves towards monitoring that considers the customer, expected and observed behaviour, transactions, risk indicators and connected information together rather than as separate compliance processes.
For obliged entities preparing for the AMLR, the question is therefore no longer simply whether they have a transaction monitoring system. The more important questions are whether that system can be calibrated to their actual risk exposure, whether customer risk and behaviour can inform detection, whether monitoring logic can evolve without lengthy development cycles, whether alerts can be investigated efficiently, and whether the institution can demonstrate why its monitoring framework is appropriate for its business model.
Those are exactly the questions AMLA’s consultation is bringing to the surface. And they are also where combining regulatory expertise with configurable technology can make the greatest difference.
