Como transformamos CADOC, CCS e bloqueio de contas em chamadas de API

O pesadelo de compliance que ninguém menciona

Eis o que acontece quando você obtém uma licença bancária no Brasil: você herda uma obrigação de compliance tão vasta, tão intrincada e tão implacável que a maioria dos CTOs que conheço tem um canal dedicado no Slack chamado #pânico-regulatório.

Deixa eu te mostrar os highlights.

CADOC — Cadastro de Documentos. O Banco Central do Brasil (BACEN) exige que instituições financeiras enviem dezenas de documentos padronizados em prazos rígidos. Perdeu um deadline? Multa automática. Enviou dados incorretos? Auditoria. Formato errado? Rejeitado, reenvie, reze.

CCS — Cadastro de Clientes do Sistema Financeiro Nacional. Cada relação com cliente, cada abertura de conta, cada mudança de status deve ser reportada ao cadastro de clientes do BACEN. Em tempo real. Com rastreabilidade completa por CPF (pessoas físicas) ou CNPJ (empresas). Cada. Uma. Delas.

SisbaJud — O sistema judiciário envia ordens de bloqueio de contas diretamente para instituições financeiras. Quando um juiz ordena o bloqueio de uma conta, você tem *horas* — não dias — para cumprir. Não bloqueou? Desobediência. Bloqueou a conta errada? Processo. Bloqueou devagar demais? Os dois.

PLD/FT — Prevenção à lavagem de dinheiro e financiamento ao terrorismo. Relatórios de transações suspeitas (STR) ao COAF. Screening de PEP. Listas de sanções. Monitoramento contínuo. Se o seu sistema perde um padrão que um regulador depois identifica, você não só leva multa — você entra em território criminal.

MED 2.0 — Mecanismo Especial de Devolução do PIX. Quando fraude é detectada, os fundos devem ser rastreados e bloqueados em até 5 níveis de dispersão. Em tempo real. Entre múltiplas instituições. Com documentação completa de cadeia de custódia.

Isso é o que fintechs e bancos brasileiros enfrentam. Todo dia. E a maioria lida com uma colcha de retalhos de planilhas, processos manuais e sistemas que nunca foram projetados para funcionar juntos.

Como a maioria das instituições lida com compliance hoje

Vou ser direto: mal.

Reporting CADOC tipicamente envolve um time puxando dados manualmente de múltiplos sistemas, formatando segundo as specs do BACEN e fazendo upload por um portal web. O processo leva dias. Erros são descobertos após o envio. Correções exigem reenvio com justificativas.

Atualizações do CCS frequentemente são processadas em batch durante a noite. Isso significa que existe uma janela — às vezes de 24 horas — onde o cadastro do BACEN não reflete a realidade. Durante essa janela, uma ordem de bloqueio judicial pode atingir a conta errada, ou uma operação de lavagem de dinheiro pode passar despercebida.

Bloqueio de contas é o pior. A maioria dos sistemas tem um botão "bloquear conta" em algum lugar do backoffice. Alguém recebe uma ordem do SisbaJud por email, entra no sistema, encontra a conta, clica no botão e atualiza uma planilha para rastrear. O processo inteiro depende de um humano ler um email rapidamente.

Monitoramento PLD/FT frequentemente roda em um sistema separado com seu próprio modelo de dados. Alertas disparam em uma fila que compliance officers revisam manualmente. Taxas de falso positivo acima de 90% significam que atividade suspeita real se perde no ruído.

Isso não é um problema de tecnologia. É um problema de arquitetura. Essas funções de compliance foram parafusadas em sistemas que foram projetados antes das regulações existirem.

AuthorityOS: compliance como infraestrutura

Construímos o AuthorityOS para resolver uma tese específica: compliance deve ser uma propriedade do sistema, não um processo que roda ao lado dele.

Cada operação na Revenu passa pelo AuthorityOS antes da execução. Não depois. Não em um job batch. Antes.

O Policy Engine

No coração do AuthorityOS está um motor de políticas declarativo que avalia regras em menos de 5 milissegundos:

• transfer.amount > 50000 → require_approval(["compliance", "admin"])
• account.type == "PJ" && kyb.status != "verified" → block
• pix.velocity > 5_per_minute → flag_and_review

Políticas são definidas como código, deployadas em hot via API (sem redeploy), e versionadas com histórico completo de mudanças. Cada avaliação é logada imutavelmente.

CADOC: de relatórios manuais para geração automática

No AuthorityOS, CADOC não é um processo de reporting — é um efeito colateral das operações normais.

Cada decisão de autorização, cada mudança de estado de conta, cada avaliação de política gera um evento de auditoria imutável. Esses eventos são estruturados seguindo as especificações de documentos do BACEN. Na hora do relatório, documentos CADOC são *montados a partir de eventos*, não *construídos a partir de queries no banco de dados*.

A diferença é profunda: você não vai procurar dados para preencher um relatório. O relatório se constrói sozinho a partir da trilha de decisões que seu sistema já tomou.

CCS: cadastro de clientes em tempo real

Cada abertura de conta, mudança de status e atualização de cliente na Revenu emite um evento que o AuthorityOS mapeia para os requisitos do CCS. O cadastro é atualizado em tempo real — não em batch, não overnight, não "quando alguém lembrar."

Isso significa que o cadastro de clientes do BACEN sempre reflete o estado atual da sua instituição. Quando uma ordem judicial chega, a informação já está lá. Sem gaps. Sem janelas de inconsistência.

