Critérios KYC/KYB — O Critério como Ativo Versionado
Numa inspeção do regulador, a pergunta que dói não é "a IA leu o documento?" — é "qual texto exato do critério vigorava na análise de janeiro, e quem respondia por ele?". No DATTA, o critério de compliance é um ativo versionado: uma regra de negócio escrita em português pelo próprio especialista, com dono, versão e histórico de alterações. Mudar um critério deixa de ser um chamado de TI com prazo de semanas — é o gerente de compliance editando um texto e salvando.
Dono, versão e histórico
Cada critério, no painel de Regras de Triagem, exibe três informações que sustentam a rastreabilidade:
| Elemento | O que mostra |
|---|---|
| v{N} | A versão corrente do critério |
| Dono | Quem responde pelo critério — o criador, ou quem for definido depois |
| Histórico | As versões anteriores, cada uma com autor, data e motivo da alteração |
Ao salvar uma edição, a versão vigente é fotografada no histórico na mesma transação: se a fotografia falhar, a edição não acontece. Nenhuma versão se perde pelo caminho. O campo "Motivo da alteração" é opcional e fica registrado junto com a fotografia.
A plataforma também expõe o histórico para integração: é possível listar todas as versões de um critério e recuperar o texto exato de uma versão específica — a resposta direta para "qual texto vigorava na análise de janeiro?". Veja a referência de API.
Versão aplicada no laudo
Cada análise da triagem registra a versão do critério aplicada (campo regraVersao no laudo). Meses depois, o laudo permite reconstruir a decisão inteira: qual texto vigorava na data, com a evidência anexada e — no fluxo de onboarding PJ — quem decidiu com base nele.
Catálogo inicial de critérios KYB
O arquivo scripts/criterios-kyb-exemplo.json traz 15 critérios organizados em quatro blocos:
- Completude — o dossiê tem o que precisa ter;
- Societário e beneficiário final — cadeia de participação e quem controla de fato;
- Poderes e representação — quem pode assinar pela empresa;
- Cruzamentos — sinais que só aparecem ao comparar entidades entre si.
Eles são dado de usuário, não conteúdo de fábrica: carregue-os pelo painel de Regras de Triagem ou pela API (um objeto por critério). A plataforma nunca os semeia automaticamente — assim, um critério que a instituição removeu de propósito não volta sozinho na próxima atualização.
Princípios embutidos nos textos
Os três princípios abaixo já vêm escritos nos critérios de exemplo e podem ser editados por cada instituição:
- Ausência é insuficiência. Um critério que depende de dado ausente produz anomalia por insuficiência — nunca "conforme por omissão".
- Números calculados são fatos. O beneficiário final calculado pela plataforma entra pronto no critério; o texto nunca pede ao modelo que recalcule o percentual.
- Cruzamento nunca reprova sozinho. Um vínculo obtido por casamento probabilístico (nome, CPF parcial) aponta o achado com força e origem, para decisão humana. O critério de atributos compartilhados (endereço/telefone/contador) traz o aviso explícito: endereço compartilhado também é a realidade de habitação coletiva — é indício, não sentença, e o limiar pertence à política de cada instituição.
Boas práticas
- Defina o dono de cada critério. É a pessoa a quem o regulador vai perguntar; deixar em branco transfere a pergunta para quem estiver na sala.
- Use o motivo ao alterar. Um "ajuste do limiar após revisão da política X" vale ouro numa inspeção — e custa dez segundos para escrever.
- Escolha o escopo certo. Critérios que dependem do dossiê inteiro (completude, soma de percentuais societários) usam escopo GLOBAL; os pontuais usam LOCAL. O catálogo de exemplo já vem calibrado assim.
Para saber mais
- Geração de regras de triagem com IA — quando a ideia do critério ainda precisa virar texto.
- Validação de referências das regras — como conferir se o dispositivo citado existe de fato.
- Fluxo de onboarding PJ — onde os critérios são aplicados na prática.