KYC sem fricção: verificar identidade sem perder o usuário

Em fintech, uma das primeiras experiências do cliente costuma acontecer justamente no momento em que a empresa precisa desconfiar dele. Quem está entrando quer abrir a conta, movimentar dinheiro ou começar a usar o produto. A instituição precisa verificar identidade, entender risco, prevenir fraude e cumprir regras que o usuário provavelmente nunca leu.

Esses interesses não precisam entrar em conflito. O problema começa quando toda complexidade de risco é transformada em complexidade para o cliente. Um KYC bem desenhado não remove fricção indiscriminadamente. Ele coloca a fricção certa, na pessoa certa e no momento em que ela realmente é necessária.

O cliente legítimo e o fraudador chegam com disposições diferentes

Existe uma assimetria importante em processos de verificação. O cliente legítimo normalmente quer terminar logo. Está no intervalo do almoço, no ônibus, entre reuniões ou simplesmente tentando concluir uma tarefa que considera burocrática. O fraudador pode ter uma disposição completamente diferente. Ele veio preparado para enfrentar barreiras: tem documento, tenta novamente, muda dispositivo, procura outra combinação, espera. O fraudador tem paciência porque aquilo faz parte do trabalho dele.

Isso cria um problema para o produto. Se a principal estratégia de segurança for simplesmente tornar o processo mais trabalhoso para todo mundo, parte relevante desse custo cai justamente sobre quem a empresa quer aprovar. O objetivo não deveria ser criar o KYC mais rápido possível. Deveria ser fazer o esforço exigido acompanhar o risco observado.

Nem toda verificação precisa acontecer da mesma forma

Em contas de pagamento sujeitas à Resolução BCB nº 96, instituições precisam adotar procedimentos capazes de verificar e validar a identidade e a qualificação do titular e, quando aplicável, de seus representantes. A própria regulamentação admite, em determinados casos, processo de qualificação simplificado acompanhado de limites adequados de saldo e aportes.

Isso revela uma ideia útil também para Product Design: risco pode ser tratado em camadas. Dependendo do produto e das regras aplicáveis, nem toda capacidade precisa necessariamente ser liberada no mesmo momento. O usuário pode passar por uma verificação inicial suficiente para determinado estado da conta e encontrar controles adicionais conforme aumenta o risco da operação.

Essa lógica precisa ser desenhada junto com risco, compliance e jurídico. Não é uma licença para simplesmente adiar verificações obrigatórias. O ponto de produto é outro: não transforme automaticamente todas as verificações possíveis numa sequência única de formulários apresentados para todo usuário.

Explique a razão antes de pedir algo sensível

Compare duas interfaces.

Envie uma foto do seu documento.

e:

Precisamos confirmar sua identidade antes de liberar movimentações nesta conta.

A segunda não torna a tarefa menor. Mas reduz uma dúvida importante: por que vocês precisam disso? Documento, selfie, endereço e informações financeiras não são campos comuns de cadastro. O usuário entende que está entregando algo sensível. Por isso, contexto ajuda.

A explicação também precisa ser verdadeira. Evite justificar toda coleta com uma frase genérica como “o Banco Central exige” quando a exigência real é mais específica ou quando parte das informações decorre da política de risco da própria instituição. É melhor dizer claramente qual é a finalidade.

Usamos esta informação para confirmar sua identidade.

Precisamos deste dado para avaliar os limites disponíveis para a conta.

Uma nova verificação é necessária porque este acesso aconteceu em um dispositivo diferente.

Boa microcopy não serve para tornar uma exigência mais simpática. Serve para deixar claro o que está acontecendo e por quê.

Captura de documento é parte do produto

Uma tela pode estar perfeitamente desenhada e ainda produzir uma experiência ruim porque a câmera falha em condições reais: reflexo, documento cortado, texto desfocado, iluminação ruim, câmera com dificuldade de foco, permissão negada, arquivo incompatível. Quando a resposta para tudo isso é:

Documento inválido.

o produto transferiu seu problema técnico para o cliente. Uma captura melhor tenta evitar o erro antes do envio e, quando não consegue, explica o que precisa mudar. Alguns recursos ajudam:

• enquadramento visível;

• indicação de distância;

• validação de foco ou legibilidade quando tecnicamente disponível;

• exemplo do documento esperado;

• orientação específica quando alguma parte ficou cortada;

• possibilidade de tentar novamente sem perder o restante do progresso.

