PLD/FT pela regra da norma

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ódulo pld_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".

{
  "flow_id": "flow_01J8PLD0000000000000000000",
  "reference_id": "cliente_42",
  "pld_profile": {
    "monthly_capacity_cents": 1500000,
    "activity_code": { "kind": "cbo", "code": "252210" },
    "residence_country": "BR",
    "pep_declared": false,
    "relationship_started_at": "2025-03-10"
  },
  "transactions": [
    {
      "type": "deposit",
      "amount_cents": 4500000,
      "external_id": "dep_1001",
      "cash": true,
      "counterparty_country": "BR"
    }
  ]
}

Os campos novos do evento. 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 (baixo, medio ou alto, 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_risco 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.

{
  "id": "evt_plda_01J8PLDALERTA000000000000_pld_alert_created",
  "schema_version": 1,
  "event": "pld.alert.created",
  "livemode": true,
  "created": "2026-09-24T12:00:00.000Z",
  "data": {
    "object": "pld_alert",
    "id": "plda_01J8PLDALERTA000000000000",
    "reference_id": "cliente_42",
    "severity": "alta",
    "kind": "analise",
    "items": ["cc4001.I.d"],
    "basis": "Circular BCB 3.978/2020, art. 39; Carta Circular BCB 4.001/2020, art. 1, I, d",
    "selected_at": "2026-09-24T11:00:00.000Z",
    "deadlines": [{ "id": "analysis", "due_at": "2026-11-08T11:00:00.000Z" }],
    "dashboard_path": "/dashboard/pld?alerta=plda_01J8PLDALERTA000000000000"
  }
}

Guarda, exclusão e exportação. Enquanto a conta existe, o registro de PLD/FT (política, alerta, disposição, caso, dossiê, comunicação e declarações) fica guardado pelo prazo legal do seu regime, e o pedido de exclusão do titular não o alcança antes disso: a guarda é obrigação legal (LGPD, art. 16, I). A exportação de dados da conta leva o bloco 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.

// Node 20+ (SDK oficial)
import { readFileSync } from "node:fs";
import { verifyPldDossierPackage } from "unifokal";

const pacote = JSON.parse(readFileSync("dossie-selado-pldc_....json", "utf8"));
const r = verifyPldDossierPackage(pacote);
// r.valid, r.errors (o motivo de cada recusa), r.dossier_id, r.content_hash, r.exported_at

# Python (SDK oficial, extra "unifokal[crypto]")
import json
from unifokal import verify_pld_dossier_package

r = verify_pld_dossier_package(json.load(open("dossie-selado-pldc_....json")))
# r["valid"], r["errors"], r["dossier_id"], r["content_hash"], r["exported_at"]

// chaves públicas do selo do dossiê (Ed25519, 32 bytes em base64). A âncora é ESTA lista.
[
  { "key_id": "sbx-250e08bd4bf1",
    "public_key": "p9/bS+qZIlV8UB7+aVLygeCOV4IHJ/sRgjHIEeejyWI=",
    "environment": "sandbox",
    "not_before": "2026-09-27T00:00:00.000Z" }
]
// A chave de produção entra nesta lista antes da primeira exportação de produção.

Sem SDK, o openssl 3 confere a mesma assinatura. Escolha na lista a chave com o key_id e o environment do pacote, confira que o exported_at do texto assinado não é anterior ao not_before dela, e rode:

# a chave pública da lista, em PEM (prefixo SPKI do Ed25519 + os 32 bytes)
( printf '302a300506032b6570032100' | xxd -r -p; echo 'p9/bS+qZIlV8UB7+aVLygeCOV4IHJ/sRgjHIEeejyWI=' | base64 -d ) \
  | openssl pkey -pubin -inform DER -out chave.pem

# o texto assinado (bytes exatos, UTF-8) e a assinatura, tirados do pacote
python3 - dossie-selado.json <<'FIM'
import base64, json, sys
p = json.load(open(sys.argv[1], encoding="utf-8"))
open("texto.txt", "wb").write(p["canonical"].encode("utf-8"))
open("assinatura.bin", "wb").write(base64.b64decode(p["signature"]))
FIM
sha256sum texto.txt          # igual ao campo "sha256" do pacote
openssl pkeyutl -verify -pubin -inkey chave.pem -rawin -in texto.txt -sigfile assinatura.bin
# Signature Verified Successfully

Um único byte trocado no texto faz a conferência falhar. Depois de conferir, leia o conteúdo do próprio canonical: o envelope do pacote (dossiê, caso e ambiente) não é assinado, e os SDKs recusam o pacote quando ele diverge do texto assinado.

A contratação, pelos arts. 44, 45 e 47

Para as instituições do Banco Central, três artigos da Circular BCB 3.978/2020 falam de quem contrata ferramenta de monitoramento. O resumo abaixo segue o texto oficial, relido na fonte em 27/09/2026. O enquadramento da sua contratação é da sua instituição: esta seção não é parecer jurídico.

Art. 44. A análise do art. 43 não pode ser contratada de terceiros nem realizada no exterior. A vedação não inclui a contratação de terceiros para serviços auxiliares à análise.

Art. 45. A instituição deve dispor, no País, de recursos e competências necessários à análise de operações e situações suspeitas.

Art. 47. Na contratação de serviços de processamento e armazenamento de dados e de computação em nuvem usados no monitoramento e na seleção, e de serviços auxiliares à análise, a instituição observa o Capítulo III da Circular 3.909/2018, no caso de instituição de pagamento, ou o da Resolução 4.658/2018, no caso de instituição financeira e demais autorizadas, e, no que couber, os Capítulos IV e V de cada uma. A página de normativos do Banco Central registra que os arts. 1º a 26 da Circular 3.909 foram revogados pela Resolução BCB 85/2021, a partir de 1º/8/2021, e que a Resolução 4.658 foi revogada pela Resolução CMN 4.893/2021, a partir de 1º/7/2021.

O que a sua avaliação encontra aqui. O serviço é hospedado no Brasil, na região AWS sa-east-1 (São Paulo). A lista de subprocessadores é pública, com o que cada um recebe e o país onde trata. A análise, a decisão de comunicar e a transmissão continuam com a sua equipe: o produto entrega a seleção, o prazo, o caso, o dossiê e o registro.