top of page

AMLR 2027: Why Updating the AML Policy Will Not Be Enough

Aug 1
11 min read

The EU’s new AML single rulebook will affect risk assessment, customer due diligence, ongoing monitoring, governance, group controls and reporting. Preparing for it requires a connected implementation programme — not a document refresh.


For most obliged entities, the EU Anti-Money Laundering Regulation will apply from 10 July 2027.


That date may still appear far enough away to treat AMLR implementation as a project for next year. The emerging AMLA rulebook suggests otherwise.


As at 27 July 2026, consultations on customer due diligence, business relationships, business-wide risk assessment and group-wide requirements have closed. Consultations on ongoing monitoring and the format for reporting suspicions remain open.


AMLA’s planning indicates that many of the relevant final drafts are expected during the second half of 2026, while parts of the supporting rulebook will continue to be developed into 2027.


This leaves firms with an uncomfortable but manageable challenge.


Waiting until every technical standard and Guideline is final would leave too little time to assess data, systems, governance and operational dependencies. Finalising every procedural detail now, however, could lead to unnecessary redesign.


The practical answer is to begin with the architecture.


Firms can already identify which decisions, documents, processes, systems and responsibilities will be affected — while leaving controlled flexibility for requirements that remain in draft.


Direct applicability does not mean automatic implementation


AMLR is directly applicable across the European Union. Its substantive requirements will not depend on every Member State reproducing them in a separate national AML law.


But direct applicability does not automatically update an organisation’s operating model.


A regulation cannot, by itself:


  • add missing data fields to an onboarding system;

  • recalibrate a customer-risk model;

  • introduce new review triggers;

  • connect monitoring scenarios to the Business-Wide Risk Assessment;

  • define who may approve an exception;

  • redesign group information flows;

  • produce the data required for a report to the FIU;

  • create evidence that a control has operated.


Each of these changes still needs to be interpreted, designed, approved, implemented and tested.


AMLR readiness should therefore not begin with:


Which paragraphs must be added to the AML Policy?

The more useful question is:

Which parts of our governance, documentation and operating model must change so that the new requirements can work in practice?

The AMLA rulebook is already taking shape


At the time of writing, six AMLA instruments are particularly relevant to obliged entities preparing for AMLR.


Customer Due Diligence


The consultation has closed.


The draft RTS provide more detail on the information and documents to be collected for customers, beneficial owners, representatives, trusts and other legal arrangements. They also address verification, enhanced measures and targeted-financial-sanctions screening.


Business relationships and linked transactions


The consultation has closed.


The draft RTS address when an interaction constitutes a business relationship, an occasional transaction or linked transactions — and therefore when the relevant CDD obligations are triggered.


Business-Wide Risk Assessment


The consultation closed on 15 July 2026.


The draft Guidelines set out minimum components for assessing business exposure, inherent risk, the quality of controls and residual risk.


Group-wide requirements


The consultation has closed.


The draft RTS cover group governance, information sharing, the identification of the relevant parent undertaking and additional measures where third-country law restricts implementation of the group framework.


Ongoing monitoring


The consultation remains open until 3 September 2026.


The draft Guidelines cover customer-information updates, periodic and event-driven reviews, and transaction and activity monitoring.


Reporting suspicions and providing transaction records


The consultation remains open until 20 September 2026.


The draft ITS introduce a common reporting dataset, sector-adapted templates and machine-readable reporting arrangements.


These instruments are not yet final. Individual provisions may change following consultation and before formal adoption.


They nevertheless point in one consistent direction: AMLR implementation will affect the connections between risk assessment, customer controls, monitoring, escalation, governance and reporting.


Why a policy-update project will fail


An AML Policy can state that a firm follows a risk-based approach.


That does not necessarily mean that the wider framework is genuinely risk-based.


A Business-Wide Risk Assessment may identify certain products, jurisdictions or customer groups as high risk, while the onboarding process does not collect the information needed to distinguish them.


The Customer Risk Assessment Methodology may define several risk levels, while monitoring thresholds remain the same for every customer.


The Ongoing Monitoring Procedure may require event-driven reviews, but no system or operational team may be responsible for identifying the relevant events and opening the review.


A Group AML Policy may require information sharing without defining what information should be shared, who receives it or how the local entity should reassess its own decision.


Each document may look reasonable when reviewed separately.


The weakness becomes visible only when the documents are compared with the workflows, system configuration, decision rights and evidence that are supposed to support them.


The Business-Wide Risk Assessment should drive the framework


AMLA describes the BWRA as a central element of the obliged entity’s risk-based approach.


The draft Guidelines propose four minimum components:


  1. a business and operational overview;

  2. identification and classification of inherent risk;

  3. assessment of the quality of AML/CFT and targeted-financial-sanctions controls;

  4. assessment and classification of residual risk.


The results should not remain inside a risk document prepared once a year for management approval.


They should influence:


  • internal policies and procedures;

  • customer-risk methodology;

  • the intensity of CDD;

  • monitoring rules and scenarios;

  • resource allocation;

  • training;

  • control testing;

  • management reporting;

  • remediation priorities.


