SEPRELAD e AML
A Veridia não é certificada, registrada, aprovada nem revisada pela SEPRELAD nem por nenhuma outra unidade de inteligência financeira. Ela não gera nenhum reporte regulatório, não produz nenhuma declaração no formato de nenhum supervisor e não submete nada a ninguém em seu nome.
Se você é um sujeito obrigado, suas obrigações de AML permanecem inteiramente suas: seu programa, seu compliance officer, sua avaliação de risco, suas declarações. O que esta página descreve é um conjunto de controles que podem contribuir com evidências para esse programa — não um substituto para ele.
Confirme com o jurídico o que a sua atividade regulada realmente exige. Esta página não pode te dizer isso.
Estabelecido esse limite, aqui está precisamente o que o sistema faz.
Screening de sanções
Toda verificação cujo OCR produziu um nome é submetida a screening contra listas de sanções antes de um veredito ser emitido.
Quais listas
| Fonte | Lista |
|---|---|
| OFAC (Tesouro dos EUA) | Specially Designated Nationals (SDN) |
| Nações Unidas | Consolidated Sanctions List |
Essa é a cobertura completa. Especificamente não incluídos:
- Nenhuma lista de PEP. Pessoas expostas politicamente não passam por screening nenhum.
- Nenhum screening de mídia adversa.
- Nenhuma lista consolidada da UE. Considerada e adiada; não implementada.
- Nenhuma lista local ou regional de qualquer jurisdição.
Se o seu programa exige screening de PEP — e para muitas atividades reguladas ele exige — você precisa de um provedor ou processo separado para isso. Não presuma que está coberto aqui.
Quão atualizadas estão as listas
Um timer atualiza as duas fontes diariamente a partir dos endpoints oficiais dos publicadores e reconstrói o índice de correspondência. Se um download falhar, o índice anterior permanece no lugar, em vez de o sistema passar a fazer screening contra nada.
O estado datado das listas é, portanto, "a publicação de ontem, no pior caso" em operação normal — mas não existe contrato de alertas em torno de uma atualização que falhe de forma persistente, nem SLA publicado de atualidade. Se a atualidade das listas é um ponto de auditoria para você, verifique isso operacionalmente em vez de presumir.
O que uma correspondência produz
Os resultados do screening aparecem como flags na verificação:
| Flag | Nível | Significado |
|---|---|---|
aml_sanctions_match | err | Uma correspondência forte contra um nome listado |
aml_possible_match | warn | Uma correspondência mais fraca que merece atenção humana |
Uma correspondência forte força a verificação para review, para que uma pessoa decida. Ela não produz um veredito rejected por conta própria, por mais confiante que seja a correspondência.
Isso é deliberado e vale entender, porque o design intuitivo é o oposto. A comparação de nomes contra listas de sanções produz falsos positivos constantemente — nomes comuns, variantes de transliteração, correspondências parciais. Rejeitar automaticamente por uma coincidência de nome negaria serviço a pessoas reais com base numa comparação de strings, e faria isso silenciosamente. Colocar o caso na frente de um humano é o único tratamento defensável: a decisão, e o raciocínio por trás dela, passam então a pertencer a uma pessoa a quem se pode pedir justificativa.
A consequência para a sua integração: um caso de sanções chega como verdict: "review", não como uma rejeição. Se o seu onboarding trata review como uma fila que ninguém acompanha, os casos de sanções ficam parados nela.
Um limite que vale conhecer
O screening roda sobre o nome extraído por OCR do documento. Se o OCR ler o nome errado, o screening roda contra a versão lida errado. Um nome que não é extraído não passa por screening nenhum.
Isso é inerente a fazer screening de um documento fotografado em vez de uma identidade digitada, e não é totalmente resolvido por nada no pipeline. Se você precisa que o nome submetido a screening coincida com um nome que os seus próprios sistemas guardam, envie-o como submittedFullName no init, para que a comparação entre os dois seja pontuada e fique visível nos resultados.
O que o sistema retém como evidência
O registro da verificação foi projetado para sobreviver como o artefato da verificação de identidade. Ele guarda:
- O veredito, a confiança geral e o score de cada verificação individual
- Todas as flags levantadas, incluindo as flags de sanções acima
- Os campos de identidade extraídos do documento
- Os horários de submissão e de conclusão
- Quando uma pessoa revisou o caso: quem revisou, quando e a nota dela
Registros de verificações identificadas como paraguaias mantêm suas imagens por 5 anos; todo o resto, e qualquer caso cuja jurisdição seja incerta, por 8. A própria linha do banco de dados nunca é apagada pela varredura de retenção. Veja Retenção de dados para o que exatamente isso significa, incluindo a parte em que as imagens vão embora e o registro fica.
O que a Veridia não produz
Listado explicitamente, porque estas são as coisas de que um programa de AML precisa e que seria razoável supor que um produto de "KYC/AML" fornece:
| Reportes de operação suspeita (ROS / STR) | Não gerados, não formatados, não protocolados |
| Formatos de reporte da SEPRELAD | Não implementados |
| Protocolo ou submissão a qualquer supervisor | Nenhum |
| Scoring ou classificação de risco do cliente | Não produzido. O score de confiança é uma medida de verificação de identidade, não uma classificação de risco de lavagem de dinheiro — não o use como tal |
| Re-screening contínuo ou periódico | Não implementado. O screening acontece uma vez, na verificação. Um cliente que seja listado depois de ter sido verificado não passa por novo screening e não será sinalizado |
| Monitoramento de transações | Totalmente fora de escopo |
| Screening de PEP ou de mídia adversa | Não implementado |
| Beneficiário final ou KYB corporativo | Não implementado |
| Guarda de registros no formato prescrito por qualquer supervisor | Não implementado |
A ausência de re-screening contínuo merece atenção particular. As listas mudam; uma checagem única no onboarding é um controle pontual no tempo. Se as suas obrigações incluem re-screening periódico da sua base de clientes existente, isso tem que ser resolvido em outro lugar.
O que você pode razoavelmente afirmar
Se você está descrevendo o seu stack na sua própria documentação de compliance, as afirmações defensáveis têm este formato:
A verificação de identidade é realizada por um provedor terceirizado, que submete o nome extraído a screening contra as listas OFAC SDN e Consolidated da ONU no momento da verificação. Correspondências fortes são encaminhadas para revisão manual em vez de automaticamente rejeitadas. Os registros de verificação, incluindo o veredito, as verificações realizadas e a decisão do revisor, são retidos por [prazo].
O que não é defensável é qualquer afirmação que dê a entender que a Veridia é certificada pela SEPRELAD, que ela cumpre uma obrigação de reporte, ou que usá-la deixa um processo de onboarding em conformidade. Ela não deixa, e afirmar isso num documento que um regulador pode ler cria um problema consideravelmente maior do que o que ele resolve.