Why AMLR 2027 is a data architecture problem, and what compliance teams need to do about it

Published: 4 June, 2026

Key takeaways

• In July 2027, Regulation (EU) 2024/1624 will replace the harmonised core of national AML law across the EU. The same standard applies in every member state, with no national transposition required.

  
  

• Three requirements force a structural response: UBO calculation method changes entirely; Transaction Monitoring becomes a legal obligation requiring customer data; Source and Destination of Funds extend beyond high-risk customers, collected where necessary.

  
  

• AMLR requires compliance systems to connect. Onboarding data must feed Transaction Monitoring, monitoring must trigger automated reviews, and every compliance decision must be reconstructable on demand. For most compliance stacks today, the data sits in separate tools, making AMLR compliance difficult.

  
  

• Preparing for AMLR means building a data infrastructure where onboarding, monitoring, and case management operate on the same customer record. The window to start the architectural work is now.

  
  

On 10 July 2027, the Anti-Money Laundering Regulation, or AMLR, comes into force across all 27 EU member states simultaneously, with no national transposition required (Regulation EU 2024/1624). Compliance teams at regulated financial companies will recognise the new requirements: tighter KYC, expanded UBO identification, more rigorous monitoring.

The more important change sits underneath the specific requirements. AMLR asks for a different compliance architecture: one where onboarding, monitoring, and risk decisions operate as a single connected process rather than separate workflows in separate systems.

Most compliance stacks today don't work that way. That is the gap AMLR is now making a legal requirement to close and the one we'll focus on in this article.

Note: AMLA must submit its first draft regulatory technical standards to the European Commission by 10 July 2026; the Commission then adopts them. Not everything lands on that date - several guidelines and RTS run to 10 July 2027. This article reflects the regulation as enacted (Regulation EU 2024/1624) and guidance available to date.

How AMLR differs from previous EU AML directives

AMLR is a regulation, not a directive. Directives require national transposition: each EU member state interprets and implements them into local law. This is why operating across the European market today means maintaining compliance processes calibrated to several different national standards.

AMLR eliminates that layer. From July 2027, the same rules apply in Stockholm, Amsterdam, and Frankfurt without interpretation. Whatever compliance infrastructure you build to AMLR architecture applies across every EU market you operate in.

AMLA, the new EU-level supervisory authority operational since July 2025, adds a pan-European oversight layer above national regulators. From January 2028, AMLA will directly supervise 40 of the EU's highest-risk financial institutions.

Three changes that require a structural response

AMLR introduces a multitude of changes across identification methods, governance requirements, reporting obligations, and ongoing monitoring intervals. Three of those requirements force a structural rethink in how data is utilized.

1. UBO identification: AMLR standardises how beneficial owners are calculated

Today there is no single EU method for calculating indirect ownership. The regulation itself notes the inconsistency across member states (Recital 104). One common approach, which we'll call the dominance method, traces ownership chains by identifying the majority owner at each level: where one entity holds a controlling interest in another, the chain stops there. The result is a relatively contained list of named individuals, typically the direct or near-direct majority shareholders. AMLR replaces this with the accumulation method (Art. 52, Regulation EU 2024/1624).

Under the accumulation method, ownership percentages are multiplied at each level of a corporate structure and added across all chains, without truncating at intermediate ownership points. The threshold shifts from 'more than 25%' to '25% or more.' One exception applies: where ownership and control coexist across different layers of a chain, Art. 54 sets its own identification rule instead of clean multiplication.

The practical effect is significant. Corporate structures with several minority-ownership chains - each individually below the current threshold - can produce additional named UBOs under the accumulation method that would not appear at all under the dominance method. Structures that look straightforward under today's national standard become more complex as the calculation method captures more of the ownership chain.

Ownership is only one of two routes to beneficial ownership; AMLR requires both to be assessed in parallel, not in sequence (Art. 51). The second is control - either through control via ownership of 50% plus one of shares or voting rights (Art. 53(2)(c)), or via other means such as board-appointment rights, veto rights, or nominee arrangements (Art. 53(3) and (4)).

An individual can be a beneficial owner through control while holding little or no equity, and percentage arithmetic will never surface them - so a UBO engine that only multiplies ownership chains is incomplete on its own terms.

What this means for compliance teams:

Each additional UBO identified must go through identity verification, PEP and sanctions screening, and be enrolled in ongoing monitoring. A structure that produces more named individuals under the accumulation method expands the verification and screening workload for that customer proportionally.

For compliance teams running UBO checks manually or across separate tools, that volume increase compounds across the portfolio: each additional individual requires its own identity verification, its own screening check against PEP and sanctions lists, and its own place in the ongoing monitoring queue.

Any system built to current national standards will produce different results under AMLR. The ownership mapping that is complete by today's standard will be incomplete from July 2027.

2. Transaction monitoring: a legal obligation requiring onboarding data

Art. 26(1) AMLR requires all obliged entities to conduct ongoing monitoring of business relationships, including transactions, to ensure they are consistent with the obliged entity's knowledge of the customer, the customer's business activity and risk profile, and where necessary, with information about the origin and destination of funds.

