Blog

KYC não é “um botão de segurança”. É um conjunto de decisões. E essas decisões definem o custo, a complexidade e a taxa de aprovação do seu app.

Se o seu projeto envolve pagamentos, marketplace, cadastro de prestadores, saques/repasse, benefícios, crédito ou qualquer cenário com risco de fraude, cedo ou tarde aparece a pergunta:

“Precisamos fazer KYC?”

A resposta quase nunca é “sim” ou “não”. A resposta correta é: qual nível de validação faz sentido para o seu risco, sem matar a conversão.

O que você vai ver aqui

• O que é KYC (e o que é KYB / AML) na prática
• Quais documentos e evidências você pode (ou não deve) pedir
• Níveis de validação: do básico ao reforçado (e o impacto no funil)
• Perguntas que definem custo e complexidade antes de contratar qualquer fornecedor
• O que fazer quando o usuário é recusado (sem virar caos no suporte)
• Responsabilidades: o que é do cliente, do fornecedor de KYC e do time de tecnologia
• Impactos em privacidade (LGPD) e armazenamento: como reduzir risco sem travar o projeto
• Checklist final para briefing (para você copiar e mandar)

1. KYC, KYB e AML: traduções rápidas

KYC significa Know Your Customer (“conheça seu cliente”). Na prática, é o processo de:

1. identificar quem é a pessoa/empresa que está se cadastrando;
2. verificar se essa identidade é real e consistente;
3. decidir se você aceita, recusa ou pede informações adicionais.

Termos que aparecem junto:

• KYB (Know Your Business): quando você valida empresa (CNPJ, contrato social, sócios, beneficiário final, etc.).
• AML (Anti‑Money Laundering): controles para prevenção à lavagem de dinheiro e outros riscos regulatórios (por exemplo: checagens de listas, PEP, sanções, monitoramento).

Importante: nem todo app precisa de “KYC reforçado”. Mas apps com transações financeiras e repasse quase sempre precisam de algum nível de diligência — mesmo que seja gradual (começa simples e “sobe o nível” conforme risco e volume).

2. Níveis de validação (e onde o projeto começa a ficar caro)

Uma forma simples (para alinhar com o time e com o fornecedor) é pensar em níveis.

Tabela prática: níveis x uso x impacto

Dica: se você não sabe o nível, comece pela pergunta: qual é o prejuízo máximo se alguém fraudar a identidade?
Quanto maior a exposição, mais validação faz sentido.

3. Quais documentos e evidências você pode pedir (e o que cada um resolve)

O erro mais comum é pedir documento “porque sim” e descobrir depois que:

• o usuário não consegue concluir (fricção),
• o suporte explode (tickets),
• e a empresa passa a armazenar dados sensíveis sem necessidade (LGPD).

Abaixo está um mapa simples de “evidência → motivo → custo/atrito”.

Regra de ouro: cada evidência deve ter um motivo de negócio. Se não existe motivo, é custo e risco extra.

4. O fluxo do KYC precisa existir (antes de escolher fornecedor)

KYC não termina quando você “chama a API”. Você precisa de um fluxo completo: cadastro, validação, status, recusa, reenvio, revisão e auditoria.

Pontos que geralmente travam o projeto:

• “Quem decide quando está pendente?”
• “Existe revisão manual?”
• “Qual é o prazo (SLA) para aprovar?”
• “Como o usuário sabe o que fazer para corrigir?”
• “Quem atende contestação?”

Se essas respostas não existem, a integração vira uma “caixa preta”: aprova/recusa sem transparência.

5. Perguntas que definem custo e complexidade (checklist de decisão)

A seguir, um checklist que costuma evitar 80% dos erros de contratação e de desenho de fluxo.

5.1 Escopo e risco (define o nível)

• Qual ação do usuário depende do KYC? (cadastrar, comprar, vender, sacar, receber comissão, acessar dados sensíveis?)
• Qual o prejuízo máximo se houver fraude? (financeiro, reputação, chargeback, risco regulatório)
• O KYC é obrigatório para todos ou só para quem atinge um limite? (ex.: só para sacar / só acima de R$ X)
• Você precisa validar pessoa (KYC), empresa (KYB) ou ambos?
• O seu produto precisa de checagens adicionais (listas/PEP/sanções) ou é “só” validação de identidade?

5.2 Experiência e operação (define suporte e funil)

• Qual é o SLA esperado? (instantâneo, em minutos, em horas, em dias)
• O que acontece se o fornecedor ficar fora do ar? (contingência / fila / “volte depois”)
• Quantas tentativas o usuário pode fazer? (e quando vira revisão manual?)
• Existe canal de suporte para “não aprovado”? (e quem responde: você ou o fornecedor?)
• Você precisa de multi‑idioma e documentos de vários países?

5.3 Dados e privacidade (define risco e arquitetura)

• Quais dados você realmente precisa armazenar? (ou só precisa do “resultado” + token?)
• Por quanto tempo é necessário reter evidências? (e por quê?)
• Quem terá acesso interno às imagens/documentos?
• Como você atende solicitações de privacidade (LGPD), inclusive exclusão, quando aplicável?
• Os dados vão para qual país/infra? (isso impacta contratos e governança)

