> ## 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-Leitfaden: EU-Verordnung 2024/1624 APIs

> Erfüllen Sie die EU-Geldwäscheverordnung (AMLR) mit Didit: Workflows, API-Endpoints und Webhooks für jede regulatorische Anforderung.

Die EU-Geldwäscheverordnung (AMLR), Verordnung (EU) 2024/1624, fasst die Vorschriften zur Erfüllung der Sorgfaltspflichten gegenüber Kunden (CDD) in einem unmittelbar geltenden Rechtsakt zusammen. Sie verpflichtet Kredit- und Finanzinstitute einschließlich Anbieter von Krypto-Dienstleistungen (CASPs), Anbieter von Glücksspieldiensten sowie die weiteren in Artikel 3 genannten Verpflichteten. Sie trat am 9. Juli 2024 in Kraft und gilt ab dem 10. Juli 2027. Bis dahin gelten die nationalen Gesetze zur Umsetzung der aktuellen Richtlinie fort.

Diese Seite richtet sich an Entwickler und Compliance-Ingenieure, die die Anforderungen technisch umsetzen müssen. Jeder Abschnitt erläutert die Vorgaben der Verordnung, nennt den jeweiligen Artikel und zeigt den Workflow-Schritt, den API-Endpoint oder den Webhook von Didit, den Sie für diesen Teil nutzen können. Einen geschäftlichen Überblick finden Sie auf der [AMLR-Lösungsseite](https://didit.me/solutions/amlr).

Zuletzt überprüft: 2. Oktober 2026.

> [!WARNING]
>
> **Didit stellt die Prüfungen und die Nachweise bereit. Sie bleiben der Verpflichtete.** Sie legen das Risikoprofil des Kunden fest, Sie entscheiden über das Onboarding und Sie haften vollumfänglich für jede ausgelagerte Aufgabe (Artikel 18). Die Nutzung von Didit führt allein nicht dazu, dass Ihr Unternehmen die AMLR einhält. Diese Seite stellt keine Rechtsberatung dar: Stimmen Sie die Anwendung der einzelnen Bestimmungen auf Ihr Unternehmen mit Ihrem Rechtsbeistand und Ihrer Aufsichtsbehörde ab.

## Was die AMLR auf einen Blick verlangt

| Verpflichtung | Artikel | Entsprechung in Didit |
| - | - | - |
| Erkennen, wann Sorgfaltspflichten greifen | Art. 19 | Ihre eigene Routing-Logik, anschließend eine Sitzung pro Auslöser. Siehe [Wann die Sorgfaltspflichten gelten](#wann-die-sorgfaltspflichten-gelten) |
| Den Kunden identifizieren und seine Identität überprüfen | Art. 20 Abs. 1 Buchst. a, Art. 22 | Ausweisverifizierung mit digitalen ID-Wallets oder Dokumentenerfassung. Siehe [Personen identifizieren und verifizieren](#personen-identifizieren-und-verifizieren) |
| Wirtschaftlich Berechtigte ermitteln und die Eigentümerstruktur verstehen | Art. 20 Abs. 1 Buchst. b, Art. 51 bis 53 | Unternehmensverifizierungs-Workflow. Siehe [Unternehmen und wirtschaftlich Berechtigte verifizieren](#unternehmen-und-wirtschaftlich-berechtigte-verifizieren) |
| Sanktionen und politisch exponierte Personen prüfen | Art. 20 Abs. 1 Buchst. d und g, Art. 42 | AML-Screening. Siehe [Auf Sanktionen und PEPs prüfen](#auf-sanktionen-und-peps-prüfen) |
| Die Geschäftsbeziehung überwachen und Kundendaten aktuell halten | Art. 26 | Laufende AML-Überwachung und Ablaufdaten von Dokumenten. Siehe [Laufend überwachen und aktualisieren](#laufend-überwachen-und-aktualisieren) |
| Den Zweck der Geschäftsbeziehung und bei Bedarf die Mittelherkunft verstehen | Art. 25 | Fragebögen. Siehe [Zweck und Mittelherkunft](#zweck-und-mittelherkunft) |
| Transaktionen überwachen und Verdachtsfälle melden | Art. 26 Abs. 1, Art. 69 | Transaktionsüberwachung und Fallmanagement. Siehe [Transaktionen überwachen und melden](#transaktionen-überwachen-und-melden) |
| Unterlagen 5 Jahre lang aufbewahren, danach personenbezogene Daten löschen | Art. 77 | Aufbewahrungseinstellung, Exporte und Löschung auf Anfrage. Siehe [Aufzeichnungen aufbewahren, danach löschen](#aufzeichnungen-aufbewahren-dann-löschen) |
| Eine menschliche Überprüfung bei automatisierten Entscheidungen vorsehen | Art. 76 Abs. 5 | Manuelle Prüfung und Statusaktualisierungen. Siehe [Menschliche Überprüfung automatisierter Entscheidungen](#menschliche-überprüfung-automatisierter-entscheidungen) |
| Ausgelagerte Aufgaben kontrollieren | Art. 18 | Ihr Auslagerungsregister. Siehe [Auslagerung](#auslagerung) |

## End-to-End-Ablauf

Ihr Backend erstellt eine Sitzung, der Benutzer schließt den Workflow ab, Didit benachrichtigt Sie und Sie rufen die vollständige Entscheidung ab. Die Onboarding-Entscheidung verbleibt bei Ihrem Team. Die Überwachung wird nach dem Onboarding fortgesetzt.

```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
```

## Wann die Sorgfaltspflichten gelten

Artikel 19 legt fest, wann Sie die Sorgfaltspflichten gegenüber Kunden anwenden müssen: bei der Begründung einer Geschäftsbeziehung; bei einer gelegentlichen Transaktion von mindestens 10.000 EUR, sei es in einem einzigen Vorgang oder in miteinander verknüpften Transaktionen; bei Verdacht auf Geldwäsche oder Terrorismusfinanzierung, unabhängig vom Betrag; und bei Zweifeln an bereits vorliegenden Identifikationsdaten. In bestimmten Sektoren gelten niedrigere Schwellenwerte: 1.000 EUR bei gelegentlichen Geldtransfers und für CASPs, 3.000 EUR bei gelegentlichen Bartransaktionen (mindestens Identifizierung und Verifizierung) und 2.000 EUR im Glücksspielsektor. Ein CASP muss den Kunden auch bei einer gelegentlichen Transaktion unter 1.000 EUR zumindest identifizieren und verifizieren.

Didit entscheidet nicht darüber, ob ein Auslöser vorliegt. Sie steuern das Routing nach Transaktionsart und -betrag in Ihrem eigenen Code und starten anschließend den passenden Workflow.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Sorgfaltspflichten für eine neue Geschäftsbeziehung einleiten (Art. 19 Abs. 1 Buchst. a) | Verifizierungssitzung in Ihrem Onboarding-Workflow | [`POST /v3/session/`](https://docs.didit.me/de/sessions-api/create-session) |
| Sorgfaltspflichten einleiten, wenn eine gelegentliche Transaktion Ihren Schwellenwert überschreitet (Art. 19 Abs. 1 Buchst. b, Art. 19 Abs. 2 bis 19 Abs. 5) | Verifizierungssitzung in dem Workflow, den Sie für diesen Auslöser wählen | [`POST /v3/session/`](https://docs.didit.me/de/sessions-api/create-session) mit der passenden `workflow_id` |
| Verknüpfte Transaktionen erkennen, die gemeinsam einen Schwellenwert überschreiten | Velocity-Regeln in der Transaktionsüberwachung | [`POST /v3/transactions/`](https://docs.didit.me/de/transaction-monitoring/transactions), [Regeln](https://docs.didit.me/de/transaction-monitoring/rules.md) |
| Den Kunden vor Abwicklung einer markierten Transaktion zur Verifizierung auffordern | Eine Regelaktion setzt die Transaktion auf `AWAITING_USER` und eine verknüpfte Verifizierungssitzung wird erstellt | [Transaktionsstatus](https://docs.didit.me/de/transaction-monitoring/statuses.md) |

Eine minimale Routing-Skizze für Ihr Backend. Sie deckt nicht jeden Auslöser in Artikel 19 ab (beispielsweise die Beteiligung an der Gründung einer juristischen Person), und die für Sie geltenden Branchenvorschriften können abweichen:

```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",
}
```

## Personen identifizieren und verifizieren

Artikel 22 Absatz 1 listet die Daten auf, die Sie über eine natürliche Person erfassen müssen: alle Vornamen und Nachnamen, Geburtsort und vollständiges Geburtsdatum, Staatsangehörigkeiten, die nationale Identifikationsnummer (sofern zutreffend), der gewöhnliche Wohnsitz und, sofern vorhanden, die Steuernummer. Artikel 22 Absatz 6 nennt anschließend zwei Mittel zur Identitätsüberprüfung: ein Ausweisdokument, einen Reisepass oder ein gleichwertiges Dokument oder eine elektronische Identifizierung (eID), die den eIDAS-Vertrauensniveaus „substanziell“ oder „hoch“ entspricht, zusammen mit entsprechenden qualifizierten Vertrauensdiensten.

### Datenpunkte im Vergleich zur Entscheidung

Die von [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/de/sessions-api/retrieve-session) zurückgegebene Entscheidung enthält einen Eintrag pro Identitätsprüfung in `id_verifications[]`.

| Artikel 22(1)(a)-Datenpunkt | Feld in `id_verifications[]` | Hinweise |
| - | - | - |
| Alle Vornamen und Nachnamen | `first_name`, `last_name`, `full_name` | Wie sie auf dem Dokument erscheinen oder wie die Wallet sie zurückgibt |
| Geburtsort und vollständiges Geburtsdatum | `place_of_birth`, `date_of_birth` | Der Geburtsort ist vorhanden, wenn das Dokument ihn enthält |
| Staatsangehörigkeiten | `nationality` | Erfassen Sie zusätzliche Staatsangehörigkeiten, die der Kunde angibt, in Ihrem eigenen System |
| Nationale Identifikationsnummer, sofern zutreffend | `personal_number` | Was dieses Feld enthält, hängt vom Dokument ab. Siehe den [Bericht zur Ausweisverifizierung](https://docs.didit.me/de/core-technology/id-verification/report-id-verification.md) |
| Gewöhnlicher Wohnsitz | `address`, `formatted_address`, `parsed_address` | Reisepässe enthalten selten eine Adresse. Fügen Sie einen [Adressnachweis](https://docs.didit.me/de/core-technology/proof-of-address/overview.md) oder eine [Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) hinzu, wenn das Dokument keine Adresse enthält |
| Steuernummer, sofern vorhanden | `extra_fields.tax_number` | Nur, wenn das Dokument sie enthält. Erfassen Sie sie andernfalls mit einem [Fragebogen](https://docs.didit.me/de/core-technology/questionnaires/overview.md) |

### Die zwei Wege

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Verifizierung mit elektronischer Identifizierung (Art. 22(6)(b)) | [Digitale ID-Wallets](https://docs.didit.me/de/core-technology/id-verification/digital-id-wallets.md). In Produktion verfügbar: MitID (Dänemark), BankID Schweden, Finnish Trust Network (Finnland), Smart-ID (Estland, Lettland, Litauen, Belgien) und Mobile-ID (Estland, Litauen). European Digital Identity (EUDI) Wallet: **Demnächst** | Konfigurieren Sie die Methoden pro Land im [Schritt zur Ausweisverifizierung](https://docs.didit.me/de/console/id-verification-methods.md). Das Ergebnis gibt `verification_method` und `wallet_provider` an |
| Verifizierung mit einem Ausweisdokument (Art. 22(6)(a)) | [Dokumentenerfassung](https://docs.didit.me/de/core-technology/id-verification/overview.md) mit Echtheitsprüfungen und [NFC-Chip-Auslesen](https://docs.didit.me/de/core-technology/nfc-verification/overview.md) für e-Reisepässe und e-Ausweise. Für die Remote-Nutzung lesen Sie die folgenden Normentwürfe | Schritte zur Ausweisverifizierung und NFC im Workflow |
| Überprüfen, ob die vorlegende Person der Dokumenteninhaber ist | [Liveness-Erkennung](https://docs.didit.me/de/core-technology/liveness/overview.md) und [Gesichtsabgleich](https://docs.didit.me/de/core-technology/face-match/overview.md) mit dem Porträtfoto des Dokuments | Schritte für Liveness-Erkennung und Gesichtsabgleich. Ergebnisse in `liveness_checks[]` und `face_matches[]` |
| Nachweise aufbewahren, die Sie später prüfen können | Sitzungsdatensatz mit Bildern, extrahierten Daten und Zeitstempeln | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/de/sessions-api/generate-pdf), [Exporte](https://docs.didit.me/de/console/export-pdf-csv.md) |

Das Vertrauensniveau, das jede Wallet meldet, ist auf der Seite [Digitale ID-Wallets](https://docs.didit.me/de/core-technology/id-verification/digital-id-wallets.md) aufgeführt. Ob ein bestimmtes Verfahren Artikel 22 Absatz 6 Buchstabe b für Ihren Anwendungsfall erfüllt, müssen Sie selbst beurteilen. Didit ist die Integration, über die Ihr Kunde die Wallet nutzen kann; es ist selbst weder ein qualifizierter Vertrauensdiensteanbieter noch ein eID-System.

### Was die technischen Regulierungsstandards im Entwurf zur Remote-Verifizierung sagen

Die technischen Regulierungsstandards (RTS) zur Sorgfaltspflicht gegenüber Kunden gemäß Artikel 28 Absatz 1 werden von der Anti-Money Laundering Authority (AMLA) verfasst. Der Abschlussbericht der AMLA datiert vom 30. September 2026 und wurde am 1. Oktober 2026 angekündigt. **Es handelt sich um einen endgültigen Entwurf, der der Europäischen Kommission vorgelegt wurde. Er ist nicht verabschiedet und stellt kein geltendes Recht dar.** Die Kommission kann ihn noch ändern, und der Entwurf sieht vor, dass er sechs Monate nach seinem Inkrafttreten gilt.

Dieser Entwurf behandelt die beiden Mittel in Artikel 22 Absatz 6 als Standard. Die Remote-Verifizierung mit einem Dokument ist eine alternative Lösung für den Fall, dass von der Person vernünftigerweise nicht erwartet werden kann, das Dokument persönlich vorzulegen, und sie keinen Zugang zu einer qualifizierenden eID hat (Entwurf Artikel 7 Absatz 1). Wenn Sie die Alternative nutzen, verlangt der Entwurf von Ihnen, begründen zu können, warum, und Ihrer Aufsichtsbehörde nachzuweisen, dass die Lösung über Sicherheitsvorkehrungen verfügt (Entwurf Artikel 7 Absätze 2 und 3). Der Entwurf ist technologieneutral: Er nennt keine Technik.

Wie die im Entwurf genannten Schutzmaßnahmen mit den Aufzeichnungen einer Didit-Sitzung übereinstimmen:

| Schutzmaßnahme im Entwurf (Artikel 7(2)) | Was Sie in Didit nutzen können |
| - | - |
| Kontrollen, mit denen sichergestellt wird, dass die das Dokument vorlegende Person dessen Inhaber ist | Liveness- und Gesichtsabgleich-Ergebnisse in der Sitzung |
| Bilder, Videos und Daten von ausreichender Qualität zur Identifizierung der Person | Qualitätsprüfungen bei der Erfassung während des Ablaufs, mit Warnungen im Bericht |
| Abbruch, wenn Zweifel an der Identität oder der Integrität des Prozesses bestehen | Warnungen und ein Sitzungsstatus von `"Declined"` oder `"In Review"` |
| Aufbewahrte, mit Zeitstempel versehene Kopien, die für spätere Prüfungen verfügbar sind | Sitzungsdatensatz, PDF-Bericht und Ihre [Aufbewahrungseinstellung](#aufzeichnungen-aufbewahren-dann-löschen) |

Den Grund, warum ein Kunde den Weg über das Dokument anstelle von eID gewählt hat, müssen Sie dokumentieren. Speichern Sie ihn in Ihrem eigenen System oder hängen Sie ihn beim Erstellen über `metadata` an die Sitzung an.

## Unternehmen und wirtschaftlich Berechtigte verifizieren

Für eine juristische Person verlangt Artikel 22 Absatz 1 Buchstabe b die Rechtsform und den Namen, die Anschrift des satzungsmäßigen Sitzes, die gesetzlichen Vertreter sowie, soweit vorhanden, die Registernummer, die Steuernummer und den Legal Entity Identifier. Sie müssen zudem die wirtschaftlich Berechtigten ermitteln und angemessene Maßnahmen zu deren Verifizierung ergreifen, um die Eigentümer- und Kontrollstruktur zu verstehen (Artikel 20 Absatz 1 Buchstabe b). Ein wirtschaftlich Berechtigter ist eine natürliche Person, die direkt oder indirekt Eigentümer von „mindestens 25 %“ der Anteile, Stimmrechte oder sonstigen Eigentumsrechte ist (Artikel 52 Absatz 1) oder die das Unternehmen über Eigentumsrechte oder auf sonstige Weise kontrolliert (Artikel 51 und 53). Die Kontrolle wird parallel zur Eigentümerstruktur beurteilt.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Juristische Person identifizieren und mit einem Register abgleichen | [Unternehmensverifizierung](https://docs.didit.me/de/business-verification/overview.md) (Know Your Business, KYB) mit einer Unternehmensregister-Abfrage auf den Stufen Lite, Shareholders oder UBOs. Die Verfügbarkeit der Stufen variiert je nach Land | [`POST /v3/session/`](https://docs.didit.me/de/sessions-api/create-session) mit einer KYB-`workflow_id`. Siehe [unterstützte Länder](https://docs.didit.me/de/business-verification/supported-countries.md) |
| Wirtschaftlich letztlich Berechtigte (UBOs) mit mindestens 25 % ermitteln | [Eigentümerstruktur](https://docs.didit.me/de/business-verification/ownership.md) aus dem Register, sofern verfügbar, bestätigt und ergänzt durch den Unternehmensvertreter | UBO-Schwellenwert in **Workflows**, im KYB-Workflow. Ergebnisse in `key_people_checks[]` |
| Identität von Eigentümern, Geschäftsführern und Vertretern verifizieren | Verknüpfte Identitätsprüfungen: Jede [Schlüsselperson](https://docs.didit.me/de/business-verification/key-people.md) erhält eine untergeordnete Verifizierungssitzung in dem von Ihnen pro Rolle gewählten Workflow | Rollenspezifische Einstellungen unter **Schlüsselpersonen** im KYB-Workflow |
| Registerdaten mit den Angaben des Kunden vergleichen (Art. 22 Abs. 7, Art. 24) | Registerdaten und übermittelte Beteiligte werden nebeneinander dargestellt | `key_people_checks[].registry` und `key_people_checks[].submitted` in der Entscheidung |
| Unternehmen, dessen Eigentümer und Kontrollpersonen screenen | [AML-Screening](https://docs.didit.me/de/business-verification/aml.md) für Unternehmen und Personen | AML-Schritt im KYB-Workflow |

Vier Punkte, die bei der Konzeption zu beachten sind:

* **Den Schwellenwert legen Sie fest.** Die AMLR-Formulierung lautet „mindestens 25 %“, nicht „mehr als 25 %“. Der UBO-Schwellenwert im Workflow ist konfigurierbar; stellen Sie ihn entsprechend ein und passen Sie ihn an, falls Ihre internen Richtlinien strenger sind.
* **Ein Register allein reicht nicht aus.** Artikel 22 Absatz 7 verpflichtet Sie dazu, die zentralen Register zusätzlich zur Verifizierung der wirtschaftlich Berechtigten zu konsultieren. Die Meldung von Unstimmigkeiten an das Register innerhalb von 14 Kalendertagen (Artikel 24) liegt in Ihrer Verantwortung.
* **Ein leeres Registerergebnis ist kein Beweis dafür, dass ein Unternehmen keine Eigentümer hat.** Ein Register enthält für ein bestimmtes Unternehmen oder Land möglicherweise keine Eigentümerdaten. Wenn Sie keinen wirtschaftlich Berechtigten ermitteln, verlangt Artikel 22 Absatz 2, dies zu dokumentieren und stattdessen die leitenden Führungskräfte zu identifizieren und zu verifizieren.
* **Registerüberwachung folgt in Kürze.** Eine kontinuierliche Überwachung von Registeränderungen ist derzeit noch nicht verfügbar. Führen Sie bis dahin die Unternehmensverifizierung gemäß Ihrem Aktualisierungsplan erneut durch.

## Auf Sanktionen und PEPs prüfen

Sie müssen überprüfen, ob der Kunde oder seine wirtschaftlich Berechtigten gezielten finanziellen Sanktionen unterliegen und ob sanktionierte Personen einen Kunden, der eine juristische Person ist, kontrollieren oder mehr als 50 % an ihm halten (Artikel 20 Absatz 1 Buchstabe d). In der AMLR beziehen sich gezielte finanzielle Sanktionen auf EU-Sanktionen. Zudem müssen Sie ermitteln, ob der Kunde oder ein wirtschaftlich Berechtigter eine politisch exponierte Person (PEP), ein Familienmitglied oder eine bekanntermaßen nahestehende Person ist (Artikel 20 Absatz 1 Buchstabe g). Für PEPs verlangt Artikel 42 zusätzlich die Genehmigung der oberen Führungsebene, Maßnahmen zur Feststellung der Herkunft des Vermögens und der Mittelherkunft sowie eine verstärkte laufende Überwachung.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Beim Onboarding prüfen | [AML-Screening](https://docs.didit.me/de/core-technology/aml-screening/overview.md)-Schritt im Workflow gegen Sanktions-, PEP- und Beobachtungslisten | AML-Schritt und dessen Schwellenwerte im Workflow. Ergebnisse in `aml_screenings[]` |
| Ohne gehosteten Ablauf prüfen | Eigenständiges Screening einer Person oder eines Unternehmens | [`POST /v3/aml/`](https://docs.didit.me/de/standalone-apis/aml-screening) |
| Wissen, welche Listen abgedeckt sind | [Beobachtungslisten-Datenbank](https://docs.didit.me/de/core-technology/aml-screening/watchlist-database-aml-screening.md), die die konsolidierte EU-Finanzsanktionsliste enthält | Referenzseite |
| Eine Entscheidung zu jedem Treffer dokumentieren | Trefferprüfung mit einem `review_status` pro Treffer | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/de/sessions-api/update-aml-hit-status) |
| PEP- und Sanktionstreffer an eine Person weiterleiten | Schwellenwerte, die die Sitzung auf `"In Review"` setzen | AML-Schwellenwerte im Workflow, anschließend [manuelle Prüfung](https://docs.didit.me/de/console/manual-review.md) |

```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"
  }'
```

Die Erfassung eines Treffers als `Confirmed Match` oder `False Positive` löst einen `data.updated`-Webhook aus und ändert die Sitzungsentscheidung nicht automatisch. Die Genehmigung einer Geschäftsbeziehung mit einer PEP durch die obere Führungsebene liegt in Ihrem eigenen Prozess: Leiten Sie die Sitzung zur Prüfung weiter und dokumentieren Sie, wer die Genehmigung erteilt hat.

## Laufend überwachen und aktualisieren

Artikel 26 verlangt die laufende Überwachung der Geschäftsbeziehung und aktuelle Kundeninformationen. Der Zeitraum zwischen Aktualisierungen darf 1 Jahr bei Kunden mit höherem Risiko und 5 Jahre bei allen anderen Kunden nicht überschreiten (Artikel 26 Absatz 2), und Sie müssen auch aktualisieren, wenn sich die Umstände des Kunden ändern oder Sie von einer relevanten Tatsache erfahren (Artikel 26 Absatz 3). Sanktionsprüfungen müssen regelmäßig wiederholt werden, und bei Kredit- und Finanzinstituten bei jeder neuen Benennung (Artikel 26 Absatz 4).

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Kunden erneut gegen Sanktions- und PEP-Listen prüfen | [Laufende AML-Überwachung](https://docs.didit.me/de/core-technology/aml-screening/continuous-monitoring-aml-screening.md) mit täglichem Re-Screening | Im AML-Schritt aktivieren oder pro Profil mit [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/de/management-api/aml-monitoring/toggle-users) |
| Unternehmen erneut prüfen | Laufende AML-Überwachung für Unternehmensprofile | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/de/management-api/aml-monitoring/toggle-businesses) |
| Benachrichtigt werden, wenn ein Re-Screening das Ergebnis ändert | Webhooks für die Sitzung | `status.updated`, wenn sich der Status ändert, beispielsweise zu `"In Review"`, sowie `data.updated`. Die Payload enthält `trigger: "ongoing_monitoring"` |
| Nachweisen, dass die Überwachung lief, wenn sich nichts geändert hat | Datum des letzten Screenings und Screening-Historie | `last_ongoing_screening_at` im AML-Bericht und Export der Screening-Historie |
| Abgelaufene Ausweisdokumente erkennen | [Dokumentenüberwachung](https://docs.didit.me/de/core-technology/id-verification/document-monitoring-id-verification.md) | Die Sitzung wechselt von `"Approved"` zu `"Kyc Expired"` und ein `status.updated`-Webhook wird ausgelöst |

```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"]}'
```

Das Umschalten der Überwachung löst keinen eigenen Webhook aus. Sobald die Überwachung aktiviert ist, lösen Re-Screenings die üblichen Ereignisse `status.updated` und `data.updated` aus.

### Die 1-Jahres- und 5-Jahres-Aktualisierung im eigenen System planen

Der Aktualisierungszyklus hängt von der Risikoklasse ab, die Sie zuweisen, und diese Entscheidung kann nicht ausgelagert werden. Didit speichert Ihre Risikoklasse nicht und plant die periodische Aktualisierung nicht für Sie.

**1. Risikoklasse und Datum der letzten Aktualisierung speichern**

Bewahren Sie diese in Ihrem Kundendatensatz auf, neben den `vendor_data`, die Sie an Didit senden.

**2. Geplanten Job ausführen**

Wählen Sie Kunden aus, deren letzte Aktualisierung älter als Ihr Intervall ist: höchstens 1 Jahr bei höherem Risiko, höchstens 5 Jahre beim Rest. Dies sind Höchstfristen, ein kürzeres Intervall liegt also in Ihrer Entscheidung.

**3. Neue Sitzung erstellen**

Rufen Sie [`POST /v3/session/`](https://docs.didit.me/de/sessions-api/create-session) mit denselben `vendor_data` und Ihrem Aktualisierungs-Workflow auf und senden Sie dem Kunden anschließend die `url`.

**4. Auch auf Ereignisse reagieren**

Behandeln Sie `"Kyc Expired"`, einen Überwachungs-Webhook, der eine Sitzung auf `"In Review"` setzt, sowie eine vom Kunden gemeldete Änderung als Auslöser für eine frühere Aktualisierung.

## Zweck und Mittelherkunft

Bevor Sie eine Geschäftsbeziehung eingehen oder eine gelegentliche Transaktion durchführen, verlangt Artikel 25 von Ihnen, deren Zweck und beabsichtigte Art zu verstehen. Soweit erforderlich holen Sie Informationen über den Zweck und die wirtschaftliche Begründung, den geschätzten Umfang der Aktivitäten, die Mittelherkunft, das Ziel der Mittel sowie die geschäftliche Tätigkeit oder den Beruf des Kunden ein. „Soweit erforderlich“ bedeutet, dass der Umfang risikobasiert ist. Eine verstärkte Sorgfaltspflicht kann auch die Vermögensherkunft umfassen (Artikel 34 Absatz 4).

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Zweck und erwartete Aktivität erfassen | [Fragebögen](https://docs.didit.me/de/core-technology/questionnaires/overview.md) mit der Vorlage „Purpose of Account“ | Fragebogen-Schritt im Workflow |
| Mittelherkunft mit Belegen erfassen | Vorlage „Source of Funds“ mit Datei-Upload | Fragebogen-Schritt im Workflow |
| Beruf und Arbeitgeber erfassen | Vorlage „Employment Details“ | Fragebogen-Schritt im Workflow |
| Jede Antwort von einer Person lesen lassen | Fragebogen so konfiguriert, dass er immer zu `"In Review"` führt | Einstellung für manuelle Prüfung beim Fragebogen |

Vorlagen sind ein Ausgangspunkt. Passen Sie die Fragen an Ihre Risikobewertung an und speichern Sie die Antworten in der Sitzung, damit sie sich im selben Datensatz wie die Identitätsprüfung befinden.

## Transaktionen überwachen und melden

Die laufende Überwachung erstreckt sich auf die während der Geschäftsbeziehung durchgeführten Transaktionen, damit sie mit dem übereinstimmen, was Sie über den Kunden wissen (Artikel 26 Absatz 1). Wenn Sie wissen, vermuten oder berechtigten Grund zu der Annahme haben, dass Gelder Erträge aus kriminellen Aktivitäten darstellen oder mit Terrorismusfinanzierung in Verbindung stehen, melden Sie dies Ihrer Financial Intelligence Unit (FIU) gemäß Artikel 69.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Jede Transaktion zur Bewertung übermitteln | [Transaktionsüberwachung](https://docs.didit.me/de/transaction-monitoring/overview.md) für Fiat und Krypto | [`POST /v3/transactions/`](https://docs.didit.me/de/transaction-monitoring/transactions) |
| Von Ihnen genehmigte Erkennungskriterien anwenden | Vordefinierte Regelpakete und benutzerdefinierte [Regeln](https://docs.didit.me/de/transaction-monitoring/rules.md), jeweils mit einem von Ihnen gesteuerten Modus | Regeln in der Konsole oder die Regel-API |
| Das Ergebnis mitgeteilt bekommen | Webhooks | `transaction.created` und `transaction.status.updated` |
| Untersuchen | [Alerts](https://docs.didit.me/de/transaction-monitoring/alerts.md) und [Fälle](https://docs.didit.me/de/transaction-monitoring/cases.md) mit einer Chronologie jeder Aktion | Fallmanagement in der Konsole |
| Den Bericht vorbereiten | [FIU-Berichtsvorbereitung](https://docs.didit.me/de/console/case-management/fiu-reports.md) aus Falldaten | Tab **FIU-Berichte** bei einem Fall |

```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" }
  }'
```

Zwei Einschränkungen, die Sie beachten sollten:

* **Sie genehmigen die Erkennungskriterien.** Die Genehmigung der Kriterien zur Erkennung verdächtiger oder ungewöhnlicher Transaktionen kann nicht ausgelagert werden (Artikel 18 Absatz 3 Buchstabe f). Prüfen Sie jede Regel, die Sie einrichten, und halten Sie diese Genehmigung in Ihren eigenen Richtlinien fest.
* **Sie erstatten die Meldung.** Didit bereitet die Berichtsdateien aus dem Fall vor. Didit übermittelt nichts an eine FIU. Die Meldung erfolgt durch Ihren Compliance-Beauftragten über den Kanal Ihrer FIU.

## Aufzeichnungen aufbewahren, dann löschen

Artikel 77 regelt Ihre Aufbewahrungspflicht. Sie bewahren die für die Sorgfaltspflichten gegenüber Kunden eingeholten Dokumente und Informationen, die Aufzeichnungen Ihrer Verdachtsprüfungen und die Transaktionsaufzeichnungen 5 Jahre lang auf. Die Frist beginnt mit der Beendigung der Geschäftsbeziehung, der Durchführung der gelegentlichen Transaktion oder der Ablehnung der Aufnahme der Beziehung (Artikel 77 Absatz 3). Nach Ablauf der 5 Jahre löschen Sie die personenbezogenen Daten, es sei denn, ein anderes Gesetz findet Anwendung oder eine Behörde fordert Sie auf, bestimmte Aufzeichnungen länger aufzubewahren.

Die Frist beginnt mit einem Ereignis in Ihrem System: dem Ende der Beziehung. Didit kennt dieses Datum nicht, daher liegen die von Ihnen konfigurierte Datenaufbewahrung und die von Ihnen veranlassten Löschungen in Ihrer Verantwortung.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Sitzungsaufzeichnungen so lange aufbewahren, wie Ihre Pflicht besteht | [Einstellung zur Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md): ein Zeitfenster von 1 Monat bis 10 Jahren oder unbegrenzt | **Business Console → App Settings → Data retention** |
| Löschen, wenn Ihre 5-Jahres-Frist abläuft | Löschung einer Sitzung auf Abruf | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/de/sessions-api/delete-session) |
| Eine Akte an eine Aufsichtsbehörde oder einen Prüfer übergeben | PDF-Bericht pro Sitzung und pro Benutzer, CSV-Export als Bulk-Export | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/de/sessions-api/generate-pdf), [Exporte](https://docs.didit.me/de/console/export-pdf-csv.md) |
| Screening-Nachweise aufbewahren | Export des Screening-Verlaufs pro Sitzung | [Nachweise der laufenden Überwachung](https://docs.didit.me/de/core-technology/aml-screening/continuous-monitoring-aml-screening.md#nachweis-über-die-durchführung-der-überwachung) |

**1. Wählen Sie ein Aufbewahrungsfenster, das nicht vorzeitig enden kann**

Eine Sitzung erreicht das Ende des Zeitfensters und wird gelöscht. Wählen Sie ein Zeitfenster, das die Dauer Ihrer Kundenbeziehungen plus 5 Jahre abdeckt, oder lassen Sie es unbegrenzt und löschen Sie auf Abruf.

**2. Erfassen Sie das Ende der Beziehung**

Speichern Sie das Datum der Beendigung, der Transaktion oder der Ablehnung in Ihrem eigenen System. Damit beginnt Ihre Fünfjahresfrist.

**3. Löschen Sie nach Ablauf der Frist**

Rufen Sie `DELETE /v3/session/{sessionId}/delete/` für jede Sitzung dieses Kunden auf. Die Löschung ist unumkehrbar und Medien-URLs lassen sich nicht mehr auflösen.

> [!WARNING]
>
> **Audit-Logs und der Screening-Verlauf decken die 5-Jahres-Pflicht allein nicht ab.** Audit-Logs sind je nach Ihrem [Tarif](https://docs.didit.me/de/console/audit-logs.md#datenaufbewahrung) 30 Tage bis 3 Jahre verfügbar, und Durchläufe des Screening-Verlaufs stehen standardmäßig zwei Jahre zur Verfügung. Wenn Ihre Aufbewahrungsrichtlinie darauf basiert, exportieren Sie sie in Ihre eigenen Unterlagen, bevor diese Zeiträume enden. Die Sitzungsaufzeichnungen im Rahmen Ihrer Aufbewahrungseinstellung bilden die Anforderungen aus Artikel 77 ab.

## Menschliche Überprüfung automatisierter Entscheidungen

Artikel 76 Absatz 5 erlaubt es Ihnen, Entscheidungen zu treffen, die sich aus automatisierten Prozessen ergeben, einschließlich Profiling und KI-Systemen, und zwar unter drei Bedingungen. Die Daten sind auf Daten zur Erfüllung der Sorgfaltspflichten beschränkt. Jede Entscheidung über die Aufnahme, Ablehnung oder Fortführung einer Geschäftsbeziehung, die Durchführung oder Ablehnung einer gelegentlichen Transaktion oder die Änderung des Umfangs der Sorgfaltspflichten unterliegt einem maßgeblichen menschlichen Eingreifen. Und der Kunde kann eine Erklärung der Entscheidung erhalten und die Entscheidung anfechten.

| Anforderung | Didit-Funktion | Endpoint oder Einstellung |
| - | - | - |
| Fälle an eine Person weiterleiten | Workflow-Schwellenwerte und Verzweigungen, die in `"In Review"` enden | [Workflows](https://docs.didit.me/de/console/workflows.md) |
| Nachweise prüfen und entscheiden | [Manuelle Prüfung](https://docs.didit.me/de/console/manual-review.md) mit einem Ablehnungsgrund und Prüfnotizen | Console oder [`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/de/sessions-api/update-status) |
| Einen zweiten Prüfer verlangen | [Vier-Augen-Prüfung](https://docs.didit.me/de/console/case-management/four-eyes.md) bei einer Fallvorlage: Ein anderer Prüfer genehmigt oder lehnt die Entscheidung ab | Fallmanagement in der Console |
| Das Ergebnis erklären | Ergebnisse pro Prüfung, Warnungen und Prüferkommentare zur Sitzung | [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/de/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"
  }'
```

Ein Sitzungsstatus von `"Approved"` oder `"Declined"` ist das Ergebnis der von Ihnen konfigurierten Prüfungen. Er dient als Eingabe für Ihre Onboarding-Entscheidung, welche gemäß Artikel 18 Absatz 3 bei Ihnen verbleibt. Entscheiden Sie gemeinsam mit Ihrer Rechtsabteilung, wo eine Person eingreifen muss, und binden Sie diesen Schritt dann in den Workflow und in Ihr eigenes Backoffice ein.

## Auslagerung

Artikel 18 ermöglicht es Ihnen, Aufgaben, die sich aus der AMLR ergeben, an einen Dienstleister auszulagern. Er legt Bedingungen fest: Sie benachrichtigen Ihre Aufsichtsbehörde, bevor der Dienstleister seine Tätigkeit aufnimmt (Artikel 18 Absatz 1), Sie bleiben für die ausgelagerten Aufgaben voll haftbar (Artikel 18 Absatz 2), und Sie legen die Bedingungen in einer schriftlichen Vereinbarung fest und führen regelmäßige Kontrollen beim Dienstleister durch (Artikel 18 Absatz 4). Die Verordnung besagt zudem, dass die Nutzung von Software Dritter oder der Zugriff auf Datenbanken oder Screening-Dienste, bei denen Sie die Anforderung selbst erfüllen, keine Auslagerung darstellt (Erwägungsgrund 47). Ob Ihre Nutzung von Didit als Auslagerung gilt, hängt davon ab, wie Sie es einsetzen. AMLA-Leitlinien zur Auslagerung sollen bis zum 10. Juli 2027 vorliegen.

Sechs Aufgaben können unter keinen Umständen ausgelagert werden (Artikel 18 Absatz 3). Sie verbleiben bei Ihnen:

1. Der Vorschlag und die Genehmigung Ihrer unternehmensweiten Risikobewertung.
2. Die Genehmigung Ihrer internen Grundsätze, Verfahren und Kontrollen.
3. Die Entscheidung über das dem Kunden zuzuordnende Risikoprofil.
4. Die Entscheidung über die Aufnahme einer Geschäftsbeziehung oder die Durchführung einer gelegentlichen Transaktion.
5. Die Meldung verdächtiger Aktivitäten und schwellenwertbasierte Meldungen an die FIU.
6. Die Genehmigung der Kriterien zur Erkennung verdächtiger oder ungewöhnlicher Transaktionen und Aktivitäten.

Die damit verbundenen Aufgaben können delegiert werden: Erhebung von Identitätsdaten, Durchführung der Dokumenten- oder eID-Verifizierung, Erfassung von Daten zu wirtschaftlich Berechtigten und Registerabfragen, Screening gegen Sanktions- und PEP-Listen, Durchführung der Transaktionsüberwachung anhand von Ihnen genehmigter Kriterien sowie Vorbereitung von Alerts und Nachweisen.

Was Sie in Ihr Auslagerungsregister zu Didit aufnehmen sollten:

| Punkt | Was zu erfassen ist | Wo Sie es finden |
| - | - | - |
| Schriftliche Vereinbarung (Art. 18 Abs. 4) | Ihr Vertrag mit Didit und die Vereinbarung zur Auftragsverarbeitung | Bitten Sie Ihren Didit-Ansprechpartner um die AVV und die technischen und organisatorischen Maßnahmen |
| Delegierte Aufgaben | Die Prüfungen in jedem von Ihnen ausgeführten Workflow, nach Workflow-Version | [Workflows](https://docs.didit.me/de/console/workflows.md). Sitzungen und Webhooks enthalten `workflow_id` und `workflow_version` |
| Aufgaben, die bei Ihnen verbleiben | Die sechs oben genannten Aufgaben mit dem Verantwortlichen in Ihrer Organisation | Ihre eigenen Richtlinien |
| Dienstleisterqualifikation (Art. 18 Abs. 4) | Zertifizierungen und Attestierungen | [Zertifizierungen](https://docs.didit.me/de/getting-started/certifications.md) |
| Datenstandort | Daten werden standardmäßig in der EU verarbeitet und gespeichert. Eine Verarbeitung im jeweiligen Land ist im Enterprise-Tarif verfügbar | [Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md#rolle-und-verarbeitungsort) |
| Regelmäßige Kontrollen (Art. 18 Abs. 4) | Ihre Stichprobenprüfung von Sitzungen, Exporten und Prüfprotokollen in einer Häufigkeit, die der Kritikalität der Aufgabe entspricht | [Exporte](https://docs.didit.me/de/console/export-pdf-csv.md), [Audit-Logs](https://docs.didit.me/de/console/audit-logs.md) |
| Benachrichtigung der Aufsichtsbehörde (Art. 18 Abs. 1) | Das Datum, an dem Sie Ihre Aufsichtsbehörde vor dem Go-Live benachrichtigt haben | Ihr Schritt. Die Benachrichtigung bedeutet nicht, dass die Aufsichtsbehörde die Vereinbarung genehmigt |

## Referenz-Workflow

Ein Ausgangspunkt für einen Onboarding-Workflow für natürliche Personen. Passen Sie ihn an Ihre Risikobewertung an.

**1. Workflow erstellen**

Öffnen Sie in der Business Console **Workflows** und erstellen Sie einen Know-Your-Customer-Workflow (KYC). Verwenden Sie den visuellen Builder, wenn Sie Verzweigungen nach Land oder Ergebnis benötigen.

**2. Identitätsmethoden pro Land auswählen**

Aktivieren Sie im Schritt **Ausweisverifizierung** die digitalen ID-Wallets, die für die von Ihnen bedienten Länder verfügbar sind, und die Dokumentenerfassung als Weg für alle anderen. Siehe [Methoden zur Ausweisverifizierung](https://docs.didit.me/de/console/id-verification-methods.md).

**3. Dokument an die Person binden**

Fügen Sie für den Dokumentenweg **Liveness-Erkennung** und **Gesichtsabgleich** hinzu sowie **NFC**, wenn das Dokument über einen Chip verfügt.

**4. Adresse abdecken**

Fügen Sie **Adressnachweis** für Kunden hinzu, deren Dokument keine Adresse enthält.

**5. Screening und Überwachung**

Fügen Sie **AML-Screening** hinzu, legen Sie die Schwellenwerte fest, die einen Treffer zur Prüfung weiterleiten, und aktivieren Sie die laufende Überwachung.

**6. Zweck und Mittelherkunft abfragen**

Fügen Sie einen **Fragebogen** aus den Vorlagen für Kontozweck und Mittelherkunft hinzu.

**7. Webhooks abonnieren**

Erstellen Sie ein Webhook-Ziel, das `status.updated` und `data.updated` abonniert. Siehe [Webhooks](https://docs.didit.me/de/integration/webhooks.md).

**8. Workflow veröffentlichen und Workflow-ID kopieren**

Veröffentlichen Sie den Workflow und verwenden Sie dessen `workflow_id`, wenn Sie Sitzungen erstellen.

Erstellen Sie eine Sitzung:

```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"
  }'
```

Antwort (`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"
}
```

Leiten Sie den Kunden zu `url` weiter. Wenn für die Sitzung eine Entscheidung vorliegt, sendet Didit ein `status.updated`-Webhook. Ein Auszug:

```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" }
}
```

Prüfen Sie die Signatur, verwenden Sie `event_id` als Idempotenzschlüssel und gleichen Sie `status` als exakte Zeichenkette ab, bei der die Groß- und Kleinschreibung berücksichtigt wird. Die Werte sind in [Verifizierungsstatus](https://docs.didit.me/de/integration/verification-statuses.md) aufgeführt. Rufen Sie anschließend die vollständige Entscheidung mit `GET /v3/session/{sessionId}/decision/` ab und übergeben Sie sie an die für Ihre Onboarding-Entscheidung zuständige Person oder den dafür zuständigen Prozess.

## Zeitplan

| Datum | Was geschieht |
| - | - |
| 19. Juni 2024 | Die AMLR, Verordnung (EU) 2024/1624, wird im Amtsblatt veröffentlicht |
| 9. Juli 2024 | Die AMLR tritt in Kraft |
| 30. September 2026 | Die AMLA datiert ihren Abschlussbericht über die Entwürfe für Standards zur Sorgfaltspflicht gegenüber Kunden (angekündigt für den 1. Oktober 2026). Der Kommission vorgelegt, nicht verabschiedet |
| 10. Juli 2027 | Die AMLR gilt. Frist für die Mitgliedstaaten zur Umsetzung der sechsten Geldwäscherichtlinie, Richtlinie (EU) 2024/1640. AMLA-Leitlinien zur Auslagerung sollen vorliegen |
| 2028 | Die AMLA beginnt die direkte Aufsicht über ausgewählte Finanzunternehmen. Die erste Runde ist auf 40 begrenzt |
| 10. Juli 2029 | Die AMLR gilt für Spielervermittler im Fußball und Profifußballvereine |

## FAQ

> [accordion] Wann gilt die AMLR?
>
> Die AMLR trat am 9. Juli 2024 in Kraft und gilt ab dem 10. Juli 2027. Für Fußballvermittler und Profifußballvereine gilt sie ab dem 10. Juli 2029. Bis zum 10. Juli 2027 gelten die nationalen Gesetze zur Umsetzung der aktuellen Richtlinie.

> [accordion] Was ist der Unterschied zwischen AMLR, AMLD6 und AMLA?
>
> Die AMLR ist die Verordnung (EU) 2024/1624. Sie enthält die Vorschriften für Verpflichtete und gilt unmittelbar, ohne nationale Umsetzung. Die AMLD6 ist die Richtlinie (EU) 2024/1640. Sie richtet sich an die Mitgliedstaaten und regelt Aufsichtsbehörden, Register und Sanktionen, wobei die Frist zur Umsetzung am 10. Juli 2027 endet. Die AMLA ist die durch die Verordnung (EU) 2024/1620 geschaffene Anti-Geldwäsche-Behörde mit Sitz in Frankfurt. Sie erarbeitet die technischen Standards sowie Leitlinien und wird ab 2028 eine ausgewählte Gruppe von Finanzunternehmen direkt beaufsichtigen.

> [accordion] Ist die Fernverifizierung mit einem Ausweisdokument weiterhin zulässig?
>
> Ja, unter bestimmten Voraussetzungen. Artikel 22 Absatz 6 nennt zwei Mittel: ein Ausweisdokument oder eine eID mit dem Sicherheitsniveau „substanziell“ oder „hoch“. Der endgültige Entwurf der AMLA-Standards vom 30. September 2026 sieht die Fernverifizierung mit einem Dokument weiterhin als Alternative vor, wenn von der Person vernünftigerweise nicht erwartet werden kann, dass sie das Dokument physisch vorlegt, und sie keinen Zugang zu einer qualifizierenden eID hat. Sie müssen deren Nutzung begründen und die Schutzmaßnahmen nachweisen können. Der Entwurf nennt keine spezifische Technik und ist noch kein geltendes Recht.

> [accordion] Sind die technischen Standards final?
>
> Nein. Die AMLA hat ihren Entwurf am 30. September 2026 finalisiert und an die Europäische Kommission übermittelt. Verbindlich wird er erst, wenn die Kommission ihn annimmt und er im Amtsblatt veröffentlicht wird; die Kommission kann ihn noch ändern. Der Entwurf sieht vor, dass er sechs Monate nach seinem Inkrafttreten anwendbar wird, sodass es noch kein fixes Kalenderdatum gibt.

> [accordion] Muss ich die EUDI Wallet akzeptieren, und unterstützt Didit sie?
>
> Die AMLR selbst nennt die eID als eines von zwei Verifizierungsmitteln. Sie verpflichtet nicht jeden Verpflichteten, die EUDI Wallet zu akzeptieren. Die Akzeptanzpflicht ergibt sich aus der eIDAS-Verordnung: Private vertrauende Parteien, die für die Online-Identifizierung eine starke Benutzerauthentifizierung verlangen müssen, akzeptieren die Wallet auf Anfrage des Benutzers spätestens 36 Monate nach Inkrafttreten der Durchführungsrechtsakte; Kleinst- und Kleinunternehmen sind davon ausgenommen. Ob dies Ihr Onboarding betrifft, sollten Sie rechtlich prüfen lassen. In Didit ist die EUDI Wallet **Demnächst verfügbar**. Die heute in der Produktion verfügbaren Wallets sind MitID, BankID Schweden, Finnish Trust Network, Smart-ID und Mobile-ID.

> [accordion] Liegt der Schwellenwert für wirtschaftlich Berechtigte bei 25% oder 15%?
>
> Er liegt bei „25 % oder mehr“ der Geschäftsanteile, Stimmrechte oder sonstigen Eigentumsrechte (Artikel 52 Absatz 1), wobei die Kontrolle parallel geprüft wird. Artikel 52 Absatz 2 erlaubt es der Kommission, für Kategorien von Unternehmen mit höherem Risiko per delegiertem Rechtsakt einen niedrigeren Schwellenwert von maximal 15 % festzulegen. Ein solcher Rechtsakt existiert bislang nicht. In Didit ist der UBO-Schwellenwert eine Einstellung in Ihrem KYB-Workflow.

> [accordion] Wie setze ich die 1-jährige und 5-jährige Aktualisierung um?
>
> Speichern Sie die Risikoklasse und das Datum der letzten Aktualisierung des Kunden in Ihrem eigenen System, führen Sie einen geplanten Job aus, der Kunden nach Ablauf Ihres Intervalls auswählt, und erstellen Sie mit `POST /v3/session/` und denselben `vendor_data` eine neue Sitzung. Fügen Sie Ereignisauslöser hinzu: den Status `"Kyc Expired"`, einen Monitoring-Webhook oder eine vom Kunden gemeldete Änderung. Die 1-Jahres- und 5-Jahres-Werte in Artikel 26 Absatz 2 sind Höchstfristen.

> [accordion] Was kann ich auslagern?
>
> Aufgaben wie die Erfassung von Identitätsdaten, die Durchführung der Verifizierung, Registerabfragen, das Screening und die Ausführung der Transaktionsüberwachung anhand von Ihnen genehmigter Kriterien. Sechs Aufgaben dürfen nicht ausgelagert werden: die Genehmigung der unternehmensweiten Risikoanalyse, die Genehmigung interner Richtlinien, die Festlegung des Risikoprofils des Kunden, die Entscheidung über das Onboarding, die Meldung an die FIU und die Genehmigung der Erkennungskriterien. Sie bleiben für das, was Sie auslagern, voll verantwortlich (Artikel 18 Absatz 2).

> [accordion] Wie richte ich die Datenaufbewahrung für die 5-Jahres-Regel ein?
>
> Die 5 Jahre beginnen mit der Beendigung der Geschäftsbeziehung, nicht mit dem Zeitpunkt der Verifizierung des Kunden. Wählen Sie in **Business Console → App Settings → Data retention** ein Zeitfenster, das lang genug ist, um die Geschäftsbeziehung plus 5 Jahre abzudecken, oder lassen Sie es unbegrenzt. Erfassen Sie das Beendigungsdatum in Ihrem eigenen System und rufen Sie `DELETE /v3/session/{sessionId}/delete/` auf, sobald Ihre Frist abgelaufen ist. Exportieren Sie Audit-Logs und den Screening-Verlauf, falls Ihre Richtlinien zur Datenaufbewahrung darauf beruhen.

> [accordion] Macht mich die Nutzung von Didit AMLR-konform?
>
> Nein. Compliance ist eine Eigenschaft Ihres Gesamtprogramms: Ihrer Risikobewertung, Ihrer Richtlinien, Ihrer Entscheidungen und Ihrer Kontrollen. Didit stellt Ihnen die Prüfungen, die Überwachung und die Nachweise bereit, auf denen diese Teile des Programms basieren. Es gibt keine AMLR-Zertifizierung oder -Genehmigung für Anbieter oder Tools.

## Weiterführende Ressourcen

> [card] [Übersicht über die AMLR-Lösung](https://didit.me/solutions/amlr)
>
> Die geschäftliche Perspektive: für wen die AMLR gilt und wie Didit sich einfügt.

> [card] [Methoden der Ausweisverifizierung](https://docs.didit.me/de/core-technology/id-verification/verification-methods.md)
>
> Dokumentenerfassung, dokumentenlose Abfrage und digitale Identitäts-Wallets.

> [card] [Digitale Identitäts-Wallets](https://docs.didit.me/de/core-technology/id-verification/digital-id-wallets.md)
>
> Verfügbarkeit und Vertrauensniveau pro Wallet.

> [card] [Unternehmensverifizierung (KYB)](https://docs.didit.me/de/business-verification/overview.md)
>
> Registerabfragen, Eigentümerstruktur und Schlüsselpersonen.

> [card] [AML-Screening](https://docs.didit.me/de/core-technology/aml-screening/overview.md)
>
> Screening auf Sanktionen, PEPs und Beobachtungslisten mit laufender Überwachung.

> [card] [Transaktionsüberwachung](https://docs.didit.me/de/transaction-monitoring/overview.md)
>
> Regeln, Alerts, Fälle und Vorbereitung von FIU-Meldungen.

> [card] [Fragebögen](https://docs.didit.me/de/core-technology/questionnaires/overview.md)
>
> Vorlagen für den Zweck der Geschäftsbeziehung und die Mittelherkunft.

> [card] [Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md)
>
> Aufbewahrungsfristen und bedarfsgesteuerte Löschung.

> [card] [Webhooks](https://docs.didit.me/de/integration/webhooks.md)
>
> Ereignistypen, Payloads und Signaturprüfung.

> [card] [Preise](https://docs.didit.me/de/getting-started/pricing.md)
>
> Zahlung pro Überprüfung. Sehen Sie sich den aktuellen Preis jeder Funktion an.


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