This article is part of Protiviti’s AMLA Insights Series. Read: Part 1, Part 2, Part 3.
What the AMLR and Customer Due Diligence RTS Really Require
Introduction
The European Union’s AMLA (Anti-Money Laundering Authority) consultation on the draft Customer Due Diligence Regulatory Technical Standards closed in May 2026. The final Regulatory Technical Standards (RTS) is expected to be submitted to the European Commission during the third quarter of 2026, ahead of the broader AML package becoming applicable in July 2027.
While much of the discussion has focused on the new information that institutions will be required to collect, that only tells part of the story. The more significant shift is that AMLR increasingly treats customer data as a core component of financial crime controls.
For years, financial institutions have collected customer information during onboarding, documented it in KYC files, and revisiting it only during periodic reviews. That model is becoming increasingly difficult to sustain. Under AMLR and the draft RTS, information such as place of birth, nationality, beneficial ownership, source of wealth, and purpose of relationship will be needed to support sanctions screening, PEP screening, customer risk assessments, transaction monitoring, investigations, and ongoing customer due diligence processes
Collecting this information is not a one-off onboarding exercise. AMLR reinforces the expectation that customer information is kept up to date through periodic and event-driven reviews, with higher-risk relationships subject to more frequent refresh. This means firms need sustainable mechanisms to maintain data quality throughout the customer lifecycle, including when ownership, customer circumstances or other risk-relevant information changes.
The challenge of meeting this obligation is magnified by the realities many institutions face today. Customer data often resides across multiple systems. Information is manually enriched, inconsistently validated, or difficult to access when needed. Data may exist, but it is frequently siloed within onboarding files and disconnected from the controls designed to identify financial crime risks.
This matters because modern financial crime compliance programs are entirely dependent on data.
When customer information is inaccurate or incomplete, customer risk assessments become less reliable. Sanctions and PEP screening effectiveness declines. Transaction monitoring loses critical context. Investigators spend more time validating information than evaluating risk. Simply put, weak data produces weak controls.
Regulators have increasingly demonstrated their willingness to treat data failures as control failures. We have seen this translate into significant enforcement actions:
- 10 to 100 €million for local control failures ($11.5 million to $115 million)
- 100 to 500 €million for major AML or data issues, ($115 million to $576 million),
- And in systemic cases, up to several billion euros.
As supervisory expectations continue to evolve, organizations that view AMLR merely as a compliance project risk missing the broader transformation that is required. The institutions best prepared for July 2027 will not necessarily be those that collect the most information. They will be those institutions that can demonstrate that customer data is structured, trusted, maintained, and actively supporting decision-making across the financial crime framework.
A different way of thinking about data
Rather than asking whether required information is collected, organizations should ask a broader set of questions:
- Do we collect the information?
- Is it stored in a structured format?
- Can it be easily accessed?
- Is it trusted?
- Which financial crime controls actually use it?
- How do we know it remains accurate over time?
The answers to these questions often reveal a vastly different picture. And the answers will determine the scale of the implementation effort required before July 2027.
Many institutions already have much of the information required under AMLR. The challenge is that it was never designed to support the broader range of use cases that regulators increasingly expect. Information collected for onboarding purposes will now be expected to support screening, monitoring, investigations, risk assessments, and ongoing customer reviews. The value of the data depends not on whether it exists, but whether it can be effectively operationalized.
The table below summarizes several of the most significant data-related developments emerging from AMLR and the draft CDD RTS.
| Data Point | What is changing? | Refresh and maintenance expectation | What do organizations need to do? |
| Place of Birth | Required identification attribute for natural persons and increasingly relevant for identity resolution. | Not applicable – static date point. | Update onboarding, define verification standards and ensure the field can be consumed by screening and risk scoring tools. |
| Nationality / Citizenship | More structured use as a country-risk, sanctions and customer risk indicator. | Maintain through periodic refresh and event triggers such as changes in nationality, residence, customer profile or jurisdictional exposure. | Standardize capture of multiple nationalities and align usage across screening, country-risk logic and customer risk models. |
| Tax Identification Number | Increased emphasis on structured, reliable and reusable tax identifier data. | Validate and update when tax residence, legal status or customer circumstances change, and during scheduled customer reviews. | Define common validation rules, ownership responsibilities, storage standards and data quality controls. |
| Beneficial Ownership | Greater focus on ownership chains, control structures and complex legal arrangements. | Refresh when ownership, control, legal structure or intermediary entities change, and as part of periodic reviews. | Move from document-based records to structured ownership data models with change history and downstream control usage. |
| Source of Funds | Expected to provide context for transaction activity and ongoing monitoring. | Update when activity patterns, funding sources, products, expected volumes or risk profile materially change. | Connect the data to transaction monitoring, customer reviews and investigation workflows rather than leaving it in onboarding files. |
| Source of Wealth | Enhanced expectations in higher-risk scenarios and for customer risk assessment. | Refresh when wealth profile, occupation, business activity, assets or risk indicators materially change. | Ensure the information supports enhanced due diligence, ongoing monitoring and investigation context. |
| PEP Information | Expanded scope and more harmonized screening and escalation expectations. | Maintain dynamically through screening alerts, status changes, role changes, relationship changes and periodic review cycles. | Review data quality, matching logic, escalation workflows, approval requirements and enhanced monitoring triggers. |
| Purpose and Nature | More granular understanding of expected customer activity and relationship rationale. | Refresh when products, channels, transaction behavior, geography or customer objectives change materially. | Structure the information so it can calibrate monitoring, support risk assessments and inform customer review outcomes. |
Place of birth: More than another data field
One of the most debated features of the draft RTS has been the introduction of place of birth as a required customer attribute.
A recurring question during the consultation process has been why AMLA considers this information necessary. The answer appears to lie less in customer risk assessment and more in identity resolution.
Across sanctions screening, politically exposed person (PEP) screening and adverse media screening, place of birth is frequently used as a secondary identifier to distinguish between individuals with similar names and dates of birth. This becomes particularly important when screening against international sanctions and PEP databases where name matching alone may not be sufficient.
Many institutions do not currently use place of birth within their screening architecture. As a result, implementation is not simply a matter of updating onboarding forms. Organizations will need to assess whether place of birth can be consumed by downstream screening tools, customer risk models and monitoring systems.
Place of birth should, therefore, not be viewed as a standalone compliance field. It should be viewed as part of a broader identity resolution framework.
Nationality and citizenship: From static information to risk indicator
Most organizations already collect nationality information. However, nationality is often treated as a static identification attribute rather than a dynamic risk indicator.
Under AMLR, nationality increasingly supports country risk assessments, sanctions screening, enhanced due diligence requirements and customer segmentation. Customers with multiple nationalities, links to high-risk jurisdictions or complex international profiles may require differentiated treatment from a risk perspective.
The challenge is not collection. The challenge is ensuring that nationality information is maintained in a structured format and consistently consumed across screening, risk scoring and customer review processes.
Organizations should also consider how they will manage multiple nationalities, changes in nationality, and inconsistencies across customer records.
Tax identification number: A data governance challenge
Tax identification numbers have historically been collected primarily for tax reporting purposes, such as CRS and FATCA obligations.
The draft RTS increases the importance of this information within the broader customer due diligence framework. This creates a data governance challenge because tax identifiers are often maintained differently across business units, jurisdictions and systems.
A robust implementation approach should focus on standardization. Organizations should establish common validation rules, ownership responsibilities and storage standards. Tax identifiers should not only support compliance obligations, but also contribute to customer identification, deduplication and data quality initiatives.
For many firms, the challenge will be less about obtaining the data and more about ensuring the data is reliable.
Beneficial ownership: From documents to data
Beneficial ownership remains one of the most significant implementation challenges within the AML framework.
Many institutions can demonstrate beneficial ownership information during onboarding. Far fewer can demonstrate beneficial ownership intelligence during ongoing monitoring.
Historically, beneficial ownership information has been maintained through structure charts, PDF extracts and manually maintained records. While these approaches support onboarding activities, they are far less effective when organizations need to identify ownership changes, screen intermediary entities or assess concentration risk across customer portfolios.
The draft RTS increases expectations around complex ownership structures and creates a need for more sophisticated beneficial ownership data models.
In practice, this means moving beyond storing the name of a beneficial owner. Organizations should increasingly be capable of capturing parent-child relationships between entities, ownership percentages, jurisdictions of incorporation, control mechanisms, nominee arrangements and change history.
The question is no longer whether beneficial ownership information exists. The question is whether it exists in a format that supports screening, monitoring and ongoing risk assessment.
Source of funds and source of wealth: Turning data into context
Source of funds and source of wealth information is often collected during onboarding and then rarely revisited.
The RTS reinforces the importance of maintaining this information and ensuring it supports ongoing monitoring activities.
This is particularly relevant for transaction monitoring. Customer profiles should provide context for understanding whether observed activity is consistent with expected behavior. If a customer has declared a particular source of wealth or expected activity profile, monitoring systems should be capable of considering that information when evaluating transactions.
Where source of funds and source of wealth information remain trapped within onboarding files, monitoring systems lose valuable context.
The objective should be to create a direct connection between customer due diligence information and financial crime detection capabilities.
PEP information: A growing data challenge
The AMLR package expands the scope of politically exposed persons and introduces a more harmonized approach across the European Union (EU). Among other developments, the framework broadens coverage of certain local and regional public officials and supports the development of a more consistent European approach to PEP identification. For organizations, this creates a data challenge as much as a compliance challenge.
PEP screening increasingly depends on the quality and completeness of customer data. Name matching alone is rarely sufficient. Place of birth, nationality, aliases and beneficial ownership information all contribute to screening accuracy and the reduction of false positives.
Once identified, PEP status should not remain within a screening platform. It should be used to trigger enhanced due diligence, source of wealth assessments, management approval workflows and enhanced monitoring.
Purpose and nature of the relationship
The purpose and nature of the business relationship has always been a core element of customer due diligence. The RTS places renewed emphasis on understanding expected customer behavior in a more structured manner.
For many organizations, this information currently is captured through free-text descriptions that provide limited operational value. Going forward, the value will be in structuring this information so that it can support customer risk assessments, monitoring scenarios and review processes.
A clear understanding of expected activity remains one of the strongest foundations for identifying unusual or potentially suspicious behavior.
Data lineage: The next regulatory frontier
Historically, supervisory reviews focused heavily on whether required customer information had been collected.
Increasingly, regulators are likely to ask more sophisticated questions:
- Where did the information originate?
- Who verified it?
- When was it last updated? How is it maintained?
- Which controls rely upon it?
- What evidence exists to demonstrate its quality? In other words, regulators are becoming more interested not only in customer data itself, but also in the lineage, governance, and control environment surrounding that data.
For many organizations, answering these questions consistently will prove more challenging than collecting the information in the first place.
Converting compliance requirements into a practical implementation roadmap
How do obligated parties approach this transformation in practice? One important point is this: It is not about repapering the entire customer base overnight. A more effective approach is to define a minimum viable target data model. That means identifying the key data fields that actually drive your controls:
- For customer due diligence,
- For sanctions screening,
- For transaction monitoring, and
- For risk rating.
Then prioritizing those fields based on impact.
In parallel, institutions should:
- Focus first on high-risk customers and products,
- Reduce duplication in data collection, and
- Move towards event-driven updates where possible.
What we have seen work well is a very pragmatic approach:
- Map each data field to a specific control use case,
- Separate regulatory minimum requirements from longer-term optimization, and
- Implement changes gradually, aligned with system and process readiness.
The objective is not to collect more data. The objective is to use data more effectively, with less friction for customers and the business.
For the industry as a whole, this implies a number of structural changes.
We would expect to see:
- More standardization of controls across groups,
- More centralization of governance and data, and
- Significantly higher investment in technology and data infrastructure.
At the same time, supervision will become more consistent across the EU,
and more focused on outcomes rather than formal compliance.
Institutions that continue to operate fragmented, locally optimized models will find it increasingly difficult to meet these expectations.
The bottom line
Many organizations continue to view AMLR as a customer due diligence initiative, but that perspective is too narrow.
What AMLR ultimately reveals is that effective financial crime compliance depends on more than policies, procedures, or technology. It depends on whether organizations can trust the data that enables their controls.
We are witnessing a broader shift across regulatory frameworks: a move away from documentation-centric compliance toward standardized, data-driven control environments. Supervisors increasingly expect consistency, transparency, and traceability. Fragmented systems, disconnected data sources and locally optimized processes will become increasingly difficult to defend.
The organizations that will be most successful in the AMLR era will not be those that collect the greatest amount of information.
They will be the organizations that understand how customer data supports financial crime controls and have built the governance, operating model, and technology infrastructure necessary to use that data effectively.
Under AMLR, customer data is no longer just customer data. It is control data. And that may be the most important change institutions need to prepare for.
How Protiviti can help
As organizations prepare for the upcoming regulatory changes, Protiviti can support the journey from assessment to implementation, helping clients build compliant, sustainable, and business-aligned operating models. Drawing on deep regulatory, transformation, data, and technology expertise, we help organizations not only meet new requirements but also strengthen their overall financial crime and risk management capabilities.
- Assess readiness – Identify regulatory gaps, control weaknesses, and implementation priorities.
- Deliver transformation – Design and execute the operational, governance, and compliance changes required to meet new regulatory expectations.
- Enable through data & technology – Establish the data, analytics, and technology capabilities needed to support sustainable compliance and ongoing regulatory oversight.
For more information, please visit Protiviti’s AML Consulting page or Connect with a local expert below.
- France: Arnaud Floquet
- Germany: Cornelia Tomczak
- Italy: Francesco Monini
- Netherlands: Perry Huijgen; Owen Roderik Strijland
- United Kingdom: Christine Reisman
- United States: Carol Beaumier
Don’t miss the entire AMLA & AMLR conversation
This article is a continuation of Protiviti’s AMLA Insights Series. Explore related perspectives:
- AMLA Readiness Starts Now: Ten Practical Moves for 2026
- Crypto AML Has Entered Its “No Excuses” Era, and the U.K.’s 2026 AML Reforms Make That Explicit
- AMLA May Not Be Your Supervisor – but It Is Redefining Your Risk
