Übersicht
Die Geräte- und IP-Analyse profiliert jede Sitzung anhand von IP-Geolokalisierung, Geräte-Fingerprint, Browser/Betriebssystem und Netzwerktyp. Geolokalisierung, Anreicherung um Netzwerkrisiken, Geräteabgleich und Integritätsprüfungen von Remote-Geräten laufen asynchron ab, während der Benutzer die Verifizierung durchführt. Geräte- und IP-Beobachtungen bleiben verfügbar, während die Analyse noch aussteht; Geolokalisierungsfelder können leer sein, bis die Ergebnisse eintreffen oder wenn die Adresse nicht öffentlich ist. Wenn Ihr Workflow diese Prüfungen nutzt, um das Ergebnis zu bestimmen oder einen nachfolgenden Schritt auszuwählen, bleibt die Sitzung im StatusIn Progress, bis die erforderlichen Ergebnisse vorliegen.
Wenn eine erforderliche Analyse nach begrenzten Wiederholungsversuchen weiterhin nicht verfügbar ist, wechselt die Sitzung für eine manuelle Entscheidung zu In Review.
Fehler bei optionalen Anreicherungen verhindern den Abschluss nicht, und manuelle Entscheidungen bleiben maßgeblich.
Sie liefert:
- Einen IP-Geolokalisierungs-Block (Land, Bundesland/Region, Stadt, Breitengrad/Längengrad, Zeitzone), der aus der öffentlichen IP abgeleitet wird.
- Netzwerk-Risiko-Flags —
is_vpn_or_torundis_data_center—, um Verschleierungsversuche zu erkennen (VPN, Tor-Exit-Nodes, Hosting-Provider, Anonymisierungsdienste). - Dokumentübergreifende Distanzberechnungen — Luftlinie in km zwischen dem IP-Standort, dem Standort des Ausweisdokuments und dem Standort des Adressnachweis-Dokuments.
- Sitzungsübergreifende Übereinstimmungen — wenn dieselbe IP-Adresse oder Geräteidentität über Sitzungen verschiedener Benutzer hinweg auftritt (gruppiert nach
vendor_data). - Geräte-Fingerprint-Wiederherstellung — ein Wiederherstellungssignal mit hohem Konfidenzwert, das Sitzungen selbst dann verknüpft, wenn der Benutzer den Speicher leert, in den Inkognito-Modus wechselt oder die App neu installiert.

Wo es in API-Antworten erscheint
Der Decision-Endpoint gibt die Geräte- und IP-Analyse als Arrayip_analyses[] in GET /v3/session/{sessionId}/decision/ zurück. Die Einträge sind deduplizierte Location-Beobachtungen mit dem Schlüssel (node_id, ip_address, device_fingerprint) — ein einzelner Knoten kann mehrere Einträge liefern, wenn sich die IP-Adresse oder das Gerät des Benutzers während der Sitzung ändert.
Schema
Siehe Geräte- und IP-Analyse in der Datenmodell-Referenz für das kanonische Schema.Match-Semantik
match_source gibt an, wie die Übereinstimmung ermittelt wurde, und confidence bewertet, wie wahrscheinlich es ist, dass sie falsch ist (confidence = 1 - P(false positive)):
Wiederherstellungskandidaten mit niedrigerem Konfidenzwert werden ausschließlich als Risikowarnungen ausgegeben — niemals in
matches[]. IP-Matches und Geräte-Matches sind jeweils auf 5 begrenzt, sodass das Array maximal 10 Einträge enthält.
Statuswerte
Statuswerte sindFeatureStatusChoices-Werte auf Funktionsebene. Jede ausgelöste Warnung wird der Aktion zugeordnet, die auf dem Workflow-Knoten für sie konfiguriert ist; die stärkste Aktion setzt sich durch.
Benutzerdefinierte Statusregeln, die auf dem IP-Analyse-Knoten konfiguriert sind, können den resultierenden Status weiter anpassen.
VPN-, Proxy- und Tor-Erkennung
is_vpn_or_tor und is_data_center sind unabhängige boolesche Flags, die für jede Sitzung zurückgegeben werden. Wenn is_vpn_or_tor auf true steht, gibt Didit zusätzlich die Warnung PRIVATE_NETWORK_DETECTED aus, damit Ihr Team per Workflow-Konfiguration darauf reagieren kann. Reiner Rechenzentrums-Traffic (ohne VPN/Tor) setzt is_data_center=true, löst aber keine automatische Warnung aus — nutzen Sie dies als zusätzliches Signal in Ihrem eigenen Scoring.
Beispiele
Approved
Declined — IP-Sperrlisten-Treffer + VPN + doppeltes Gerät
Verwandte Themen
- Warnungen der Geräte- und IP-Analyse — jeder Warncode, den die IP-Analyse ausgeben kann
- Übersicht zur Geräte- und IP-Analyse — was die einzelnen Blöcke erfassen
- Datenmodelle — IP-Analyse — kanonisches Schema
- Webhooks —
status.updatedüberträgt dieselbe IP-Analyse-Payload