> ## 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. # Reivindicações de identidade entre organizações > O Didit reporta evidências de identidade de outras organizações sem acusar fraude: resultados separados e compartilhamento desativado por padrão. ## A regra que motiva esta página Um rosto é uma identidade estável. Ele não é um rótulo de fraude, e a Didit não o trata como tal. Essa distinção importa sobretudo no caso que a motivou: uma pessoa real que deu seu consentimento, tenta se verificar com uma identidade que não é a dela. A tentativa precisa ser barrada. Mas, depois disso, três pessoas diferentes precisam ser deixadas em paz: essa mesma pessoa quando, mais tarde, se verificar com a própria identidade válida; a pessoa cuja identidade foi usada indevidamente (que é a vítima, não a infratora); e qualquer pessoa cujo rosto seja apenas parecido. Por isso, o significado de fraude fica associado a uma **alegação de identidade**, que é um evento, e nunca à pessoa que a fez nem à identidade que ela reivindicou. ## Quatro dimensões, quatro campos Uma decisão nunca é reduzida a uma única palavra escolhida para você. Cada uma destas dimensões é informada de forma independente, e você decide o que o seu produto faz com a combinação: | Dimensão | O que ela responde | Onde aparece | | - | - | - | | **Integridade da captura** | A captura foi feita ao vivo, sem modificações e com uma câmera real? | Avisos de prova de vida (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) | | **Correspondência de identidade** | A pessoa correspondeu à identidade que declarou ser, com base em uma referência confiável? | Avisos de correspondência facial e de rosto duplicado na sessão | | **Evidências de comportamento e de rede** | Outras organizações registraram declarações de identidade dessa mesma pessoa com divergências? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` | | **Decisão final** | Qual foi o status resultante da sessão | `status` no payload da decisão | Uma prova de vida reprovada, uma divergência de identidade e um padrão na rede são três afirmações diferentes sobre três coisas diferentes. Lê-las como um único número é o que transforma uma foto ruim em uma acusação. ### A correspondência de identidade exige uma referência confiável `match` e `mismatch` só são gerados quando existe algo confiável com que comparar um rosto: o retrato de um documento oficial ou uma identidade já fortemente vinculada a esse rosto. Um endereço de e-mail ou um número de telefone sem vínculo forte prévio não oferece nada com que comparar um rosto. Nesse caso, a resposta é **sem referência**, nunca `mismatch`, e nunca um `match` inferido apenas pelo histórico do rosto. ## O que as evidências entre organizações podem e não podem dizer Quando a sua organização está no plano Enterprise e o modo de compartilhamento dela é `global`, uma sessão pode gerar `CROSS_ORG_IDENTITY_CLAIM_PATTERN`. Abaixo do Enterprise, ou com o compartilhamento definido como `private` ou `off`, a verificação entre organizações não é executada. As evidências de reivindicação só vêm de outras organizações que também estão no plano Enterprise e compartilham globalmente. O aviso significa: > Outras organizações participantes registraram eventos de reivindicação de identidade dessa mesma pessoa em > que a identidade reivindicada não correspondeu às evidências dessas sessões. Ele **não** significa que a pessoa é fraudulenta, e nenhuma resposta da Didit jamais dirá isso. Três garantias sustentam isso: * **Ele é suprimido quando a sua própria verificação foi aprovada.** Se a correspondência de identidade desta sessão for `match`, o aviso não é gerado. Uma pessoa que se verifica com sucesso em relação à sua própria referência confiável está verificada: qualquer coisa em que ela possa ter se envolvido antes diz respeito àquelas reivindicações, não a esta. * **Ele não pode resultar em recusa.** A ação é Revisão ou Nenhuma ação. Definir Recusar em `cross_org_identity_claim_pattern_action` é rebaixado para Revisão, porque o histórico de uma pessoa pode abrir uma investigação sobre a reivindicação atual, mas nunca pode rejeitá-la. * **Ele é apenas agregado.** O payload informa quantas organizações, quantas reivindicações divergentes, quantas identidades distintas foram reivindicadas e há quanto tempo ocorreram essas reivindicações, mas nunca quem são essas organizações, nunca as sessões delas, nunca nenhum dos dados delas. `CROSS_ORG_FRAUD_FACE` é a versão descontinuada deste aviso e não é mais gerado. Ele é mantido como valor para que os registros e as regras existentes continuem sendo resolvidos; as ocorrências históricas são registros, não julgamentos sobre uma pessoa. ## Consulta apenas pelo rosto: um id de pessoa, não um veredito Reconhecer novamente o mesmo ser humano é uma capacidade separada de decidir qualquer coisa sobre ele. Uma consulta apenas pelo rosto retorna um **id de pessoa opaco e estável** para capturas repetidas, com alta confiança, do mesmo rosto, e nada mais. * O id é um identificador aleatório. Ele não é derivado de um rosto, de um embedding, de uma sessão, de uma organização nem de uma referência de cliente, portanto não revela nada além de "esta captura já foi vista antes". * Ele não carrega nenhum estado de fraude. Não há nenhum campo nele que possa armazenar um estado de fraude. * Uma correspondência de baixa confiança ou apenas possível nunca mescla duas pessoas. A mesclagem excessiva funde dois seres humanos em uma única identidade e não pode ser desfeita a partir dos dados; a mesclagem insuficiente reduz apenas o recall. ## A detecção de múltiplas contas ocorre na mesma organização e é segmentada "Este rosto abriu várias contas **conosco**?" é uma pergunta de produto diferente das evidências entre organizações, e ela é respondida apenas dentro da sua própria organização. Defina `multi_account_segment` na criação da sessão para dar a essa busca um domínio explícito. Duas sessões em segmentos diferentes nunca são duplicatas entre si, e é isso que permite manter bases separadas de contas pessoais e empresariais, ou um segmento por subcliente, sem que uma pessoa que legitimamente tem uma conta em cada uma pareça estar criando contas em massa. Se você omitir esse parâmetro, todas as sessões ficam no único domínio padrão, que é exatamente o comportamento atual. A correspondência com a lista de bloqueio e a lista de permissões ignora os segmentos de propósito: um rosto na lista de bloqueio fica bloqueado em toda a sua organização, então um segmento nunca pode ser usado para escapar de um bloqueio. ## Privacidade * Rostos nunca atravessam a fronteira da organização. O índice compartilhado de fraudes fisicamente não tem como armazenar sequer um: o banco de dados rejeita a gravação. * O que atravessa a fronteira é um hash unidirecional com chave de um valor exato (um número de documento, um dispositivo, um endereço IP, um telefone, um e-mail) que uma organização participante marcou como fraude. * As consultas entre organizações respondem com contagens e faixas de recência. A organização que contribuiu nunca é identificada, e nenhum valor bruto, imagem ou sessão sai dela. * O compartilhamento é recíproco e exige tanto o plano Enterprise quanto o modo de compartilhamento `global`. Uma organização que não contribui não consulta, e uma organização em um plano inferior ao Enterprise não contribui nem consulta, qualquer que seja o seu modo de compartilhamento. * A inteligência de **facial** entre organizações, especificamente, fica desativada por padrão e permanece desativada até que a avaliação de impacto sobre a proteção de dados e a revisão jurídica do identificador biométrico de pessoa e do modelo de eventos de declaração estejam concluídas. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.