Part 2 of 3.
In Part 1 we covered what AMLA finalised on 1 October 2026 and why this is an implementation problem. Now we get into the detail that will test your data.
TL;DR: The CDD draft is detailed at field level, so start with the customer record, not the policy document. The remediation clock for existing customers counts from entry into force, so a good part of the one-year window for higher-risk customers will be gone by the time the rules apply to new onboarding. And linked transactions are only as good as the data your monitoring logic can see.
What should CDD teams review first?
Start with the customer record, not the policy document. The CDD draft covers, for example, place of birth and nationality, and expects firms to take reasonable steps to establish whether a customer holds more than one nationality.
For each required data point, ask four questions:
- Do we collect it?
- Can we verify it?
- Can the investigator get to it when they need it?
- Can we show what happened and why?
The fourth question is where programmes usually get harder than expected. Collecting a field is one thing. Showing what was done with it, and why a decision followed, is another.
Why is remediation of existing customers a start-now project?
Existing customers are the second planning issue. The CDD draft keeps the AMLR’s maximum update periods of one year for higher-risk customers and five years for the rest.
Those periods count from entry into force, not from the date the standards start to apply. Since application comes six months after entry into force, a good part of the one-year window for higher-risk customers will already have gone by the time the rules apply to new onboarding.
That makes remediation a project to start now:
- Work out which customer populations are affected,
- Identify what data is missing, and
- Check whether your systems can support the work without creating yet another manual queue.
How should firms deal with linked transactions?
This is among the most operational parts of the package. The draft asks firms to look at all relevant facts, and lists criteria such as:
- Transactions by the same person,
- Connected customers,
- Shared digital infrastructure, such as device identifiers or IP addresses,
- Transactions that belong to the same purchase, and
- Activity within a short time frame.
Two details are easy to miss:
- Money remitters, bureaux de change and crypto-asset service providers offering exchange or transfer services must take into account a period of at least one month when assessing linked transactions.
- Firms aren’t required to go and collect extra data just to spot linked activity. They are expected to use information they have, or should have, access to.
Did AMLA lower the CDD thresholds?
No. AMLA did not introduce new lower CDD thresholds in this RTS. It may reassess if new evidence emerges, so the challenge isn’t “lower the threshold”.
The real question is whether your data and transaction logic can recognise the behaviour the rule cares about. A policy that says “we aggregate linked transactions” proves nothing if the monitoring system only ever sees one payment at a time.
How do you test it?
Test real or controlled historical patterns. Take cases where you know activity was connected, such as the same person splitting payments, connected customers, or a shared device, and check whether your logic flags them consistently. If it doesn’t, you have found the gap before anyone else has.
The practical takeaway
Both topics come down to the same thing: a requirement only counts if the data is there, the logic can use it, and the investigator can see it. Policies describe intent. Records and monitoring logic show what actually happens.
Customer data is only half the story. What happens when local law blocks your group controls and you have 28 days to tell your supervisor?
Read Part 3: GROUP-WIDE CONTROLS AND A 7-STEP PLAN.
This article is for general information and is not legal advice.
About Author:
