Protocolo de "compliance comprovável" quer provar que decisões de KYC/AML estavam atualizadas no momento da transação
O artigo propõe o ChainIT Provable Compliance, uma camada que transforma decisões de KYC, AML, sanções, PEP e verificação de identidade em registros assinados, com prazo de validade e rastreáveis até a evidência de origem que as sustentou. A motivação é que evidência de compliance envelhece e hoje é difícil provar, de forma compacta e auditável, que a decisão de aprovar um cliente ou uma transação ainda era válida no exato momento em que o pagamento foi liberado — problema que se agrava quando parte do processo é delegada a agentes de software e fluxos automatizados. O protocolo deixa explícito que uma decisão de compliance nunca autoriza pagamento por si só: só uma aprovação final combinada com o identificador exato da transação e uma credencial de execução de uso único pode liberar valor.
Esse artigo ataca um problema real e pouco discutido no antifraude e compliance: a maior parte das obrigações de KYC/AML trata a verificação como um evento único (onboarding), mas o risco de um cliente, contraparte ou transação muda continuamente — sanções são atualizadas, uma pessoa se torna PEP, uma licença expira, um padrão de transação muda de risco. Quando a decisão de "isso é compliant" não registra explicitamente qual evidência estava vigente e por quanto tempo ela continua válida, a instituição fica exposta tanto a fraude (aprovar algo que já não deveria ser aprovado) quanto a risco regulatório (não conseguir provar ao auditor por que aprovou).
A proposta formaliza cada fato usado numa decisão de compliance — identidade verificada, resultado de sanções, status de PEP, histórico de antecedentes, validade de licença — como uma unidade de evidência ("Evidence Assertion") com proveniência (de onde veio), atualidade (quando foi verificada, até quando vale), nível de confiança e propósito permitido de uso. Essas evidências alimentam um motor de regras de negócio determinístico, que aplica um perfil de política de compliance versionado e devolve resultados com motivo codificado — ou seja, não é uma caixa-preta estatística, é uma decisão rastreável e reproduzível. O resultado final é um "Compliance Decision", assinado e com prazo de validade, que alimenta como um único predicado (permitido/não permitido) a decisão mais ampla de liberar ou não a transação.
O ponto crítico de design, e que tem valor direto para quem opera programas de AML, é a separação estrita entre decisão de compliance e autorização de pagamento: a conformidade nunca libera valor por conta própria, apenas contribui como um "sim" ou "não" para uma decisão de autorização que também exige o identificador exato da transação, reserva de capacidade e uma credencial de execução de uso único. Essa separação evita um erro comum em implementações reais, onde um sistema de KYC aprova o cliente uma vez e esse "aprovado" fica implicitamente válido para sempre, sendo reutilizado indevidamente (inclusive por fraudadores que exploram a lentidão de reverificação) em transações muito posteriores e de perfil de risco diferente.
Na prática, para equipes de AML e antifraude, a recomendação que emerge do desenho é: tratar toda evidência de compliance como tendo validade limitada e explícita, nunca como um carimbo permanente; exigir que cada decisão de liberar uma transação referencie qual evidência específica (e de que data) a sustentou, para permitir auditoria e investigação de fraude após o fato; e, ao automatizar onboarding e monitoramento com agentes de software, garantir que a automação herde esse mesmo rigor de atualidade — não apenas velocidade — já que decisões de compliance desatualizadas são uma porta de entrada conhecida para contas e transações fraudulentas.