> ## 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. # Manuelle KYC-Prüfung: Prüfer-Dashboard > Markierte Ausweisverifizierungen im Didit-Dashboard prüfen: genehmigen, ablehnen oder erneute Einreichung anfordern – mit Audit-Logs und Nachweisen. Die manuelle Prüfung ist ein zentraler Bestandteil jedes robusten Workflows zur Identitätsverifizierung und KYC-Compliance. Wenn das automatisierte System eine Verifizierungssitzung mit Warnungen oder Unstimmigkeiten markiert, wechselt sie in den Status **In Prüfung**. Dann ist ein geschulter Prüfer erforderlich, der die endgültige Entscheidung trifft. Dieser Leitfaden führt Sie durch den gesamten Prozess der manuellen Prüfung, einschließlich der Verwendung der Funktion **erneute Einreichung**, mit der Sie Benutzern eine zweite Chance geben können. *** ## Übersicht des Verifizierungs-Dashboards ![Übersicht der Verifizierungen zur manuellen Prüfung](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=4f16a753968d444bf4e917c08bcbbef5) Die Tabellenansicht der Verifizierungen listet alle Sitzungen mit ihrem aktuellen Status, Dokumenttyp, Land und weiteren wichtigen Details auf. Sitzungen können folgende Status haben: | Status | Bedeutung | | - | - | | **Genehmigt** | Der Benutzer hat alle Identitätsprüfungen bestanden | | **Abgelehnt** | Der Benutzer hat eine oder mehrere Verifizierungsprüfungen nicht bestanden | | **In Prüfung** | Erfordert Ihre manuelle Prüfung, bevor eine Entscheidung getroffen werden kann | | **Erneut eingereicht** | Der Benutzer wurde aufgefordert, bestimmte Verifizierungsschritte erneut durchzuführen | > [!WARNING] > > Sitzungen, die als **In Prüfung** markiert sind, haben während der automatisierten Verarbeitung ein oder mehrere Warnsignale ausgelöst. Die Gesamtzahl der Sitzungen, die auf eine Prüfung warten, wird oben im Verifizierungs-Dashboard angezeigt. *** ## So führen Sie eine effektive manuelle Prüfung durch **1. Erste Prüfung** Klicken Sie auf eine beliebige Sitzung, um die detaillierte Sitzungsansicht zu öffnen: 1. **Alle Warnungen prüfen**, die in der Sitzungsübersicht angezeigt werden. Dabei handelt es sich um die konkreten Signale, die die manuelle Prüfung ausgelöst haben (z. B. niedriger Liveness-Score, AML-Treffer, Inkonsistenz im Dokument). 2. **Frühere Verifizierungsversuche des Benutzers prüfen**: Klicken Sie auf die Anbieterdaten des Benutzers, um den Sitzungsverlauf aufzurufen und zu sehen, ob frühere Verifizierungssitzungen vorliegen. 3. **Zeitleiste der Sitzungsereignisse prüfen**: Der Bereich Ereignisse enthält ein chronologisches Protokoll jeder Aktion während der Sitzung. **2. Dokumentenprüfung** Das automatisierte System von Didit führt bereits eine umfassende Dokumentenverifizierung durch, einschließlich der Erkennung von Sicherheitsmerkmalen, feldbezogener Konsistenzprüfungen, MRZ-Validierung, Prüfung des Ablaufdatums und Analyse der Bildqualität. Ihre Aufgabe ist es, die markierten **Warnungen zu bewerten** und das Dokument bei Bedarf visuell zu bestätigen. 1. **Dokumentwarnungen prüfen**: Prüfen Sie die konkreten Warnungen, die das System ausgegeben hat. Häufige Warnungen betreffen Inkonsistenzen zwischen Feldern, fehlgeschlagene Prüfziffernvalidierung der MRZ, abgelaufene Dokumente oder den Verdacht auf Manipulation. 2. **Bei unklaren Warnungen visuell verifizieren**: Wenn eine Warnung auf eine mögliche Manipulation oder niedrige Bildqualität hindeutet, prüfen Sie die Dokumentbilder direkt. Achten Sie auf Anzeichen digitaler Bearbeitung, des Zuschneidens, von Bildschirmaufnahmen oder physischer Manipulation. 3. **Extrahierte OCR-Daten prüfen**: Sehen Sie sich die Daten an, die das System aus dem Dokument extrahiert hat, und bestätigen Sie, dass sie konsistent wirken. Das System hebt Felder hervor, bei denen die Konfidenz niedrig ist. 4. **Dekodierte QR-Codes und Barcodes prüfen**: Wenn Document AI einen QR-Code oder Barcode auf dem Dokument erkennt, hebt die Sitzungsansicht dessen Position auf der Bild- oder PDF-Vorschau hervor und zeigt die dekodierte Payload an. Ein Code, der gefunden, aber nicht dekodiert werden konnte, wird nur als erkannt angezeigt, ohne dass eine Payload angegeben wird. Diese Positionsmarkierung ist getrennt von den Hervorhebungen der Warnungen zur Dokumentmanipulation, die ihre bisherige Darstellung beibehalten. 5. **Dokumenttreffer prüfen**: Wenn **Gesichtssuche** oder die Duplikaterkennung aktiviert ist, prüfen Sie, ob dieser Benutzer bereits unter einer anderen Identität verifiziert wurde oder ob das Dokument in Ihrer **Sperrliste** erscheint. > [!TIP] > > Fahren Sie in der Didit-Konsole mit der Maus über Dokumentbilder, um die **Zoom-Funktion** für eine detaillierte Prüfung auf Pixelebene zu nutzen. Das ist besonders hilfreich beim Prüfen von Mikrodruck und Hologrammen. **3. Biometrische Prüfung und Liveness-Verifizierung** Didit führt automatisch einen **Gesichtsabgleich**, eine **Liveness-Erkennung** und, falls aktiviert, eine **Gesichtssuche** durch. Ihre Aufgabe ist es, die Ergebnisse zu prüfen, wenn sie markiert sind. 1. **Übereinstimmungswert des Gesichtsabgleichs**: Das System berechnet einen biometrischen Ähnlichkeitswert zwischen dem Selfie und dem Porträt im Dokument. Wenn Sie einen markierten Gesichtsabgleich prüfen, konzentrieren Sie sich auf strukturelle Merkmale wie Augenform, Nasengeometrie, Kieferlinie und unverwechselbare Kennzeichen. 2. **Score der Liveness-Erkennung**: Das Liveness-System erkennt Präsentationsangriffe wie gedruckte Fotos, Bildschirmwiedergaben, Deepfakes und 3D-Masken. Schlechte Kameraqualität oder schwache Beleuchtung können bei echten Benutzern manchmal niedrigere Scores erzeugen. Ziehen Sie in Betracht, **eine erneute Einreichung anzufordern**, statt abzulehnen. 3. **Ergebnisse der Gesichtssuche**: Prüfen Sie Treffer sorgfältig: * **Duplikaterkennung**: Ein Treffer mit einer anderen Sitzung kann darauf hindeuten, dass sich dieselbe Person unter mehreren Identitäten verifiziert. * **Sperrlisten-Treffer**: Wenn das Gesicht einem Benutzer auf der Sperrliste entspricht, ist in der Regel eine Ablehnung angebracht. * **Falsch positive Treffer**: Gesichtsähnlichkeit zwischen verschiedenen Personen kommt tatsächlich vor. Bewerten Sie den Konfidenzwert und vergleichen Sie die Bilder visuell. **4. Risiko- und Signalprüfung** Prüfen Sie die Bereiche **AML-Screening**, **Geräte- und IP-Analyse** und **Datenbankvalidierung**, um das kontextbezogene Risiko zu bewerten. ![AML-Screening-Ergebnisse in der manuellen Prüfung](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review-aml.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=f08862b7abc947edb57e81b87ff8ecac) **AML-Screening** * **Keine Treffer**: geringes Risiko. Es wurden keine Treffer in globalen Beobachtungslisten, Sanktionslisten oder PEP-Datenbanken gefunden. * **Treffer gefunden**: Prüfen Sie jeden Treffer. Stellen Sie fest, ob es sich um einen echten Treffer oder um einen falsch positiven Treffer handelt, prüfen Sie die Trefferkategorie (PEP, Sanktionen, Beobachtungsliste, negative Medienberichte) und berücksichtigen Sie Quelle und Aktualität der Daten. * **Die Scores nutzen, nicht nur das Label**: Der Bereichskopf zeigt den aggregierten **Risiko-Score**, aus dem der AML-Status abgeleitet wurde (der höchste Risiko-Score unter den Treffern, die nicht als falsch positiv markiert sind, verglichen mit den Schwellenwerten für Genehmigung und Prüfung des Workflows). Jede Zeile zeigt den **Übereinstimmungswert** des Treffers (Identitätskonfidenz) und den **Risiko-Score** (Entitätsrisiko). Fahren Sie mit der Maus über einen der beiden, um die Berechnung einzusehen. Dies sind dieselben `score`-, `match_score`- und `risk_score`-Werte, die Ihre Integration im [Entscheidungs-Payload](https://docs.didit.me/de/core-technology/aml-screening/report-aml-screening.md#drei-scores-kein-einzelnes-urteil) erhält. **Geräte- und IP-Analyse sowie Geräteinformationen** * **Geografische Konsistenz**: Vergleichen Sie das Ausstellungsland des Dokuments, die angegebene Adresse des Benutzers und die IP-Geolokalisierung. * **VPN-/Proxy-Erkennung**: Prüfen Sie, ob der Benutzer über ein VPN, einen Proxy oder das Tor-Netzwerk verbunden ist. * **Gerätemetadaten**: Prüfen Sie Gerätetyp, Betriebssystem und Browserinformationen auf Auffälligkeiten. *** ## Entscheidung treffen Nach Abschluss Ihrer Prüfung haben Sie drei Optionen: **Genehmigen**, **Ablehnen** oder **Erneute Einreichung anfordern**. > [card] Genehmigen > > * Dokument wirkt echt und unverändert > * Alle Datenfelder sind konsistent und lesbar > * Biometrischer Abgleich des Selfies bestätigt dieselbe Person > * Liveness-Erkennung liegt im akzeptablen Bereich > * Keine relevanten Treffer bei AML, Sanktionen oder PEP > * Geräte- und Standortdaten sind konsistent > [card] Ablehnen > > * Dokument wirkt manipuliert, gefälscht oder verändert > * Selfie stimmt nicht mit dem Foto im Dokument überein > * Treffer bei AML oder Sanktionen mit hoher Konfidenz bestätigt > * Starke Hinweise auf einen Präsentationsangriff > * Betrügerische Identitätsmuster erkannt > * Kritische Abweichungen bei Gerät oder Standort > [card] Erneute Einreichung anfordern > > * Unscharfe oder qualitativ schlechte Dokumentbilder > * Liveness-Erkennung wegen technischer Probleme fehlgeschlagen > * Falsches Dokument eingereicht > * Unvollständige oder abgelaufene Verifizierungsschritte > * Behebbare Probleme, die der Benutzer korrigieren kann ![Auswahldialog für Ablehnungskriterien](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-decline-criteria.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=1b6056a86de8250e5e4a5cd786de4171) > [!NOTE] > > Wählen Sie beim Ablehnen einer Sitzung immer einen **Ablehnungsgrund** aus und fügen Sie detaillierte **Prüfnotizen** hinzu. Dies unterstützt die Qualitätssicherung, regulatorische Prüfungen und interne Auswertungen. *** ## Erneute Einreichung anfordern Wenn eine Sitzung weder eindeutig genehmigt noch eindeutig abgelehnt werden kann, meist wegen **behebbarer Probleme**, können Sie den Benutzer auffordern, bestimmte Verifizierungsschritte erneut einzureichen. ### So fordern Sie eine erneute Einreichung an **1. Sitzung öffnen** Navigieren Sie in der Didit-Konsole zur Sitzung. **2. Erneute Einreichung anfordern auswählen** Öffnen Sie das Steuerelement für den Sitzungsstatus, wählen Sie **Erneut eingereicht** und anschließend **Weiter** aus. **3. Funktionen für die erneute Einreichung auswählen** Der Dialog zeigt alle nicht genehmigten Funktionen mit ihrem aktuellen Status. Wählen Sie einzelne Schritte aus oder ab. Funktionen, die nie gestartet wurden, sind automatisch erforderlich. **4. Optional eine E-Mail-Benachrichtigung senden** Wenn die E-Mail-Adresse des Benutzers vorliegt, senden Sie ihm eine lokalisierte Benachrichtigung mit einem direkten Link zum Fortsetzen. Die E-Mail nennt den Grund für jeden Schritt. Wenn alle Schritte angefordert werden, weil das Dokument abgelaufen ist, wird dies genannt, und es wird um ein gültiges Dokument gebeten, statt allgemein zu einem „erneuten Versuch“ aufzufordern. Der Wortlaut lässt sich je Sprachversion unter [White-Label → Texte](https://docs.didit.me/de/console/white-label.md#individueller-text) anpassen. **5. Vorschau anzeigen und bestätigen** Wählen Sie **Vorschau**, um Empfänger, Absender, Betreff und die lokalisierte E-Mail zu prüfen. White-Label-Sitzungen verwenden das konfigurierte Branding und den verifizierten Absender. Wählen Sie **Bearbeiten**, um die Prüfungen, den Empfänger oder die Sprache zu ändern, und erstellen Sie danach eine neue Vorschau. Mit **Bestätigen** wird die erneute Einreichung angefordert. Die reine Vorschau ändert die Sitzung nicht und versendet keine E-Mail. Wenn automatische Prüfungen die Verifizierung ohne weitere Aktion des Benutzers abschließen, wird die E-Mail mit der Aufforderung nicht versendet. ### Was nach der erneuten Einreichung passiert 1. **Die früheren Ergebnisse bleiben lesbar**: Nur die ausgewählten Schritte beginnen von vorn. Was sie vorher zurückgegeben haben, wird zu einer früheren Einreichung. Die Sitzung zeigt sie in den Einreichungs-Tabs jedes Schritts an („Submission 2 · latest“, „Submission 1“), und die API gibt sie mit `?include=resubmissions` bei [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md) zurück. 2. **Der Benutzer kehrt in den Verifizierungsablauf zurück**: Er muss nur die gezielt angeforderten Schritte abschließen. 3. **Die Sitzung bleibt im Status Erneut eingereicht**: Dieser unterscheidet sich von **In Bearbeitung**, sodass Sie Sitzungen mit erneuter Einreichung separat verfolgen können. 4. **Automatische Neubewertung**: Sobald alle erneut eingereichten Funktionen abgeschlossen sind, berechnet das System den finalen Status automatisch neu. 5. **Neuer Webhook wird ausgelöst**: Ihr Server erhält einen Webhook mit dem aktualisierten finalen Status. > [!TIP] > > Sie können für dieselbe Sitzung mehrmals eine erneute Einreichung anfordern. Jede Anforderung wird nummeriert, und jede frühere Einreichung bleibt lesbar, mit Angabe, wer sie angefordert hat und warum. Versuche innerhalb eines Schritts (zum Beispiel ein zweites Foto, das der Ablauf angefordert hat) gelten nicht als Einreichungen: Die Sitzung zeigt den neuesten Versuch, und unter Events sind alle Versuche aufgeführt. Wenn Sie die Sitzung löschen, werden alle Einreichungen gelöscht. ### Erneute Einreichung im Vergleich zu einer neuen Sitzung | | Erneute Einreichung | Neue Sitzung | | - | - | - | | **Sitzungs-ID** | Gleiche Sitzungs-ID bleibt erhalten | Es wird eine neue Sitzungs-ID erstellt | | **Verlauf** | Frühere Versuche bleiben innerhalb derselben Sitzung archiviert | Eigene Sitzung, kein verknüpfter Verlauf | | **Aufwand für den Benutzer** | Nur fehlgeschlagene oder ausgewählte Schritte wiederholen | Vollständige Verifizierung von vorn | | **Auswirkung auf die Konversion** | Höhere Abschlussquoten | Risiko eines Abbruchs durch den Benutzer | | **Webhook** | Gleiche Sitzungs-ID, Status wechselt zu Erneut eingereicht → finaler Status | Neuer Sitzungslebenszyklus ab „Not Started“ | | **Prüfpfad** | Vollständiger Verlauf an einem Ort | Verteilt auf mehrere Sitzungen | *** ## Best Practices für die Prüfung > [accordion] Einheitlich vorgehen > > Wenden Sie bei jeder Prüfung dieselben Maßstäbe an. Dokumentieren Sie Ihre Begründung, damit andere Teammitglieder Ihre Entscheidungen nachvollziehen und reproduzieren können. > [accordion] Bei behebbaren Problemen erneute Einreichung statt Ablehnung bevorzugen > > Wenn das Problem ein unscharfes Foto oder ein technischer Fehler ist, bleibt die Sitzung durch eine erneute Einreichung erhalten, und echte Benutzer werden nicht unnötig belastet. > [accordion] Zoom-Funktion nutzen > > Zoomen Sie bei Dokumentbildern stets hinein, um subtile Manipulationen, Mikroschrift oder Sicherheitsmerkmale zu prüfen, die bei der üblichen Vergrößerung nicht sichtbar sind. > [accordion] Datenpunkte gegenseitig abgleichen > > Bewerten Sie Signale nicht isoliert. Ein niedriger Liveness-Score in Kombination mit einer VPN-Verbindung und einer abweichenden Geolokalisierung ist bedenklicher als jeder einzelne Faktor für sich allein. > [accordion] Alles dokumentieren > > Fügen Sie für jede Entscheidung detaillierte Prüfnotizen hinzu, insbesondere bei Ablehnungen. Diese Notizen unterstützen die interne Qualitätssicherung und regulatorische Prüfungen und helfen dabei, neue Teammitglieder einzuarbeiten. > [accordion] Benachrichtigungen einrichten > > Richten Sie E-Mail- oder Slack-Alerts ein, damit Sie sofort benachrichtigt werden, sobald Sitzungen in den Status **in Prüfung** wechseln. Schnelle Reaktionszeiten verbessern sowohl die Compliance als auch das Nutzererlebnis. > [accordion] Muster bei erneuten Einreichungen beobachten > > Wenn ein Benutzer mehrere Zyklen erneuter Einreichung durchlaufen hat, prüfen Sie den gesamten Verlauf sorgfältig. Wiederholte Fehler bei derselben Funktion können auf ein systemisches Problem hinweisen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.