Como comunicar segurança sem assustar o cliente

Segurança é um dos argumentos mais mal comunicados em produtos financeiros. Ou vira um parágrafo jurídico que ninguém lê, ou aparece como uma sequência de alertas sobre fraude, golpe e roubo de dados justamente no momento em que o usuário estava prestes a confiar.

O problema é que segurança não funciona apenas quando existe. Ela também precisa ser percebida. Em fintech, essa percepção faz parte do produto. Antes de movimentar dinheiro, enviar um documento ou cadastrar um cartão, a pessoa precisa sentir que entende o que está acontecendo e que existe controle sobre aquela ação. Confiança é o que a pessoa compra antes de comprar qualquer coisa.

Falar demais sobre risco também cria risco percebido

Imagine uma tela de transferência com três avisos:

Cuidado com golpes.

Nunca transfira para desconhecidos.

Verifique os dados antes de continuar.

As mensagens podem ter sido colocadas com boa intenção. Mas, juntas, também podem produzir uma sensação inesperada:

isso aqui parece perigoso.

Segurança mal comunicada obriga o usuário a pensar constantemente na ameaça. Uma abordagem melhor é mostrar proteção em ação. Em vez de:

Atenção: sua conta pode ser acessada por terceiros.

prefira, quando for verdadeiro para aquele contexto:

Vamos confirmar sua identidade antes de continuar.

Em vez de um aviso genérico sobre fraude:

Confira o nome e os dados do destinatário antes de confirmar esta transferência.

A diferença está no objeto da mensagem. Uma descreve um perigo abstrato. A outra ajuda a tomar uma decisão concreta.

A garantia precisa aparecer onde nasce a dúvida

Selo de segurança no rodapé da home pode ter alguma função institucional. Mas ele ajuda pouco quando a pessoa está com o cartão na mão se perguntando quem terá acesso àqueles dados. A comunicação funciona melhor quando acompanha o contexto.

Ao pedir documento

Explique por que aquela informação é necessária e qual função ela cumpre no processo.

Ao cadastrar um método de pagamento

Deixe claro o que será processado, por quem e, quando relevante, como os dados serão tratados.

Antes de movimentar um valor alto

Destaque destinatário, valor e consequências da confirmação.

Num dispositivo novo

Explique por que existe uma verificação adicional e o que fazer caso aquele acesso não tenha sido iniciado pelo próprio usuário.

Ao alterar um dado sensível

Confirme a mudança e permita reconhecer rapidamente uma alteração não autorizada.

A regra não é colocar uma mensagem de segurança em toda tela. É identificar onde o usuário precisa de uma garantia para continuar com confiança.

Autenticação protege melhor quando respeita o risco

Segundo fator é uma camada importante de segurança e pode ser obrigatório em contextos específicos. Isso não significa que toda ação de todo usuário precise receber exatamente a mesma fricção. Um produto pode considerar contexto, risco da operação, dispositivo, sessão e regras aplicáveis para decidir quando elevar a autenticação.

Essa lógica também evita outro problema: transformar segurança em sequência de obstáculos previsíveis. Código que expira antes de chegar, SMS que não aparece, aplicativo autenticador exigido sem nenhuma explicação, código que não pode ser colado, fluxo de recuperação que termina pedindo para falar com o suporte. Cada uma dessas situações pode transformar uma medida de proteção numa causa de abandono.

O problema fica ainda mais sério na recuperação de acesso. Quem esqueceu uma senha ou perdeu o dispositivo já está numa situação de tensão. Se o caminho de recuperação for obscuro, essa pessoa não sente que o produto está mais protegido. Sente que perdeu o controle da própria conta.

Uma boa experiência de autenticação precisa pensar também em:

• métodos adequados ao nível de risco;

• instruções compreensíveis;

• códigos que funcionam bem com autofill e colagem quando aplicável;

• estados claros durante a verificação;

• recuperação segura quando o método principal deixou de existir.

Segurança não termina no login bem-sucedido.

