> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# AMLR compliance guide

> Map each requirement of the EU Anti-Money Laundering Regulation (AMLR) to the Didit workflows, API endpoints and webhooks that implement it.

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](https://didit.me/solutions/amlr).

Last reviewed: 2 October 2026.

<Warning>
  **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.
</Warning>

## 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](#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-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](#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](#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](#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](#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](#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](#keep-records-then-delete) |
| Put a human in automated decisions | Art. 76(5) | Manual review and status updates. See [Human review of automated decisions](#human-review-of-automated-decisions) |
| Govern what you outsource | Art. 18 | Your outsourcing register. See [Outsourcing](#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.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User as Your customer
    participant You as Your backend
    participant Didit as Didit API
    participant Team as Your compliance team

    You->>Didit: POST /v3/session/ (workflow_id, vendor_data)
    Didit-->>You: session_id and url
    You->>User: Redirect to url
    User->>Didit: Completes the workflow
    Didit--)You: status.updated webhook
    You->>Didit: GET /v3/session/{sessionId}/decision/
    Didit-->>You: Decision with the result of every check
    You->>Team: Queue the case for a decision
    Note over You,Team: Risk profile and onboarding decision are yours (Article 18)
    Team->>Didit: PATCH /v3/session/{sessionId}/update-status/
    You->>Didit: POST /v3/users/aml-monitoring/
    Didit--)You: status.updated and data.updated on each change
```

## 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/`](/sessions-api/create-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/`](/sessions-api/create-session) with the matching `workflow_id` |
| Detect linked transactions that cross a threshold together | Velocity rules in Transaction Monitoring | [`POST /v3/transactions/`](/transaction-monitoring/transactions), [rules](/transaction-monitoring/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](/transaction-monitoring/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:

```python theme={null}
# 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/`](/sessions-api/retrieve-session) 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](/core-technology/id-verification/report-id-verification) |
| Usual place of residence | `address`, `formatted_address`, `parsed_address` | Passports rarely carry an address. Add [Proof of Address](/core-technology/proof-of-address/overview) or a [database validation](/core-technology/database-validation/overview) 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](/core-technology/questionnaires/overview) |

### The two routes

| Requirement | Didit feature | Endpoint or setting |
| - | - | - |
| Verify with electronic identification (Art. 22(6)(b)) | [Digital ID wallets](/core-technology/id-verification/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](/console/id-verification-methods). The result reports `verification_method` and `wallet_provider` |
| Verify with an identity document (Art. 22(6)(a)) | [Document capture](/core-technology/id-verification/overview) with authenticity checks, and [NFC chip reading](/core-technology/nfc-verification/overview) 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](/core-technology/liveness/overview) and [Face Match](/core-technology/face-match/overview) 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/`](/sessions-api/generate-pdf), [exports](/console/export-pdf-csv) |

The assurance level each wallet reports is listed on the [Digital ID wallets](/core-technology/id-verification/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](#keep-records-then-delete) |

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](/business-verification/overview) (know your business, KYB) with a company registry lookup at the Lite, Shareholders or UBOs tier. Tier availability varies by country | [`POST /v3/session/`](/sessions-api/create-session) with a KYB `workflow_id`. See [supported countries](/business-verification/supported-countries) |
| Identify ultimate beneficial owners (UBOs) at 25 % or more | [Ownership](/business-verification/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](/business-verification/key-people) 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](/business-verification/aml) | 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](/core-technology/aml-screening/overview) 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/`](/standalone-apis/aml-screening) |
| Know which lists are covered | [Watchlist database](/core-technology/aml-screening/watchlist-database-aml-screening), 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/`](/sessions-api/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](/console/manual-review) |

```bash theme={null}
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](/core-technology/aml-screening/continuous-monitoring-aml-screening) with daily re-screening | Enable it on the AML step, or per profile with [`POST /v3/users/aml-monitoring/`](/management-api/aml-monitoring/toggle-users) |
| Re-screen companies | Ongoing AML monitoring for business profiles | [`POST /v3/businesses/aml-monitoring/`](/management-api/aml-monitoring/toggle-businesses) |
| 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](/core-technology/id-verification/document-monitoring-id-verification) | The session moves from `"Approved"` to `"Kyc Expired"` and a `status.updated` webhook fires |

