AMLR compliance guide

The EU Anti-Money Laundering Regulation (AMLR), Regulation (EU) 2024/1624, puts the customer due diligence (CDD) rules into one directly applicable text. It binds credit and financial institutions, including crypto-asset service providers (CASPs), providers of gambling services and the other obliged entities listed in Article 3. It entered into force on 9 July 2024 and will apply from 10 July 2027. Until then, the national laws that transpose the current directive continue to apply. This page is for the developers and compliance engineers who have to build it. Each section states what the regulation asks for, gives the article, and shows the Didit workflow step, API endpoint or webhook you can use for that part. For the business overview, see the AMLR solution page. Last reviewed: 2 October 2026.

Didit provides the checks and the evidence. You remain the obliged entity. You decide the customer’s risk profile, you decide whether to onboard, and you remain fully liable for any task you outsource (Article 18). Using Didit does not by itself make your company compliant with AMLR. This page is not legal advice: confirm how each rule applies to your business with your counsel and your supervisor.

What AMLR requires at a glance

Obligation	Article	Where it lives in Didit
Know when due diligence is triggered	Art. 19	Your own routing logic, then a session per trigger. See When due diligence applies
Identify the customer and verify their identity	Art. 20(1)(a), Art. 22	ID Verification with digital ID wallets or document capture. See Identify and verify people
Identify beneficial owners and understand the ownership structure	Art. 20(1)(b), Arts. 51 to 53	Business Verification workflow. See Verify businesses and beneficial owners
Check sanctions and politically exposed persons	Art. 20(1)(d) and (g), Art. 42	AML Screening. See Screen for sanctions and PEPs
Monitor the relationship and keep customer data current	Art. 26	Ongoing AML monitoring and document expiry. See Monitor on an ongoing basis and refresh
Understand the purpose of the relationship and, where necessary, the source of funds	Art. 25	Questionnaires. See Purpose and source of funds
Monitor transactions and report suspicions	Art. 26(1), Art. 69	Transaction Monitoring and case management. See Monitor transactions and report
Keep records for 5 years, then delete personal data	Art. 77	Retention setting, exports and on-demand deletion. See Keep records, then delete
Put a human in automated decisions	Art. 76(5)	Manual review and status updates. See Human review of automated decisions
Govern what you outsource	Art. 18	Your outsourcing register. See Outsourcing

End-to-end flow

Your backend creates a session, the user completes the workflow, Didit notifies you, and you retrieve the full decision. The onboarding decision stays with your team. Monitoring continues after onboarding.

When due diligence applies

Article 19 says when you must apply customer due diligence: when you establish a business relationship; for an occasional transaction of at least EUR 10,000, in one operation or in linked transactions; when there is a suspicion of money laundering or terrorist financing, whatever the amount; and when you doubt identification data you already hold. Lower triggers apply in some sectors: EUR 1,000 for occasional transfers of funds and for CASPs, EUR 3,000 for occasional cash transactions (at least identification and verification), and EUR 2,000 in gambling. A CASP must at least identify and verify the customer for an occasional transaction below EUR 1,000. Didit does not decide whether a trigger applies. You route by transaction type and amount in your own code, then start the workflow that matches.

Requirement	Didit feature	Endpoint or setting
Start due diligence for a new business relationship (Art. 19(1)(a))	Verification session on your onboarding workflow	`POST /v3/session/`
Start due diligence when an occasional transaction crosses your threshold (Art. 19(1)(b), 19(2) to 19(5))	Verification session on the workflow you choose for that trigger	`POST /v3/session/` with the matching `workflow_id`
Detect linked transactions that cross a threshold together	Velocity rules in Transaction Monitoring	`POST /v3/transactions/`, rules
Ask the customer for verification before a flagged transaction settles	A rule action moves the transaction to `AWAITING_USER` and a linked verification session is created	Transaction statuses

A minimal routing sketch for your backend. It does not cover every trigger in Article 19 (for example, taking part in the creation of a legal entity), and the sector rules that apply to you may differ:

# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}

Identify and verify people