Um incidente operacional e um incidente de dados não são a mesma coisa

Produto financeiro precisa comunicar problemas diferentes: uma indisponibilidade temporária, uma cobrança duplicada, uma transferência atrasada, uma falha de processamento, um incidente que envolveu dados pessoais. Todos podem afetar confiança, mas não deveriam receber a mesma comunicação.

Numa falha operacional, o cliente quer respostas práticas: o que aconteceu, minha operação foi concluída, meu dinheiro está seguro, preciso fazer alguma coisa, quando isso será resolvido. Se uma cobrança apareceu duas vezes, por exemplo, “identificamos uma instabilidade” é insuficiente. A pessoa precisa saber se houve duplicidade real, se haverá estorno e se deve evitar uma nova tentativa.

Já incidentes de segurança envolvendo dados pessoais podem trazer obrigações específicas. Quando um incidente for capaz de acarretar risco ou dano relevante aos titulares, a regulamentação da ANPD prevê comunicação à autoridade e aos titulares nos casos aplicáveis. Nesse cenário, comunicação deixa de ser apenas decisão de UX ou reputação. Também faz parte da resposta ao incidente.

Transparência não compensa um problema mal resolvido

Quando algo dá errado, comunicação pesa muito na confiança. Mas ela não substitui resolução. Um incidente grave continua grave mesmo com uma ótima mensagem. Falhas recorrentes não deixam de incomodar porque a empresa escreve bem. Por isso, a comunicação deveria acompanhar a resposta real. Uma boa estrutura costuma responder:

1. O que aconteceu

2. Quem ou o que pode ter sido afetado

3. O que a empresa já fez

4. O que ainda está acontecendo e qual é a expectativa de prazo

5. O que o cliente precisa fazer, se precisar fazer algo

Se uma dessas informações ainda não existe, diga isso com clareza.

Ainda estamos verificando quais operações foram afetadas. Atualizaremos este status assim que essa análise terminar.

Isso transmite muito mais controle do que:

Nossa equipe está trabalhando para resolver o problema o mais rápido possível.

A segunda frase parece comunicação. Na prática, quase não contém informação.

Em B2B, segurança também faz parte da venda

Para uma fintech ou SaaS financeiro vender para outra empresa, a decisão raramente termina na demonstração do produto. Segurança, tecnologia, jurídico e compliance podem entrar na avaliação. É comum o comprador precisar descobrir coisas como:

• como funciona controle de acesso;

• se existe MFA;

• quais dados são armazenados;

• quais práticas existem para proteção e retenção;

• como incidentes são tratados;

• quais fornecedores críticos participam da operação;

• quais certificações, auditorias ou controles a empresa realmente possui.

Quando essas respostas estão espalhadas entre documentos, conversas e tickets, o processo comercial fica mais lento. Uma página de segurança ou trust center pode organizar essa informação em camadas. No primeiro nível:

como protegemos o produto e seus dados.

Depois:

controles, arquitetura e políticas relevantes.

E, para quem precisa aprofundar:

documentação técnica e evidências disponíveis.

O gestor não deveria precisar interpretar um whitepaper para entender a postura de segurança. E o responsável técnico não deveria receber apenas a frase “usamos segurança de nível bancário”.

“Segurança de nível bancário” não explica nada

Existe uma tentação grande de escrever sobre segurança usando palavras que parecem fortes. “Criptografia militar.” “Segurança de nível bancário.” “Proteção máxima.” “Tecnologia de ponta.” O problema é que nenhuma delas ajuda o usuário a verificar o que está sendo prometido. Prefira afirmações específicas.

Mas existe um cuidado igualmente importante: não transforme simplificação em promessa falsa. Por exemplo:

Ninguém além de você consegue ver esses dados.

Essa frase só deveria existir se a arquitetura realmente garantir isso. Dependendo do sistema, funcionários autorizados, processadores, serviços antifraude ou outros componentes podem participar do tratamento. Traduzir um mecanismo técnico para linguagem simples não significa exagerar o efeito dele.

