Data has always been part of an effective AML programme. But AMLR introduces even clearer expectations on what data must be collected, how it should be structured, and how it connects to risk assessments and operational outcomes.
This raises a common question among AML professionals: does our current data environment support the level of transparency and consistency that supervisors will expect?
Earlier this year, we hosted a breakfast seminar, where SannaMari Bölenius, Senior Manager at Frank Penny, a Swedish AML consulting firm, addressed the questions related to data and AMLR.
In this article, we’re highlighting some of the key takeaways from her session.
AMLR: what does the market say?
The EU AML Package introduces AMLR as a directly applicable regulation across member states. This creates a more harmonised framework with less room for national interpretation.
For Nordic institutions, AML frameworks are already well-developed. The focus now is on aligning these frameworks with stricter and more detailed requirements, while ensuring that execution can be clearly demonstrated.
When surveying our customers, we’ve noticed a general awareness that data requirements are increasing, but there’s less clarity on what that means in practice.
Several patterns tend to emerge from these discussions:
- Data is spread across multiple systems
- Definitions are not standardised
- Different onboarding flows exist across products or entities
- External data sources are not consistently integrated
- Systems are difficult to adapt when new requirements are introduced
This creates uncertainty when trying to interpret AMLR at an operational level. The challenge is less about understanding the regulation itself and more about understanding what it requires from existing processes and data structures.
AMLR data requirements: what has been published so far
As of March 2026, AMLR introduced a detailed regulatory framework, containing 90 articles and five annexes covering:
- Risk assessments
- Customer due diligence (CDD)
- Customer risk classification
- Transaction monitoring
However, much of the detail is still evolving. As SannaMari stated:
“The data points will be further specified, and additional ones will be added through upcoming RTS (Regulatory Technical Standards), ITS (Implementing Technical Standards), and guidelines.”
Examples of AMLR data requirements
AMLR introduces more explicit expectations across several areas of the AML lifecycle, such as customer identification and profile data, risk, as well as periodic reporting.
1. Expanded customer identification data
New or more clearly defined datapoints include:
- Place of birth (country of birth)
- Nationality
- Occupation
- Purpose and nature of the business relationship
- Customer risk factors such as:
- Complex ownership structures
- Cash-intensive activities
- “Unusual circumstances”
This increases the level of detail required at onboarding and during ongoing due diligence.
2. Enhanced risk and behavioural data
AMLR introduces more structured expectations around:
- Sanctions risk assessment
- Product risk variables
- Customer asset levels
- Relationship duration and frequency
- Transaction size and product usage
- Exposure to specific sectors (e.g. oil, weapons, precious metals, cultural artefacts)
This connects customer data more directly to transaction behaviour and risk modelling.
3. Operational and performance metrics
One of the most significant shifts is the inclusion of operational datapoints that reflect how the AML framework performs in practice:
- Number of overdue ongoing due diligence (ODD) reviews
- Time from sanctions publication to screening update
- Customers with incomplete CDD data
- Transaction volumes by country
- Backlog of transaction monitoring alerts
- SAR/STR ratios
- Investigation timelines (from alert to reporting)
These datapoints move AML from static compliance to measurable operational effectiveness.
How to work with AMLR data requirements in practice
A common starting point is uncertainty around where to begin. The most effective approach is to translate regulatory requirements into internal processes and data flows.
1. Start with a practical exercise
The recommended starting point is to take a single datapoint and ask:
- Could we implement this today?
- Where would the data live?
- How would we collect it?
- Which processes would be affected?
This exercise forces a detailed review of how data flows through your organisation and highlights gaps that are otherwise difficult to see.
2. Expect multiple activities for each new datapoint
A key insight from SannaMari’s presentation is that a single datapoint can trigger updates across several areas, such as:
- Onboarding processes
- Customer risk classification
- Periodic reviews and reporting
- Ongoing due diligence
- Sanctions screening
- Transaction monitoring
- Enhanced due diligence
In addition, there are supporting activities such as:
- Defining the datapoint
- Updating data models and logic
- Adjusting parameters and thresholds
- Integrating external data sources
- Updating multiple onboarding flows
- Recalibrating risk models
- Adjusting data exports and reporting
The number of required changes depends on how mature your data architecture and processes are.
3. Use the exercise to identify structural weaknesses
When organisations go through this process, several recurring issues appear, such as:
- Uncertainty about where definitions should be maintained
- Weak or missing connections to external registers
- Multiple onboarding flows creating many update points
- Data stored in several locations with no clear source of truth
- Systems that are difficult to change or extend
4. Translate insights into concrete initiatives
Once the gaps are visible, the next step is to define actions. Some common initiatives include:
- Consolidate data into a single location
- Introduce one onboarding flow for all customers
- Address existing backlogs and data quality issues
- Enable integration with external data sources
- Ensure flexibility in customer risk classification
- Track when KYC data was last updated
- Automate data extraction and reporting
These initiatives create the foundation required to support new and future datapoints.
5. Prioritise the changes that matter most
Not all changes need to be implemented immediately. As SannaMari highlighted:
“The important thing is to identify the major changes - the ones you should start with already now.”
A useful way to prioritise is to ask:
- Which datapoints affect the most processes?
- Where do we currently lack data or control?
- Which changes reduce fragmentation and manual work?
- Would you be able to go live with this already this summer? Why? Why not?
These questions help you distinguish between theoretical readiness and actual implementation capability in your organisation.
6. Build for what is coming next
Many AMLR requirements are still being specified. Additional datapoints and clarifications will follow, thus making flexibility a key requirement.
Systems and processes need to support new datapoints without major redesign, changes to definitions and logic, and integration of additional data sources.
How Trapets supports AMLR implementation
AMLR requires organisations to translate new data requirements into structured processes, consistent logic, and clear documentation. Trapets supports this work at a practical level:
One connected data foundation
Bring together customer data, screening results, and transaction activity in one platform. Reduce fragmentation and ensure that new datapoints can be applied consistently across the AML lifecycle.
Structured and adaptable data collection
Update KYC and due diligence workflows as new requirements emerge, making it easier to introduce additional datapoints without rebuilding processes.
Consistent risk logic and transparency
Configure and trace risk models, rules, and thresholds to support a clear linkage between data, risk assessments, and decisions.
Operational control and audit readiness
All actions, updates, and outcomes are logged and accessible, allowing your team to respond to supervisory requests with clear and structured evidence.
Flexibility as requirements evolve
As AMLR is further specified through RTS and ITS, the platform supports continuous updates to data, models, and workflows without disrupting daily operations.
Curious to learn more about how Trapets can help you with your AML workflows? Our team is happy to help you.