A maior parte das mesas de compliance que falamos coloca PEP e listas restritivas como “já resolvido”. Pergunte um pouco mais a fundo e você descobre o oposto: o stack é frágil, a base é desatualizada, o matching tem falso-positivo grosseiro e a reverificação não existe. É a etapa onde o regulador olha primeiro, e onde mais multas saem.
O que está em jogo
PEP (Pessoa Exposta Politicamente) é alguém que ocupa, ocupou ou é próximo de quem ocupa cargo público relevante. Eles não são proibidos de ter conta, são clientes que exigem monitoramento reforçado porque o risco de envolvimento em lavagem ou corrupção é estatisticamente maior.
Listas restritivas (sanções, terror, narcotráfico, lavagem) são clientes ou contrapartes que a sua instituição não pode atender, sob pena de violação direta de lei e exposição a multas multimilionárias. ONU, OFAC, União Europeia e órgãos locais publicam essas listas, e elas mudam todos os dias.
A combinação PEP + sanções é a checagem mínima de qualquer onboarding em RegTech sério. E é onde a maior parte das instituições tropeça.
Os cinco problemas reais
1. Base desatualizada
Listas oficiais são atualizadas pelos próprios órgãos diariamente. Se a sua instituição roda atualização semanal ou mensal, você está com cliente sancionado na base, e isso, juridicamente, é o seu problema.
Programas maduros têm ingestão automática diária das fontes oficiais, com logs de quando cada lista foi atualizada e qual versão estava ativa quando o cliente foi verificado.
2. Matching frágil
Nome é o pior identificador do mundo: “João Silva” tem milhões. Sistemas que fazem só match exato deixam passar 80% das ocorrências reais (porque “Joao Silva” sem acento já escapa). Sistemas que fazem só fuzzy match geram um lago de falsos-positivos onde o analista se afoga.
Bom matching combina:
- Match exato com prioridade alta.
- Match fonético (Soundex, Metaphone) para variações de grafia.
- Match fuzzy (Levenshtein) com threshold calibrado.
- Match estruturado: nome + data de nascimento + país de nacionalidade.
- Match transliterado: nomes árabes, russos, chineses transliterados de forma diferente entre listas.
E retorna um nível de confiança, não um sim/não.
3. Falta de reverificação
Cliente bom no onboarding pode virar PEP em dois meses (foi nomeado para um cargo público). Cliente pode ser sancionado depois de virar cliente (mudou de regime, entrou em lista nova). Se você só verifica no onboarding, está com clientes-fantasma na base.
Boas práticas:
- Reverificação noturna de TODA a base contra as listas atualizadas do dia.
- Alerta automatizado quando há novo match.
- Caso disparado para a mesa de decisão, sem depender de operação manual.
4. Falsos positivos sem governança
A mesa marca o caso como “não é o mesmo João Silva”. Ótimo. Mas o sistema lembra dessa decisão? Quando o nome aparecer de novo amanhã, vai gerar o mesmo alerta? Em programas frágeis, sim, e o analista refaz o trabalho. Em programas maduros, decisões viram conhecimento institucional: o alerta não dispara para um match já analisado e descartado.
5. Beneficiários finais (UBO) ignorados
Verificar só o cliente direto é metade do trabalho. O cliente é uma PJ, mas o sócio oculto através de holding é PEP, e ninguém viu. Bom KYB descobre UBO em cadeia até o ponto de controle real, e cada UBO descoberto passa pela mesma checagem de PEP e sanções.
Como tratar em escala
A escala muda a equação. Quem tem 500 clientes pode resolver na mão. Quem tem 50.000 ou 5 milhões precisa de arquitetura.
Os blocos essenciais:
- Fonte unificada: as listas chegam por API ou feed automatizado, são normalizadas em um schema interno, e o motor de matching consome esse schema. Não importa se a fonte mudou de formato, a sua mesa não sente.
- Matching como serviço: o mesmo serviço atende onboarding, monitoramento contínuo, reverificação e consultas ad-hoc. Não há lógica duplicada.
- Workflow de revisão: o alerta cai em fila com prioridade calibrada (PEP de alto cargo, sanção crítica, valor alto), passa por analista e a decisão é registrada com motivo.
- Audit trail completo: cada alerta, decisão, lista consultada e versão do motor é registrado com timestamp para auditoria e regulador.
O custo de não fazer
Um único cliente sancionado escapando custa, em média, multiplas vezes o orçamento anual do programa de compliance entre multa, processo administrativo e dano reputacional. E o risco é binário: você não é punido pela quantidade de erros, é punido por UM erro.
Não é um lugar para economizar.
Conclusão
PEP e sanções são problema de engenharia de dados disfarçado de problema de compliance. Quem trata dessa forma, com pipeline de ingestão, motor de matching configurável, governança de falso positivo e audit trail, não tem surpresa. Quem trata como item de checklist, tem.
A Guardline trata listas restritivas como infraestrutura crítica. Atualização diária, matching calibrado, governança de decisão e audit trail por padrão. Quer ver o motor rodando contra sua base? Agende uma demo.