5.4 Integração e produto (define engenharia)

• Você precisa de webhooks para receber o status automaticamente?
• Você precisa de dashboard/backoffice para revisar casos?
• Quais métricas serão acompanhadas? (taxa de aprovação, recusas por motivo, tempo médio, drop‑off)
• Como o app vai guiar a captura (câmera) para reduzir recusa?
• O fluxo precisa existir também no web/admin (além do app)?

6. O que fazer com recusas (sem virar “disputa infinita”)

A recusa não é o problema. O problema é a recusa virar um beco sem saída.

Boas práticas para “recusa acionável”:

1. Dizer o motivo em linguagem simples (“foto borrada”, “documento vencido”, “dados não conferem”).
2. Mostrar como corrigir (iluminação, enquadramento, remover capa, evitar reflexo).
3. Permitir reenvio com limite e com feedback a cada tentativa.
4. Ter fallback: revisão manual (quando o usuário é “bom” e o sistema está incerto).
5. Registrar log (o que foi enviado, quando, resultado) — isso reduz disputa.
6. Ter uma política clara para suspeita de fraude e canal de contestação.

Métrica que você precisa acompanhar: “recusa por motivo”.
Se um motivo domina, não é “culpa do usuário” — geralmente é UX ruim ou regra rígida demais.

7. Responsabilidades (cliente vs fornecedor vs time)

A divisão de responsabilidades precisa estar clara no kickoff. Caso contrário, você cai neste cenário: o fornecedor “recusa”, o usuário reclama, o cliente cobra, e ninguém sabe quem resolve.

Resumo simples:

• Cliente (negócio): define nível, regra, exceções, risco aceitável, política de retenção e comunicação.
• Fornecedor KYC: valida evidências, retorna motivo e status, oferece SLA e logs.
• Time do app/plataforma: desenha o fluxo (UX), integrações (API/webhooks), backoffice, monitoramento e segurança de dados.

8. Privacidade e armazenamento (LGPD): como reduzir risco sem travar o projeto

Como regra geral:

• evite coletar o que você não precisa;
• proteja o que você coletar;
• saiba por quanto tempo precisa manter;
• tenha um processo para atender solicitações do titular.

Na prática, isso vira decisões de arquitetura:

8.1 Armazenar documento “no seu sistema” ou “no fornecedor”?

Duas abordagens comuns:

1. Fornecedor armazena, você guarda só token + resultado
   Menos risco operacional e menos superfície de ataque, mas exige bom contrato e governança.
2. Você armazena (ou replica) imagens/documentos
   Dá mais controle, mas aumenta responsabilidade: criptografia, acesso, auditoria, retenção e exclusão.

Não existe “certo” universal. Existe o que faz sentido para o seu risco, seu compliance e sua capacidade operacional.

8.2 Checklist prático de LGPD para KYC (sem juridiquês)

• Você consegue explicar (para o usuário) por que está pedindo cada dado?
• A política de privacidade menciona validação de identidade/documentos?
• Acesso interno é restrito (perfil e necessidade real)?
• Existe política de retenção (prazo e motivo) e descarte seguro?
• Dados em trânsito e em repouso estão protegidos (HTTPS, criptografia, etc.)?
• Existe plano para incidente (vazamento) e para auditoria?
• Existe procedimento para solicitações do titular (acesso, correção, eliminação quando aplicável)?

Se você também está desenhando fluxos de privacidade/exclusão de conta, este post complementa:
Exclusão de conta e LGPD: como desenhar o fluxo para não reprovar o app

9. Modelo de briefing para contratar KYC (copie e cole)

Se você quiser acelerar alinhamento interno, copie este bloco e preencha:

1. País(es) de operação e tipos de documento aceitos:
2. Nível desejado (básico/intermediário/reforçado) e por quê:
3. Ações que dependem do KYC (ex.: saque, cadastro de prestador, compra):
4. SLA esperado e volume estimado (por dia/mês):
5. Regras de tentativa e reenvio (quantas tentativas / quando vira manual):
6. Lista de checagens extras (liveness, endereço, KYB, listas/AML):
7. Como o status volta para o app (webhook, polling):
8. Evidências e motivos de recusa (formato e granularidade):
9. Backoffice: precisa de revisão manual? Quem revisa?
10. Retenção e armazenamento (quem guarda o quê e por quanto tempo):
11. Exigências de privacidade e segurança (LGPD):
12. Contingência (o que fazer se o serviço cair):

Conclusão

KYC bem desenhado é o que reduz fraude sem travar cadastro e operação.
O segredo não é “o fornecedor mais famoso”, e sim:

• nível certo para o risco,
• fluxo completo (incluindo recusa e exceção),
• processo interno definido,
• e cuidado real com privacidade e armazenamento.

Se você quiser, também vale revisar estes temas que costumam andar juntos com KYC:

• Pagamentos no app: como escolher um gateway sem dor de cabeça
• Split de pagamento e comissão: explicação prática para marketplace
• MFA/2FA para clientes: como não travar o projeto e manter a conta segura