AMLA's final draft regulatory technical standards on customer due diligence, published on 30 September 2026, specify what the customer due diligence process must collect, verify and refresh: identification data, verification routes including electronic identification, beneficial-ownership sources, simplified and enhanced measures, and screening. Outside the EU, they work as a detailed benchmark for banks.
The standards are not yet in force. They go to the European Commission for adoption, and they bind EU obliged entities, not institutions supervised by the BSP, OJK or BNM. Treat what follows as a comparison point and a preview of examiner expectations, not as a local obligation.
The EU's Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA) published three sets of final draft standards on the same day. This article covers the customer due diligence set, which is the one that changes how onboarding data, verification and screening are designed.
What did AMLA publish, and what is its status?
AMLA published its final report on 30 September 2026, and the standards still need Commission adoption before they take effect.
The final report covers 29 articles and an annex, drafted under Article 28(1) of the EU Anti-Money Laundering Regulation, Regulation (EU) 2024/1624. A public consultation ran from 9 February to 8 May 2026 and drew 325 responses.
| Milestone | Timing |
|---|---|
| Final report published | 30 September 2026 |
| Commission adoption and Official Journal publication | Pending |
| Entry into force | 20th day after publication |
| Application of the standards | 6 months after entry into force |
| Application for certain entity types (Art. 3(3)(n) and (o) AMLR) | 10 July 2029 |
| Application of the AMLR itself | 10 July 2027 |
Does this apply to institutions outside the EU?
Not directly, but it reaches further than the EU's borders in three ways.
First, a separate set of standards under the same package covers group-wide requirements, including additional measures for subsidiaries and branches in third countries. Groups that operate in both the EU and Southeast Asia should expect the EU standard to shape group policy. Second, EU-based correspondent and counterparty banks will apply these standards to their own customer files, and it is reasonable to expect more detailed data requests to follow. That second point is an inference, not something the report states.
Third, the standards show a regulator turning a risk-based principle into specific data, verification and screening expectations. That makes them a practical benchmark for customer due diligence for banks under BSP, OJK or BNM supervision. Teams can test whether their own programme is documented to the same level of detail.
What data must the customer due diligence process collect and verify?
The standards require a defined set of identification data points. Every point that is collected must also be verified.
For natural persons, the final report requires all names shown on the identity document or electronic identification (Art. 2), address data down to street level where it exists (Art. 3), place of birth to at least country level (Art. 4), and reasonable steps to establish whether the person holds more than one nationality (Art. 5). If several nationalities are declared, at least one must be verified.
Senior managing officials of a legal entity can be recorded at the entity's registered office. The consultation draft had a separate article on their residential addresses, and the final text deletes it. For low-risk customers, simplified due diligence reduces the minimum data set to names, place and date of birth and nationality (Art. 18). It does not remove the verification requirement.
For banks, the practical test is whether the onboarding data model can hold multiple names and multiple nationalities in structured fields. A single free-text name field and a single nationality field will not hold the data the standards describe.
How is identity verified, including remotely?
Electronic identification and qualified trust services are the default route, and other remote methods are an exception that must be justified.
Under Article 6 of the standards and Article 22(6) of the AMLR, identity is verified through an identity document or equivalent, or through electronic identification means and qualified trust services. Electronic identification can also be used face to face. Article 7 permits alternative remote verification only where the customer cannot reasonably use those routes, and the institution must be able to justify that choice to its supervisor.
The Article 7 safeguards are specific. The process must confirm that the person presenting the document is its holder and protect the integrity and confidentiality of the communication. It must capture images and sound of sufficient quality, and it must stop on a technical failure or doubt about identity. Records must be time-stamped and stored securely for later review.
This is a useful reference for identity verification and know-your-customer controls: the standard separates proving who someone is from the wider customer due diligence process, and requires documented fallback logic for each.
How must beneficial owners be verified?
Institutions must use reliable sources beyond central registers and must understand the ownership structure, not just record the names at the top.
Article 10 lists acceptable verification sources, including public registers other than central registers, and third-party sources such as data providers and group entities. Article 11 requires an understanding of ownership and control, including intermediate entities and nominee arrangements. The final text treats complexity as an indicator weighed against factors such as layering, trusts, high-risk jurisdictions and nominees, and drops the rigid definition of a complex structure that the consultation draft proposed.
A bank that verifies an ultimate beneficial owner from one register extract will have a documentation gap under this standard. The file should show which sources were consulted and why they were considered reliable. It should also show how the institution reached its view of who controls the entity.
What changed between the consultation draft and the final text?
The final text is shorter and gives institutions more room, in exchange for stronger documentation duties.
Analysis of the final report notes that the text was cut from 33 to 29 articles. Mandatory information lists on the purpose of the relationship and on enhanced due diligence became optional. Information the institution or its group already holds must be taken into account. Source of funds was removed from the minimum information for simplified due diligence. Manual screening is now treated the same as automated screening, provided it is effective for the institution's size, business model and risks.
The common thread is a shift of burden. Supervisors will not prescribe every data point, so institutions must be able to explain why their chosen approach is adequate for their risk. That is the same expectation that sits behind a well-run customer risk rating methodology.
What do the screening requirements say?
They require screening of customers, owners and controlling persons against politically exposed person and sanctions lists, including original-script names, transliterations, aliases and wallet addresses.
Article 17 requires institutions to determine politically exposed person status before establishing a relationship. The same check applies to existing customers and beneficial owners at a risk-sensitive frequency, and without delay when new information or an updated list appears. Our guide to PEP categories, EDD triggers and ongoing monitoring covers how that obligation looks in practice.
Article 25 covers targeted financial sanctions. Names must be screened in their original alphabet and, where relevant, transliterated into the Latin alphabet. Aliases and digital wallet addresses must be screened where they appear on a sanctions list. Onboarding, changes to designations and changes to customer due diligence data all trigger re-screening. Reporting on the final text says AMLA rejected a generally risk-based approach to sanctions screening, so the obligation is not scaled down for low-risk customers.
The transliteration requirement matters in this region. Name variants are a documented weakness of default configurations, which is why we wrote about why compound surnames break screening. Payment-level checks follow different logic from customer-level checks, as set out in our comparison of payment screening and transaction monitoring.
How often must customer information be refreshed?
At least every year for higher-risk customers and every five years for others, with event-driven updates in between.
Under Article 26(2) of the AMLR, customer information must be kept up to date within those maximum periods. The final report applies the same periods to existing relationships through the transitional provision in Article 28. They are counted from the entry into force of the standards, so back-book remediation is part of the workload. Review frequency within the limits remains risk-based.
For teams building the review cycle, the parallel with ongoing customer due diligence is direct: a calendar date is the backstop, and a change in the customer's data, risk indicators or list status is the trigger that matters. Monitoring results should also feed the file, which is where transaction monitoring and the customer file have to talk to each other.
What should a compliance team outside the EU do now?
Use the standards as a gap-analysis checklist for CDD in banking. There is no need to wait for local rules to change.
- 01Audit the data model. Check that onboarding systems hold multiple names, multiple nationalities, structured addresses and place of birth as separate fields.
- 02Map verification routes. Document which route each journey uses, what the fallback is, and who approves a fallback.
- 03Review beneficial-ownership sourcing. Record the sources used and the reasoning, and avoid relying on a single register.
- 04Test screening on variants. Run original-script names, transliterations and aliases through the screening configuration and record the results.
- 05Set refresh triggers. Define the annual and five-year cycles by risk tier and the events that bring a review forward.
- 06Write the justification. Where the programme departs from a benchmark, record why that is adequate for the institution's risk.
If you want to see how customer risk rating, screening and ongoing review work together in a single AML platform, book a walkthrough of Fyscal ARCX and bring your current onboarding data model with you.