Abrir uma conta empresarial pode levar minutos para o cliente e horas para o time de Compliance. Esse contraste explica boa parte do problema do onboarding B2B em fintechs.
Enquanto a experiência do usuário se tornou digital, muitos processos internos de PLD/AML (Prevenção à Lavagem de Dinheiro / Anti-Money Laundering) ainda dependem de analistas consultando diferentes fontes, revisando documentos, investigando sócios e beneficiários finais, verificando PEPs e listas de sanções, avaliando alertas e, finalmente, decidindo se uma empresa pode ou não ser aceita.
Não é necessariamente um processo ruim. O problema aparece quando o volume cresce. Cem novas empresas por mês podem ser administráveis com um bom time. Dez mil exigem outra arquitetura.
A solução também não é simplesmente “automatizar o AML”. Uma fintech precisa separar aquilo que pode ser decidido de forma determinística daquilo que realmente exige investigação e julgamento humano.
A melhor automação de AML não elimina o analista de Compliance. Ela elimina o trabalho que não precisa de um analista de Compliance.
E essa diferença importa.
Onboarding empresarial é muito mais do que validar um CNPJ
No onboarding de uma pessoa física, boa parte da análise gira em torno de um indivíduo. Em empresas, a estrutura rapidamente se torna mais complexa.
A fintech precisa entender não apenas se aquele CNPJ existe, mas quem está por trás dele. Isso pode envolver validar dados cadastrais, situação da empresa, atividade econômica, data de constituição, endereço, quadro societário, administradores e beneficiários finais.
Depois vem uma segunda camada: risco.
- Algum dos sócios é uma Pessoa Exposta Politicamente (PEP)?
- Existem correspondências em listas de sanções ou watchlists?
- Há sinais negativos relevantes?
- A atividade declarada pela empresa é compatível com o produto solicitado e com o comportamento esperado?
- A estrutura societária merece uma análise adicional?
- Existem inconsistências entre as informações declaradas pelo cliente e aquelas encontradas em fontes externas?
O verdadeiro desafio do KYB não é consultar um dado: é conectar diferentes sinais e transformá-los em uma decisão consistente.
Onde se perde tempo em uma análise manual de AML?
Pense em um processo bastante comum: uma fintech recebe o cadastro de uma nova empresa. Um analista consulta dados cadastrais e societários. Identifica os sócios. Verifica quem são os beneficiários finais. Consulta essas pessoas em outro fornecedor. Pesquisa PEP e listas de sanções. Avalia outras informações relevantes e compara os resultados com a política interna. Se aparece um alerta, investiga. Depois documenta sua conclusão.
Agora multiplique isso por centenas ou milhares de solicitações. O problema não é apenas custo.
Dois analistas podem interpretar uma mesma situação de maneiras ligeiramente diferentes. Uma análise pode ser melhor documentada do que outra. Nos períodos de maior demanda, os prazos aumentam. E uma política perfeitamente descrita em um manual de Compliance pode acabar sendo executada de formas diferentes na operação.
A automação começa justamente aqui: transformando a política de AML em um fluxo de decisão executável.
1. Transforme a política de AML em regras
Muitas políticas de Compliance ainda são escritas para serem interpretadas por pessoas. Por exemplo:
Empresas com beneficiários finais identificados como PEP devem passar por diligência reforçada.
A orientação é clara para um analista. Para automatizá-la, é necessário transformá-la em lógica operacional:
Beneficiário final identificado → consulta PEP → match confirmado → Enhanced Due Diligence / análise manual.
Outro exemplo: “Empresas pertencentes a determinados setores de maior risco devem receber uma análise adicional.” Isso pode virar:
CNAE/atividade econômica → classificação de risco → alto risco → solicitar informações adicionais + encaminhar para análise.
Esse exercício é fundamental. Antes de contratar mais dados ou colocar IA no processo, uma fintech precisa saber o que pretende decidir com cada sinal. Caso contrário, automatizará as consultas e continuará tomando as decisões manualmente.
2. Automatize a coleta de dados
Depois de estruturar a política, o próximo gargalo são os dados. O onboarding empresarial pode depender de diversas fontes: dados cadastrais e societários, beneficiários finais (UBO), PEP, listas de sanções, watchlists, informações judiciais, sinais de fraude, documentos, bases internas e outras fontes de inteligência.
Em um processo manual, cada consulta pode se transformar em uma tarefa. Em um fluxo automatizado, deveria acontecer o contrário: o sistema recebe o CNPJ ou identificador da empresa e executa automaticamente as consultas necessárias de acordo com a política.
Mas existe um detalhe importante: nem todas as empresas precisam das mesmas consultas.
Uma empresa simples, com estrutura societária transparente e baixo risco, pode seguir um caminho. Uma companhia com estrutura mais complexa, atividade de maior risco ou algum sinal relevante pode disparar consultas adicionais. Isso permite construir um onboarding progressivo: usar mais dados e gerar mais diligência apenas quando o risco justificar.
3. Automatize o screening de sócios e beneficiários finais
Esse é um dos pontos em que o onboarding empresarial mais se diferencia do onboarding de pessoas físicas. Aprovar uma empresa sem entender quem a controla pode deixar uma parte fundamental do risco fora da análise.
Por isso, uma infraestrutura de decisão precisa trabalhar com relacionamentos:
Empresa → sócios → beneficiários finais → administradores.
A partir dessa estrutura, cada pessoa relevante pode passar automaticamente pelas verificações previstas na política. O resultado não deveria ser apenas um conjunto de respostas de APIs: a plataforma precisa interpretar esses resultados dentro da política.
Um possível match de PEP, por exemplo, não significa necessariamente reprovar a empresa. Pode significar que aquele caso precisa seguir para uma etapa de diligência reforçada.
Screening não é decisioning.
Consultar listas é screening. Determinar o que fazer com o resultado é decisioning.
4. Crie uma classificação de risco para o onboarding
Quando uma fintech utiliza dezenas de variáveis, analisar cada sinal isoladamente começa a fazer pouco sentido. Uma alternativa é consolidar essas informações em uma classificação de risco:
- Baixo Risco: estrutura societária simples, atividade esperada, informações consistentes e nenhum alerta material → aprovação automática.
- Médio Risco: algum sinal que exija validação adicional → análise simplificada ou solicitação de documentos adicionais.
- Alto Risco: combinação relevante de fatores de AML, PEP, sanções, atividade econômica, estrutura societária ou jurisdição → Enhanced Due Diligence (EDD).
O score não precisa substituir as regras: na verdade, uma arquitetura robusta normalmente combina os dois.
5. Automatize o óbvio. Envie as exceções para pessoas.
Talvez essa seja a decisão de arquitetura mais importante de todo o processo. Uma fintech não deveria tentar automatizar todos os casos. Deveria automatizar todos os casos em que uma pessoa não agrega valor.
Se uma empresa atende claramente a todos os critérios da política, a aprovação pode ser automática. Se descumpre uma condição objetiva e inequívoca, a ação correspondente também pode ser automatizada.
O trabalho humano deveria se concentrar no meio: casos ambíguos, matches potenciais, estruturas societárias complexas, PEPs, informações contraditórias e exceções.
Na Sinky, por exemplo, esse tipo de arquitetura conecta o fluxo criado no Studio ao AI Case Management. Quando uma operação precisa de revisão, o analista recebe o caso já organizado, com os dados, documentos, consultas e sinais relevantes disponíveis para análise. Ele não começa do zero.
6. Use IA onde ela realmente faz sentido
A chegada dos modelos de IA criou uma tentação compreensível: colocar inteligência artificial em todas as etapas do processo. Em AML, isso exige cuidado. Existem decisões que deveriam continuar determinísticas.
Onde a IA gera muito mais valor é nas tarefas que tradicionalmente consomem tempo humano:
- Ler documentos e extrair informações;
- Comparar dados declarados com documentos enviados;
- Resumir um caso e organizar sinais encontrados em diferentes fontes;
- Identificar inconsistências para investigação e destacar pontos de atenção;
- Gerar uma explicação inicial sobre por que determinada operação foi encaminhada para análise.
Exemplo prático de resumo gerado por IA:
“A empresa foi encaminhada para análise devido a um possível match de PEP relacionado a um de seus beneficiários finais. Os dados cadastrais estão consistentes com as informações declaradas. Não foram encontrados alertas relevantes nas demais verificações realizadas. Recomenda-se validar o possível match de PEP antes de prosseguir com o onboarding.”
O analista continua tomando a decisão, mas começa muito mais à frente.
7. Faça com que cada decisão possa ser explicada
Automatizar uma decisão regulada sem conseguir explicar como ela aconteceu é trocar um problema operacional por um problema de governança. Uma fintech precisa conseguir reconstruir uma decisão.
Se uma empresa foi aprovada seis meses atrás, deveria ser possível identificar qual política estava vigente, quais dados foram consultados, quais respostas os fornecedores retornaram, quais regras foram acionadas, qual classificação de risco foi atribuída, se houve análise manual, quem realizou essa análise e qual foi a decisão final.
A pergunta não é apenas “Por que aprovamos essa empresa?” — pode ser: “Por que aprovamos essa empresa com a política que estava vigente naquele momento?” Uma boa infraestrutura de decisioning precisa responder às duas.
8. AML não termina quando o onboarding termina
Esse é um dos erros mais comuns no desenho de processos de Compliance. Uma empresa pode ser de baixo risco hoje e apresentar novos sinais daqui a seis meses: mudar seu quadro societário, ter novos administradores, um beneficiário se tornar PEP ou surgir em uma nova lista de sanções.
Por isso, onboarding e monitoring deveriam fazer parte de uma mesma arquitetura de decisão. A política utilizada para aceitar o cliente pode evoluir para regras de monitoramento periódico, re-screening e geração de alertas contínuos (Portfolio Monitoring).
Qual arquitetura uma fintech precisa para automatizar AML?
Não basta contratar uma API de PEP e sanções, nem apenas ter um fornecedor de KYC ou KYB. Uma arquitetura moderna de compliance pode ser dividida em quatro camadas:
- Dados: fontes cadastrais e societárias, UBO, PEP, sanções, watchlists, fraude, documentos, registros públicos e dados internos.
- Decisioning: regras, políticas, scores, modelos, fluxos, thresholds e critérios de escalonamento.
- Case Management: gestão de exceções, análise humana, alçadas, SLAs, evidências e decisões.
- Monitoring: re-screening, alterações cadastrais e societárias, novos alertas e reavaliação contínua.
Onde a Sinky entra?
A proposta da Sinky não é substituir fornecedores especializados de AML, KYC ou KYB. É conectá-los a uma camada de decisão.
Com o Sinky Studio, uma fintech pode transformar sua política de onboarding e Compliance em fluxos visuais de decisão, combinando regras, dados, integrações, scores, modelos e ações. Por meio do Data Marketplace, diferentes provedores podem fazer parte desses fluxos.
Quando um caso exige intervenção humana, o AI Case Management permite encaminhá-lo para uma mesa de análise com os sinais, documentos e contexto já organizados. O objetivo não é substituir o time de Compliance: é fazer com que um especialista dedique seu tempo àquilo que realmente exige julgamento especializado.
A métrica mais importante não é o percentual de automação
É tentador medir o sucesso de um projeto dizendo: “Automatizamos 90% do onboarding.” Mas esse número, sozinho, diz pouco. Uma operação pode ter uma taxa altíssima de automação e uma política de risco mal desenhada.
As melhores perguntas são:
- Quanto tempo uma empresa de baixo risco leva para ser aprovada?
- Qual percentual dos casos chega desnecessariamente à análise manual?
- Quanto tempo um analista gasta coletando informações versus analisando risco?
- Quantas decisões podem ser reconstruídas e explicadas?
- Com que velocidade uma política pode ser alterada quando o risco muda?
As máquinas executam a política e as pessoas se concentram nas exceções que exigem julgamento.