Article 22(1) lists the data you must hold on a natural person: all names and surnames, place and full date of birth, nationalities, the national identification number where applicable, the usual place of residence and, where available, the tax identification number. Article 22(6) then names two means of verifying identity: an identity document, passport or equivalent, or electronic identification (eID) that meets the eIDAS assurance levels “substantial” or “high”, together with relevant qualified trust services.

Data points against the decision

The decision returned by GET /v3/session/{sessionId}/decision/ carries one entry per identity check in id_verifications[].

Article 22(1)(a) data point	Field in `id_verifications[]`	Notes
All names and surnames	`first_name`, `last_name`, `full_name`	As they appear on the document or as the wallet returns them
Place and full date of birth	`place_of_birth`, `date_of_birth`	Place of birth is present when the document carries it
Nationalities	`nationality`	Record additional nationalities the customer declares in your own system
National identification number, where applicable	`personal_number`	What this field holds depends on the document. See the ID Verification report
Usual place of residence	`address`, `formatted_address`, `parsed_address`	Passports rarely carry an address. Add Proof of Address or a database validation when the document does not
Tax identification number, where available	`extra_fields.tax_number`	Only when the document carries it. Otherwise collect it with a questionnaire

The two routes

Requirement	Didit feature	Endpoint or setting
Verify with electronic identification (Art. 22(6)(b))	Digital ID wallets. Available in production: MitID (Denmark), BankID Sweden, Finnish Trust Network (Finland), Smart-ID (Estonia, Latvia, Lithuania, Belgium) and Mobile-ID (Estonia, Lithuania). European Digital Identity (EUDI) Wallet: Coming soon	Configure the methods per country in the ID Verification step. The result reports `verification_method` and `wallet_provider`
Verify with an identity document (Art. 22(6)(a))	Document capture with authenticity checks, and NFC chip reading for e-passports and e-IDs. For remote use, read the draft standards below	ID Verification and NFC steps in the workflow
Check that the person presenting the document is its holder	Liveness and Face Match against the document portrait	Liveness and Face Match steps. Results in `liveness_checks[]` and `face_matches[]`
Keep evidence you can review later	Session record with images, extracted data and timestamps	`GET /v3/session/{sessionId}/generate-pdf/`, exports

The assurance level each wallet reports is listed on the Digital ID wallets page. Whether a given scheme meets Article 22(6)(b) for your use is your assessment to make. Didit is the integration that lets your customer use the wallet; it is not itself a qualified trust service provider or an eID scheme.

What the draft technical standards say about remote verification

The regulatory technical standards (RTS) on customer due diligence under Article 28(1) are written by the Anti-Money Laundering Authority (AMLA). AMLA’s final report is dated 30 September 2026 and was announced on 1 October 2026. It is a final draft submitted to the European Commission. It is not adopted and it is not law. The Commission may still change it, and the draft proposes to apply six months after it enters into force. That draft treats the two means in Article 22(6) as the default. Remote verification with a document is an alternative solution for when the person cannot reasonably be expected to present the document face to face and does not have access to qualifying eID (draft Article 7(1)). If you use the alternative, the draft asks you to be able to justify why, and to show your supervisor that the solution has safeguards (draft Article 7(2) and 7(3)). The draft is technology neutral: it names no technique. How the draft safeguards line up with what a Didit session records:

Safeguard in the draft (Article 7(2))	What you can use in Didit
Controls that the person presenting the document is the document holder	Liveness and Face Match results on the session
Images, video and data of sufficient quality to identify the person	Capture quality checks during the flow, with warnings on the report
Stop when there are doubts about the identity or the integrity of the process	Warnings and a session status of `"Declined"` or `"In Review"`
Copies kept, time-stamped and available for later verification	Session record, PDF report and your retention setting

The reason a customer went through the document route instead of eID is yours to record. Store it in your own system or attach it to the session with metadata when you create it.

Verify businesses and beneficial owners

For a legal entity, Article 22(1)(b) asks for the legal form and name, the registered office address, the legal representatives and, where available, the registration number, tax identification number and Legal Entity Identifier. You must also identify the beneficial owners and take reasonable measures to verify them, so that you understand the ownership and control structure (Article 20(1)(b)). A beneficial owner is a natural person with direct or indirect ownership of “25 % or more” of the shares, voting rights or other ownership interest (Article 52(1)), or who controls the entity through ownership or other means (Articles 51 and 53). Control is assessed in parallel to ownership.

