Pular para o conteúdo principal

PEP e listas restritivas

O módulo pep_sanctions confere o CPF e o nome lidos do documento contra listas oficiais de pessoas expostas politicamente e de sanções. Ele exige Verificação de Identidade + Face Match + Liveness no mesmo flow: o dado consultado vem do documento apresentado por quem está vivo na frente da câmera, nunca de um CPF digitado. O widget não ganha nenhum passo novo.
Este módulo nunca reprova sozinho. Um resultado positivo é candidato, não veredito: nomes brasileiros repetem muito (dentro da própria lista de PEP há um nome com 13 CPFs diferentes). Por isso um sinal leva a verificação para review, com a evidência (lista, referência da entrada, score e motivo) no webhook, para a sua análise decidir. Nunca a denied automático.
Cobertura desta fase, e nada além dela: PEP federal e expulsões da administração federal (CGU: PEP e CEAF), empresas e pessoas inidôneas ou punidas (CGU: CEIS e CNEP), empresas declaradas inidôneas pelo TCU para licitar (Lei 8.443/1992, art. 46, pelo CNPJ) e as listas internacionais de sanções da ONU (obrigatória no Brasil pela Lei 13.810/2019), do OFAC (Tesouro dos EUA) e do Reino Unido (UK Sanctions List, do FCDO). Não estão incluídos, e não os anunciamos: a lista de sanções da União Europeia (a fonte exige uma credencial que ainda não temos, então ela nasce desabilitada e sai marcada como tal em dataset_versions), parentes e associados de PEP, PEP estadual/municipal, PEP estrangeiro, improbidade do CNJ e adverse media. Cada resposta carimba a idade e o tamanho de cada lista em dataset_versions (ingested_at, age_hours e record_count). Se uma lista que entraria na resposta estiver vencida, o módulo devolve pending com dataset_stale e a verificação vai para review: nós não afirmamos “nada consta” sobre uma base que não conseguimos atualizar, e esse caso não é cobrado. Sem CPF legível no documento o resultado também é pending. A mesma regra vale quando a lista não foi consultada, e não só quando ela envelheceu. A resposta sai pending com no_coverage quando nenhuma lista do módulo está disponível, e com critical_source_disabled quando uma lista que a resposta não pode dispensar está fora do ar. Os dois casos vão para review e não são cobrados, pelo mesmo motivo do dataset_stale: um veredito de “nada consta” só vale se alguma lista tiver sido de fato consultada. E quando uma lista específica não entrou na consulta, ela aparece em aggregates.by_list com null em vez de sumir do objeto, para que “não foi olhada” nunca se pareça com “olhada e sem resultado” no seu código. O campo coverage resume isso: band sai complete quando todas as listas foram consultadas e partial quando alguma estava desligada, com os ids em unavailable_sources. Com pending nenhuma lista chegou a ser consultada, e coverage sai null. Esse aviso convive com approved: não baixa a nota, não pesa contra a pessoa e só chega a você, nunca à tela de quem se verifica. A lista 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 lista não é consultada e o módulo não é cobrado. Com pending, os campos pep e flagged não afirmam nada: leia o reason. Quando a verificação é aprovada manualmente no painel, a lista roda na aprovação e o módulo é cobrado pelo preço de sempre. Se a resposta pedir análise (hit, política, lista vencida), a aprovação não aprova: a verificação vai para review com o resultado, o webhook sai com esse status, e quem aprova confere e aprova de novo. A política “aceito clientes que são PEP?” é sua: por padrão ser PEP não reprova (sai como sinalização, que é o que a regulação pede: diligência reforçada, não recusa). Você pode desligá-la no flow, ou por sessão ao criar com sk_ mandando { "policy": { "allow_pep": false } }. Só o vínculo atual reprova; vínculo passado nunca. Atual inclui a carência: quem deixou a função há até cinco anos segue PEP pela norma (Circular BCB 3.978/2020, art. 27) e segue a mesma política de quem está em exercício. Chave de política desconhecida é 400 unknown_policy_key. O resumo pronto de PEP e sanção. Você não precisa refazer a conta em cada integração. O bloco pep_status diz se há função pública em exercício (current) e se a pessoa deixou a função no último ano, nos últimos três ou nos últimos cinco anos (last_1y, last_3y, last_5y), contados do fim do exercício. roles traz a descrição da função como a fonte oficial publica, e só quando o casamento foi pelo documento e forte: semelhança de nome nunca traz cargo. Em aggregates, is_pep, has_sanctions_br (lista publicada por órgão brasileiro) e has_sanctions_intl (lista publicada por organismo ou governo estrangeiro) resumem os hits, worst_severity dá a pior zona entre eles (no_hit, weak ou strong), e sanction_windows e pep_windows separam as janelas por tipo de lista. windows continua no payload como a soma das duas, marcado como depreciado: prefira as separadas. Programe contra source, não contra list. Em cada hit, source é o identificador estável da lista (cgu_pep, cgu_ceis, ofac_sdn) e não muda; list é o rótulo legível e pode mudar de texto. Na lista de PEP, left_at é o fim do período em que a pessoa é considerada politicamente exposta, e exercise_end é o fim do exercício da função; pep_in_grace_period marca quem já deixou a função e ainda está dentro dos cinco anos. Cota diária do módulo. Cada organização tem uma cota diária de sessões novas com este módulo em produção. Passando dela, a criação de sessão responde 429 module_quota_reached com Retry-After até a virada do dia (meia-noite UTC). A renovação de uma sessão não conta de novo. Se o seu volume pede mais, fale com a gente: o ajuste é por organização. A lista de hits tem teto, e o corte vem declarado. Nome comum produz muito candidato, e um payload sem limite viraria incidente de custo e de leitura do seu lado. Passando do teto, hits sai cortado e hits_truncated vem true. Duas garantias tornam o corte seguro de programar: os aggregates são calculados sobre o conjunto completo (a contagem continua verdadeira mesmo com a lista cortada), e a ordem é determinística antes do corte, com hit forte na frente do fraco e casamento por documento na frente do casamento por nome. O que fica de fora é sempre a cauda mais fraca, nunca a evidência que decide.
Em sandbox nada é consultado: o desfecho vem do sufixo do documento, como no resto do ambiente de testes. 66 devolve PEP atual com a política recusando, 77 PEP atual com a política permitindo, 44 PEP que deixou a função há dois anos e segue na carência, 88 sanção por documento no CEIS e 99 um homônimo na OFAC com semelhança 0,82. O pep_status e os agregados do sandbox saem da mesma conta da produção. 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.