```bash theme={null}
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.

<Steps>
  <Step title="Store the risk class and the last update date">
    Keep them on your customer record, next to the `vendor_data` you send to Didit.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Create a new session">
    Call [`POST /v3/session/`](/sessions-api/create-session) with the same `vendor_data` and your refresh workflow, then send the customer the `url`.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/core-technology/questionnaires/overview) 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](/transaction-monitoring/overview) for fiat and crypto | [`POST /v3/transactions/`](/transaction-monitoring/transactions) |
| Apply detection criteria you approved | Preset rule bundles and custom [rules](/transaction-monitoring/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](/transaction-monitoring/alerts) and [cases](/transaction-monitoring/cases) with a timeline of every action | Case management in the console |
| Prepare the report | [FIU report preparation](/console/case-management/fiu-reports) from case data | **FIU reports** tab on a case |

```bash theme={null}
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](/console/data-retention): 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/`](/sessions-api/delete-session) |
| 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/`](/sessions-api/generate-pdf), [exports](/console/export-pdf-csv) |
| Keep the screening evidence | Screening history export per session | [Ongoing monitoring evidence](/core-technology/aml-screening/continuous-monitoring-aml-screening#proving-that-monitoring-ran) |

<Steps>
  <Step title="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.
  </Step>

  <Step title="Record the end of the relationship">
    Store the termination, transaction or refusal date in your own system. That date starts your 5 years.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  **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.
</Warning>

## 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](/console/workflows) |
| Review the evidence and decide | [Manual review](/console/manual-review) with a decline reason and review notes | Console, or [`PATCH /v3/session/{sessionId}/update-status/`](/sessions-api/update-status) |
| Require a second reviewer | [Four-eyes review](/console/case-management/four-eyes) 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/`](/sessions-api/retrieve-session) |

```bash theme={null}
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:

1. The proposal and approval of your business-wide risk assessment.
2. The approval of your internal policies, procedures and controls.
3. The decision on the risk profile to attribute to the customer.
4. The decision to enter into a business relationship or carry out an occasional transaction.
5. Reporting suspicious activity and threshold-based reports to the FIU.
6. 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](/console/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](/getting-started/certifications) |
| Data location | Data is processed and stored in the EU by default. In-country processing is available on Enterprise | [Data retention](/console/data-retention#role-and-processing-location) |
| Regular controls (Art. 18(4)) | Your sampling of sessions, exports and review trails, at a frequency that matches how critical the task is | [Exports](/console/export-pdf-csv), [audit logs](/console/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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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](/console/id-verification-methods).
  </Step>

  <Step title="Bind the document to the person">
    For the document route, add **Liveness** and **Face Match**, and **NFC** where the document has a chip.
  </Step>

  <Step title="Cover the address">
    Add **Proof of Address** for customers whose document does not carry one.
  </Step>

  <Step title="Screen and monitor">
    Add **AML Screening**, set the thresholds that send a match to review, and turn on ongoing monitoring.
  </Step>

  <Step title="Ask for purpose and source of funds">
    Add a **Questionnaire** from the Purpose of Account and Source of Funds templates.
  </Step>

  <Step title="Subscribe to webhooks">
    Create a webhook destination subscribed to `status.updated` and `data.updated`. See [Webhooks](/integration/webhooks).
  </Step>

  <Step title="Publish and copy the workflow ID">
    Publish the workflow and use its `workflow_id` when you create sessions.
  </Step>
</Steps>

Create a session:

```bash theme={null}
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`):

```json theme={null}
{
  "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:

```json theme={null}
{
  "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](/integration/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

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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)).
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Related resources

<CardGroup cols={2}>
  <Card title="AMLR solution overview" icon="scale-balanced" href="https://didit.me/solutions/amlr">
    The business view: who AMLR binds and where Didit fits.
  </Card>

  <Card title="ID Verification methods" icon="id-card" href="/core-technology/id-verification/verification-methods">
    Document capture, non-document lookup and digital ID wallets.
  </Card>

  <Card title="Digital ID wallets" icon="wallet" href="/core-technology/id-verification/digital-id-wallets">
    Availability and assurance level per wallet.
  </Card>

  <Card title="Business Verification" icon="building" href="/business-verification/overview">
    Registry lookups, ownership and key people.
  </Card>

  <Card title="AML Screening" icon="shield-check" href="/core-technology/aml-screening/overview">
    Sanctions, PEP and watchlist screening with ongoing monitoring.
  </Card>

  <Card title="Transaction Monitoring" icon="magnifying-glass-chart" href="/transaction-monitoring/overview">
    Rules, alerts, cases and FIU report preparation.
  </Card>

  <Card title="Questionnaires" icon="clipboard-list" href="/core-technology/questionnaires/overview">
    Templates for purpose of the relationship and source of funds.
  </Card>

  <Card title="Data retention" icon="clock" href="/console/data-retention">
    Retention windows and on-demand deletion.
  </Card>

  <Card title="Webhooks" icon="webhook" href="/integration/webhooks">
    Event types, payloads and signature verification.
  </Card>

  <Card title="Pricing" icon="tag" href="/getting-started/pricing">
    Pay per check. See the current price of each feature.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.