Requirement	Didit feature	Endpoint or setting
Identify the legal entity and check it against a register	Business Verification (know your business, KYB) with a company registry lookup at the Lite, Shareholders or UBOs tier. Tier availability varies by country	`POST /v3/session/` with a KYB `workflow_id`. See supported countries
Identify ultimate beneficial owners (UBOs) at 25 % or more	Ownership from the registry where available, confirmed and extended by the company representative	UBO threshold in Workflows, on the KYB workflow. Results in `key_people_checks[]`
Verify the identity of owners, directors and representatives	Linked identity checks: each key person gets a child verification session on the workflow you choose per role	Per-role settings under Key People in the KYB workflow
Compare what the register holds with what the customer declares (Art. 22(7), Art. 24)	Registry and submitted parties shown side by side	`key_people_checks[].registry` and `key_people_checks[].submitted` in the decision
Screen the company, its owners and its controllers	Company and person AML screening	AML step in the KYB workflow

Four points to design around:

The threshold is yours to set. The AMLR figure is “25 % or more”, not “more than 25 %”. The UBO threshold on the workflow is configurable, so set it to match and review it if your policy is stricter.
A register is not enough by itself. Article 22(7) requires you to consult the central registers in addition to verifying the beneficial owners. Reporting a discrepancy to the register within 14 calendar days (Article 24) is your step.
An empty registry result is not proof that a company has no owners. A register may hold no ownership record for a company or a country. If you identify no beneficial owner, Article 22(2) asks you to record that and to identify and verify the senior managing officials instead.
Registry monitoring is Coming soon. Continuous monitoring of registry changes is not available yet. Until it is, re-run the Business Verification on your refresh schedule.

Screen for sanctions and PEPs

You must verify whether the customer or its beneficial owners are subject to targeted financial sanctions, and whether sanctioned persons control a legal-entity customer or hold more than 50 % of it (Article 20(1)(d)). In AMLR, targeted financial sanctions means EU sanctions. You must also determine whether the customer or a beneficial owner is a politically exposed person (PEP), a family member or a close associate (Article 20(1)(g)). For PEPs, Article 42 adds senior management approval, measures to establish source of wealth and source of funds, and enhanced ongoing monitoring.

Requirement	Didit feature	Endpoint or setting
Screen at onboarding	AML Screening step in the workflow, against sanctions, PEP and watchlists	AML step and its thresholds in the workflow. Results in `aml_screenings[]`
Screen without a hosted flow	Standalone screening of a person or a company	`POST /v3/aml/`
Know which lists are covered	Watchlist database, which includes the EU consolidated list of financial sanctions	Reference page
Record a decision on each hit	Hit review with a `review_status` per hit	`PATCH /v3/session/{sessionId}/update-aml-hit-status/`
Send PEP and sanctions matches to a person	Thresholds that move the session to `"In Review"`	AML thresholds in the workflow, then manual review

curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'

Recording a hit as Confirmed Match or False Positive fires a data.updated webhook and does not change the session decision by itself. Senior management approval for a PEP relationship is your process: route the session to review and record who approved it.

Monitor on an ongoing basis and refresh

Article 26 requires ongoing monitoring of the business relationship and up-to-date customer information. The period between updates must not exceed 1 year for higher-risk customers and 5 years for all other customers (Article 26(2)), and you must also update when the customer’s circumstances change or you learn a relevant fact (Article 26(3)). Sanctions checks must be repeated regularly, and for credit and financial institutions on any new designation (Article 26(4)).

Requirement	Didit feature	Endpoint or setting
Re-screen customers against sanctions and PEP lists	Ongoing AML monitoring with daily re-screening	Enable it on the AML step, or per profile with `POST /v3/users/aml-monitoring/`
Re-screen companies	Ongoing AML monitoring for business profiles	`POST /v3/businesses/aml-monitoring/`
Be told when a re-screen changes the result	Webhooks on the session	`status.updated` when the status moves, for example to `"In Review"`, and `data.updated`. The payload carries `trigger: "ongoing_monitoring"`
Prove that monitoring ran when nothing changed	Last screening date and screening history	`last_ongoing_screening_at` on the AML report, and the screening history export
Catch expired identity documents	Document monitoring	The session moves from `"Approved"` to `"Kyc Expired"` and a `status.updated` webhook fires

curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'

Toggling monitoring emits no webhook of its own. Once monitoring is on, re-screens fire the usual status.updated and data.updated events.

Schedule the 1-year and 5-year refresh in your own system

The refresh clock depends on the risk class you assign, and that decision cannot be outsourced. Didit does not hold your risk class and does not schedule the periodic refresh for you.

Store the risk class and the last update date

Keep them on your customer record, next to the vendor_data you send to Didit.

Run a scheduled job

Select customers whose last update is older than your interval: at most 1 year for higher risk, at most 5 years for the rest. These are maximum periods, so a shorter interval is your choice.

Create a new session

Call POST /v3/session/ with the same vendor_data and your refresh workflow, then send the customer the url.

React to events as well

Treat "Kyc Expired", a monitoring webhook that moves a session to "In Review", and a change the customer reports as triggers for an earlier update.

Purpose and source of funds

Before you enter a business relationship or carry out an occasional transaction, Article 25 asks you to understand its purpose and intended nature. Where necessary, you obtain information on the purpose and economic rationale, the estimated amount of activity, the source of funds, the destination of funds, and the customer’s business activity or occupation. “Where necessary” means the extent is risk-based. Enhanced due diligence can add source of wealth (Article 34(4)).

Requirement	Didit feature	Endpoint or setting
Collect purpose and expected activity	Questionnaires with the Purpose of Account template	Questionnaire step in the workflow
Collect source of funds with supporting documents	Source of Funds template with file upload	Questionnaire step in the workflow
Collect occupation and employer	Employment Details template	Questionnaire step in the workflow
Have a person read every answer	Questionnaire set to always result in `"In Review"`	Manual review setting on the questionnaire

Templates are a starting point. Edit the questions to match your risk assessment, and keep the answers with the session so they sit in the same record as the identity check.

Monitor transactions and report

Ongoing monitoring covers the transactions carried out during the relationship, so that they stay consistent with what you know about the customer (Article 26(1)). When you know, suspect or have reasonable grounds to suspect that funds are the proceeds of criminal activity or related to terrorist financing, you report to your Financial Intelligence Unit (FIU) under Article 69.

Requirement	Didit feature	Endpoint or setting
Submit each transaction for evaluation	Transaction Monitoring for fiat and crypto	`POST /v3/transactions/`
Apply detection criteria you approved	Preset rule bundles and custom rules, each with a mode you control	Rules in the console or the rules API
Be told the verdict	Webhooks	`transaction.created` and `transaction.status.updated`
Investigate	Alerts and cases with a timeline of every action	Case management in the console
Prepare the report	FIU report preparation from case data	FIU reports tab on a case

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'

Two limits to keep in mind:

You approve the detection criteria. Approving the criteria for detecting suspicious or unusual transactions cannot be outsourced (Article 18(3)(f)). Review each rule you install and record that approval in your own policies.
You file the report. Didit prepares the report files from the case. It does not submit anything to an FIU. Filing is done by your compliance officer through your FIU’s channel.

Keep records, then delete

Article 77 is your record-keeping duty. You keep the documents and information obtained for customer due diligence, the records of your suspicion assessments and the transaction records for 5 years. The period starts when the business relationship ends, when the occasional transaction is carried out, or when you refuse to enter the relationship (Article 77(3)). When the 5 years expire, you delete the personal data, unless another law applies or an authority asks you to keep specific records longer. The clock starts from an event in your system: the end of the relationship. Didit does not know that date, so the retention you configure and the deletions you request are your decisions.

Requirement	Didit feature	Endpoint or setting
Keep session records for as long as your duty runs	Retention setting: a window from 1 month to 10 years, or unlimited	Business Console → App Settings → Data
Delete when your 5-year period ends	On-demand deletion of a session	`DELETE /v3/session/{sessionId}/delete/`
Hand a file to a supervisor or an auditor	PDF report per session and per user, CSV export in bulk	`GET /v3/session/{sessionId}/generate-pdf/`, exports
Keep the screening evidence	Screening history export per session	Ongoing monitoring evidence