The draft Guidelines expressly connect BWRA results with improvements to the risk-management framework and the design and implementation of mitigating measures. They also extend the assessment beyond ML/TF risk to include the risk of non-implementation and evasion of targeted financial sanctions.


The underlying logic should be traceable:


Business model and exposure

→ Inherent risk

→ Controls

→ Control effectiveness

→ Residual risk

→ Operational response


Where this chain cannot be followed, the organisation may have several individually acceptable documents without having one coherent risk-based framework.


Customer due diligence becomes a data and workflow issue


The draft CDD RTS provide more detail on the information and evidence to be obtained for natural persons, legal entities, beneficial owners, representatives and legal arrangements.


The practical impact reaches beyond the KYC Procedure.


Firms will need to consider whether their onboarding architecture supports:


  • the required customer and beneficial-owner data;

  • distinctions between mandatory and risk-dependent information;

  • appropriate verification sources;

  • simplified, standard and enhanced CDD decisions;

  • evidence explaining the level of CDD selected;

  • targeted-financial-sanctions screening;

  • later updates to customer records.


A procedure cannot require information that the onboarding system has no field to capture.


Nor is it sufficient for a field to exist if it remains optional when the firm’s risk methodology considers that information necessary.


The draft RTS also recognise that relevant information may already be available within the obliged entity or elsewhere in its group. Firms should consider whether that information is reliable and sufficient before requesting substantially the same information again.


For customers onboarded before the new framework takes effect, the draft proposes that the maximum one- and five-year update periods should begin from the application date of the future Delegated Regulation. Existing records would then be brought into line on a risk-sensitive basis within those periods.


This is still a draft position. It does not yet establish the final remediation timetable.


It does, however, support a practical conclusion: firms may not need to refresh every legacy customer file on the first day of the new regime, but they will need to understand where existing data, verification evidence and risk classifications differ from the emerging requirements.


Ongoing monitoring is broader than transaction monitoring


Ongoing monitoring is often treated as another name for transaction monitoring.


The draft Guidelines use a broader concept.


They cover:


  • keeping customer information current;

  • periodic reviews;

  • event-driven reviews;

  • transaction monitoring;

  • activity monitoring;

  • pre-transaction checks;

  • real-time monitoring where relevant;

  • post-transaction and post-activity review;

  • handling and escalation of monitoring results.


A change in ownership, business activity, products used, financial position, counterparties or geographical exposure may affect a customer’s risk profile even when no individual transaction generates an alert.


The organisation must therefore connect:


customer information → trigger events → risk classification → monitoring → review → escalation → decision


The draft Guidelines also address risk that becomes visible only when behaviour is examined collectively over time. This includes linked, repeated or aggregated behaviour across accounts, customers, devices, wallets and other identifiers.


For a CASP, this may mean looking beyond one blockchain transaction to understand patterns across wallets, devices and related customers.


For a PSP or EMI, it may mean checking whether customer-risk levels, expected activity and monitoring scenarios are genuinely connected — rather than being maintained as separate models by different teams.


Governance must show who is accountable


AMLR distinguishes between the compliance manager, who is a member of the management body in its management function, and the compliance officer, who is responsible for the day-to-day operation of the AML/CFT framework. The two roles may be combined where the nature, complexity and size of the business justify it.


This requires more than adding two titles to an organisational chart.


The firm should establish:


  • which decisions belong to the management body;

  • which matters require the compliance manager’s approval or escalation;

  • what the compliance officer controls operationally;

  • who receives information about material weaknesses;

  • how the adequacy of resources is assessed;

  • how remediation is monitored;

  • what information is included in management reporting.


Those responsibilities should be reflected consistently across the AML Policy, committee mandates, role descriptions, escalation procedures and issue-management framework.


Where different documents allocate the same responsibility to different functions, accountability becomes unclear precisely when a control fails.


Group-wide compliance requires an operating process


The draft group-wide RTS address governance, risk assessment, information sharing and additional measures for situations involving third-country legal restrictions.


The information-sharing model is intended to be proportionate, subject to confidentiality and data-protection safeguards and based on the need-to-know principle. It also includes ad hoc sharing of newly identified relevant information, such as adverse information concerning a customer or beneficial owner.


Information sharing does not remove the responsibility of each obliged entity to conduct its own CDD and risk assessment.


A statement that group entities “shall share relevant information” will therefore not be enough.


The operating framework should define:


  • which events trigger information sharing;

  • what data should be shared;

  • whether sharing is automatic or request-based;

  • who may access the information;

  • how urgent adverse information is escalated;

  • whether the local risk assessment must be reconsidered;

  • how the receiving entity documents its decision.


Without these details, a group may have a common AML Policy but no reliable group-wide process.


Reporting suspicions becomes a data-mapping project


AMLA’s draft ITS propose a common core dataset and templates adapted to different categories of obliged entities.


Data points may be:


  • mandatory;

  • technically required;

  • mandatory if available;

  • optional;

  • dependent on another response;

  • required by an FIU because of national legislation or specific national circumstances.


