> ## 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. # Organisationsübergreifende Identitätsansprüche > Didit meldet Identitätsnachweise anderer Organisationen ohne Betrugs-Label: separate Ergebnisdimensionen, standardmäßig inaktiv. ## Die Regel, für die diese Seite existiert Ein Gesicht ist eine stabile Identität. Es ist kein Betrugsmerkmal, und Didit wird es niemals als ein solches behandeln. Diese Unterscheidung ist besonders in dem Fall von Bedeutung, der der Anlass dafür war: Eine echte, einwilligende Person versucht, sich unter einer Identität zu verifizieren, die nicht ihre eigene ist. Dieser Versuch muss gestoppt werden. Danach müssen jedoch drei verschiedene Personen unbehelligt bleiben – dieselbe Person, wenn sie sich später mit ihrer eigenen gültigen Identität verifiziert, die Person, deren Identität missbraucht wurde (die das Opfer ist, nicht der Täter), und jeder, dessen Gesicht lediglich ähnlich aussieht. Daher ist die Bedeutung als Betrug an eine **Identitätsbehauptung** gekoppelt, bei der es sich um ein Ereignis handelt, und niemals an die Person, die sie aufgestellt hat, oder an die Identität, die behauptet wurde. ## Vier Dimensionen, vier Felder Eine Entscheidung wird niemals in einem einzigen, in Ihrem Namen gewählten Wort zusammengefasst. Jede dieser Dimensionen wird unabhängig voneinander gemeldet, und Sie entscheiden, wie Ihr Produkt mit der Kombination umgeht: | Dimension | Was beantwortet wird | Wo es erscheint | | - | - | - | | **Integrität der Eingabe** | War die Erfassung live, unverändert und von einer echten Kamera? | Liveness-Warnungen (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) | | **Identitätsabgleich** | Stimmte die Person mit der beanspruchten Identität im Abgleich mit einer vertrauenswürdigen Referenz überein? | Warnungen zu Gesichtsabgleich und doppelten Gesichtern in der Sitzung | | **Verhaltens- und Netzwerkindizien** | Haben andere Organisationen für dieselbe Person Anspruchsereignisse festgestellt, die nicht übereinstimmten? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` | | **Endentscheidung** | Welchen Status die Sitzung erhalten hat | `status` im Entscheidungs-Payload | Eine fehlgeschlagene Liveness-Prüfung, ein nicht übereinstimmender Identitätsabgleich und ein Netzwerkmuster sind drei verschiedene Aussagen über drei verschiedene Dinge. Sie als eine einzige Zahl zu interpretieren, führt dazu, dass ein schlechtes Foto zu einer Anschuldigung wird. ### Identitätsabgleich erfordert eine vertrauenswürdige Referenz `match` und `mismatch` werden nur generiert, wenn eine vertrauenswürdige Referenz vorliegt, mit der ein Gesicht verglichen werden kann – das Porträt auf einem amtlichen Dokument oder eine Identität, die diesem Gesicht bereits stark zugeordnet ist. Eine E-Mail-Adresse oder eine Telefonnummer ohne vorherige starke Zuordnung bietet keine Grundlage für den Vergleich eines Gesichts. In diesem Fall lautet die Antwort **keine Referenz**, niemals `mismatch` und niemals ein `match`, das allein aus dem Gesichtsverlauf abgeleitet wird. ## Was organisationsübergreifende Nachweise aussagen können und was nicht Befindet sich Ihre Organisation im Enterprise-Tarif und ist ihr Sharing-Modus auf `global` gesetzt, kann eine Sitzung `CROSS_ORG_IDENTITY_CLAIM_PATTERN` auslösen. Unterhalb von Enterprise oder bei einer Freigabeeinstellung auf `private` oder `off` wird die organisationsübergreifende Prüfung nicht ausgeführt. Nachweise zu Ansprüchen stammen ausschließlich von anderen Organisationen, die sich ebenfalls im Enterprise-Tarif befinden und global teilen. Die Warnung bedeutet: > Andere teilnehmende Organisationen haben Identitätsanspruchs-Ereignisse für dieselbe Person erfasst, > bei denen die beanspruchte Identität nicht mit den Nachweisen in diesen Sitzungen übereinstimmte. Sie bedeutet **nicht**, dass die Person betrügerisch handelt, und keine Antwort von Didit wird dies jemals behaupten. Drei Garantien stellen dies sicher: * **Sie wird unterdrückt, wenn Ihre eigene Prüfung erfolgreich war.** Wenn der Identitätsabgleich dieser Sitzung `match` ergibt, wird die Warnung gar nicht erst ausgelöst. Eine Person, die sich erfolgreich anhand ihrer eigenen vertrauenswürdigen Referenz verifiziert, ist verifiziert – woran auch immer sie zuvor beteiligt gewesen sein mag, gehört zu jenen Ansprüchen, nicht zu diesem. * **Sie kann nicht ablehnen.** Die Aktion ist Prüfung (Review) oder Keine Aktion (No action). Das Festlegen von Ablehnen (Decline) für `cross_org_identity_claim_pattern_action` wird auf Prüfung (Review) herabgestuft, da die Historie zu einer Person zwar eine Untersuchung des aktuellen Anspruchs veranlassen darf, ihn jedoch niemals ablehnen darf. * **Sie ist rein aggregiert.** Die Payload enthält Informationen darüber, wie viele Organisationen, wie viele nicht übereinstimmende Ansprüche und wie viele unterschiedliche Identitäten beansprucht wurden sowie wie lange dies her ist – niemals, wer diese sind, niemals deren Sitzungen und niemals deren Daten. `CROSS_ORG_FRAUD_FACE` ist die veraltete Version dieser Warnung und wird nicht mehr ausgelöst. Sie wird als Wert beibehalten, damit bestehende Logs und Regeln weiterhin aufgelöst werden; historische Vorkommnisse sind Datensätze, keine Urteile über eine Person. ## Reine Gesichtssuche: eine Personen-ID, kein Urteil Das Wiedererkennen desselben Menschen ist eine eigenständige Funktion, getrennt von jeglicher Entscheidung über ihn. Eine reine Gesichtssuche liefert eine **stabile opake Personen-ID** für wiederholte Erfassungen desselben Gesichts mit hoher Konfidenz, und sonst nichts. * Die ID ist ein zufälliger Bezeichner. Sie wird weder von einem Gesicht, einem Gesichts-Embedding, einer Sitzung, einer Organisation noch einer Kundenreferenz abgeleitet, sodass sie nichts weiter offenlegt als: „Diese Erfassung wurde bereits zuvor erfasst“. * Sie enthält keinen Betrugsstatus. Es gibt kein Feld dafür, das dies abbilden könnte. * Eine Übereinstimmung mit geringer Konfidenz oder eine mögliche Übereinstimmung führt niemals zur Zusammenführung zweier Personen. Ein fehlerhaftes Zusammenführen verschmilzt zwei Menschen zu einer Identität und kann aus den Daten nicht mehr rückgängig gemacht werden; ein unterbliebenes Zusammenführen beeinträchtigt lediglich die Trefferquote. ## Multi-Account-Erkennung erfolgt innerhalb derselben Organisation und ist segmentiert „Hat dieses Gesicht mehrere Konten bei **uns** eröffnet?“ ist eine andere geschäftliche Frage als organisationsübergreifende Nachweise und wird ausschließlich innerhalb Ihrer eigenen Organisation beantwortet. Legen Sie beim Erstellen einer Sitzung `multi_account_segment` fest, um dieser Suche einen expliziten Bereich zu geben. Zwei Sitzungen in unterschiedlichen Segmenten werden niemals als Duplikate voneinander gewertet. Dadurch können Sie getrennte Bestände für Privat- und Geschäftskonten führen – oder ein Segment pro Unterkunde –, ohne dass eine Person, die berechtigterweise jeweils ein Konto besitzt, wie Kontenmissbrauch aussieht. Wenn Sie den Parameter weglassen, befindet sich jede Sitzung im einzigen Standardbereich, was exakt dem heutigen Verhalten entspricht. Der Abgleich mit Sperrlisten und Positivlisten ignoriert Segmente bewusst: Ein Gesicht auf der Sperrliste ist überall in Ihrer Organisation gesperrt, sodass ein Segment niemals genutzt werden kann, um einer Sperrliste zu entgehen. ## Datenschutz * Gesichter überschreiten niemals die Organisationsgrenze. Der geteilte Betrugsindex kann physisch keines enthalten – die Datenbank weist den Schreibvorgang ab. * Was die Grenze überschreitet, ist ein schlüsselbasierter Einweg-Hash eines exakten Werts (eine Dokumentennummer, ein Gerät, eine IP-Adresse, eine Telefonnummer, eine E-Mail-Adresse), den eine teilnehmende Organisation als Betrug markiert hat. * Bei organisationsübergreifenden Abfragen werden Zählwerte und Kategorien zur Aktualität zurückgegeben. Die beitragende Organisation wird niemals genannt, und kein Rohwert, kein Bild und keine Sitzung verlässt jemals die Organisationsgrenze. * Das Teilen erfolgt auf Gegenseitigkeit und erfordert sowohl den Enterprise-Tarif als auch den Freigabemodus `global`. Eine Organisation, die nichts beiträgt, führt keine Abfragen durch, und eine Organisation unterhalb von Enterprise trägt weder Daten bei noch fragt sie welche ab, unabhängig von ihrem Freigabemodus. * Organisationsübergreifende Informationen speziell zu **Gesichtern** sind standardmäßig deaktiviert und bleiben deaktiviert, bis die Datenschutz-Folgenabschätzung und die rechtliche Prüfung für die biometrische Personen-ID und das Claim-Event-Modell abgeschlossen sind. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.