Most AMLR checklists test the wrong thing. They check whether your controls match the rules as they stand on 10 July 2027: a snapshot.
But AMLR (Regulation (EU) 2024/1624) is not a snapshot.
AMLA's technical standards are still landing through 2026, thresholds are still moving, and fixed review calendars give way to event-triggered ones. The regulation is built to keep changing.
So the real test is not whether your rule set matches AMLR today. Or even on 10 July 2027. It is whether it can change as fast as AMLR will. At any given time.
That is a question about capability, not configuration – and it comes down to four of them.
The rest (appointing your compliance function, documenting policy, mapping CDD to the new triggers) is table stakes, covered briefly below. The four capabilities are where readiness is actually won or lost, and where most legacy compliance tools quietly fail.
Run this against your current system this quarter. For each capability: what AMLR demands, what to look for, and the one diagnostic question that tells you where you stand.
Before the four: the table-stakes AMLR items
Clear these first. They are the parts most closely resembling a traditional AML checklist, updated for AMLR, and they are necessary but not where the risk sits:
- a business-wide risk assessment refreshed against AMLR's expanded scope
- the two prescribed governance roles AMLR requires – a board-level Compliance Director and an operational Compliance Manager
- customer and beneficial-ownership data consolidated, verified, and reusable across processes – the single largest source of AMLR compliance risk is data inconsistency, not a missing control
- CDD, sanctions screening, and suspicious-transaction reporting mapped to AMLR's sharpened triggers
If those are in hand, you have a compliant program on paper. What you do not yet know is whether it can move. That is what the next four items test.
Before you score: run it as a gap analysis, not an audit
An audit asks whether you are compliant. This asks whether you are adaptable.
Those are different tests, and the second is actually harder to pass.
For each of the four capabilities below, score yourself against the diagnostic question. Anything that isn't a clean "yes, this week" is a gap worth a line in your plan.
Capability 1 – dynamic risk scoring with event-triggered re-review
What AMLR demands. Records now run on a refresh cap, not a fixed calendar. Higher-risk customers must be reviewed at least annually, everyone else at least every five years – but on top of that, event-triggered updates apply whenever something material changes in a customer's profile. This is perpetual KYC in everything but name: continuous customer lifecycle management, not a periodic batch review.
What to look for. A system that only re-scores customers on a schedule cannot meet this. The test is whether a material event – a change in beneficial ownership, a new high-risk counterparty, a jump in transaction velocity – triggers a re-review the moment it happens, or whether it waits for the next quarterly run.
Ready looks like: risk scores that recalculate on live events, with the re-review routed to an investigator automatically.
Not ready looks like: a periodic batch job, a spreadsheet of review dates, or a "we'll catch it at the annual review" answer.
Diagnostic question: when a customer's risk profile changes today, does your system know within minutes, or at the next scheduled review?
Capability 2 – configurable enhanced due diligence triggers
What AMLR demands. The EDD triggers get sharper and the PEP definition widens considerably. Domestic politically exposed persons are now treated the same as foreign ones. Regional and local authority heads are added. Siblings join the family-member definition. And enhanced due diligence extends at least 12 months after someone leaves office – a tail that most legacy systems were never built to track. For high-risk third countries, EDD becomes mandatory and simplified due diligence is barred outright, with no case-by-case waiver.
What to look for. Every one of those is a trigger your rules have to encode, and several are still being finalized by AMLA. The question is not whether your system can apply EDD – it is whether your compliance team can change when EDD fires, without raising a vendor ticket and waiting for a release.
Ready looks like: EDD trigger conditions your risk team edits directly, including time-based rules like the 12-month post-office tail.
Not ready looks like: EDD logic hard-coded by a vendor, or a change request queue measured in weeks.
Diagnostic question: if AMLA widens a PEP category next quarter, who changes your rule – your team, this week, or your vendor, eventually?
Capability 3 – beneficial ownership logic that flexes by sector
What AMLR demands. The standard beneficial ownership threshold sits at 25%. High-risk sectors are expected to see it lowered to 15%. A single hard-coded number cannot serve both, and the exact sectors where 15% applies are among the details still in consultation.
What to look for. This is the sharpest test of flexibility in the whole checklist, because it is not a yes/no rule – it is a threshold that varies by sector and may change again. A rule engine built around one ownership percentage will need re-engineering the day AMLA finalizes the split. A configurable one absorbs it as a settings change.
Ready looks like: ownership thresholds set per sector, adjustable by your team the same day guidance lands.
Not ready looks like: 25% baked into the detection logic, changeable only by whoever wrote the code.
Diagnostic question: can you apply a 15% threshold to one sector and 25% to another today, without a development cycle?
Capability 4 – audit trails built for evidencing change, not just detection
What AMLR demands. AMLA's direction of travel is clear. What matters to a supervisor is not only that you caught something, but that you can show what changed in your rules, when, and what you did in response. Detection logs alone will not clear that bar.
What to look for. Most systems log alerts. Far fewer version the rules themselves. The test is whether you can hand a supervisor a complete, timestamped history of a rule – who changed it, when, why, and what it looked like before – as easily as you can show them an alert.
Ready looks like: every rule, alert, and decision versioned and traceable, with rule-change history a supervisor can read.
Not ready looks like: an audit trail that shows detections but treats rule changes as invisible infrastructure.
Diagnostic question: if a supervisor asked what your monitoring rules looked like 18 months ago and why they changed, could you show them in minutes?
Reading your results
Four capabilities, four diagnostic questions. Score honestly.
Zero or one clean yes: your rule set is configured for today's rules but not built to move with AMLR. That is the most common starting point. EY's 2025 survey of 20 Nordic banks found false positives running at 90–91% regardless of bank size, traced directly to rule engines that could not be retuned without a vendor change request – so if you scored low here, you are in the majority, mid-transformation rather than behind.
Two or three: you have real flexibility in parts of the system, usually risk scoring, and rigidity in others, usually the audit trail or the ownership logic. Map which is which. Partial adaptability tends to fail at exactly the seam AMLA will test.
Four clean yes answers: your infrastructure already works the way AMLR is designed to. The 2027 date is a formality for you, not a deadline.
The point of the exercise is not the score. It is that all four questions share a root: can the people who own the rules change the rules, quickly, and prove they did. A system that passes has that property. A system that fails has it missing in one place or another – and no amount of building to the current spec fixes a missing property.
Where Marble fits
Marble is the compliance AI decision platform that adapts to your risk framework – not the other way around.
All four capabilities in this checklist are core to how it is built. Dynamic risk scoring and event-triggered re-review run natively. EDD triggers, PEP definitions, and beneficial ownership thresholds are set by your compliance team directly, in a no-code interface – no vendor ticket, no release cycle. When AMLA finalizes where the 15% threshold applies, your team adjusts the logic the same day. And every rule, alert, and decision is versioned and traceable, built for a supervisor who wants evidence of adaptation, not just a log of detections.
If you want the full argument behind the checklist – the EY data, the enforcement record, and how the three Nordic markets diverge – it is in the whitepaper, From Fixed Rules to Living Rules written for banks in the Nordics. AMLR reaches Sweden and Denmark directly, and Norway through the EEA on the same 10 July 2027 date – the market-by-market detail is in our guide to AMLR requirements for banks in Sweden, Norway, and Denmark.
But the challenges are not limited to Scandinavia – that’s why the whitepaper and the guide is worth a read for anyone tackling this transition.
Read the base guide: AMLR requirements for banks in Sweden, Norway, and Denmark →
Download the whitepaper: From Fixed Rules to Living Rules →
Frequently asked questions about the AMLR checklist for banks
What should be on an AMLR checklist for banks?
An AMLR checklist covers two layers. Table stakes: a refreshed business-wide risk assessment, the two prescribed governance roles, consolidated beneficial-ownership data, and CDD mapped to AMLR's sharper triggers. The layer that decides readiness: whether your rule set can be retuned as fast as AMLR changes – dynamic risk scoring, configurable EDD triggers, sector-flexible ownership thresholds, and a rule-change audit trail.
How is AMLR different from the current AML directive?
The current regime runs on AMLD – a directive each country transposes into its own national law, with local variation. AMLR (Regulation (EU) 2024/1624) is a regulation, so it applies directly and identically across the EU from 10 July 2027, with no transposition step. It also replaces fixed review cycles with continuous, event-triggered ones, which is the change most legacy rule engines are not built for.
Does AMLR replace national AML law?
For the directly applicable parts, largely yes. AMLR sets one rulebook across EU member states, removing the national-interpretation layer that shaped AML practice for years. A parallel directive (AMLD6) still governs some nationally implemented areas, and non-EU EEA states such as Norway adopt AMLR through their own implementing legislation on the same timeline.
What is the AMLR beneficial ownership threshold?
The standard beneficial ownership threshold under AMLR is 25%. High-risk sectors are expected to see it lowered to 15%, with the exact sectors still being finalized through AMLA's technical standards. A rule engine hard-coded to a single percentage cannot serve both, which is why sector-flexible ownership logic is one of the four capabilities on the checklist.
Do banks need new software to comply with AMLR?
Not necessarily new software – but the software has to clear a specific bar. AMLR does not prescribe a tool. It effectively requires that your compliance team can change monitoring rules quickly, apply variable thresholds, and evidence every change to a supervisor. Whether your current system can do that is exactly what the four-capability checklist above is designed to reveal.