The draft does not prescribe one universal technical language or file format for every Member State. Reports would be submitted in a machine-readable format accepted by the relevant FIU.


This means that a common EU reporting structure will not automatically create harmonised internal data.


A firm seeking to automate or partially automate reporting will need to determine:


  • where each required data point is stored;

  • whether the information is complete and structured;

  • how data can be extracted from customer, transaction and case-management systems;

  • who validates the report;

  • how national fields are handled;

  • how subsequent information and corrections are submitted;

  • how the audit trail is retained.


Where information is distributed across several systems, investigation notes and spreadsheets, reporting may remain highly manual even under a common EU template.


The work therefore begins with data mapping, not with rewriting the STR Procedure.


Where implementation gaps are likely to appear


The most significant AMLR weaknesses may not be obvious drafting errors.


They are more likely to appear where one part of the framework should affect another.


For example:


  • The BWRA identifies a high-risk service, but no additional monitoring control is associated with it.

  • The customer-risk methodology requires information that the onboarding system does not collect.

  • A change in beneficial ownership is detected but does not trigger a customer review.

  • Monitoring thresholds are changed without a documented rationale or approval.

  • The Group AML Policy permits information sharing, but no workflow or access model exists.

  • The STR Procedure lists required information, but investigators cannot retrieve it from the relevant systems.

  • Management receives alert volumes but no information about overdue cases, recurring control failures or remediation.


These are not isolated documentation defects.


They show that risk assessment, policies, procedures, systems and governance do not operate as one connected framework.


What firms should begin mapping now


Firms do not need to wait for every AMLA instrument to be final before beginning implementation.


A practical readiness assessment can already cover six connected layers.


Regulatory requirements


Identify the relevant AMLR provisions and emerging AMLA instruments. Clearly distinguish final legal requirements from draft proposals.


Governance and ownership


Determine which function or individual owns each decision, control and implementation action.


Documentation


Map the affected policies, methodologies, procedures, standards, committee terms and reporting templates.


Processes and systems


Identify the workflows, data fields, monitoring tools, case-management processes and system configurations supporting each requirement.


Evidence


Define what will demonstrate that a control has operated: approvals, logs, reviews, investigation records, test results, reports and remediation files.


Change dependencies


Record which actions can begin immediately and which depend on final RTS, Guidelines, Commission adoption or national FIU implementation.


The objective is not to produce a longer document inventory.


It is to understand how each requirement moves through the organisation:


Requirement → decision → document → process → system → evidence

What can be done now — and what should remain flexible


Firms can already:

  • map the affected framework;

  • identify inconsistencies and gaps;

  • clarify ownership;

  • review the BWRA methodology;

  • assess customer-data availability;

  • map customer-review triggers;

  • document monitoring governance;

  • assess group information flows;

  • review the availability of FIU-reporting data;

  • establish a structured AMLR change register.


Some detailed elements should remain adaptable until the relevant instruments are final:

  • specific CDD data requirements;

  • final customer-review expectations;

  • detailed monitoring requirements;

  • technical FIU reporting specifications;

  • parts of the group information-sharing model;

  • detailed expectations concerning compliance-function resources.


This does not mean postponing implementation.


It means using documented assumptions, controlled dependencies and defined decision points so that final requirements can be incorporated without rebuilding the framework from the beginning.


The wider supervisory direction


In July 2026, AMLA published final draft standards intended to support a more consistent EU approach to classifying breaches and determining enforcement outcomes.


The standards are not yet legally binding. They will apply directly only after adoption by the European Commission. Their direction is nevertheless clear: comparable breaches should be assessed more consistently across Member States, with supervisors considering factors such as gravity, duration, repetition and impact.


This reinforces the importance of operational effectiveness.


Supervisors will not look only at whether a policy contains the correct regulatory language. They will also consider whether controls are effective, whether weaknesses are structural and whether deficiencies are properly remediated.


Lynsora perspective


AMLR readiness should not be treated as a legal update assigned to one policy owner.


It is a structured transformation across governance, risk methodology, customer due diligence, ongoing monitoring, escalation, group controls, data and operational evidence.


The AML Policy remains an important part of the framework.


But it cannot compensate for:


  • an incomplete BWRA;

  • inconsistent customer-risk logic;

  • missing onboarding data;

  • ineffective monitoring;

  • unclear decision rights;

  • fragmented group information;

  • inadequate reporting data;

  • weak evidence that controls operate.


The central implementation question is therefore not:

Have we updated our AML documentation?

It is:

Do our risk assessment, documentation, systems, decisions and evidence operate as one coherent framework under AMLR?
AMLR readiness will not be demonstrated by the date on an updated policy. It will be demonstrated by the organisation’s ability to translate the new rulebook into consistent decisions, controlled processes and reliable evidence.

Official sources


Disclaimer


This article is provided for general information purposes only and does not constitute legal, regulatory or professional advice.

Comments

Commenting on this post isn't available anymore. Contact the site owner for more info.
bottom of page