Pular para o conteúdo principal

Mídia adversa

O módulo adverse_media confere o nome lido do documento contra um corpus aberto de notícias (negative news) mantido e atualizado por nós, construído sobre o GDELT Project (dados do Global Knowledge Graph, uso comercial livre, com atribuição). Ele exige Verificação de Identidade + Face Match + Liveness no mesmo flow: o nome consultado vem do documento apresentado por quem está vivo na frente da câmera, nunca de um nome digitado. O widget não ganha nenhum passo novo.
Este módulo nunca reprova sozinho. Notícia não publica CPF, então todo casamento é por nome, e homônimo é o caso comum. Um hit forte leva a verificação para review com a evidência no webhook (fonte, data e link), para a sua análise humana decidir. Nunca a denied automático: uma coincidência de nome não pode destruir o cadastro de um inocente.
O grau de confiança do casamento vem sempre declarado. Cada hit carrega name_match (strong ou possible) e a similarity de 0 a 100; a resposta agrega o grau mais forte no topo. Um hit forte vem com a evidência completa: a fonte, a data de publicação e o link da notícia, que é o que o seu revisor abre para julgar. Um possível homônimo (zona cinzenta) apenas sinaliza: sai o grau, a similaridade e uma referência opaca, sem link, sem veículo e sem data, porque provável terceiro não ganha dossiê. Divergência de data de nascimento, quando existe nos dois lados, rebaixa o grau e fica marcada em birth_date_mismatch, nunca esconde o hit. A lista de hits tem teto de 20, e o corte vem declarado. Homônimo comum produz dezenas de notícias, e um payload sem limite viraria incidente de custo e de leitura do seu lado. Passando de 20, hits sai cortado e hits_truncated vem true. O que continua verdadeiro no corte: hits_total declara o número real de hits, aggregates é calculado sobre o conjunto completo, e a ordenação é determinística antes do corte (hit forte na frente do possível, depois maior similaridade). Sem essa ordem, um homônimo com 50 hits fracos empurraria para fora da lista justamente o único hit forte, que é o que o seu revisor precisa ver primeiro. Cada resposta carimba a fonte que a sustentou em coverage e a idade da base em dataset_versions. Se a base estiver vencida, ou ainda sem carga, o módulo devolve pending com dataset_stale e a verificação vai para review: o resultado é indeterminado, nós não afirmamos “nada consta” sobre base que não conseguimos atualizar, e esse caso não é cobrado. A base só é consultada quando a verificação comprova que a pessoa presente é a dona do documento: Face Match, Liveness e leitura do documento aprovados, sem indício de ataque. Sem essa prova o módulo sai pending com identity_not_proven, a base não é consultada e o módulo não é cobrado. Com pending, os campos has_adverse_media e flagged não afirmam nada: leia o reason. Quando a verificação é aprovada manualmente no painel, a consulta roda na aprovação e o módulo é cobrado pelo preço de sempre. Se a resposta pedir análise (hit forte, base vencida), a aprovação não aprova: a verificação vai para review com o resultado, e quem aprova confere e aprova de novo.
Em sandbox nada é consultado: o desfecho vem do sufixo do documento. 02 devolve um hit forte com a evidência completa, 33 um possível homônimo que aprova com sinalização e 01 o caminho de base vencida (pendente, indeterminado, não cobrado). O portão de identidade também vale no sandbox: com um desses sufixos e o Face Match, a Liveness ou a leitura do documento reprovados, o módulo sai pending com identity_not_proven. Flows com este módulo não permitem renovação de sessão pelo widget: a renovação é sempre pelo seu servidor.