Vínculos, antecedentes e processos
Cinco módulos de compliance aprofundam o screening além do titular:pep_relatives (parentes de pessoa exposta politicamente), betting_barred_relatives (vínculo familiar com impedido de apostar, a fase 2 da Lei 14.790/2023, Art. 26), criminal_records_state, lawsuits e scr_bacen (retrato de endividamento no SCR). Todos partem do CPF lido do documento, e exigem Documento, Face Match e Liveness no mesmo flow pela mesma razão do pep_sanctions: nada aqui é consultado a partir de um número digitado. A consulta à fonte é pelo CPF; o nome só entra no betting_barred_relatives, e ainda assim como nome do parente, dentro do nosso motor local de vedação.
Venda pausada hoje, os cinco. Eles aparecem na tabela de preços e no GET /v1/capabilities com preço e status coming_soon, e não podem ser ligados num flow enquanto a credencial do fornecedor não existir na conta. O estado vem do catálogo vivo, e esta página acompanha. O payload abaixo é o contrato que já está implementado e que passa a valer no dia da abertura.
O portão de identidade. A fonte 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 a fonte não é consultada, o módulo sai pending e não é cobrado. No pep_relatives e no betting_barred_relatives, o reason vem identity_not_proven. A aprovação manual da verificação no painel não chama estas fontes: o módulo continua pending.
Outro campo que promete mais do que entrega: nestes módulos matched_by: "document" é derivado de flagged, não é a prova de que o casamento se deu por CPF. Ele diz “houve resultado”, e não “casou pelo documento”. A única exceção é o betting_barred_relatives, onde ele é medido de verdade e distingue document, document_partial e name. E ele nem existe em dois dos cinco: criminal_records_state e scr_bacen não emitem a chave. No lawsuits, document diz que o titular é réu num processo casado pelo CPF, e um dossiê truncado sinaliza com none. Nos demais, trate-a como sinônimo de flagged.
clear_record, no criminal_records_state, tem três estados e não dois: false quando há ocorrência, true só quando a fonte afirma que nada consta, e null quando não houve ocorrência e a fonte também não afirmou nada. Campo ausente na resposta nunca vira atestado nosso. E scr_bacen.flagged é sempre false, por construção: o módulo é informacional, o produto dele é o retrato de endividamento, e não existe caminho no código que o marque. Não escreva alerta em cima dessa flag.
O betting_barred_relatives é o mais denso dos cinco, porque ele precisa provar duas coberturas ao mesmo tempo: de onde veio o grafo familiar (graph_coverage, hoje sempre "pep_relatives", ou seja a fonte de parentesco de PEP e mais nada) e quais bases de vedação sustentaram a triagem de cada parente (coverage e dataset_versions, as mesmas do módulo Impedidos de apostar). E ele conta os parentes de forma auditável: relatives_total é quanto a fonte devolveu, relatives_screened é quanto o motor de fato respondeu, e relatives_unscreened agrupa por motivo quem ficou de fora. Essa lista tem vocabulário fechado de seis valores: degree_unknown, degree_out_of_scope, document_missing, name_missing, screening_indeterminate e over_cap. Repare que relatives_total menos relatives_screened não é o tamanho dessa lista: ela é agrupada, e cada item traz o próprio count.
pep_sanctions: um resultado é candidato, vai para review com a evidência no webhook, e a sua análise decide. E vale a mesma minimização: o que sai do betting_barred_relatives sobre o parente é contagem e restrição minimizada, nunca nome, CPF ou datas de terceiro. O nome e o documento do parente entram na consulta e morrem lá.