Segurança de embedded finance: quando o risco está na empresa não-financeira

Imagine a seguinte cena: você abre seu aplicativo favorito de delivery de comida para pedir o jantar. A interface é fluida, o cartão já está salvo, a compra acontece em um clique. A experiência do usuário beira a perfeição. Agora imagine que, por trás dessa tela inofensiva de hambúrgueres e pizzas, roda uma engrenagem financeira complexa que concede crédito, movimenta contas digitais e processa pagamentos via PIX. Você não está mais apenas em um app de comida. Você está dentro de um banco disfarçado de restaurante.

Essa é a mágica do embedded finance. Ao plugar APIs de provedores de Banking as a Service (BaaS) como Dock, Celcoin ou Pismo, qualquer empresa hoje pode oferecer serviços financeiros. O varejista vira fintech. A montadora de carros vira seguradora. A operadora de telecom vira banco digital. O mercado brasileiro abraçou essa tese com uma agressividade ímpar. Dados recentes mostram que o volume transacionado via embedded finance no Brasil ultrapassou a marca de R$ 400 bilhões anuais em 2025.

Mas existe um elefante na sala que poucos querem encarar. Quando transformamos um e-commerce em uma instituição de pagamento, herdamos os superpoderes bancários, mas frequentemente esquecemos de importar a armadura. O fraudador cibernético sabe ler essa assimetria. Ele não vai tentar invadir os servidores blindados do provedor de BaaS. Ele vai chutar a porta dos fundos: o aplicativo de varejo.

A Ilusão do Cofre Forte e a Realidade das APIs

Observamos uma falsa sensação de segurança no mercado corporativo brasileiro. CEOs de varejistas costumam pensar: 'Contratamos um provedor de BaaS homologado pelo Banco Central. A segurança é problema deles'. Essa premissa é letal. O provedor de BaaS fornece o motor do carro e garante que ele não vai explodir. Mas quem desenha as portas, as travas e decide quem ganha a chave do veículo é a empresa não-financeira.

A arquitetura do embedded finance funciona essencialmente através de APIs (Application Programming Interfaces). O aplicativo da loja de roupas comúnica-se com os servidores do banco parceiro solicitando a abertura de uma conta ou a liquidação de um pagamento. O banco confia nessa requisição porque ela vem assinada com credenciais criptográficas estabelecidas em contrato.

Aqui mora o perigo. Se um cibercriminoso conseguir comprometer a infraestrutura do varejista — ou pior, roubar a sessão de um usuário legítimo dentro do app da loja —, o provedor de BaaS receberá uma ordem perfeitamente válida e autenticada para transferir dinheiro. Para o sistema bancário, a transação é legítima. Para o cliente fraudado, o dinheiro sumiu.

O Paradoxo da Fricção: UX contra a Segurança

Bancos tradicionais são chatos por um motivo. Eles exigem senhas complexas, reconhecimento facial, tokens físicos, confirmação em dois fatores (2FA) e bloqueiam sua conta se você tentar fazer um PIX de madrugada de um IP desconhecido. Essa fricção salva bilhões de reais anualmente.

Empresas não-financeiras, por outro lado, nasceram adorando a ausência de fricção. No e-commerce, cada clique extra no checkout derruba a taxa de conversão em até 15%. O mantra do Vale do Silício e da Faria Lima sempre foi fácilitar. O resultado? Aplicativos que mantêm o usuário logado perpetuamente, processos de recuperação de senha baseados apenas em um SMS (fácilmente interceptável via SIM Swap) e ausência de biometria para transações de baixo valor.

Quando você injeta uma carteira digital (wallet) dentro de um ambiente desenhado para não ter fricção, você cria o paraíso do fraudador. O cibercriminoso compra lotes de senhas vazadas na dark web, aplica técnicas de credential stuffing (testar a mesma senha em vários sites) e invade a conta do usuário no app de farmácia. Uma vez lá dentro, ele não quer comprar remédios. Ele quer limpar o saldo da carteira digital embutida ou estourar o limite de crédito pré-aprovado.

Vetores de Ataque Inéditos no Mercado Brasileiro

Nossa análise de incidentes recentes revela que o crime organizado digital no Brasil parou de atacar a infraestrutura central (core banking) e migrou quase 100% dos seus esforços para as bordas (edge). As empresas não-financeiras oferecem uma superfície de ataque muito mais ampla e menos monitorada.

Sequestro de Sessão e Tokens JWT

A maioria dos aplicativos modernos usa tokens JWT (JSON Web Tokens) para manter o usuário autenticado. Se a empresa de varejo armazena esses tokens de forma insegura no dispositivo do cliente, malwares bancários — que infestam celulares Android no Brasil — podem roubar esse token. O hacker então clona a sessão do usuário em outro aparelho. Como o app de varejo muitas vezes não faz a validação do device ID (identificador do aparelho) cruzado com o motor de risco do BaaS, o roubo acontece silenciosamente.

Vulnerabilidades na Lógica de Negócios

Outro vetor clássico envolve a manipulação das APIs. Hackers interceptam a comúnicação entre o app do cliente e os servidores do varejista. Se a empresa não-financeira não implementar validações rigorosas (como mTLS - mutual TLS e pinning de certificados), o fraudador pode alterar parâmetros das requisições.

Um caso prático documentado no último ano envolveu um app de mobilidade urbana. O atacante descobriu que, ao recarregar a carteira digital do app, a API do cliente enviava o valor do pagamento para o servidor. Alterando o pacote de dados, o hacker conseguiu injetar R$ 10.000 de saldo pagando apenas R$ 10 via cartão de crédito. A API do BaaS operou perfeitamente: ela recebeu a ordem do app de mobilidade para creditar os 10 mil reais. A falha estava na regra de negócios da empresa não-financeira.