Pick a retention window that cannot end early

A session reaches the end of the window and is deleted. Choose a window that covers the length of your customer relationships plus 5 years, or leave it unlimited and delete on demand.

Record the end of the relationship

Store the termination, transaction or refusal date in your own system. That date starts your 5 years.

Delete when the period expires

Call DELETE /v3/session/{sessionId}/delete/ for each session of that customer. Deletion is irreversible and media URLs stop resolving.

Audit logs and screening history do not cover the 5-year duty by themselves. Audit logs are available for 365 days, and screening history runs are available for two years by default. If your records policy relies on them, export them into your own records before those periods end. The session records under your retention setting are what map to Article 77.

Human review of automated decisions

Article 76(5) lets you adopt decisions that result from automated processes, including profiling and AI systems, on three conditions. The data is limited to due diligence data. Any decision to enter, refuse or maintain a business relationship, to carry out or refuse an occasional transaction, or to change the extent of due diligence is subject to meaningful human intervention. And the customer can obtain an explanation of the decision and challenge it.

Requirement	Didit feature	Endpoint or setting
Send cases to a person	Workflow thresholds and branches that end in `"In Review"`	Workflows
Review the evidence and decide	Manual review with a decline reason and review notes	Console, or `PATCH /v3/session/{sessionId}/update-status/`
Require a second reviewer	Four-eyes review on a case blueprint: a different officer approves or rejects the resolution	Case management in the console
Explain the outcome	Per-check results, warnings and reviewer comments on the session	`GET /v3/session/{sessionId}/decision/`

curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'

A session status of "Approved" or "Declined" is the result of the checks you configured. It is an input to your decision to onboard, which Article 18(3) keeps with you. Decide with your counsel where a person has to intervene, then build that step into the workflow and into your own back office.

Outsourcing

Article 18 lets you outsource tasks that result from AMLR to a service provider. It sets conditions: you notify your supervisor before the provider starts (Article 18(1)), you remain fully liable for the outsourced tasks (Article 18(2)), and you lay down the conditions in a written agreement and run regular controls on the provider (Article 18(4)). The regulation also says that using third-party software, or accessing databases or screening services, where you perform the requirement yourself, is not outsourcing (recital 47). Which side your use of Didit falls on depends on how you use it. AMLA guidelines on outsourcing are due by 10 July 2027. Six tasks cannot be outsourced under any circumstances (Article 18(3)). They stay with you:

The proposal and approval of your business-wide risk assessment.
The approval of your internal policies, procedures and controls.
The decision on the risk profile to attribute to the customer.
The decision to enter into a business relationship or carry out an occasional transaction.
Reporting suspicious activity and threshold-based reports to the FIU.
The approval of the criteria for detecting suspicious or unusual transactions and activities.

The tasks around them can be delegated: collecting identity data, running the document or eID verification, gathering beneficial ownership data and registry lookups, screening against sanctions and PEP lists, running transaction monitoring against criteria you approved, and preparing alerts and evidence. What to put in your outsourcing register about Didit:

Item	What to record	Where to find it
Written agreement (Art. 18(4))	Your contract with Didit and the data processing agreement	Ask your Didit representative for the DPA and the technical and organisational measures
Tasks delegated	The checks in each workflow you run, by workflow version	Workflows. Sessions and webhooks carry `workflow_id` and `workflow_version`
Tasks you keep	The six tasks above, with the owner in your organisation	Your own policies
Provider qualification (Art. 18(4))	Certifications and attestations	Certifications
Data location	Data is processed and stored in the EU by default. In-country processing is available on Enterprise	Data retention
Regular controls (Art. 18(4))	Your sampling of sessions, exports and review trails, at a frequency that matches how critical the task is	Exports, audit logs
Supervisor notification (Art. 18(1))	The date you notified your supervisor, before go-live	Your step. Notification does not imply that the supervisor accepts the arrangement

Reference workflow

A starting point for an onboarding workflow for natural persons. Adapt it to your risk assessment.

Create the workflow

