Cybersecurity para Fintechs no Brasil

Fintech nasce rápida: produto na nuvem, deploy várias vezes por dia, time enxuto. O regulador e o fraudador, porém, não dão desconto por ser startup. A partir do momento em que a empresa movimenta dinheiro de terceiros, passa a responder ao Banco Central, à ANPD e, se processa cartão, ao PCI DSS. E passa a ser alvo de uma indústria de fraude que já opera em escala industrial no Brasil.

Este guia organiza o que o BACEN efetivamente exige, onde as fintechs mais falham e como montar um programa de segurança que atende o regulador sem travar o produto.

Quem está sujeito a quê

O primeiro passo é saber em qual caixa regulatória a empresa está, porque ela define o nível de exigência:

• Instituições financeiras (bancos, SCDs, SEPs, financeiras): Resolução CMN nº 4.893/2021, que trata de política de segurança cibernética e contratação de processamento, armazenamento de dados e computação em nuvem
• Instituições de pagamento autorizadas pelo BCB: Resolução BCB nº 85/2021, com requisitos equivalentes para esse segmento
• Participantes do Pix e do Open Finance: regulamentos próprios, com requisitos técnicos de segurança, autenticação e gestão de risco de fraude
• Toda empresa que trata dado pessoal: LGPD e o regulamento de comunicação de incidentes da ANPD
• Quem armazena, processa ou transmite dados de cartão: PCI DSS 4.0, cujos requisitos antes marcados como futuros passaram a ser obrigatórios em março de 2025

Fintechs que ainda não são autorizadas, como correspondentes ou empresas que operam por meio de um banco parceiro (BaaS), não estão diretamente sob essas resoluções. Na prática, herdam as exigências por contrato: o parceiro regulado precisa demonstrar ao BCB que controla o risco dos seus terceiros e repassa os requisitos.

O que o BACEN exige na prática

As resoluções não mandam comprar ferramenta. Exigem que a instituição tenha um programa documentado, proporcional ao seu porte e perfil de risco, e que consiga provar que ele funciona. Os blocos centrais:

Política de segurança cibernética

Documento aprovado pela diretoria ou pelo conselho, com objetivos, procedimentos e controles para prevenir, detectar e reduzir a vulnerabilidade a incidentes. Precisa cobrir autenticação, criptografia, prevenção e detecção de intrusão, prevenção de vazamento, testes e varreduras de vulnerabilidade, proteção contra software malicioso, rastreabilidade, cópias de segurança e controle de acesso.

Diretor responsável

Um diretor formalmente designado responde pela política e pelo plano de resposta. Não é cargo decorativo: é quem assina e quem é chamado quando algo dá errado.

Plano de ação e de resposta a incidentes

Rotinas, procedimentos e controles para implementar a política, incluindo o tratamento de incidentes relevantes. Um plano genérico, copiado de modelo, não sobrevive à primeira inspeção. Veja como estruturar um plano de resposta a incidentes executável.

Relatório anual

A instituição elabora um relatório sobre a implementação do plano de ação e de resposta a incidentes, com os incidentes relevantes do período, as ações de prevenção e resposta e os resultados dos testes de continuidade. O relatório é apresentado à governança da instituição e fica disponível para o Banco Central.

Comunicação de incidentes

Incidentes relevantes e interrupções de serviços relevantes precisam ser comunicados ao Banco Central, com a descrição do impacto e das providências. "Relevante" é definido pela própria instituição na política, e é aí que muitas fintechs erram: deixam o critério vago e depois não sabem se precisavam ter comunicado.

Nuvem e terceiros

A contratação de serviços relevantes de processamento, armazenamento de dados e computação em nuvem exige avaliação prévia do fornecedor, cláusulas contratuais mínimas (acesso a dados e informações pelo regulador, continuidade, confidencialidade, localização dos dados) e comunicação ao Banco Central. Para fintech 100% cloud, essa é uma das partes mais trabalhosas de documentar.

Onde as fintechs mais falham

Nas avaliações que fazemos, os mesmos pontos aparecem com frequência:

