AMLR · Ongoing monitoring
Transaction monitoring under AMLR
AMLR applies from 10 July 2027. AMLA’s draft guidelines on ongoing monitoring describe what your transaction monitoring framework must be able to detect, and what you must be able to demonstrate about it. Sygno helps you meet those requirements with models based on your own data, running within your current system.
Key dates
3 June – 3 September 2026
Consultation on AMLA’s draft guidelines on ongoing monitoring
Q4 2026
Final guidelines expected · we are here
10 July 2027
AMLR applies
What changes
What AMLA requires of your monitoring
Article 26 AMLR requires obliged entities to monitor every business relationship on an ongoing basis. Article 26(5) mandated AMLA to issue guidelines on how that should be done, and Guideline 2 of those guidelines covers the transaction and activity monitoring framework.
AMLA considered a prescriptive approach and decided against it, on the reasoning that detailed rules encourage institutions to follow steps rather than assess their actual risk. The guidelines therefore describe outcomes: what your framework must be capable of, and what you must be able to show about it.
Two shifts stand out
01
What is monitored
Before
Transactions
Under AMLR
Transactions and activities, including behaviour and events such as repeated changes in device or IP address.
02
What you must show
Before
A model in place
Under AMLR
Evidence that it works for your client activity, and that it keeps working over time.
Six capabilities AMLR asks for
The requirements in Article 26 AMLR and Guideline 2 converge on six capabilities that a monitoring framework needs to have in place.
01
All customer behaviour in one assessment
Behaviour is assessed at customer level, across products, group entities and activities that only form a pattern when seen together.
02
Reference points derived from data
Detection works from what is expected of each customer: their own history, a peer group where it has explanatory value, and the counterparty on the other side of the transaction.
03
Detection logic based on your own data
The framework has to fit your risks and complexity. Default settings may not be used without a documented assessment of whether they suit your institution.
04
A complete record of what the framework did and why
Every alert is stored with the features that produced it, and every change to the logic is logged with its rationale and the date it took effect.
05
Performance measured on evidence
Data quality checks, sampling, below-the-line testing and false and true positive rates tracked over time, with drift monitored against the model’s behaviour at validation.
06
A framework that learns from what it finds
Investigation results, sampling results and new typologies feed back into the risk assessment and into the next version of the detection logic.
Read the full analysis
Our three AMLR whitepapers walk through the draft guidelines provision by provision, and translate them into the capabilities your monitoring needs. Start with the overview, then go deeper with Part 1 on what the framework must detect, and Part 2 on what it must demonstrate.
Free to download, no form required.
What Sygno can do for you
Meeting the AMLA guidelines with models based on your own data
The Sygno platform generates transaction monitoring models from your own data. Because the logic is generated rather than configured, the record of how it was built, what it does and why it changed comes out of the same process that produces the model.
Any data, any format, inside your environment
Transaction data, CDD attributes and non-transactional records come in from your existing systems, in whatever format they produce. There is no data cleaning project required to start with, and no customer data leaves your environment.
Individual, group and network in one assessment
A behavioural baseline is derived for each customer from their own history. Peer group membership is tested as a variable rather than assumed, and counterparty and network characteristics enter on the same basis.
Explainable detection logic and complete audit logs
An explicit ruleset states which features drive each detection, readable by the people who operate it. Each alert carries the features and values that triggered it, and every change is versioned with its rationale and effective date.
Performance measurement built into the platform
Detection is measured against known historic cases, false and true positive rates are reported over time, and data quality is checked as part of the process. Configurable dashboards also generate reports for internal and external stakeholders.
Automatic model regeneration that takes in what was learned
Modelling legitimate behaviour means anomalies surface without a pre-defined risk typology. Investigation outcomes, sampling results and changes to your risk assessment feed the next regeneration, which runs on current data without rebuilding the framework.
Generating models from your own data answers what Article 26 and Guideline 2 require, and at the same time enhances your transaction monitoring system: ~80% fewer false positives and 20–200% more true positives.
Frequently asked questions
When does AMLR apply?
AMLR, Regulation (EU) 2024/1624, applies from 10 July 2027. AMLA published its draft guidelines on ongoing monitoring on 3 June 2026, and final guidelines are expected in Q4 2026.
Do the guidelines prescribe how to monitor transactions?
No. AMLA chose an outcome-based approach. The guidelines describe what a monitoring framework must be capable of and what an institution must be able to demonstrate, rather than prescribing specific rules or methods.
Do we need to replace our transaction monitoring system?
Not necessarily. The guidelines focus on what the framework can do, not on which system runs it. They do state that limitations in monitoring should not arise from design choices or systems an institution selected itself (paras 66 and 73). Detection logic generated by Sygno runs within your current system.
Can we keep using our vendor’s default settings?
Only with a documented assessment of whether those settings are appropriate for your institution (para 50). The institution carries the burden of showing that pre-configured logic fits its risk profile, customer base and product mix. Deploying fit-for-purpose detection logic instead not only relieves this burden but also offers better performance.
What if our data quality isn’t where it should be?
The guidelines require data quality to be controlled, deficiencies to be identified and material limitations to be documented (paras 82 and 92). The Sygno platform works with data as it is and checks data quality as part of the monitoring process, so improving your data and improving your monitoring can go hand in hand.
How do we show that our monitoring is effective?
Alert volumes, reporting volumes and the breadth of typology coverage do not on their own settle effectiveness. It also covers what the framework did not surface at all. In practice that means sampling, below-the-line testing, tracking false and true positive rates over time and monitoring model behaviour against validation.
Preparing for AMLR?
Let’s get in touch
Every institution starts from a different setup, with its own data, systems and risk appetite. We’re happy to think along about where your transaction monitoring stands today and which changes are required to meet AMLR by July 2027.