In the Business Console, open Workflows and create a know your customer (KYC) workflow. Use the visual builder if you need branches by country or by result.

Choose the identity methods per country

In the ID Verification step, enable the digital ID wallets available for the countries you serve, and document capture as the route for everyone else. See ID Verification methods.

Bind the document to the person

For the document route, add Liveness and Face Match, and NFC where the document has a chip.

Cover the address

Add Proof of Address for customers whose document does not carry one.

Screen and monitor

Add AML Screening, set the thresholds that send a match to review, and turn on ongoing monitoring.

Ask for purpose and source of funds

Add a Questionnaire from the Purpose of Account and Source of Funds templates.

Subscribe to webhooks

Create a webhook destination subscribed to status.updated and data.updated. See Webhooks.

Publish and copy the workflow ID

Publish the workflow and use its workflow_id when you create sessions.

Create a session:

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'

Response (201 Created):

{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}

Redirect the customer to url. When the session reaches a decision, Didit sends a status.updated webhook. An excerpt:

{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}

Verify the signature, key your idempotency on event_id, and match status as an exact, case-sensitive string. The values are listed in Verification statuses. Then read the full decision with GET /v3/session/{sessionId}/decision/ and hand it to the person or the process that makes your onboarding decision.

Timeline

Date	What happens
19 June 2024	AMLR, Regulation (EU) 2024/1624, is published in the Official Journal
9 July 2024	AMLR enters into force
30 September 2026	AMLA dates its final report on the draft customer due diligence standards (announced 1 October 2026). Submitted to the Commission, not adopted
10 July 2027	AMLR applies. Deadline for Member States to transpose the sixth Anti-Money Laundering Directive, Directive (EU) 2024/1640. AMLA guidelines on outsourcing are due
2028	AMLA starts direct supervision of selected financial entities. The first round is capped at 40
10 July 2029	AMLR applies to football agents and professional football clubs

FAQ

When does AMLR apply?

AMLR entered into force on 9 July 2024 and will apply from 10 July 2027. For football agents and professional football clubs it will apply from 10 July 2029. Until 10 July 2027, the national laws that transpose the current directive apply.

What is the difference between AMLR, AMLD6 and AMLA?

AMLR is Regulation (EU) 2024/1624. It holds the rules for obliged entities and applies directly, with no national transposition. AMLD6 is Directive (EU) 2024/1640. It is addressed to Member States and covers supervisors, registers and penalties, with transposition due by 10 July 2027. AMLA is the Anti-Money Laundering Authority, created by Regulation (EU) 2024/1620 and based in Frankfurt. It drafts the technical standards and guidelines and will directly supervise a selected group of financial entities from 2028.

Is remote verification with an identity document still allowed?

Yes, with conditions. Article 22(6) names two means: an identity document, or eID at assurance level substantial or high. AMLA’s final draft standards of 30 September 2026 keep remote verification with a document as an alternative for when the person cannot reasonably be expected to present the document face to face and has no access to qualifying eID. You must be able to justify using it and show the safeguards. The draft names no technique, and it is not yet law.

Are the technical standards final?

No. AMLA finalised its draft on 30 September 2026 and sent it to the European Commission. It becomes binding only when the Commission adopts it and it is published in the Official Journal, and the Commission may amend it. The draft proposes to apply six months after it enters into force, so there is no calendar date yet.

Do I have to accept the EUDI Wallet, and does Didit support it?

AMLR itself lists eID as one of two means of verification. It does not order every obliged entity to accept the EUDI Wallet. The acceptance duty sits in the eIDAS regulation: private relying parties that must use strong user authentication for online identification accept the wallet at the user’s request, no later than 36 months after the implementing acts entered into force, and micro and small enterprises are exempt. Whether that covers your onboarding is a question for your counsel. In Didit, the EUDI Wallet is Coming soon. The wallets available in production today are MitID, BankID Sweden, Finnish Trust Network, Smart-ID and Mobile-ID.

Is the beneficial ownership threshold 25% or 15%?

It is “25 % or more” of the shares, voting rights or other ownership interest (Article 52(1)), with control assessed in parallel. Article 52(2) allows the Commission to set a lower threshold, at a maximum of 15 %, for higher-risk categories of entities by delegated act. No such act exists. In Didit, the UBO threshold is a setting on your KYB workflow.