1. Política que não conversa com a operação. O documento diz que há revisão trimestral de acessos; ninguém faz. Na inspeção, a distância entre papel e prática é o achado mais grave.
2. Critério de incidente relevante indefinido. Sem régua objetiva (volume de clientes, valor, indisponibilidade, dado exposto), cada incidente vira uma discussão, e a comunicação atrasa.
3. Segredos no código e em pipelines. Chaves de API, tokens de parceiros e credenciais de banco de dados em repositórios e variáveis de CI mal protegidas.
4. APIs sem autorização por objeto. IDOR e falhas de autorização em endpoints de conta e extrato continuam sendo a vulnerabilidade mais explorada em fintechs. O pentest de APIs precisa testar isso explicitamente.
5. Nuvem sem inventário. Buckets, funções e ambientes de homologação expostos que ninguém lembra de ter criado. Sem mapa da superfície de ataque, não há como proteger.
6. Logs sem retenção nem correlação. Existe log, mas ninguém olha, e quando o incidente acontece a janela de retenção já passou.

Fraude é o outro lado da segurança

Para fintech, segurança cibernética e prevenção à fraude não podem viver em times que não se falam. O golpe de engenharia social que leva o cliente a fazer um Pix não é "problema do cliente" quando o regulador avalia se a instituição tinha controles de risco adequados.

O Pix endureceu as regras em 2024: limites para transações iniciadas em dispositivos não cadastrados, uso obrigatório de solução de gerenciamento de risco de fraude e consulta às marcações de fraude do DICT. O Mecanismo Especial de Devolução (MED) permite recuperar recursos em casos de fraude, mas depende de a instituição agir rápido.

Na prática, o programa precisa de:

• Monitoramento transacional em tempo real, com sinais de dispositivo, comportamento e rede
• Detecção de contas laranja na própria base, antes que recebam dinheiro de golpe
• Monitoramento de marca: sites falsos, perfis falsos e apps clonados usando o nome da fintech, com OSINT e fraud hunting
• Integração entre o SOC e o time de fraude, porque a conta tomada começa com uma credencial vazada

LGPD e ANPD

Fintech trata dado pessoal e, com frequência, dado financeiro sensível do ponto de vista do cliente. Desde 2024, o regulamento de comunicação de incidentes da ANPD fixa prazo de três dias úteis para comunicar à autoridade e aos titulares o incidente que possa acarretar risco ou dano relevante. Três dias úteis é pouco se o plano de resposta não prevê quem decide, com quais informações e com qual texto. Veja mais em LGPD, ISO 27001 e segurança.

Um programa em quatro camadas

Uma forma de organizar o programa sem travar o produto:

A camada de validação é a que mais pesa na conversa com o regulador, porque é a que prova que as outras funcionam. O TIBER-EU, referência europeia de Red Team regulatório, indica para onde os reguladores tendem a caminhar. Entenda o modelo em TIBER-EU e o Red Team regulatório no Brasil.

Por onde começar

Para uma fintech que ainda não tem programa estruturado, a ordem que costuma dar mais resultado em 90 dias:

1. Definir o critério de incidente relevante e o fluxo de comunicação (BCB, ANPD, parceiros, clientes)
2. Inventariar ativos expostos e fornecedores de nuvem relevantes
3. Fazer pentest de APIs e aplicação, com foco em autorização e lógica de negócio
4. Centralizar logs de autenticação, APIs e nuvem, com retenção definida
5. Revisar a política para refletir o que de fato é feito, e só então aprovar

Conclusão

A regulação do BACEN não pede que a fintech seja um banco grande. Pede que ela conheça seus riscos, tenha controles proporcionais e consiga provar que eles funcionam. A diferença entre passar ou não por uma inspeção raramente está na ferramenta; está na coerência entre o que a política diz, o que a operação faz e o que os testes mostram.

Conformidade contínua, e não relatório de gaveta, é o que o TrustSentinel mede: aderência a BACEN, LGPD, PCI DSS e ISO 27001 acompanhada ao longo do ano, não só na véspera da auditoria.