Detecção de rede de fraude
O módulofraud_network responde uma pergunta só: esta pessoa está ligada a outras contas suas? A ligação é procurada por aparelho, rede, e-mail, telefone, rosto (quando a Detecção de Múltiplas Contas está no mesmo flow) e pela conta que você informa no reference_id. Ele não pede foto nem passo novo ao titular.
O veredito sai em decision, com cinco valores possíveis, e ele depende das classes de evidência, nunca do número de chaves. clean: componente de um titular só, ou uma classe única (a família no mesmo wi-fi cai aqui). linked_weak: duas classes ou mais, nenhuma delas de pessoa, e a decisão não muda (é aqui que cai o escritório de contabilidade). linked: duas classes ou mais com ao menos uma de pessoa, e vai para revisão. ring: o componente alcança um titular já rotulado como fraude confirmada e há aresta de pessoa no caminho, também para revisão. insufficient_keys: havia menos de duas chaves utilizáveis, então não olhamos rede nenhuma, e esse caso não é cobrado. As classes são exatamente três, local (IP, aparelho), contact (e-mail, telefone) e person (rosto, conta), e subject_resolution diz sobre quem o laudo falou: subject (o documento lido), reference (o reference_id que você mandou) ou verification (não havia nem um nem outro).
link_meanings traz, em texto, o que cada vínculo significa e o que ele não prova, e só para os tipos que de fato ligaram. Ele existe porque a leitura errada (“ligado, logo fraudador”) é o falso positivo número um deste módulo, e o operador que abre o webhook não deve precisar desta página aberta do lado. linked_subjects_by_kind responde a outra metade da pergunta, quantos titulares por qual vínculo: é ela que deixa você ler por que a família no mesmo wi-fi não foi acusada. Ela sai também no clean; já linked_references vem vazia em clean e insufficient_keys, de propósito, porque listar contas sem veredito seria entregar vizinhança de rede sem afirmação nenhuma.
Dois campos dão contexto à sua revisão. network_risk é a exposição do titular a fraude confirmada dentro do seu próprio grafo, propagada a partir dos rótulos que você mesmo confirmou (de 1 a 100, decaindo com a distância e com a idade da aresta). sync_burst mede sincronia: quantos titulares distintos passaram pelas mesmas chaves num intervalo curto (subjects inclui o próprio titular, e by_kind só lista tipo em que houve ao menos um outro). A decisão do módulo está em decision, score, passed e outcome. E null nos dois significa não medido, jamais “medido e limpo”: um zero fabricado seria a afirmação errada.
O que não sai, e é o coração do módulo: o valor de nenhuma chave. Nem IP, nem e-mail, nem telefone, nem documento, e nem o hash deles. Sai o tipo (key_kinds) e a classe da evidência. Devolver o hash pareceria inofensivo e não é: ele é determinístico, e dois payloads bastariam para você confirmar que dois titulares compartilham o mesmo e-mail sem nunca ter visto o e-mail.
keys_observed viaja ao lado de key_kinds porque as duas respondem perguntas opostas: não achei ligação por rosto e não havia rosto para olhar (flow sem unique_face) não podem sair iguais. linked_references são os reference_id das contas do seu próprio tenant: sem eles você leria “há ligação” e não conseguiria agir.