Third-party risk management: o fornecedor que pode derrubar sua fintech

Você acorda às 6h da manhã com o celular vibrando loucamente. O CTO liga em pânico avisando que os dados sensíveis de 500 mil clientes estão expostos em um fórum na dark web. O instinto inicial é culpar a própria equipe. Você revisa sua infraestrutura na AWS. Tudo intacto. Os firewalls configurados. O código blindado. O vazamento não aconteceu nos seus servidores.

A brecha ocorreu naquele fornecedor de biometria facial que vocês integraram via API há três anos para acelerar o onboarding. Eles deixaram um bucket do S3 aberto. A culpa técnica é deles. A manchete no Valor Econômico, a multa da ANPD e a fúria do Banco Central? Vão cair diretamente no seu colo.

Bem-vindos à realidade brutal do risco de terceiros — ou Third-Party Risk Management (TPRM). Nós observamos o mercado brasileiro de pagamentos e crédito migrar de estruturas monolíticas para um verdadeiro ecossistema de Lego. Ninguém constrói tudo do zero hoje. Você pluga uma API de KYC, um motor de antifraude, um gateway de pagamentos e um serviço de mensageria.

O resultado? Sua superfície de ataque se multiplica por cem. Cada fornecedor conectado aos seus sistemas é uma porta de entrada potencial. Se você opera uma fintech regulada, preste atenção aqui: delegar o serviço não significa delegar a responsabilidade.

O ecossistema de Lego e a ilusão do controle

Até meados de 2018, os grandes bancos brasileiros construíam a maioria de suas soluções dentro de casa. Era lento, caro e engessado. A explosão do Open Finance e do modelo de Banking as a Service (BaaS) mudou a arquitetura financeira do país. Fintechs como Nubank, Mercado Pago e Stone escalaram rápidamente porque souberam orquestrar serviços de terceiros.

Hoje, em 2026, uma fintech de tamanho médio possui entre 40 e 70 integrações críticas de terceiros. São fornecedores de cloud, plataformas de CRM, sistemas de conciliação bancária e APIs de verificação de identidade. O problema mora na confiança cega.

Nós analisamos os relatórios recentes de incidentes cibernéticos no setor financeiro. Mais de 60% das invasões bem-sucedidas não começaram na infraestrutura da empresa alvo, mas sim em um parceiro comercial com defesas mais fracas. Os hackers entenderam que não precisam arrombar a porta blindada do cofre principal se podem simplesmente entrar pela janela destrancada da empresa que fornece o café.

A ilusão do controle acontece quando o CISO (Chief Information Security Officer) da fintech acredita que um questionário de segurança em Excel preenchido durante o onboarding é garantia de segurança. Aquele documento de 150 perguntas é uma fotografia do passado. A segurança da informação é um filme em tempo real.

O peso da caneta do regulador: CMN 4.893 e além

O Banco Central do Brasil não está brincando com a segurança cibernética. A Resolução CMN 4.893 (e suas atualizações recentes) estabeleceu regras draconianas sobre como as instituições financeiras e de pagamento devem tratar seus dados e serviços em nuvem.

O texto da regulação é cristalino. A instituição contratante deve assegurar que o prestador de serviço cumpra as mesmas exigências de segurança cibernética aplicáveis a ela própria. Isso muda o jogo. Se o seu fornecedor de motor de crédito sofrer um ataque de ransomware e interromper suas operações, o Bacen vai penalizar a sua fintech por falha na gestão de continuidade de negócios.

Vimos casos reais nos últimos anos onde vazamentos de chaves PIX ocorreram não por falha dos bancos, mas por vulnerabilidades em correspondentes bancários e parceiros de tecnologia. A resposta do regulador foi imediata: multas pesadas e exigência de auditorias independentes.

A ANPD (Autoridade Nacional de Proteção de Dados) opera na mesma frequência. Pela LGPD, a sua fintech é a controladora dos dados. O fornecedor da API é o operador. Se o operador vazar os dados, você responde solidariamente. Tentar processar o fornecedor depois do vazamento para reaver o prejuízo é enxugar gelo. O dano reputacional já derreteu o valuation da sua empresa.

Anatomia de um desastre na cadeia de suprimentos

Para entender a gravidade, precisamos dissecar como um ataque de supply chain acontece na prática. Vamos pegar um cenário altamente provável no mercado atual de pagamentos digitais.

Sua fintech contrata uma plataforma de atendimento ao cliente (Zendesk, Intercom ou um player local). Para que os atendentes possam resolver os problemas, você integra essa plataforma ao seu banco de dados interno. O atendente consegue ver o saldo do cliente, histórico de transações e chaves PIX cadastradas.

Um grupo de cibercriminosos foca no fornecedor de atendimento. Eles disparam e-mails de phishing direcionados aos funcionários dessa empresa terceira. Um engenheiro de suporte clica no link e tem suas credenciais roubadas. Os hackers entram no sistema do fornecedor.

A partir dali, eles usam a integração legítima (via API) que o fornecedor tem com a sua fintech. O tráfego não levanta suspeitas nos seus firewalls porque vem de um IP conhecido e usa tokens de autenticação válidos. Em poucas horas, os criminosos extraem a base completa de clientes.