A diferença entre “falhou” e “a frente do documento ficou fora do enquadramento” é enorme. No primeiro caso, o usuário precisa adivinhar. No segundo, sabe o que corrigir.

Espera também precisa de interface

Nem toda decisão acontece imediatamente. Pode existir análise adicional, checagem externa ou revisão manual. Nesses momentos, o produto muda de tarefa. A pessoa já enviou o que precisava. Agora ela quer saber: deu certo? Quanto tempo leva? Preciso continuar nesta tela? Vocês vão me avisar? Posso usar alguma coisa enquanto isso?

Se o produto mostra apenas:

Estamos analisando seus dados.

e nada mais, o usuário não sabe se deve esperar trinta segundos ou dois dias. Quando for possível, informe um prazo realista. Permita fechar o aplicativo sem perder progresso. Avise quando houver mudança de estado. E, se regras e política de risco permitirem alguma funcionalidade antes da conclusão de verificações adicionais, deixe explícito o que está ou não disponível. O importante é não confundir espera do sistema com espera da interface.

Recusa não pode fingir que antifraude é atendimento ao cliente comum

Existe outro extremo perigoso: defender que toda recusa precisa explicar exatamente o motivo. Nem sempre pode. Regras de risco, prevenção à fraude e obrigações de confidencialidade podem limitar o nível de detalhe que a instituição deve expor. Mas existe uma diferença entre não revelar uma regra de segurança e abandonar o usuário com:

Não foi possível continuar.

Quando aplicável, a interface pode informar:

• que a análise não pôde ser concluída;

• se existe algum documento que pode ser reenviado;

• se há possibilidade de revisão;

• qual canal deve ser usado;

• quanto tempo uma nova análise pode levar.

A comunicação precisa respeitar os limites operacionais e regulatórios sem transformar uma decisão complexa em um beco sem saída.

KYC de pessoa física e de empresa não é a mesma jornada

Uma conta empresarial pode envolver muito mais do que um formulário com CNPJ. Dependendo do tipo de empresa e do produto, o processo pode precisar identificar representantes, estrutura societária, beneficiários finais, poderes de representação e outras informações necessárias à qualificação. E nem sempre uma única pessoa possui tudo. Quem iniciou o processo pode ser alguém do financeiro, um sócio precisa confirmar alguma informação, outro representante tem determinado documento, o responsável legal precisa aprovar.

Isso muda o desenho. Um fluxo PJ precisa considerar coisas como:

• salvar e continuar depois;

• mostrar claramente o que ainda falta;

• permitir participação de outras pessoas quando o processo exigir;

• identificar quem precisa executar cada etapa;

• preservar documentos e informações já válidos;

• deixar claro por que a análise está parada.

O modelo mental deixa de ser:

preencher cadastro.

E passa a ser:

concluir um processo com múltiplas dependências.

Essa diferença é muito importante em produtos B2B.

Antifraude não precisa virar uma coleção de barreiras visíveis

Muitos sinais de risco podem ser avaliados sem adicionar uma nova tela para o usuário. Dependendo da arquitetura e das regras do produto, sistemas antifraude podem considerar dispositivo, contexto do acesso, histórico de tentativas, padrões de comportamento e outros sinais. Esses dados ajudam a decidir quando vale aumentar a exigência de verificação. Um acesso esperado num dispositivo conhecido pode receber um tratamento. Uma mudança relevante de contexto ou uma operação atípica pode justificar outro.

O princípio é: mais risco pode justificar mais evidência. Isso é diferente de exigir a jornada mais rígida possível de qualquer pessoa porque uma pequena parcela pode representar ameaça. O modelo precisa ser construído com cuidado para não criar discriminação indevida, falsos positivos ou decisões impossíveis de revisar. Product Design entra justamente na tradução dessas decisões para estados compreensíveis do produto.

Reverificação também faz parte da experiência

A abertura de conta não é o único momento em que identidade pode precisar ser confirmada. Troca de dispositivo, alteração de dados importantes, recuperação de acesso, comportamento atípico, operação sensível. Dependendo do contexto, novas verificações podem aparecer quando o cliente já utiliza o produto há meses. E normalmente surgem no pior momento possível: quando ele está tentando fazer alguma coisa.