How do I implement the 1-year and 5-year refresh?

Store the customer’s risk class and last update date in your own system, run a scheduled job that selects customers past your interval, and create a new session with POST /v3/session/ and the same vendor_data. Add event triggers: a "Kyc Expired" status, a monitoring webhook, or a change the customer reports. The 1-year and 5-year figures in Article 26(2) are maximum periods.

What can I outsource?

Tasks such as collecting identity data, running the verification, registry lookups, screening and running transaction monitoring against criteria you approved. Six tasks cannot be outsourced: approving the business-wide risk assessment, approving internal policies, deciding the customer’s risk profile, deciding to onboard, reporting to the FIU, and approving detection criteria. You remain fully liable for what you outsource (Article 18(2)).

How do I set retention for the 5-year rule?

The 5 years start when the relationship ends, not when the customer was verified. In Business Console → App Settings → Data, choose a window long enough to cover the relationship plus 5 years, or leave it unlimited. Track the end date in your own system and call DELETE /v3/session/{sessionId}/delete/ when your period expires. Export audit logs and screening history if your records policy relies on them.

Does using Didit make me compliant with AMLR?

No. Compliance is a property of your programme: your risk assessment, your policies, your decisions and your controls. Didit gives you the checks, the monitoring and the evidence that those parts of the programme run on. There is no AMLR certification or approval for vendors or tools.

AMLR solution overview

The business view: who AMLR binds and where Didit fits.

ID Verification methods

Document capture, non-document lookup and digital ID wallets.

Digital ID wallets

Availability and assurance level per wallet.

Business Verification

Registry lookups, ownership and key people.

AML Screening

Sanctions, PEP and watchlist screening with ongoing monitoring.

Transaction Monitoring

Rules, alerts, cases and FIU report preparation.

Questionnaires

Templates for purpose of the relationship and source of funds.

Data retention

Retention windows and on-demand deletion.

Webhooks

Event types, payloads and signature verification.

Pricing

Pay per check. See the current price of each feature.

Overview

Pricing

Workflows & Verification

Review & Operations

Entities (Users & Businesses)

Settings & Customization

Security & Compliance

Didit Academy

Resources

What AMLR requires at a glance

End-to-end flow

When due diligence applies

Identify and verify people

Data points against the decision

The two routes

What the draft technical standards say about remote verification

Verify businesses and beneficial owners

Screen for sanctions and PEPs

Monitor on an ongoing basis and refresh

Schedule the 1-year and 5-year refresh in your own system

Purpose and source of funds

Monitor transactions and report

Keep records, then delete

Human review of automated decisions

Outsourcing

Reference workflow

Timeline

FAQ

AMLR solution overview

ID Verification methods

Digital ID wallets

Business Verification

AML Screening

Transaction Monitoring

Questionnaires

Data retention

Webhooks

Pricing

​What AMLR requires at a glance

​End-to-end flow

​When due diligence applies

​Identify and verify people

​Data points against the decision

​The two routes

​What the draft technical standards say about remote verification

​Verify businesses and beneficial owners

​Screen for sanctions and PEPs

​Monitor on an ongoing basis and refresh

​Schedule the 1-year and 5-year refresh in your own system

​Purpose and source of funds

​Monitor transactions and report

​Keep records, then delete

​Human review of automated decisions

​Outsourcing

​Reference workflow

​Timeline

​FAQ

​Related resources

AMLR solution overview

ID Verification methods

Digital ID wallets

Business Verification

AML Screening

Transaction Monitoring

Questionnaires

Data retention

Webhooks

Pricing

What AMLR requires at a glance

End-to-end flow

When due diligence applies

Identify and verify people

Data points against the decision

The two routes

What the draft technical standards say about remote verification

Verify businesses and beneficial owners

Screen for sanctions and PEPs

Monitor on an ongoing basis and refresh

Schedule the 1-year and 5-year refresh in your own system

Purpose and source of funds

Monitor transactions and report

Keep records, then delete

Human review of automated decisions

Outsourcing

Reference workflow

Timeline

FAQ

Related resources