AMLR 2027 webinar (on-demand): Due diligence, UBO mapping and transaction monitoring

8 October 2026 · Recording: 45 minutes

AMLR applies from 10 July 2027. It brings most of the EU’s anti-money laundering rules for companies into one regulation that applies directly in every member state.

In this 45-minute webinar, Marcus Björklund, Head of Product & Compliance at Bits, walks through the three areas where AMLR creates the most manual work for compliance teams: customer due diligence, beneficial owner (UBO) mapping and transaction monitoring.

The webinar ends with a live demo of Bits’ Transaction Monitoring, and questions from the audience.

Fill in the form to watch the recording.

Get the webinar recording

Key takeaways

The webinar covers four of the 8 big changes AMLR introduces:

Due diligence widens and tightens. Source and destination of funds move into standard onboarding, collected where the risk calls for it. AMLR also sets one minimum list of identification data, including place of birth and nationality for individuals, and the tax identification number and Legal Entity Identifier for companies, where available. Customer information has hard refresh limits: 1 year for higher-risk customers and 5 years for everyone else, with event-based reviews in between.
Identity verification moves to electronic ID. An ID document checked in person or eIDAS-level electronic ID are the main routes, and AMLA expects eID to be used wherever possible.
UBO mapping is the biggest build. Beneficial owners are identified through ownership (25% or more, added up across all layers) and, in parallel, through control. The two rules can combine across layers of the same chain.
Transaction monitoring has to see the customer. AMLR asks you to check transactions against what you know about the customer, their business and risk profile and, where necessary, the source and destination of funds. That only works if your monitoring and KYC data are connected.

Notes from the webinar

All three areas (due diligence, UBO mapping and transaction monitoring) will require your onboarding, screening and monitoring tools to work from the same customer data.

1. Customer due diligence: what you collect and how often you update it

AMLR sets out the minimum information you collect to identify a customer (Art. 22(1) AMLR). For individuals that includes place and full date of birth and nationalities. For legal entities it includes the tax identification number and the Legal Entity Identifier, where available. The same requirements apply to any person acting on behalf of the customer.

Before onboarding, you also need to understand the purpose of the relationship. Where necessary, that means collecting the purpose and economic rationale, the expected level of activity, the source and destination of funds, and the business activity or occupation (Art. 25 AMLR). This applies to occasional transactions too. AMLA’s draft standard confirms that how much of this you collect depends on the risk (Art. 16 RTS).

Customer information then has to stay current. The maximum gap between updates is 1 year for higher-risk customers and 5 years for all others (Art. 26(2) AMLR). A relevant change in a customer’s circumstances triggers a review straight away (Art. 26(3) AMLR).

On identity verification, AMLA’s final draft standard on customer due diligence (October 2026) names two main routes: an ID document checked in person, or electronic identification at eIDAS “substantial” or “high” level, including the EU Digital Identity Wallet (Art. 6 RTS; Art. 22(6) AMLR).

More in AMLA’s October release on AMLR standards.

2. UBO mapping: ownership and control

AMLR identifies beneficial owners through two rules that run in parallel:

Ownership: 25% or more of the shares, voting rights or other ownership interest, held directly or indirectly. Indirect stakes are multiplied along each chain and added up across chains (Art. 52(1) AMLR).
Control: holding 50% plus one of the shares or voting rights, or control via other means such as the right to appoint the board or relevant veto rights, which has no threshold (Art. 53 AMLR).

Where ownership and control apply on different layers of the same chain, the two combine (Art. 54 AMLR).

You collect beneficial owner information from the customer and also check it against the central beneficial ownership register (Art. 22(7) AMLR).

If they don’t match, you report the discrepancy to the register within 14 calendar days. Minor differences, such as typos, or outdated data where you know the real owner from another reliable source, can instead be settled with the customer, except in higher-risk cases (Art. 24 AMLR).

If no beneficial owner can be identified after exhausting all means, you record that and identify all senior managing officials of the company instead (Art. 22(2) AMLR).

In the webinar, Marcus walks through a UBO mapping example: a company with six people in its ownership structure, and which of them count as beneficial owners under AMLR, and why.

Read more in our guide to UBO mapping under AMLR.

3. Transaction monitoring: what transactions are checked against

Monitoring under AMLR is more specific than before. Transactions must be consistent with what you know about the customer, their business activity and risk profile and, where necessary, the origin and destination of the funds (Art. 26(1) AMLR).

Looking at single transactions isn’t enough: suspicion can come from patterns and links between transactions, and suspicious attempted transactions must be reported too (Art. 69 AMLR).

In practice your monitoring tool needs to read your KYC data: a rule can only compare a transaction with the expected activity a customer declared if that answer reaches the rule.

In the demo, Marcus shows transaction monitoring in Bits. It sits in the same platform as onboarding, due diligence, screening, risk scoring and case management, and works from the same customer data:

Rules that understand the customer. Rules are built as a flow and check each transaction against what you already know about the customer, such as their risk score, country of residence and history.
Data enrichment works both ways. A transaction can read the customer’s risk classification and update it, for example by marking a large transaction on the customer’s profile.
Cases open with the full context already there: the customer record, what triggered the case and the linked transactions.
Compliance reaches the rest of your tech stack. Bits can send updates to your CRM, Slack or in-house systems over webhooks and APIs.

—

Questions from the audience

Does the business register show who controls a company, for example a shareholder with veto rights?

It depends on the country. Some registers show why a person is a beneficial owner and the type of control they hold, others don’t. That is why you work from more than one source: what the customer tells you at onboarding, the central beneficial ownership register (which you must consult but can’t rely on alone, Art. 22(7) AMLR), and, where the market allows it, shareholder data for every company in the chain. Comparing the three is how you spot an error or a structure someone is trying to hide.

How do you ask customers about beneficial owners in a way they understand?

Many companies don’t know what counts as a beneficial owner, so give examples of the typical cases in the onboarding form. Where you can’t get ownership data from a register, ask the customer both to name the people they consider beneficial owners and to upload their group structure chart. You can then make your own assessment from the chart, even if the names they gave turn out to be incomplete.

Is a group structure chart from the customer enough to verify ownership and control?

On its own, no. The chart is the customer’s own account. Where the market allows it, verify it against the central beneficial ownership register and against shareholder data from the business registers, which are the most reliable independent sources (Art. 22(7) AMLR). Depending on your risk assessment, you can add a fourth source, such as a report from a credit bureau or data provider.

What does “in person or eID” mean for identity verification? Is a verified passport copy enough?

In person means the customer shows a valid passport or national ID card face to face. eID means electronic identification at eIDAS “substantial” or “high” level (Art. 22(6) AMLR). National schemes such as BankID in Sweden and Norway, MitID in Denmark or the Finnish trust network can be used where they meet those levels, and in future so can the EU Digital Identity Wallet. A passport copy sent by email is neither. AMLA’s final draft standard says eID should be used wherever possible (Art. 6 RTS).

So can you still onboard customers remotely without eID?

Yes, but only as an exception. Under AMLA’s final draft standard, another remote method is allowed when the customer can’t reasonably show ID in person and has no access to eID. You need to record why, and the method has to meet safeguards: matching the person to the document, secure communication, and image and sound quality good enough to identify them (Art. 7 RTS). More in AMLA’s October release on AMLR standards.

Is UBO mapping one of the most important parts of AMLR?

It is one of the areas that needs the most work. The rules get complex quickly with multi-layered ownership, they sit at the core of onboarding and the customer profile, and they are likely to be a focus when supervisors audit.