Por isso, reverificação precisa preservar contexto. Se uma transferência foi interrompida para uma confirmação adicional, o usuário deveria entender o que acontecerá depois de concluir a etapa. Vai voltar para a transferência? Precisa preencher tudo novamente? A operação ficou salva? Algum valor foi movimentado? Esse cuidado evita transformar uma medida de segurança em dúvida sobre dinheiro.

Métricas precisam separar fricção útil de fricção ruim

O objetivo não deveria ser simplesmente aumentar a taxa de aprovação. Uma fintech que aprova todo mundo rapidamente provavelmente não resolveu o problema. Também não basta comemorar que “fraude caiu” se clientes legítimos começaram a ser bloqueados em volume relevante. Alguns indicadores ajudam a enxergar o equilíbrio:

• conclusão do processo por etapa;

• primeira tentativa de captura aceita;

• tempo mediano até uma decisão;

• percentual enviado para análise adicional;

• tempo em análise;

• necessidade de reenvio de documento;

• decisões revertidas após revisão;

• abandono por etapa e dispositivo.

Nenhum número conta a história sozinho. Uma queda na aprovação na primeira tentativa pode ser câmera, documento, regra antifraude ou mudança no perfil de quem está entrando. O dado serve para indicar onde investigar.

A LGPD faz parte do desenho da experiência

KYC também envolve tratamento de dados pessoais. A LGPD classifica dado biométrico vinculado a uma pessoa natural como dado pessoal sensível. Isso significa que biometria não deveria ser tratada como apenas mais um campo de onboarding. O tratamento precisa estar enquadrado em base legal adequada, obedecer à finalidade definida e respeitar princípios como necessidade e transparência.

Para produto, algumas perguntas são importantes. Por que estamos coletando esse dado? Precisamos mesmo dele neste momento? Como a finalidade é explicada para a pessoa? Quem terá acesso? Por quanto tempo será mantido? O que acontece com ele depois?

A resposta jurídica depende do contexto concreto e não deve ser inventada pelo designer. Mas a experiência de apresentar essa resposta é definitivamente um problema de design. Texto jurídico escondido no final de uma política de privacidade não substitui contexto no momento em que uma informação sensível é solicitada.

KYC é a primeira demonstração de como a fintech lida com complexidade

Para o time interno, verificação pode ser uma sequência de fornecedores, regras, scores, documentos e análises. Para o usuário, existe apenas uma experiência. Ele não separa KYC, antifraude, PLD, cadastro e onboarding. Ele sabe que está tentando abrir ou usar uma conta.

É por isso que tratar KYC como formulário regulatório produz experiências tão ruins. A complexidade continua existindo. O trabalho de produto é decidir quanto dela realmente precisa chegar à interface. Quando o risco é baixo, talvez o usuário atravesse quase sem perceber. Quando aumenta, o produto pede mais evidência. Quando existe espera, explica o estado. Quando algo falha, ajuda a corrigir. Quando não pode revelar o motivo, pelo menos deixa claro o que ainda pode ser feito.

O melhor KYC não é necessariamente o mais curto. É aquele em que cada fricção tem uma razão que o produto consegue defender. E, para o cliente legítimo, o sistema trabalha o máximo possível para que segurança não pareça punição.

Fontes

Banco Central do Brasil. Resolução BCB nº 96, de 19 de maio de 2021, versão vigente. Dispõe sobre abertura, manutenção e encerramento de contas de pagamento. O art. 4º exige procedimentos e controles capazes de verificar e validar identidade e qualificação do titular e, quando aplicável, de seus representantes. A norma admite processo de qualificação simplificado acompanhado de limites adequados e compatíveis de saldo e aportes em determinadas contas de pagamento.

Banco Central do Brasil. Circular nº 3.978, de 23 de janeiro de 2020. Estabelece procedimentos e controles internos relacionados à prevenção da utilização do sistema financeiro para lavagem de dinheiro e financiamento do terrorismo, incluindo procedimentos de conhecimento, identificação e qualificação de clientes. Este artigo não constitui orientação jurídica.

Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais (LGPD). Classifica dados biométricos vinculados a pessoa natural como dados pessoais sensíveis e estabelece princípios e requisitos para o tratamento de dados pessoais, incluindo necessidade e transparência. Este artigo não constitui orientação jurídica.

Nielsen Norman Group. “10 Usability Heuristics for User Interface Design”, Jakob Nielsen. As heurísticas de visibilidade do estado do sistema, prevenção de erros e suporte à recuperação ajudam a fundamentar as recomendações de feedback e comunicação apresentadas no artigo.