Bloqueio de contas: três tipos, uma API

O AuthorityOS lida com os três tipos de bloqueio de contas através de uma única API orientada por políticas:

Judicial (SisbaJud/BacenJud): Quando uma ordem de bloqueio chega, o AuthorityOS avalia a ordem contra o policy engine, executa o bloqueio em menos de 5ms, gera a documentação de compliance e emite um webhook. O fluxo inteiro — de ordem recebida a conta bloqueada — é automatizado e auditável.

Compliance (PLD/FT): Quando o motor de scoring de risco identifica atividade suspeita, o AuthorityOS pode escalar automaticamente: flag → review → block → report. Cada passo é uma avaliação de política. Cada avaliação é logada. O compliance officer vê uma trilha de decisão completa, não apenas um alerta.

Fraude (MED 2.0): Fraude no PIX aciona bloqueio em cadeia em até 5 níveis de dispersão de fundos. O AuthorityOS rastreia o fluxo de fundos, avalia políticas de bloqueio para cada recebedor, executa bloqueios em paralelo e gera a trilha de compliance MED 2.0 — tudo dentro da janela de resposta do SPI.

Workflows de aprovação 4-eyes

Algumas operações não devem ser executadas por uma única pessoa, independente do seu role. O AuthorityOS torna isso programável:

• Transferências acima de R$ 100K exigem aprovação de um gerente e um compliance officer
• Mudanças de políticas exigem aprovação do CTO e do head de compliance
• Desbloqueio de conta após bloqueio judicial exige assinatura do departamento jurídico

Esses workflows são definidos via API, avaliados em tempo real e documentados na trilha de auditoria.

Alinhamento ISO 20022 AUTH

As decisões de autorização do AuthorityOS seguem o modelo semântico da família de mensagens de autorização do ISO 20022. Isso significa que eventos de autorização são estruturados, legíveis por máquina e interoperáveis com sistemas bancários globais.

Quando um sistema Temenos ou Finastra precisa entender por que uma transação foi aprovada, bloqueada ou escalada, o evento de autorização fala uma língua que eles já entendem.

RBAC + ABAC: porque roles sozinhos não bastam

RBAC tradicional (Role-Based Access Control) atribui permissões a roles: "compliance officers podem aprovar transferências." Mas autorização no mundo real é contextual:

• Um compliance officer só deve aprovar transferências *na sua jurisdição*
• Um gerente só deve aprovar transferências *das contas do seu time*
• Um admin só deve modificar políticas *durante horário comercial*

O AuthorityOS combina RBAC com ABAC (Attribute-Based Access Control). Permissões não são apenas baseadas em role — são context-aware. O policy engine avalia role, atributos, horário, localização, valor, tipo de conta e qualquer dimensão customizada que você definir.

A trilha de auditoria que auditores realmente amam

Cada decisão que o AuthorityOS toma é logada imutavelmente:

• Quem solicitou acesso
• Qual política foi avaliada
• Qual foi a decisão (allow, deny, escalate, block)
• Por quê (qual regra disparou, quais atributos casaram)
• Quando (precisão de microssegundo)
• O contexto completo (payload da request, atributos do usuário, estado da conta)

Isso não é um arquivo de log. É um banco de dados de auditoria consultável, filtrável e exportável. Compatível com SIEM. Acessível via API. Cada entrada é criptograficamente vinculada à anterior.

Quando os auditores do BACEN chegam, você não sai correndo para reconstruir o que aconteceu. Você dá a eles acesso à API e um intervalo de datas.

Os números

Depois de 12 meses de AuthorityOS em produção:

• 3 → 1 sistemas consolidados — RBAC, motor de aprovações e logging de auditoria unificados
• < 5ms de latência de avaliação de políticas (p99)
• 100% de cobertura de auditoria — zero decisões de autorização não rastreadas
• Tempo de geração CADOC: minutos — antes eram dias de trabalho manual
• Lag do CCS: zero — atualizações em tempo real, sem janelas de batch
• Tempo de resposta SisbaJud: < 30 segundos — de ordem recebida a conta bloqueada
• Zero multas regulatórias desde o deploy

Por que isso importa além do Brasil

Os desafios regulatórios que resolvemos com o AuthorityOS não são exclusivos do Brasil. Todo mercado tem sua versão de CADOC (filings da SEC nos EUA, relatórios da FCA no UK). Todo mercado tem mecanismos de bloqueio judicial. Todo mercado exige compliance PLD/AML.

O policy engine do AuthorityOS é jurisdiction-agnostic. As políticas mudam. O engine não. Deploy no Brasil e ele lida com CADOC, CCS e SisbaJud. Deploy na EU e ele lida com PSD2, GDPR e guidelines da EBA. A arquitetura é a mesma.

A verdade desconfortável

A maioria das instituições financeiras trata compliance como um centro de custo — algo que você faz porque reguladores te obrigam. Contratam compliance officers, compram ferramentas de reporting e rezam para nada passar despercebido.

Nós tratamos compliance como infraestrutura. Não é um processo que roda depois do fato. É uma propriedade de cada operação, avaliada em tempo real, logada imutavelmente e auditável by design.

O AuthorityOS não torna compliance fácil. Torna compliance *automático*.

E em um mundo onde reguladores estão ficando mais rápidos, mais inteligentes e menos pacientes — automático é a única opção que escala.