> ## 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. # Alegações de identidade entre organizações > A Didit reporta dados de identidade entre organizações sem rotular fraudes: dimensões separadas e partilha desativada por omissão. ## A regra que motiva esta página Um rosto é uma identidade estável. Não é um rótulo de fraude, e a Didit não o tratará como tal. Essa distinção é fundamental no caso que a motivou: uma pessoa real e que dá o seu consentimento tenta verificar-se sob uma identidade que não lhe pertence. A tentativa tem de ser travada. Mas três pessoas distintas têm de ser deixadas em paz a partir daí: essa mesma pessoa quando mais tarde se verificar com a sua própria identidade válida, a pessoa cuja identidade foi usurpada (que é a vítima, e não o infrator), e qualquer pessoa cujo rosto seja meramente semelhante. Por isso, o significado de fraude é associado a uma **alegação de identidade**, que é um evento, e nunca à pessoa que o efetuou ou à identidade por ela alegada. ## Quatro dimensões, quatro campos Uma decisão nunca é reduzida a uma única palavra escolhida em seu nome. Cada um destes pontos é comunicado de forma independente, e cabe-lhe a si decidir o que o seu produto fará com essa combinação: | Dimensão | A que responde | Onde aparece | | - | - | - | | **Integridade da entrada** | A captura foi em direto, não modificada e proveniente de uma câmara real? | Avisos de prova de vida (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) | | **Correspondência de identidade** | A pessoa correspondeu à identidade alegada, face a uma referência fidedigna? | Avisos de correspondência facial e de rostos duplicados na sessão | | **Evidência comportamental e de rede** | Outras organizações registaram eventos de alegação para esta mesma pessoa que não coincidiram? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` | | **Decisão final** | Em que estado ficou a sessão | `status` no payload de decisão | Uma verificação de prova de vida falhada, uma não correspondência de identidade e um padrão de rede são três declarações diferentes sobre três coisas distintas. Interpretá-las como um único número é a forma como uma fotografia de má qualidade se transforma numa acusação. ### A correspondência de identidade necessita de uma referência fidedigna `match` e `mismatch` só são gerados quando existe algo fidedigno com o qual comparar um rosto: o retrato de um documento oficial emitido pelo governo, ou uma identidade que já esteja fortemente vinculada a esse rosto. Um endereço de e-mail ou um número de telefone sem uma vinculação prévia sólida não fornecem qualquer elemento comparativo para o rosto. Nesse caso, a resposta é **sem referência**, nunca `mismatch`, e nunca um `match` inferido apenas a partir do histórico facial. ## O que a evidência interorganizações pode e não pode afirmar Quando a sua organização se encontra no plano Enterprise e o respetivo modo de partilha está definido como `global`, uma sessão pode acionar `CROSS_ORG_IDENTITY_CLAIM_PATTERN`. Nos níveis inferiores ao Enterprise, ou com a partilha definida como `private` ou `off`, a verificação interorganizações não é executada. A evidência de alegações provém apenas de outras organizações que também estejam no plano Enterprise e partilhem globalmente. O aviso significa: > Outras organizações participantes registaram eventos de alegação de identidade para esta mesma pessoa nos > quais a identidade alegada não correspondeu à evidência recolhida nessas sessões. Isto **não** significa que a pessoa seja fraudulenta, e nenhuma resposta da Didit alguma vez afirmará isso. Três garantias sustentam este princípio: * **É suprimido quando a sua própria verificação foi bem-sucedida.** Se a correspondência de identidade da própria sessão for `match`, o aviso nem sequer é acionado. Uma pessoa que se verifica com sucesso face à sua própria referência fidedigna está verificada: qualquer situação em que tenha estado envolvida anteriormente pertence a essas alegações, não a esta. * **Não pode recusar.** A ação é Revisão ou Nenhuma ação. Definir Recusar em `cross_org_identity_claim_pattern_action` é despromovido para Revisão, porque o histórico de uma pessoa pode justificar a abertura de uma investigação sobre a alegação atual, mas nunca pode rejeitá-la. * **É estritamente agregado.** O payload indica quantas organizações, quantas alegações sem correspondência, quantas identidades distintas foram alegadas e quão recentes foram — nunca quem são, nunca as suas sessões, nem quaisquer dos seus dados. `CROSS_ORG_FRAUD_FACE` é a versão descontinuada deste aviso e já não é acionada. Mantém-se como valor para que os registos e regras existentes continuem a resolver; ocorrências históricas são registos, e não julgamentos sobre uma pessoa. ## Pesquisa apenas facial: um ID de pessoa, não um veredicto Reconhecer novamente o mesmo ser humano é uma capacidade distinta de decidir o que quer que seja sobre ele. Uma pesquisa apenas facial devolve um **ID de pessoa opaco e estável** para capturas repetidas com elevada pontuação de confiança do mesmo rosto, e nada mais. * O ID é um identificador aleatório. Não é derivado de um rosto, de um embedding, de uma sessão, de uma organização ou de uma referência de cliente, pelo que não revela nada além de "esta captura já foi vista anteriormente". * Não transporta qualquer estado de fraude. Não existe qualquer campo que o pudesse fazer. * Uma correspondência possível ou com baixa pontuação de confiança nunca funde duas pessoas. Uma fusão excessiva associa dois seres humanos numa única identidade e não pode ser desfeita a partir dos dados; uma fusão insuficiente afeta apenas a cobertura. ## A deteção de várias contas é feita na mesma organização e segmentada "Será que este rosto abriu várias contas **connosco**?" é uma questão de produto diferente da evidência interorganizações, sendo respondida exclusivamente no âmbito da sua própria organização. Defina `multi_account_segment` na criação da sessão para atribuir a essa pesquisa um domínio explícito. Duas sessões em segmentos diferentes nunca são consideradas duplicados uma da outra, o que lhe permite gerir bases de contas pessoais e empresariais separadas — ou um segmento por subcliente — sem que uma pessoa que detenha legitimamente uma conta em cada uma pareça estar a criar contas em massa. Se for omitido, todas as sessões ficam integradas no domínio padrão único, que é exatamente o comportamento atual. A correspondência de listas de bloqueio e de listas de permissões ignora deliberadamente os segmentos: um rosto que esteja na lista de bloqueio está bloqueado em toda a sua organização, garantindo que um segmento nunca possa ser utilizado para contornar essa restrição. ## Privacidade * Os rostos nunca ultrapassam os limites da organização. O índice de fraude partilhado é fisicamente incapaz de conter um rosto — a base de dados rejeita a escrita. * O que ultrapassa os limites é um hash com chave unidirecional de um valor exato (um número de documento, um dispositivo, um IP, um telefone, um e-mail) que uma organização participante classificou como fraude. * As leituras entre organizações respondem com contagens e intervalos de recência. A organização contribuinte nunca é identificada, e nenhum valor bruto, imagem ou sessão sai alguma vez. * A partilha é recíproca e requer tanto o plano Enterprise como o modo de partilha `global`. Uma organização que não contribui não consulta, e uma organização abaixo de Enterprise nem contribui nem consulta, qualquer que seja o seu modo de partilha. * Especificamente, a inteligência **facial** entre organizações está desativada por predefinição e permanece desativada até que a avaliação de impacto sobre a proteção de dados e a revisão jurídica relativas ao identificador biométrico de pessoa e ao modelo de eventos de alegações estejam concluídas. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.