Didit Orchestrated Workflows sind die leistungsstärkste und flexibelste Möglichkeit, umfassende, mehrstufige Identitätsverifizierungsabläufe zu gestalten und bereitzustellen.
Diese Lektion der Didit Academy zeigt, wie Sie in der echten Konsole einen Verifizierungs-Workflow erstellen, von der Vorlage bis zum veröffentlichten Ablauf: Prüfungen für jeden Knoten auswählen, Regeln und Schwellenwerte festlegen, AML-Verzweigungen einrichten, Webhook-Knoten konfigurieren und eine Version zurücksetzen.
Dieser Integrationspfad ermöglicht es Ihnen, die volle Leistungsfähigkeit der Didit-V2-Plattform zu nutzen und mit unserem No-Code-Visual-Builder anspruchsvolle Verifizierungsabfolgen zu erstellen. Sie definieren die Logik einmal in Ihrer Business Console, und Didit übernimmt das gesamte nutzerseitige Erlebnis, das Zustandsmanagement und die bedingten Schritte.
Wählen Sie diesen Pfad, wenn Sie eine vollständige Ende-zu-Ende-Lösung für das Onboarding von Nutzern (KYC), die Altersverifizierung oder die erneute Authentifizierung benötigen und schnell mit minimalem Entwicklungsaufwand starten möchten, dabei aber maximale Kontrolle über den Prozess behalten wollen.
Länder und zulässige Ausweismethoden
Öffnen Sie in der Ausweisverifizierung Länder und zulässige Ausweismethoden, um für jedes Land die Dokumentenerfassung, die Abfrage ohne Dokument und digitale Identitäts-Wallets zu konfigurieren.
Zusätzliche Einstellungen enthalten Dokumentunterarten, Abfrageversuche und Fallback-Regeln.
Die Abfrage ohne Dokument wird nach den Preisen Ihrer Organisation für die Datenbankvalidierung abgerechnet.
Jeder abgeschlossene Versuch wird separat berechnet, auch Teiltreffer und Nicht-Treffer: Zwei abgeschlossene Versuche ergeben also zwei Abrechnungen.
Formatfehler und Anbieterausfälle, die keine Antwort liefern, werden nicht berechnet.
Antworten mehrere Datenbankdienste auf einen Versuch, werden deren jeweilige Dienstpreise addiert.
Der Standard ist ein Versuch vor dem Fallback, konfigurierbar von eins bis fünf.
Die Dokumentenerfassung wird zusätzlich berechnet, wenn eine abgeschlossene Abfrage auf Dokumente zurückfällt.
Live-Anwendungen können nur Wallets aktivieren, die für die Produktion verfügbar sind.
Wallets, deren Einführung noch aussteht, bleiben deaktiviert.
Sandbox-Anwendungen können jedes Wallet im Katalog mit simulierten Ergebnissen testen. Die Verfügbarkeit in der Sandbox bedeutet jedoch nicht, dass das Wallet in der Produktion verfügbar ist.
Szenarien für Fehler bei Abfragen und Wallets finden Sie unter Sandbox-Tests.
Workflow-Versionierung
Workflows unterstützen die Versionierung mit Entwurf und Veröffentlichung. Das bedeutet, dass Sie Ihren Workflow sicher weiterentwickeln können, ohne laufende Sitzungen zu beeinflussen:
- Entwurfsversionen sind vollständig bearbeitbar: Knoten lassen sich frei hinzufügen, entfernen und umstrukturieren
- Die Veröffentlichung eines Entwurfs erzeugt eine unveränderliche Version, die von neuen Sitzungen verwendet wird
- Frühere Versionen bleiben erhalten, sodass Sie die genaue Konfiguration einer vergangenen Sitzung einsehen können
- Sitzungen verweisen immer auf die konkrete Version, mit der sie erstellt wurden. So bleibt die Konsistenz auch nach der Veröffentlichung von Aktualisierungen erhalten
Um Änderungen an einem veröffentlichten Workflow vorzunehmen, erstellen Sie einen neuen Entwurf aus der veröffentlichten Version, bearbeiten ihn und veröffentlichen ihn, sobald er fertig ist. Den Versionsverlauf erhalten Sie über die Management API.
Zwei Wege, Workflows zu erstellen
Didit bietet zwei verschiedene Ansätze zum Erstellen von Verifizierungs-Workflows. So können Sie die Komplexität wählen, die zu Ihrem Bedarf passt:
1. Einfacher Modus: Vorlagenbasierter Builder
Der Einfache Modus eignet sich ideal für einen schnellen Einstieg. Wählen Sie eine vorgefertigte Vorlage, aktivieren oder deaktivieren Sie die benötigten Funktionen, und schon kann es losgehen.
Geeignet für:
- Schnelle Einrichtung und Bereitstellung
- Standardisierte Verifizierungsabläufe
- Teams, die neu im Bereich Identitätsverifizierung sind
- Anwendungsfälle, die gängigen Mustern entsprechen
So funktioniert es:
- Wählen Sie eine Workflow-Vorlage (KYC, Altersverifizierung usw.)
- Aktivieren oder deaktivieren Sie Funktionen (Liveness, Gesichtsabgleich, AML usw.)
- Konfigurieren Sie die grundlegenden Einstellungen für jede Funktion
- Veröffentlichen Sie den Workflow und starten Sie die Verifizierung
2. Erweiterter Modus: Visueller Graph-Builder
Der Erweiterte Modus erschließt die volle Leistungsfähigkeit der Orchestrierungs-Engine von Didit. Mit dem visuellen Graph-Editor erstellen Sie komplexe, bedingte Verifizierungsabläufe mit Knoten, Verzweigungen und benutzerdefinierter Logik per Drag-and-drop.
Geeignet für:
- Komplexe Verifizierungsabläufe mit mehreren Pfaden
- Bedingte Logik auf Basis von Benutzerdaten oder Verifizierungsergebnissen
- Benutzerdefinierte Geschäftsregeln und Verzweigungen
- Compliance-Anforderungen auf Unternehmensniveau
Wichtige Funktionen:
- Visueller Knoten-Editor: Knoten auf einer unbegrenzten Arbeitsfläche ziehen, ablegen und verbinden
- Intelligente Verbindungen: Ziehen Sie von einem Knotenanschluss ins Leere, um sofort einen neuen Knoten zu erstellen und zu verbinden
- Bedingte Verzweigungen: Leiten Sie Benutzer anhand extrahierter Daten, Verifizierungsstatus, Land, Dokumenttyp, Dokument-Untertyp, Ausstellungsdatum, Alter, Pfaden in JSON-Antworten von Webhooks oder benutzerdefinierter Regeln weiter
- Aktionsautomatisierung: Fügen Sie Tags hinzu, legen Sie Metadaten fest oder leiten Sie Benutzer je nach Ergebnis des Ablaufs zur manuellen Prüfung weiter
- Tastenkürzel: Rückgängig (Strg/Cmd+Z), Wiederholen (Strg/Cmd+Umschalt+Z), Löschen (Entf/Rücktaste)
- Zoomen und Verschieben: Navigieren Sie durch komplexe Abläufe mit Zoomen per Scrollen und Verschieben per Ziehen
Knotentypen des Graph-Builders
Kategorien der Funktionsknoten
Interaktive Funktionen für Benutzer (können einen Workflow starten):
- Ausweisverifizierung (OCR)
- Liveness-Erkennung
- Gesichtsabgleich
- Altersschätzung
- Telefonverifizierung
- E-Mail-Verifizierung
- Fragebogen
- Adressnachweis
- Document AI
- NFC / ePassport
Nur im Backend ausgeführte Funktionen (laufen automatisch, ohne Benutzerinteraktion):
- AML-Screening (benötigt zuvor einen Ausweisverifizierungs-Schritt, einen KYB-Register-Schritt oder einen Document-AI-Schritt, siehe Geprüfte Entität)
- Datenbankvalidierung (benötigt zuerst OCR)
- Geräte- und IP-Analyse
Hinweis: Rein im Backend laufende Funktionen sind im Builder mit einer besonderen Kennzeichnung versehen. Sobald ihre Abhängigkeiten erfüllt sind, werden sie ohne Benutzerinteraktion automatisch ausgeführt.
Der erste Konfigurationsreiter jedes Funktionsknotens beginnt mit der Steuerung Verifizierungs-Engine. Hier können Sie die Prüfung mit der eigenen Engine von Didit ausführen oder auf einen Drittanbieter umstellen, den Sie über den Marketplace anbinden. Ist dieser Anbieter nicht verfügbar, greift automatisch Didit als Ausweichlösung.
Geprüfte Entität
Das AML-Screening übernimmt normalerweise aus dem vorangehenden Schritt, wen es prüft: die Person, die der Ausweisverifizierungs-Schritt aus einem Dokument ausgelesen hat, oder das Unternehmen, das der KYB-Register-Schritt zurückgegeben hat. Manche Abläufe haben keines von beiden. Ein Ablauf, der vollständig auf Document AI basiert, also auf nicht standardisierten Dokumenten wie einer Steuerbescheinigung oder einer notariell beglaubigten Gründungsurkunde, enthält bereits Name, Geburtsdatum, Dokumentnummer und Land, allerdings unter Ihren eigenen Feldschlüsseln.
Auf dem Reiter Erweitert des AML-Knotens ordnen Sie diese Schlüssel dem Screening zu:
- Entitätstyp - Prüfen Sie eine Person oder das Unternehmen, das in einem hochgeladenen Dokument genannt wird. Ein Unternehmensknoten durchsucht Unternehmensdatensätze statt Personendatensätze.
- Feldquellen - Ordnen Sie jede der vier Screening-Eingaben (Name, Geburtsdatum, Land, Dokumentnummer) einem Document-AI-Feld, einer Fragebogenantwort oder einem Wert zu, den Sie bei der Sitzungserstellung senden (
expected_details / metadata). Ein Document-AI-Feld, das Sie bereits full_name genannt haben, wird automatisch übernommen.
- Unvollständige Prüfdaten - Legt fest, was geschieht, wenn das Screening mit unvollständigen Identitätsdaten durchgeführt wird. Standardmäßig ist die Einstellung manuelle Prüfung. Wählen Sie Keine Aktion nur dann, wenn der Ablauf bewusst nur einen Namen enthält.
Zwei Punkte sollten Sie kennen, bevor Sie sich darauf verlassen. Ohne einen Schritt für Ausweisverifizierung oder KYB Registry ist der Name ein Pflichtfeld - der Workflow kann nicht veröffentlicht werden, bis etwas ihn befüllt, weil ohne Namen keine Suche möglich ist. Außerdem hängt die Präzision der AML-Prüfung direkt davon ab, wie viele Identifikatoren Sie übergeben: Eine reine Namensprüfung erzeugt die hohe Zahl falsch positiver Treffer, über die sich Prüfer beklagen. Ordnen Sie deshalb Geburtsdatum und Land zu, wann immer das Dokument sie enthält.
Wie Verzweigungsbedingungen Sitzungsdaten auswerten
Welchen Datensatz eine Bedingung liest. Eine Verzweigungsbedingung ist an den Funktionsknoten gebunden, aus dem sie erstellt wurde, und liest dessen Ergebnis. Hat ein einzelner Knoten mehr als einen Datensatz erzeugt, liest die Bedingung den neuesten davon. Das ist besonders wichtig für Geräte- und IP-Analyse: Didit erfasst pro Gerät und IP-Adresse, von der aus eine Sitzung geöffnet wird, eine Beobachtung. Ein Nutzer, der während der Sitzung Telefon oder Netzwerk wechselt, hinterlässt daher mehrere Datensätze auf demselben Knoten. Eine Regel wie IP COUNTRY is in [...] wird dann gegen die neueste Beobachtung ausgewertet - denselben Datensatz, der zuerst im Panel Geräte- und IP-Analyse der Sitzung und im Array ip_analyses des Entscheidungs-Payloads angezeigt wird. Sitzungen mit mehr als einer Beobachtung tragen außerdem die Warnung MULTIPLE_DEVICES_IN_SESSION. Sie signalisiert, dass Sie die vollständige Liste prüfen sollten und nicht nur das Ergebnis der Verzweigung.
Länderwerte. Bedingungen für Länder werden anhand des Landes selbst abgeglichen, nicht anhand der Schreibweise. Wählen Sie Länder aus der Feldauswahl, dann normalisiert Didit beide Seiten des Vergleichs. So passt eine Regel in ISO 3166-1 alpha-3 (UKR) trotzdem auf einen Wert, der als alpha-2 erfasst wurde (UA).
Fehlende Werte, leere Werte und negative Vergleiche. Ein Feld ohne jeden Wert (das Dokument enthält ihn nicht, der Metadatenschlüssel wurde nicht gesendet, die Funktion lief nicht) passt nur auf is empty und equals not_defined. Jeder andere Vergleich - equals, contains, greater than, außerdem not equals und not in - passt nicht, und der Verzweigungsknoten wechselt zu seiner nächsten Verzweigung. Ein Feld mit einer leeren Zeichenkette gilt dagegen als Wert, nicht als fehlendes Feld: Eine Sitzung, die mit "metadata": {"credential_state": ""} erstellt wird, passt nicht auf metadata.credential_state equals IL, passt aber auf not equals IL, not in [IL, MA, NJ] und equals "" (is empty passt auf beide Fälle). Eine Verzweigung, die bei einem negativen Vergleich genehmigt, genehmigt daher eine Sitzung, deren Status leer gesendet wurde, während dieselbe Sitzung ohne den Schlüssel die Fallback-Verzweigung nimmt. Wenn Sie auf not equals oder not in routen, fügen Sie derselben Verzweigung metadata.<key> is not empty hinzu (UND-Logik), damit beide Fälle dort enden, wo ein fehlender Wert enden soll. Verzweigungen werden der Reihe nach ausgewertet, und der erste Treffer gewinnt. Die Fallback-Verzweigung (die Verzweigung ohne Bedingungen) wird nur dann genommen, wenn keine andere Verzweigung gepasst hat. Geben Sie daher jedem Verzweigungsknoten eine Fallback-Verzweigung, die dort endet, wo ein unerwarteter Wert enden soll. Eine Sitzung, die ohne Warnung bei einer Funktion in In Prüfung landet, wurde durch einen Statusknoten im Graphen dorthin geleitet und nicht durch eine Prüfung. Die Fallback-Verzweigung eines Verzweigungsknotens ist die übliche Ursache.
Sitzungs-Metadaten. Werte, die Sie bei der Sitzungserstellung in metadata senden, stehen jeder Verzweigung als metadata.<key> zur Verfügung. Sie können mit einem festen Wert oder mit einem anderen Sitzungsfeld verglichen werden, zum Beispiel metadata.min_age <= Age. Zahlen werden als Zahlen verglichen, daher verhalten sich 18 und "18" gleich.
Sandbox / Testmodus. Verzweigungsbedingungen, Metadaten und Statusknoten laufen in der Sandbox genauso wie im Live-Betrieb. Die Sandbox versetzt eine Sitzung allerdings nie von selbst in die Prüfung. Der Unterschied liegt beim Dokument: Ein Sandbox-Sitzungsdokument ist ein erfundenes Dokument ohne US-Bundesstaat bzw. Region, daher können Region-Bedingungen dort nie passen. Informationen dazu, wie Sie bundesstaatsabhängige Abläufe testen, finden Sie unter was das erfundene Dokument nicht enthält.
Erneute Einreichungen. Verzweigungsknoten werden bei jedem Versuch ausgewertet, auch bei einer erneuten Einreichung. Wenn Sie eine Sitzung für bestimmte Schritte zurücksenden, werden die Verzweigungen und Aktionen zwischen diesen Schritten erneut ausgeführt, sobald der Nutzer sie erneut abschließt, und zwar anhand der Daten des neuen Versuchs. Ein Nutzer, der zwischen den Versuchen in eine eingeschränkte Rechtsordnung wechselt, wird daher durch die Verzweigung geleitet, die diese Rechtsordnung abdeckt. Eine Verzweigung, die mit dem Ergebnis „abgelehnt“ endet, beendet die erneut eingereichte Sitzung an dieser Stelle.
Wie Sie sehen, welchen Weg eine Sitzung genommen hat. Jede Verzweigungsentscheidung, die der Workflow während der Laufzeit einer Sitzung trifft, und jeder Ergebnisknoten, den der Workflow erreicht, werden in der Ereignis-Timeline der Sitzung erfasst (Console-Sitzungsdetails > Events sowie GET /v3/session/{id}/decision/?include=events). Eine Zeile Workflow-Routing nennt den Verzweigungsknoten, die passende Bedingung und den Knoten, zu dem die Sitzung weitergeführt wurde. Alternativ vermerkt sie, dass keine Bedingung gepasst hat und die Fallback-Kante des Knotens genommen wurde. Eine Zeile Workflow-Ergebnis nennt den Statusknoten, der den Sitzungsstatus gesetzt hat. Wenn ein Workflow eine Sitzung ohne Funktion, die sie markiert, in In Prüfung schickt, zeigen diese Zeilen den Weg, den sie genommen hat, einschließlich jeder Fallback-Kante und des Ergebnisknotens, zu dem sie geführt hat. Spätere manuelle Entscheidungen ändern diese Workflow-Ereignisse nicht nachträglich. Fehlende Eingaben sind eine mögliche Ursache: Bedingungen, die einen vorhandenen metadata.*-Wert voraussetzen, passen nicht, wenn der Schlüssel bei der Sitzungserstellung weggelassen wurde. Bedingungen, die ausdrücklich auf fehlende Eingaben prüfen, etwa is_empty oder equals mit not_defined, können auf denselben fehlenden Schlüssel zutreffen. Die Fallback-Kante wird nur genommen, wenn keine Verzweigung passt, einschließlich einer etwaigen Else-Verzweigung. Sie führt zu dem Knoten, der am Standardausgang angeschlossen ist. Die Payloads der Ereignisse finden Sie unter Sitzungsereignisse.
Workflow-Vorlagen: Ihr Ausgangspunkt
Betrachten Sie Vorlagen nicht als starre Typen, sondern als intelligente, vorkonfigurierte Ausgangspunkte für gängige Anwendungsfälle. Im Simple Mode sind sie sofort einsatzbereit. Im Advanced Mode bilden sie eine Grundlage, die Sie umfassend anpassen können.
Verfügbare Vorlagen
1. KYC-Workflow
Die umfassende Lösung für das Onboarding neuer Benutzer und die vollständige Einhaltung der Know-Your-Customer-Anforderungen (KYC).
- Beginnt mit: grundlegende Ausweisverifizierung.
- Häufig hinzugefügte Funktionen:
[+] Liveness-Erkennung: Stellt sicher, dass die Person physisch anwesend ist, und verhindert Spoofing.[+] Gesichtsabgleich 1:1: Gleicht das Selfie des Benutzers biometrisch mit dem Foto im Ausweis ab.[+] AML-Screening: Gleicht Benutzer mit globalen Sanktionslisten, PEP-Listen und Listen mit negativen Medienberichten ab.[+] NFC-Verifizierung: Fügt eine Sicherheitsebene auf Behördenniveau hinzu, indem E-Pass- bzw. eID-Chips ausgelesen werden.[+] Adressnachweis (PoA): Verifiziert die Wohnadresse des Benutzers.[+] Telefonverifizierung: Prüft die Inhaberschaft der Telefonnummer als zusätzlichen Faktor.[+] E-Mail-Verifizierung: Prüft die Inhaberschaft der E-Mail-Adresse als zusätzlichen Faktor.[+] Datenbankvalidierung: Validiert anhand offizieller Behörden- und Kreditdatenbanken.[+] Fragebogen: Erfasst strukturierte Attestierungen und unterstützende Dokumente über anpassbare Formulare.[+] Geräte- und IP-Analyse: Analysiert Standort- und Verbindungsrisiken.
2. Adaptiver Altersverifizierungs-Workflow
Ein reibungsarmer, datenschutzfreundlicher Ablauf für altersbeschränkte Dienste.
- Beginnt mit: Selfie-basierter Altersschätzung.
- Wichtige Logik:
- Liegt das geschätzte Alter deutlich über Ihrem Schwellenwert (z. B. geschätzt 25+ bei einem Dienst mit 18+), wird der Benutzer sofort freigegeben.
- Liegt die Schätzung unter dem Schwellenwert oder innerhalb einer „Pufferzone“ (z. B. geschätzt 16 bis 20), können Sie den Workflow so konfigurieren, dass automatisch ein Fallback auf die vollständige Ausweisverifizierung ausgelöst wird, um das exakte Geburtsdatum zu bestätigen.
- Häufig hinzugefügte Funktionen:
[+] Geräte- und IP-Analyse: Beschränkt den Zugriff anhand des geografischen Standorts.
3. Workflow für biometrische Authentifizierung
Eine schnelle und sichere Möglichkeit, wiederkehrende Benutzer erneut zu verifizieren, ohne erneut nach deren Dokumenten zu fragen.
- Beginnt mit: einer Liveness-Erkennung, um die Anwesenheit des Benutzers zu bestätigen.
- Kernlogik:
- Das System führt einen Gesichtsabgleich zwischen dem neuen Live-Selfie und dem vertrauenswürdigen biometrischen Template aus der ursprünglichen, genehmigten KYC-Verifizierung des Benutzers durch.
- Hat der Benutzer bereits ein gespeichertes Gesicht unter demselben
vendor_data (genehmigtes Liveness-Gesicht, ePassport-Foto, Porträt im Ausweisdokument oder hinterlegtes Profilgesicht), können Sie portrait_image beim Anlegen der Sitzung weglassen; Didit verwendet das gespeicherte Gesicht dann automatisch. Andernfalls übergeben Sie portrait_image (Base64-kodiertes Bild, maximal 2 MB). Ohne eines von beiden schlägt das Anlegen der Sitzung mit 400 fehl.
- Häufig hinzugefügte Funktionen:
[+] Telefonverifizierung: Verknüpft die Adresse mit einer verifizierten Telefonnummer.[+] E-Mail-Verifizierung: Prüft die Inhaberschaft der E-Mail-Adresse als zusätzlichen Faktor.[+] Geräte- und IP-Analyse: Kennzeichnet verdächtige Anmeldeversuche von neuen Standorten.
4. Adressverifizierungs-Workflow
Ein eigenständiger Ablauf für den Fall, dass der Adressnachweis (PoA) die zentrale Anforderung ist.
- Beginnt mit: Der Benutzer reicht ein Adressnachweisdokument ein (z. B. Versorgungsrechnung, Kontoauszug).
- Kernlogik: Unsere KI extrahiert Name und Adresse aus dem Dokument und validiert sie.
- Häufig hinzugefügte Funktionen:
[+] Telefonverifizierung: Verknüpft die Adresse mit einer verifizierten Telefonnummer.[+] E-Mail-Verifizierung: Prüft die Inhaberschaft der E-Mail-Adresse als zusätzlichen Faktor.[+] Geräte- und IP-Analyse: Vergleicht die Adresse im Dokument mit dem aktuellen geografischen Standort des Benutzers für mehr Sicherheit.
5. Fragebogen-Verifizierungs-Workflow
Ein fokussierter Ablauf, wenn Ihr Hauptziel darin besteht, strukturierte Attestierungen und unterstützende Dokumente über anpassbare Formulare zu erfassen.
- Beginnt mit: Fragebogen.
- Kernlogik: Das System zeigt Ihren konfigurierten Fragebogen an (Abschnitte, übersetzte Inhalte, Pflichtfelder, Uploads).
- Häufig hinzugefügte Funktionen:
[+] Geräte- und IP-Analyse: Ergänzt Ihre Fragebogen-Einreichungen um Standort- und Verbindungskontext.
Vollständige Anpassung
Jede Funktion innerhalb eines Workflows kann mit spezifischen Parametern weiter angepasst werden, um Ihre genauen Anforderungen zu erfüllen. Die Einstellungen jeder Prüfung finden Sie im Builder.
Regeln auf Basis des Familienstands
Im Advanced Mode können Sie das OCR-Feld kyc.marital_status in bedingten Verzweigungen und benutzerdefinierten Statusregeln verwenden. Wählen Sie den Wert aus der Feldauswahl, damit die Regel den unterstützten Enum-Wert und nicht Freitext verwendet. Enthält das Dokument keinen Familienstand, ist der Wert leer und Ihr Ausweichzweig greift.
Der Workflow-Copilot kann außerdem Schritte der Datenbankvalidierung in einer Aktion anlegen und konfigurieren. Wenn Sie ihn bitten, diese Prüfung hinzuzufügen, geben Sie die benötigten Länder an; die Konsole ermittelt für jedes Land den unterstützten Dienst und zeigt die gespeicherte Konfiguration auf der Arbeitsfläche an.
Vergleich von Simple Mode und Advanced Mode
Integrationsablauf
Die Integration eines orchestrierten Workflows ist unkompliziert. Ihr Server erstellt eine Sitzung bei Didit, erhält eine eindeutige URL und leitet Ihren Benutzer an diese URL weiter. Didit übernimmt den Rest und benachrichtigt Ihren Server per Webhooks über die Ergebnisse.
Typische Anwendungsfälle
| Anwendungsfall | Empfohlene Vorlage | Empfohlener Modus | Empfohlene Funktionen |
|---|
| Einfache Identitätsverifizierung | KYC | Simple | Liveness-Erkennung, Gesichtsabgleich |
| Onboarding mit hoher Sicherheit | KYC | Advanced | NFC, Liveness-Erkennung, Gesichtsabgleich, AML, Telefonverifizierung |
| Altersbeschränkte Inhalte/Dienste | Adaptive Age Verification | Simple | Ausweisverifizierung als Fallback |
| Authentifizierung wiederkehrender Benutzer | Biometrische Authentifizierung | Simple | Geräte- und IP-Analyse |
| Adressverifizierung | Adressnachweis | Simple | Telefonverifizierung |
| Onboarding für Finanzdienstleistungen | KYC | Advanced | Liveness-Erkennung, Gesichtsabgleich, Adressnachweis, AML, Datenbankvalidierung |
| Regionsspezifische Compliance | KYC | Advanced | Bedingte Weiterleitung nach Land, unterschiedliche Prüfungen je Region |
| Risikobasierte Verifizierung | KYC | Advanced | Bedingte Verzweigungen auf Basis von Risiko-Scores, Eskalationspfade |
Erste Schritte
- Neu bei Didit? Beginnen Sie mit Simple Mode und einer vorgefertigten Vorlage
- Benötigen Sie individuelle Anpassungen? Wechseln Sie zu Advanced Mode, um bedingte Logik hinzuzufügen
Wenden Sie sich an unser Vertriebsteam, um individuelle Workflow-Konfigurationen zu besprechen oder sich zur besten Einrichtung für Ihre spezifischen Anforderungen beraten zu lassen.
Zuletzt geändert am 7. November 2026
Erste Schritte
Integrieren / SDKs
Benutzerverifizierung
Unternehmensverifizierung
Transaktionsüberwachung
Changelog