For payment institutions and fintechs that have treated Transaction Monitoring as an operational capability rather than a legal obligation, this changes the baseline.

Art. 26(1) specifies that Transaction Monitoring must be informed by the customer's risk profile, the nature of their business, and their declared activity, and where necessary, by information about the origin and destination of funds. Transaction Monitoring that looks only at transaction patterns, without access to onboarding data, UBO structure, and risk score, does not meet this standard.

What this means for compliance teams:

The practical implication is specific. For monitoring rules to distinguish unusual from expected, they need to know what expected looks like for that customer: declared business activity, anticipated transaction volumes, counterparty country exposure.

That context lives in the onboarding record. Without it, monitoring applies generic thresholds uniformly across all customers: less effective at detecting real risk, and more likely to flag activity that is entirely consistent with what the customer declared at onboarding.

Art. 26(3) adds a further dependency. A Transaction Monitoring alert can be a relevant fact that obliges you to review, and where relevant update, the customer information, outside the normal periodic cycle.

The review requires immediate access to the full onboarding record: risk classification, UBO structure, Source and Destination of Funds. A Transaction Monitoring system that cannot pull the onboarding record when an alert fires has a clear compliance gap.

To summarize, the requirement is for integrated monitoring, not isolated transaction analysis.

3. Source and Destination of Funds: no longer high-risk-only

Under AMLR Art. 25, before entering any business relationship or occasional transaction, an obliged entity must understand its purpose and intended nature and, where necessary, obtain information including source of funds and destination of funds. The scope is universal, meaning it applies to every relationship, not only high-risk ones.

What this means for compliance teams:

Customer onboarding questionnaires that display Source and Destination of Funds conditionally (only for high-risk customers) need structural redesign.

The data also needs to flow downstream into risk scoring and monitoring. And, collecting this data at onboarding without using it in monitoring covers only half the requirement. This presents yet another concrete case for a connected data architecture.

Why AMLR requires connected compliance data

Each of the three requirements shares an underlying constraint: they only work if compliance data, and particularly customer data, flows between systems.

The UBO requirement means your ownership graph needs to be queryable by your monitoring system if a transaction triggers a review.

The Transaction Monitoring requirement means your transaction rules need access to the customer's risk score, declared activity, and other onboarding data, not just transaction history.

The Source and Destination of Funds requirement means data collected at onboarding needs to be visible at the point of a monitoring alert and reconstructable at the point of a regulatory inspection.

Most compliance stacks today don't work this way.

The KYB/KYC onboarding process lives in one tool. Screening runs in another. Transaction Monitoring in a third. Case management in a fourth.

When a regulator asks why a customer was approved, or why a transaction wasn't flagged, the answer requires stitching together data from several separate systems - if it is retained at all.

AMLR Art. 77 makes the requirement explicit: obliged entities must retain the customer due diligence records and the record of each assessment - including the information and circumstances considered and the result - so the decision can be reconstructed on demand. That is a data architecture requirement, not a reporting one.

One term increasingly used to describe what AMLR mandates in practice is Perpetual KYC.

In short, Perpetual KYC means that instead of a static customer view based on onboarding, businesses need a continuously updated customer record that reflects current risk, current ownership, and current transaction behaviour. The process requires the onboarding data model, the screening process, the monitoring logic, and the case management system to operate on the same customer record.

While connected data infrastructure can be seen as the prerequisite to comply, AMLR also sets some explicit requirements.

Art. 9 requires every obliged entity to maintain documented, up-to-date internal policies and procedures that govern how decisions are actually made within the day-to-day compliance operations. Having the right data available is one half of the problem. Having a defined, auditable, automated process that acts on it is the other. We'll address this directly in upcoming pieces in this series.

What AMLR harmonises - and what it doesn't

While AMLR will apply across the EU, the EU markets are not identical. Registry structures differ, data availability varies, and an onboarding process for a German GmbH looks different from one for a Swedish AB.

What AMLR harmonises is the standard those processes are built to. From July 2027, the same requirements govern the data you collect, the checks you run, the decisions you document, and the monitoring you maintain.

That distinction matters for how you build. The compliance logic only needs to be designed once, to the AMLR standard. Local data sources and workflows feed into it differently per market, but the rules remain the same.

The architectural question AMLR is forcing compliance teams to ask is what infrastructure should run our compliance process so that we remain compliant.

AMLR 2027 compliance: a four-point infrastructure checklist

1. Onboarding data must feed monitoring. The customer record built at onboarding (risk score, UBO graph, declared Source and Destination of Funds, business activity) must be live when a transaction triggers a review. A snapshot from the day of onboarding is not enough (Art. 26(1), Regulation EU 2024/1624).

   
   

2. Monitoring must trigger reviews automatically. A sanctions hit, an ownership change, or a Transaction Monitoring alert can be a relevant fact that obliges you to review, and where relevant update, the customer information - not only on a calendar cycle (Art. 26(3), Regulation EU 2024/1624).

   
   