Se o produto usa criptografia durante transmissão, diga isso de maneira compreensível. Se determinado dado não é armazenado pela empresa, diga. Se um fornecedor certificado processa o pagamento, explique qual papel ele cumpre. A boa comunicação simplifica a verdade. Não inventa uma verdade mais confortável.

Golpe usando sua marca também entra na experiência

Uma fintech pode ter infraestrutura segura e ainda ver clientes perdendo dinheiro para alguém que usa seu nome no WhatsApp. Do ponto de vista técnico, o golpe aconteceu fora do sistema. Do ponto de vista da pessoa, a marca continua no centro da experiência.

Por isso existe valor em ajudar o cliente a verificar autenticidade. Não apenas com campanhas dizendo:

nunca compartilhe sua senha.

Mas com mecanismos concretos: quais canais oficiais a empresa realmente utiliza, o que um atendente nunca pedirá, como confirmar se uma mensagem recebida é verdadeira, onde denunciar um contato suspeito, como falar rapidamente com a empresa quando houver dúvida. Em alguns produtos, pode fazer sentido manter dentro do aplicativo um histórico de contatos ou notificações oficiais.

Agora o usuário não precisa lembrar de uma campanha de conscientização. Ele consegue verificar. Essa é uma diferença importante entre educar sobre segurança e dar ferramentas para agir com segurança.

Segurança precisa aparecer nos estados, não apenas no discurso

A percepção de proteção é construída em momentos pequenos. Durante o KYC, quando o produto explica por que precisa de um documento. No checkout, quando deixa claro o que aconteceu depois de uma tentativa de pagamento. Numa transferência, quando destinatário e valor ficam inequívocos antes da confirmação. Numa sessão nova, quando o usuário entende por que precisa se autenticar novamente. Numa recuperação, quando consegue provar que é o titular sem entrar num labirinto.

É por isso que segurança não deveria ser tratada como uma camada de texto adicionada depois que o produto está pronto. Ela participa dos estados, da hierarquia, da microcopy e das decisões de interação.

O usuário não precisa sentir medo para perceber proteção

Uma boa experiência de segurança não tenta fazer o risco desaparecer. Também não lembra o usuário dele o tempo inteiro. Ela mostra que existe controle. Quando uma ação é sensível, existe confirmação. Quando algo está sendo verificado, isso fica claro. Quando o risco aumenta, a proteção aumenta junto. Quando algo falha, o usuário entende o estado. Quando existe um incidente, a empresa comunica o que sabe, o que está fazendo e o que o cliente precisa fazer.

Esse equilíbrio é especialmente importante em produto financeiro. A segurança mais sofisticada do mundo produz pouca confiança se o usuário não consegue entender o que o sistema está fazendo por ele. E uma interface que parece tranquilizadora não compensa proteção insuficiente. O trabalho de Product Design está justamente em aproximar as duas coisas: proteção real e proteção compreensível.

Fontes

Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais (LGPD). Estabelece princípios, direitos e obrigações relacionados ao tratamento de dados pessoais no Brasil, incluindo transparência, necessidade e deveres relacionados à segurança da informação. Este artigo não constitui orientação jurídica.

ANPD. Resolução CD/ANPD nº 15, de 24 de abril de 2024. Regulamenta a comunicação de incidentes de segurança. Nos casos em que o incidente possa acarretar risco ou dano relevante aos titulares, a regulamentação estabelece comunicação pelo controlador à ANPD e aos titulares nos termos aplicáveis.

NIST. Digital Identity Guidelines, SP 800-63B-4. Referência técnica para autenticação digital e níveis de garantia. O padrão diferencia requisitos conforme o nível de assurance e inclui autenticação multifator em contextos de maior garantia.

Nielsen Norman Group. “10 Usability Heuristics for User Interface Design”, Jakob Nielsen. As heurísticas de visibilidade do estado do sistema, prevenção e recuperação de erros ajudam a fundamentar a necessidade de comunicação clara durante autenticação, processamento e incidentes.