> ## 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. # Rivendicazioni d'identità tra organizzazioni > Come Didit riporta prove d'identità da altre organizzazioni senza etichettare nessuno come frodatore. Condivisione disattivata di default. ## La regola per cui esiste questa pagina Un volto è un'identità stabile. Non è un'etichetta di frode, e Didit non lo tratterà come tale. Questa distinzione conta soprattutto nel caso che l'ha motivata: una persona reale, che ha acconsentito, tenta di verificarsi con un'identità che non le appartiene. Il tentativo deve essere bloccato. Ma tre persone distinte devono essere lasciate in pace successivamente: quella stessa persona quando in seguito si verifica con la propria identità valida, la persona la cui identità è stata usata (che è la vittima, non l'autore), e chiunque abbia un volto che semplicemente gli assomiglia. Il significato di frode viene quindi attribuito a una **rivendicazione di identità**, che è un evento, mai alla persona che l'ha effettuata né all'identità che ha dichiarato. ## Quattro dimensioni, quattro campi Una decisione non viene mai ridotta a una sola parola scelta al posto tuo. Ciascuna di queste dimensioni viene riportata in modo indipendente, e sei tu a decidere come il tuo prodotto deve gestire la loro combinazione: | Dimensione | A cosa risponde | Dove compare | | - | - | - | | **Integrità dell'input** | L'acquisizione era dal vivo, non modificata e proveniva da una fotocamera reale? | Avvisi di rilevamento della vitalità (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) | | **Corrispondenza di identità** | La persona corrispondeva all'identità dichiarata, rispetto a un riferimento affidabile? | Avvisi di confronto facciale e di volto duplicato sulla sessione | | **Comportamento e prove di rete** | Altre organizzazioni hanno registrato eventi di rivendicazione per questa stessa persona che non corrispondevano? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` | | **Decisione finale** | Lo stato assunto dalla sessione | `status` nel payload della decisione | Un controllo del rilevamento della vitalità non superato, una mancata corrispondenza di identità e uno schema di rete sono tre affermazioni diverse su tre cose diverse. Leggerli come un unico numero è il modo in cui una foto scadente diventa un'accusa. ### La corrispondenza di identità richiede un riferimento affidabile `match` e `mismatch` vengono prodotti solo quando c'è qualcosa di affidabile con cui confrontare un volto: il ritratto su un documento d'identità rilasciato dal governo, oppure un'identità già fortemente associata a quel volto. Un indirizzo email o un numero di telefono senza un precedente legame forte non offrono nulla con cui confrontare un volto. In quel caso la risposta è **nessun riferimento**, mai `mismatch`, e mai un `match` dedotto dalla sola storia del volto. ## Cosa può e cosa non può dire la prova tra organizzazioni Quando la tua organizzazione è nel piano Enterprise e la sua modalità di condivisione è `global`, una sessione può far scattare `CROSS_ORG_IDENTITY_CLAIM_PATTERN`. Sotto il piano Enterprise, oppure con la condivisione impostata su `private` o `off`, il controllo tra organizzazioni non viene eseguito. Le prove di rivendicazione provengono solo da altre organizzazioni che sono anch'esse nel piano Enterprise e condividono globalmente. L'avviso significa: > Altre organizzazioni partecipanti hanno registrato eventi di rivendicazione di identità per questa stessa persona > in cui l'identità dichiarata non corrispondeva alle prove presenti in quelle sessioni. **Non** significa che la persona è fraudolenta, e nessuna risposta di Didit lo dirà mai. Tre garanzie lo confermano: * **Viene soppresso quando il tuo controllo ha avuto esito positivo.** Se la corrispondenza di identità di questa sessione è `match`, l'avviso non viene affatto generato. Una persona che si verifica con successo rispetto al proprio riferimento affidabile è verificata: qualsiasi cosa possa aver riguardato in precedenza appartiene a quelle rivendicazioni, non a questa. * **Non può portare a un rifiuto.** L'azione è Revisione o Nessuna azione. Impostare Rifiuta su `cross_org_identity_claim_pattern_action` viene declassato a Revisione, perché la storia di una persona può aprire un'indagine sulla rivendicazione attuale, ma non può mai respingerla. * **È solo aggregato.** Il payload riporta quante organizzazioni, quante rivendicazioni non corrispondenti, quante identità distinte sono state dichiarate e quanto sono recenti le rivendicazioni, mai chi sono, mai le loro sessioni, mai alcun loro dato. `CROSS_ORG_FRAUD_FACE` è la versione ritirata di questo avviso e non viene più generato. Viene mantenuto come valore affinché i log e le regole esistenti continuino a essere risolti; le occorrenze storiche sono registrazioni, non giudizi su una persona. ## Ricerca basata solo sul volto: un ID persona, non un verdetto Riconoscere di nuovo lo stesso essere umano è una capacità distinta dal decidere qualsiasi cosa su di lui. Una ricerca basata solo sul volto restituisce un **ID persona opaco e stabile** per acquisizioni ripetute ad alta affidabilità dello stesso volto, e nient'altro. * L'ID è un identificatore casuale. Non deriva da un volto, da un embedding facciale, da una sessione, da un'organizzazione o da un riferimento del cliente, quindi non rivela nulla oltre a "questa acquisizione è già stata vista". * Non porta alcuno stato di frode. Non esiste alcun campo al suo interno che potrebbe contenerlo. * Una corrispondenza a bassa affidabilità o una possibile corrispondenza non unisce mai due persone. Un'eccessiva fusione unisce due esseri umani in un'unica identità e non può essere annullata a partire dai dati; la mancata unione comporta solo una perdita di capacità di rilevamento. ## Il rilevamento di account multipli è interno all'organizzazione e segmentato "Questo volto ha aperto più account presso **di noi**?" è una domanda di prodotto diversa dalle prove tra organizzazioni, e a questa si risponde solo all'interno della tua organizzazione. Imposta `multi_account_segment` alla creazione della sessione per dare a quella ricerca un ambito esplicito. Due sessioni in segmenti diversi non sono mai duplicati l'una dell'altra, ed è ciò che permette di gestire basi di account separate per persone fisiche e aziende, oppure un segmento per ogni sub-cliente, senza che una persona che legittimamente detiene un account in ciascuno appaia come un caso di apertura fraudolenta di più account. Se lo ometti, ogni sessione si trova nell'unico ambito predefinito, che è esattamente il comportamento attuale. La corrispondenza con le blocklist e le allowlist ignora deliberatamente i segmenti: un volto in blocklist è in blocklist in tutta la tua organizzazione, quindi un segmento non può mai essere usato per sfuggire alla blocklist. ## Privacy * I volti non attraversano mai il confine dell'organizzazione. L'indice condiviso antifrode non può fisicamente contenerne uno: il database rifiuta la scrittura. * Ciò che attraversa il confine è un hash con chiave unidirezionale di un valore esatto (un numero di documento, un dispositivo, un indirizzo, un numero di telefono, un'email) che un'organizzazione partecipante ha etichettato come frode. * Le letture tra organizzazioni rispondono con conteggi e fasce di recenza. L'organizzazione che ha contribuito non viene mai nominata, e nessun valore grezzo, immagine o sessione attraversa mai il confine. * La condivisione è reciproca e richiede sia il piano Enterprise sia la modalità di condivisione `global`. Un'organizzazione che non contribuisce non esegue interrogazioni, e un'organizzazione sotto Enterprise non contribuisce né esegue interrogazioni, qualunque sia la sua modalità di condivisione. * L'intelligence **facciale** tra organizzazioni è disattivata per impostazione predefinita e resta disattivata finché non sono completate la valutazione d'impatto sulla protezione dei dati e la revisione legale per l'identificativo biometrico della persona e per il modello degli eventi di dichiarazione. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.