3. UBO determination must implement the full framework, not just ownership arithmetic. Ownership is multiplied across chains at the 25%-or-more threshold (Art. 52); control - ownership of 50% plus one of shares or voting rights, or via other means - is assessed in parallel (Art. 51, Art. 53); and where the two coexist across layers, Art. 54 sets its own rule instead of clean multiplication. Systems that only run ownership arithmetic produce incomplete results from July 2027.

   
   

4. Every compliance decision must be reconstructable. The investigation, the data used, the risk signals, the outcome: retained and retrievable on demand (Art. 77, Regulation EU 2024/1624).

FAQ

When does AMLR come into force?

AMLR comes into force on 10 July 2027. AMLA's first draft technical standards are due to the Commission by 10 July 2026, with adoption following.

What is the AMLR accumulation method?

The accumulation method (Art. 52, Regulation EU 2024/1624) is the approach AMLR requires for calculating ownership-based beneficial ownership. Ownership percentages are multiplied at each level of a corporate structure and added together across all chains, without truncating at intermediate ownership points. The threshold is 25% or more. This replaces the varied national approaches used today - often a dominance-style method that stops tracing at each majority-ownership point.

The practical effect: more individuals are identified as beneficial owners under the accumulation method. Any system built to current national standards will produce incomplete results from July 2027.

This covers the ownership route only. AMLR requires beneficial ownership through control - ownership of 50% plus one of shares or voting rights, or control via other means such as board-appointment rights, veto rights, or nominee arrangements - to be assessed in parallel (Art. 51, Art. 53). And where ownership and control coexist across layers, Art. 54 applies its own rule instead of clean multiplication.

What is Perpetual KYC?

Perpetual KYC describes a compliance model where the customer record is continuously updated rather than reviewed on fixed calendar schedules alone.

AMLR mandates the key elements: Art. 26(3) requires customer reviews to be triggered by events - a sanctions hit, an ownership change, a Transaction Monitoring alert - in addition to periodic reviews. Art. 26(2) sets hard maximum intervals: 1 year for high-risk customers, 5 years for all others. Perpetual KYC requires onboarding data, screening, Transaction Monitoring, and case management to operate on the same customer record.

Does AMLR replace Swedish laws?

Largely, but not entirely. AMLR is directly applicable from 10 July 2027 and replaces the harmonised core of national AML law - customer due diligence, beneficial ownership, monitoring - with no transposition required. It does not erase national AML legislation wholesale: the parallel directive AMLD6 (Directive (EU) 2024/1640) still requires national transposition for supervisory architecture, FIUs, and beneficial ownership registers.

In practice, Sweden's penningtvättslagen will be substantially repealed and rebuilt around AMLR rather than simply deleted.

Can we meet AMLR requirements by updating our existing compliance tools separately?

Not fully. AMLR's requirements don't just change what each tool needs to do - they change how those tools need to relate to each other. Art. 26(1) requires Transaction Monitoring to be informed by the customer's knowledge, business activity, risk profile, and where necessary, the origin and destination of funds. Art. 77 requires obliged entities to retain the records behind each decision, so it can be reconstructed from a single evidence trail.

A UBO engine, a Transaction Monitoring tool, and a case management system that each get updated independently still can't satisfy these requirements if they don't share the same customer record. The architecture change is the requirement.

What does AMLR require for Source and Destination of Funds?

Under AMLR Art. 25, before entering any business relationship or occasional transaction, the obliged entity must understand its purpose and intended nature and, where necessary, obtain information including source of funds and destination of funds.

For compliance teams, this means two things: onboarding questionnaires that display these fields conditionally need redesign, and the data collected must flow downstream into risk scoring and monitoring. Collecting it at onboarding without using it in ongoing monitoring covers only half the requirement.

What is the difference between AMLR and AMLD6?

AMLR (Regulation EU 2024/1624) is directly applicable across the EU, meaning it has no national implementation layer. AMLD6 requires national transposition and covers areas where member states retain discretion. Both are part of the 2024 EU AML Package. For most compliance teams at regulated financial institutions, AMLR is the operative document.

What is AMLA and when does it start supervising?

AMLA (the Anti-Money Laundering Authority) is the new EU-level supervisory body, operational since July 2025 and headquartered in Frankfurt. From January 2028, it directly supervises 40 of the EU's highest-risk financial institutions operating across six or more member states. National supervisors retain responsibility for all other obliged entities.

What should compliance teams do now?

Assess your current stack against four questions: does KYB/KYC onboarding data feed your monitoring system? Does a screening hit or ownership change automatically open a review? Is your UBO engine built to the accumulation method? Can you reconstruct compliance decisions on demand from a single place?

The deadline is closer than it looks. AMLA's draft technical standards are due to the Commission in July 2026, with adoption following. The regulation applies in full twelve months later.

—

If you're assessing your stack against the AMLR requirements, we're happy to walk through what AMLR means for your specific setup. Talk to the team

—

This article is published by Bits Technology, a compliance infrastructure platform for regulated financial companies in Europe.