Na prática, você terceirizou o seu risco de insider threat. Você não controla quem o seu fornecedor contrata, como ele treina os funcionários ou qual é a política de senhas dele. Mas você paga a conta se houver falha.

Framework Ouro Capital: Avaliando quem entra na sua casa

Não dá para fechar as portas e voltar a construir tudo internamente. A solução é estruturar um programa maduro de Third-Party Risk Management. Na nossa análise acompanhando dezenas de operações bem-sucedidas, o framework ideal se divide em três pilares.

1. Matriz de Criticidade (Tiering)

Tratar a AWS e a empresa que faz a gestão do vale-refeição com o mesmo rigor de segurança é burrice operacional. Você precisa classificar seus fornecedores.

Tier 1 abrange os fornecedores críticos. Se eles pararem, sua fintech para. Se eles vazarem dados, você quebra. (Ex: Cloud provider, core bancário, processadora de cartões). Para estes, a due diligence deve ser extrema.

Tier 2 são os importantes, mas substituíveis com algum esforço. (Ex: Ferramentas de marketing, CRMs secundários). Tier 3 são serviços comoditizados que não tocam em dados sensíveis de clientes.

2. Due Diligence Contínua (Além do Excel)

Pedir o certificado SOC 2 Type II do fornecedor é o mínimo do mínimo. O problema do SOC 2 é que ele atesta que a empresa tem processos, mas não garante que os sistemas são impenetráveis.

As fintechs maduras aboliram as planilhas estáticas. Elas útilizam ferramentas de monitoramento contínuo de risco cibernético (como BitSight ou SecurityScorecard). Essas plataformas varrem a infraestrutura pública do fornecedor 24 horas por dia, checando portas abertas, certificados vencidos e vazamentos na dark web. Se o score do seu parceiro de KYC cair repentinamente, seu time de segurança recebe um alerta na hora.

3. Blindagem Contratual e SLAs de Segurança

O contrato de prestação de serviço precisa ter dentes. Cláusulas genéricas de confidencialidade não servem para nada na hora da crise. O seu jurídico precisa inserir o "Right to Audit" (direito de auditar o fornecedor a qualquer momento).

Os SLAs (Service Level Agreements) de segurança devem específicar tempos máximos de notificação. Se o fornecedor sofrer um incidente, ele tem obrigação contratual de avisar sua fintech em no máximo 4 horas. Vimos casos bizarros no mercado brasileiro onde a fintech descobriu que o fornecedor foi hackeado lendo as notícias no Twitter.

Quarta e quinta partes: O buraco é mais embaixo

Se você acha que mapear seus fornecedores diretos é difícil, prepare-se para o risco de quarta parte (Fourth-Party Risk). É o fornecedor do seu fornecedor.

Sua fintech contrata a Empresa A para fazer antifraude. A Empresa A roda toda a infraestrutura dela na Empresa B (AWS). A Empresa B útiliza a biblioteca open-source C (Log4j). Uma vulnerabilidade na biblioteca C derruba a Empresa A, que por sua vez trava as suas aprovações de crédito.

O mercado financeiro vive hoje um risco brutal de concentração. Se a região us-east-1 da AWS cair, metade das fintechs brasileiras sai do ar simultaneamente. O Banco Central tem focado intensamente em exigir planos de contingência multicloud exatamente por isso.

Outro vetor silencioso são os desenvolvedores terceirizados e as fábricas de software. Eles costumam ter acesso aos repositórios de código da sua fintech (GitHub, GitLab). Se o notebook de um desenvolvedor alocado for comprometido, o código-fonte da sua aplicação de pagamentos pode ser alterado com backdoors.

Guia prático: O que mudar na sua fintech amanhã

Se você lidera a tecnologia ou a operação de uma instituição regulada, a inércia não é uma opção. Aja rápido.

Primeiro, adote a filosofia Zero Trust para integrações B2B. As APIs dos seus fornecedores não devem ter acesso irrestrito aos seus bancos de dados. Aplique o princípio do menor privilégio. O sistema de atendimento só precisa ler os dados dos últimos 30 dias do cliente, não a base inteira desde 2015.

Segundo, mapeie imediatamente todos os tokens de acesso e chaves de API distribuídos. Faça a rotação dessas chaves a cada 90 dias. É assustador o número de chaves de produção com privilégios de administrador esquecidas em repositórios antigos de fornecedores que já nem prestam serviço para a empresa.

Terceiro, inclua os fornecedores Tier 1 nos seus testes de mesa (Tabletop Exercises). Quando simular um ataque de ransomware, simule que o ataque ocorreu no parceiro de processamento de cartões. Teste a comúnicação, o acionamento jurídico e a capacidade de ativar o plano B sem depender da infraestrutura deles.

O mercado não perdoa amadores. O cliente final não quer saber se o vazamento foi na sua base ou no seu fornecedor de biometria. O nome que está no cartão de crédito é o seu. A confiança foi depositada na sua marca.

Gerenciar o risco da cadeia de suprimentos de forma agressiva e contínua é a única fronteira real entre escalar com segurança e se tornar o próximo estudo de caso trágico nas circulares do Banco Central.