O Peso da Resolução 85 do BACEN

O Banco Central do Brasil não está dormindo no ponto. A Resolução CMN nº 4.893, que tratava de política de segurança cibernética, foi substituída pela Resolução nº 85, trazendo exigências muito mais granulares para instituições de pagamento e financeiras. Mas como isso afeta a empresa de varejo que não é regulada diretamente pelo BACEN?

A matemática é simples. O provedor de BaaS (este sim regulado) é legalmente responsável por toda a cadeia. A Resolução 277 do BACEN, que trata de terceirização de serviços, obriga a instituição regulada a garantir que seus parceiros e correspondentes mantenham o mesmo nível de segurança cibernética exigido dela mesma.

Na prática, provedores como BTG Pactual, Itaú BBA (via suas operações de BaaS) e players nativos como Dock estão apertando os parafusos dos seus clientes corporativos. As SLAs (Service Level Agreements) agora incluem cláusulas draconianas de segurança. Se o vazamento ou a fraude ocorrer por negligência nas APIs da empresa não-financeira, as multas e o ressarcimento aos clientes finais são integralmente repassados ao varejista. Em casos extremos, o provedor de BaaS pode desconectar o cliente da rede do Sistema Financeiro Nacional (SFN) sumariamente, paralisando a operação.

Responsabilidade Solidária: Quem Paga a Conta?

Se você opera um e-commerce ou um aplicativo de serviços e decidiu embutir uma conta digital, preste atenção aqui. O Supremo Tribunal Federal (STF) e o Superior Tribunal de Justiça (STJ) têm firmado jurisprudência dura sobre fraudes bancárias (Súmula 479 do STJ). A responsabilidade é objetiva. O risco é inerente à atividade.

Quando um cliente tem seu dinheiro roubado do seu app, ele vai processar a sua marca. Ele não conhece a processadora obscura de BaaS que roda no backend. O dano reputacional cai no seu colo. E a conta financeira também. A cadeia de responsabilidade solidária significa que o Procon e o Banco Central vão cobrar o provedor de BaaS, que por sua vez executará as garantias contratuais contra a sua empresa.

Vimos recentemente uma grande rede de postos de combustíveis enfrentar uma crise severa quando fraudadores descobriram como burlar o sistema de cashback do seu app, convertendo pontos falsos em transferências PIX reais via API do parceiro bancário. O prejuízo passou dos R$ 15 milhões em poucas semanas. A falha? O app não exigia reautenticação (MFA) para solicitar resgates de alto valor.

Implicações Práticas: Como Blindar a Operação

A transição de uma empresa de tecnologia ou varejo para uma operação de embedded finance exige uma mudança cultural profunda. Não se trata apenas de instalar um firewall. Trata-se de adotar a mentalidade de 'Security by Design' e 'Zero Trust' (Confiança Zero).

1. Implemente Fricção Inteligente

Não tenha medo de incomodar o usuário quando o dinheiro dele estiver em jogo. A biometria facial no momento de uma transferência de alto valor não é um atrito; é um diferencial de confiança. Use motores de risco comportamental. Se o usuário costuma acessar o app de São Paulo às 14h, e de repente tenta fazer um PIX às 3h da manhã de um IP da Rússia, a transação deve ser bloqueada ou exigir autenticação severa.

2. Proteção de APIs (API Gateway e WAF)

Suas APIs são vitrines abertas para o mundo. O uso de um Web Application Firewall (WAF) dedicado a APIs é inegociável. Limite a taxa de requisições (raté limiting) para impedir ataques de força bruta. Implemente mTLS nas comúnicações server-to-server com o provedor de BaaS. Nunca confie nos dados enviados pelo front-end (aplicativo do cliente) sem validá-los no back-end.

3. Gestão de Identidade e Acesso (IAM)

Adote o princípio do menor privilégio, tanto para usuários externos quanto internos. Um erro comum é permitir que desenvolvedores do varejista tenham acesso a chaves de produção das APIs financeiras. Qualquer credencial vazada de um funcionário pode virar a chave mestra de um ataque devastador.

4. Testes de Invasão (Pentest) Contínuos

O modelo antigo de fazer um teste de invasão por ano morreu. Com ciclos de desenvolvimento ágil (CI/CD) subindo atualizações para o app todas as semanas, novas vulnerabilidades são introduzidas constantemente. O pentest deve ser contínuo e focado específicamente nas jornadas financeiras do aplicativo.

O Futuro da Segurança Embutida

Olhando para o horizonte de 2026 e além, a linha que separa um banco de uma empresa de tecnologia continuará desaparecendo. O embedded finance não é uma moda passageira; é a evolução natural do consumo digital. A conveniência de pagar, tomar crédito e investir diretamente no contexto do consumo (seja comprando uma passagem aérea ou insumos agrícolas) é imbatível.

Contudo, o sucesso desse modelo a longo prazo depende da maturidade cibernética das empresas não-financeiras. O ecossistema não suportará o custo das fraudes se cada novo app de varejo se tornar uma peneira digital. Os provedores de BaaS mais sofisticados já estão evoluindo de meros fornecedores de APIs (dumb pipes) para parceiros de risco, exigindo telemetria completa dos aplicativos dos seus clientes para alimentar seus próprios motores antifraude.

A regra de ouro para qualquer empresa que deseje surfar a onda do embedded finance é clara: assuma que você será atacado com a mesma ferocidade que o maior banco do país. A diferença entre o sucesso e a ruína não estará na taxa de juros que você oferece, mas na robustez da porta virtual que protege o dinheiro do seu cliente.