PLD/FT pela regra da norma
O monitoramento de PLD/FT seleciona operações e situações pela relação que a norma publica: a Carta Circular BCB 4.001/2020 e a Circular BCB 3.978/2020 para as instituições do Banco Central, e a Portaria SPA/MF 1.143/2024 para os operadores de apostas, com o item da norma e, quando a norma tem um, o código de enquadramento do Siscoaf em cada alerta. Nos setores supervisionados pelo Coaf, pela CVM e pela Susep (Resoluções Coaf 36 e 41, Resolução CVM 50 e Circular Susep 612), as mesmas regras rodam com os parâmetros da sua política, e o alerta sai com o fundamento de monitoramento do seu regime. Em todos os regimes, o alerta nasce com o prazo legal, contado da data que a norma manda contar. A análise e a decisão de comunicar são do seu encarregado. O produto entrega o prazo, a evidência, o caso formalizado e o rascunho da comunicação no formato do formulário do Siscoaf; quem transmite, com a credencial pessoal dele, é a sua organização. É a divisão que a Lei 9.613/1998 faz: o dever de comunicar é da pessoa obrigada. Como ligar, em quatro passos. 1. Ative a política no painel, em Conformidade, PLD/FT: o regime do seu setor, as regras que você liga, os parâmetros de cada uma e a nota de aprovação da sua governança. A política é versionada e nunca se reescreve: cada ativação é uma versão nova, e o alerta registra com qual versão foi selecionado. 2. Crie um flow com o módulopld_monitor. Ele é exclusivo no flow e não abre sessão de widget: o flow só recebe eventos. O webhook do flow é o destino do aviso de alerta.
3. Envie as transações pela mesma rota de ingestão (POST /v1/verification-sessions com transaction ou transactions), acrescentando os dois campos do PLD/FT quando você os tiver: cash e counterparty_country. A seleção roda em produção: é a chave de produção que alimenta a fila, os prazos, o caso e, se a sua política ligar, o aviso pld.alert.created, e é lá que a pessoa monitorada conta no mês. No sandbox a ingestão valida o contrato dos eventos e do perfil, sem consumir saldo.
4. Opcional: mande o perfil do cliente em pld_profile, na criação de sessão ou na ingestão. Com ele as regras de capacidade financeira e de cadastro passam a ter com o que comparar; sem ele, essas regras saem como não avaliadas, com o motivo escrito, e nunca como “nada consta”.
cash diz que a operação foi em espécie e vale false quando omitido. Ele só conta de verdade quando você o preenche: as regras de espécie da norma só avaliam quem declarou na política que informa o campo. O counterparty_country é o país da contraparte em ISO 3166-1 alfa-2 (KY, PA, BR), de uma lista fechada: código fora dela é 422 counterparty_country_invalid, com o índice do evento na mensagem e nunca o valor.
O perfil do cliente. Todos os campos de pld_profile são opcionais, e nenhum é documento, nome ou contato: monthly_capacity_cents (a capacidade financeira mensal declarada), net_worth_cents (o patrimônio declarado; sem ele, a comparação com a capacidade usa só a renda ou o faturamento declarados), activity_code (kind cnae para empresa ou cbo para pessoa, e o code), legal_nature_code, residence_country, pep_declared, public_servant, minor, parliamentary_amendment_account, relationship_started_at (data, nunca no futuro) e risk_class (low, medium ou high, quando você já tem a sua classificação). Com declared_at você diz em que data o seu cliente fez a declaração (nunca no futuro); sem ele, vale a data do recebimento. Cada declaração recebida fica registrada com a data, o recebimento e a chave que a enviou, e sai na exportação de dados da conta. Campo fora do formato é 422 pld_profile_invalid, com o nome do campo na mensagem e nunca o valor. O bloco só é aceito onde há quem o consuma: num flow sem pld_risk na criação de sessão, ou sem pld_monitor na ingestão, a resposta é 422 pld_profile_not_supported, nunca aceito e ignorado.
A fila e os prazos. Os alertas aparecem no painel de PLD/FT, com a severidade, os itens da norma e o estado de cada prazo: em dia, atenção, vence hoje, vencido ou providência imediata. O painel mostra tudo para todos os owner e admin. Se a sua política ligar o resumo por e-mail, uma vez por dia, quando há prazo novo pedindo atenção, o owner e o admin da organização recebem um e-mail só com os contadores, sem nome, documento ou valor. Ele nasce desligado. A disposição de cada alerta (triar, atribuir, arquivar com motivo e justificativa, escalar para caso) fica registrada com o autor, e com quatro olhos quando a sua política pede um segundo membro.
O caso e o rascunho do Siscoaf. O caso junta os alertas de um cliente, e dele sai o dossiê da análise e o rascunho da comunicação em JSON, texto ou CSV, no formato do formulário do Siscoaf. O rascunho é validado contra as regras que o Coaf publica e marca como “campo do comunicante” o que só a sua organização preenche. Depois de transmitir pelo Siscoaf, registre a decisão e o protocolo no caso; retificação e cancelamento também se registram ali, com a justificativa quando a norma exige.
A declaração de não ocorrência. Nos regimes que a exigem, o painel lembra o prazo de cada ano civil e registra a declaração quando ela é feita, ou marca que não se aplica quando houve comunicação no ano.
A documentação e o relatório de efetividade. O painel gera, em versões guardadas, a documentação do monitoramento e da seleção que o art. 40 da Circular BCB 3.978/2020 pede e o insumo do relatório de efetividade do art. 62, com os números do ano da data-base. A avaliação, as deficiências e o plano de ação são da sua instituição e saem em branco. Cada versão baixa selada, conferível fora do sistema como o dossiê, e cada leitura e exportação fica registrada.
O aviso no seu webhook. O aviso é por adesão: ele nasce desligado e sai só quando a sua política liga o aviso por webhook. Ligado, quando um alerta nasce o webhook do flow recebe o evento pld.alert.created, assinado como todo evento da UNIFOKAL. A carga é mínima de propósito: o id do alerta, a sua reference_id, a severidade, o tipo, os itens da norma, o fundamento, a data da seleção, os vencimentos e o caminho do alerta no painel. Nenhuma evidência, valor ou operação viaja no aviso.
pld quando você o marca na tela Exportar dados (ou o pede em include), no recorte da organização inteira, e nunca no recorte de uma verificação. No encerramento da conta, a exportação disparada com o pedido já leva o bloco pld: depois da carência o registro é eliminado, e a guarda pelo prazo da sua norma continua com a sua organização.
O payload de cada módulo está na página dele: Monitoramento PLD/FT e Classificação de risco PLD/FT.
Dossiê selado: exportar e conferir
A Circular BCB 3.978/2020 manda formalizar a análise em dossiê, independentemente da comunicação ao Coaf (art. 43, § 2º), registrar nele a decisão fundamentada (art. 48, § 1º) e mantê-lo à disposição do Banco Central (art. 67). A guarda regulatória é sua. Para você levar a peça ao seu arquivo e provar depois que ela é a mesma que o painel gerou, o dono ou o administrador exporta o dossiê do caso selado: um pacote JSON assinado com Ed25519 e, do mesmo texto, uma versão HTML para imprimir. Toda exportação fica registrada na trilha da sua conta. O pacote traz o texto assinado (canonical), o SHA-256 dele, a assinatura destacada e o key_id da chave. O texto assinado leva o dossiê gravado e o estado das listas consultadas: por lista, o lote, a contagem, o hash do pacote, a data e o estado, e, para cada hit do titular, o lote vigente no dia do hit. Lista vencida ou desabilitada aparece como tal, nunca como “nada consta”.
A âncora é a lista abaixo, nunca a chave que viaja no arquivo. Os dois SDKs oficiais trazem a mesma lista e conferem sem rede.
key_id e o environment do pacote, confira que o exported_at do texto assinado não é anterior ao not_before dela, e rode:
canonical: o envelope do pacote (dossiê, caso e ambiente) não é assinado, e os SDKs recusam o pacote quando ele diverge do texto assinado.