Strêss Testing de PSPs: A Prova de Fogo do BACEN para a Resiliência do Pix
Ponto-chave
O Banco Central exige testes de estrêsse implacáveis dos PSPs, simulando picos massivos e falhas de infraestrutura. Falhar nesses testes significa suspensão do SPI e multas severas, forçando o mercado a investir milhões em arquiteturas multi-cloud e redundância.
6 de setembro de 2024. Véspera de feriado prolongado. O brasileiro médio recebe o salário, paga o aluguel, transfere para a corretora de criptoativos e pede o delivery. O Sistema de Pagamentos Instantâneos (SPI) do Banco Central processa mais de 220 milhões de transações em 24 horas. Zero quedas sistêmicas. A infraestrutura nacional não piscou.
Isso não é sorte. É engenharia paranoica e regulação implacável.
Se você acha que conectar sua fintech ao Pix é apenas consumir uma API RESTful bem documentada, está redondamente enganado. O BACEN opera com a mentalidade de que tudo vai dar errado. A autarquia exige que os Provedores de Serviços de Pagamento (PSPs) provem, matemáticamente e na prática, que sobrevivem ao caos.
Observamos de perto a evolução dessa infraestrutura desde 2020. O que era um sistema de liquidação inovador tornou-se a espinha dorsal da economia brasileira. Para garantir que essa espinha não quebre, o regulador instituiu uma rotina de strêss testing que faz até engenheiros de big techs suarem frio.
A Engenharia da Paranoia: O Contexto Regulatório
Quando o Pix foi desenhado, o BACEN sabia que a adoção seria rápida, mas ninguém previu a verticalização da curva. Passamos de zero a mais de 160 milhões de usuários cadastrados em menos de quatro anos. O volume financeiro transacionado mensalmente já ultrapassa a marca de R$ 2 trilhões.
Para segurar essa barra, o arcabouço regulatório precisou ser draconiano. A Resolução BCB nº 85/2021, que trata da política de segurança cibernética e dos requisitos para contratação de serviços de processamento, foi o primeiro aviso. Depois, o Manual de Requisitos Mínimos do Pix estabeleceu as regras do jogo: alta disponibilidade não é um diferencial competitivo, é o bilhete de entrada.
O regulador exige um SLA (Service Level Agreement) de 99,9% de disponibilidade mensal. Mais do que isso: o tempo de processamento de uma transação. O Manual de Tempos do Pix dita que 99% das transações devem ser autorizadas em até 1 segundo. O limite máximo absoluto antes do timeout é de 10 segundos.
Para provar que conseguem manter esses números sob pressão extrema, os PSPs são submetidos a baterias de strêss tests no ambiente de homologação do SPI. E o BACEN não alivia na carga.
Anatomia de um Strêss Test do BACEN
Como funciona essa prova de fogo na prática? O BACEN não simplesmente pergunta se o seu servidor aguenta o tranco. Ele inunda a sua infraestrutura com uma carga sintética maciça.
Os testes são desenhados para simular os piores dias possíveis do varejo brasileiro. Black Friday, quinto dia útil, véspera de Natal e pagamento da primeira parcela do 13º salário — tudo acontecendo simultaneamente.
O Gargalo da Criptografia (HSM)
Um dos pontos mais críticos testados é a assinatura de mensagens. Toda comúnicação com o SPI trafega via rede do Sistema Financeiro Nacional (RSFN) ou internet com túnel IPsec, e cada pacote XML precisa ser assinado digitalmente usando certificados ICP-Brasil.
Assinatura de hardware consome muito processamento. Os PSPs útilizam HSMs (Hardware Security Modules) para isso. Durante o strêss test, o BACEN eleva o TPS (Transações Por Segundo) ao limite para ver se o pool de HSMs da fintech engasga. Se a latência criptográfica passar de alguns milissegundos, a transação inteira estoura o SLA de 1 segundo.
Simulação de Queda de Banco de Dados
Outro vetor testado é a resiliência interna do PSP. O BACEN exige arquiteturas ativas-ativas. Durante o teste de carga, os auditores e engenheiros avaliam o que acontece se o banco de dados principal (seja um cluster Aurora na AWS ou um Spanner no GCP) perder um nó.
O sistema faz o failover automático? As transações em voo são perdidas ou enfileiradas corretamente? O strêss test não aceita desculpas de "instabilidade no cloud provider". A responsabilidade final é da instituição financeira.
Participante Direto vs. Indireto: A Linha de Corte
Existe uma divisão clara no ecossistema de pagamentos brasileiro. Os grandes players — Nubank, Itaú, Mercado Pago, Stone, PagSeguro — são participantes diretos. Eles possuem conta de liquidação (Conta PI) no Banco Central e conexão direta com o SPI.
Para esses gigantes, o rigor do strêss test é máximo. Uma falha no Itaú ou no Nubank tem risco sistêmico imediato. Eles são obrigados a manter links redundantes de telecomúnicações de operadoras diferentes, data centers geograficamente separados e capacidade ociosa massiva para absorver picos de 10x o volume normal.
Já as fintechs menores, SCDs (Sociedades de Crédito Direto) em estágio inicial ou subadquirentes, geralmente entram como participantes indiretos. Eles liquidam suas transações através de um participante direto (o liquidante).
Isso significa que o participante indireto não escapa das regras? Longe disso. O BACEN exige que o liquidante (o banco parceiro) garanta a resiliência tecnológica da ponta. Se a fintech parceira cair e gerar lixo na rede ou tentar inundar o SPI com retentativas mal configuradas, o banco liquidante é penalizado. O resultado prático: os bancões realizam seus próprios strêss tests privados nas fintechs antes de plugar qualquer um em suas APIs de liquidação indireta.
Cenários de Caos Controlado: O que o Regulador Exige
Na nossa análise das diretrizes do Departamento de Operações Bancárias e de Sistema de Pagamentos (Deban), identificamos três cenários principais que todo PSP precisa homologar anualmente e reportar.
1. O Teste de Pico Vertical (Spike Testing)
O tráfego salta de 100 TPS para 5.000 TPS em questão de três segundos. Isso testa a elasticidade da infraestrutura em nuvem. O auto-scaling do Kubernetes foi rápido o suficiente? Os pods subiram antes das conexões no banco de dados esgotarem? No Pix, picos verticais acontecem quando grandes e-commerces abrem vendas de ingressos muito concorridos ou liberam lotes de promoções agressivas.
2. O Teste de Exaustão (Soak Testing)
Aqui, o sistema é submetido a 80% da sua capacidade máxima, não por minutos, mas por 48 horas ininterruptas. O objetivo é caçar vazamentos de memória (memory leaks) nas aplicações, esgotamento de pool de conexões e saturação de discos de logs. Muitos sistemas brilham nos primeiros 10 minutos e travam completamente após 12 horas sob carga pesada.
3. O Teste de Injeção de Falhas (Chaos Engineering)
Inspirado nas práticas da Netflix, o BACEN encoraja o desligamento deliberado de componentes em produção simulada. Derruba-se o link principal de internet. Desliga-se o acesso ao DICT (Diretório de Identificadores de Contas Transacionais). O sistema não pode simplesmente travar; ele precisa retornar códigos de erro graciosos (fallbacks) e manter a estabilidade térmica das outras operações bancárias.
O Custo Oculto da Alta Disponibilidade
Se você opera um e-commerce ou uma plataforma de pagamentos, preste atenção aqui. O nível de exigência técnica imposto pelo regulador criou uma barreira de entrada invisível, porém caríssima, no mercado financeiro brasileiro.
Manter uma infraestrutura capaz de passar nos strêss tests do BACEN exige bolsos profundos. Estamos falando de milhões de reais mensais em Capex e Opex de TI. Bancos de dados distribuídos multi-region custam fortunas em tráfego de rede (egress data).
Além disso, existe a guerra por talentos. Engenheiros de Site Reliability Engineering (SRE) com experiência em meios de pagamento de missão crítica ganham salários comparáveis aos do mercado americano. Empresas como C6 Bank e Inter precisaram montar verdadeiros esquadrões de elite apenas para monitorar a latência do SPI em painéis do Grafana e Datadog 24 horas por dia, 7 dias por semana.
Implicações Práticas: A Guilhotina Regulatória
O que acontece quando um PSP não suporta a pressão e apresenta instabilidade real após ser aprovado nos testes? A guilhotina regulatória desce sem piedade.
O BACEN monitora a disponibilidade de cada participante em tempo real. Se o seu índice de disponibilidade cair abaixo de 99% em um mês, ou se você estourar o SLA de tempo de resposta sistematicamente, o Deban entra em contato. Primeiro, vem a notificação exigindo um plano de ação imediato (com prazos exísmos).
Se a instabilidade ameaçar a saúde do ecossistema, o BACEN aciona o "Circuit Breaker" do SPI. O PSP é sumariamente estrangulado (throttling) ou desconectado da rede. Na prática, o aplicativo da sua fintech para de fazer e receber Pix. Para o usuário final, a mensagem é um frustrante "Serviço indisponível no momento". Para a fintech, é um desastre de relações públicas, evasão de depósitos e potencial falência.
Multas também são aplicadas severamente. Dependendo do impacto e da reincidência, as sanções financeiras corroem rápidamente a margem de lucro de qualquer operação de pagamentos.
A Próxima Fronteira da Resiliência
Acompanhamos um amadurecimento brutal da TI financeira no Brasil. O strêss testing deixou de ser um checklist burocrático de compliance para se tornar o coração da operação de qualquer PSP sério.
Agora em 2024, a complexidade vai aumentar. Com o avanço do Open Finance, a implementação do Pix Automático e os testes em andamento do Drex (o real digital via DLT/Blockchain), a malha de integrações está se tornando exponencialmente mais densa. Cada nova funcionalidade introduz novos pontos de falha.
O Banco Central já sinalizou que os requisitos de resiliência e os testes de estrêsse serão unificados para cobrir jornadas completas do usuário cruzando múltiplos ecossistemas. A mensagem do regulador continua cristalina: no mercado financeiro brasileiro, não existe espaço para infraestrutura amadora. Você testa seus limites até quebrar em casa, ou o mercado quebra você em praça pública.
Perguntas Frequentes
Matheus Feijão
CEO & Fundador — ouro.capital
Especialista em fintech e criptoativos desde 2002. CEO da ouro.capital.