A cofundadora do Nubank, Cristina Junqueira, admitiu no Instagram que um pull request submetido por um funcionário ativou por engano o protocolo de comunicação de liquidação do banco, na sexta-feira (12/jun/2026). Em nota, a empresa esclarece que o fluxo não trata da liquidação do próprio Nubank: é um modelo genérico para comunicar clientes sobre liquidação de outras instituições, e o nome da companhia entrou como preenchimento padrão.
Linha do tempo do incidente
| Quando | O que aconteceu |
|---|---|
| Sex 12/jun/2026 | Clientes recebem aviso no app e por email dizendo que ativos do Nubank deixariam de circular e orientando solicitar ressarcimento ao FGC |
| Sex 12/jun/2026 | Nubank emite primeira nota: “erro operacional pontual, já identificado e solucionado” |
| Sáb 13/jun/2026 | Cristina Junqueira responde seguidores no Instagram: “bizarro mesmo, mas foi isso mesmo, um erro operacional” |
| Sáb 13/jun/2026 | Nubank detalha em nova nota: desenvolvedor acionou por engano fluxo de comunicação para liquidação de instituições financeiras; nome da companhia entrou como placeholder default |
| Sáb 13/jun/2026 | Banco Central nega ter decretado liquidação extrajudicial do Nubank |
Cronologia do incidente conforme reportagem do Valor Econômico. Fonte: Valor Econômico
O que disse a fundadora
Questionada por seguidores no Instagram, Junqueira atribuiu o episódio a uma mudança de código que ativou um fluxo de comunicação pré-existente. “Cara, bizarro mesmo, mas foi isso mesmo, um erro operacional. Uma pessoa que submeteu um PR que acabou acidentalmente ativando o protocolo que existe quando algo assim acontece. As mensagens foram para uma parcela muito pequena de clientes, mas é claro que causa uns transtorno”, escreveu, conforme reportagem do Valor. PR, no jargão de desenvolvimento de software, é a sigla de pull request, a solicitação para que alterações de código sejam incorporadas ao sistema principal.
A fundadora ainda emendou um pedido de desculpas e disse que a equipe agiu para corrigir o problema rapidamente. “Pedimos sinceras desculpas a todos que receberam a informação incorreta. Enfim, mais um aprendizado e já atuamos para que não aconteça de novo”, afirmou.
Por que o fluxo existia
A explicação técnica veio na nota oficial enviada na tarde de sábado. “Foi identificado que um desenvolvedor acionou por engano um fluxo de comunicação relacionado à liquidação de instituições financeiras. Na ausência de uma instituição real vinculada a esse fluxo, o nome da companhia apareceu como preenchimento padrão”, informou o Nubank, em comunicado citado pelo Valor. Em outras palavras, o protocolo não foi desenhado para o caso de uma liquidação do próprio banco: é um modelo de comunicação que cobriria clientes do Nubank impactados pela liquidação de alguma instituição parceira ou conectada à operação, e o template recaiu no nome da própria companhia ao ser disparado sem uma instituição vinculada.
A reportagem do Valor ouviu especialistas em segurança cibernética que apontam um erro operacional como possibilidade, mas não descartam a hipótese de sabotagem interna ou ataque hacker. O Banco Central, por sua vez, negou que tenha decretado a liquidação extrajudicial do banco e o Nubank afirmou que não houve “impacto sobre a segurança, a estabilidade da operação ou o funcionamento” dos serviços. O incidente vem na esteira de outro episódio de comunicação recente, quando o banco admitiu instabilidade no Pix enquanto o Banco Central negava qualquer falha sistêmica.
O que observar
O caso expõe um padrão comum em fintechs de grande porte: fluxos de comunicação dormentes, desenhados para cenários extremos de mercado (liquidação de parceira, suspensão de serviço, falha de provedor), ficam pré-construídos no sistema com templates que dependem de variáveis preenchidas em tempo de execução. Quando o disparo acontece sem o contexto esperado, o template recai em valores default que, fora de cenário, são errados. Vale acompanhar como instituições financeiras reguladas tratam o ciclo de vida desses fluxos de incidente, com que frequência são auditados, e quais salvaguardas estão em camadas antes do envio efetivo.
A segunda pergunta é de governança de código. Em ambientes regulados, mudanças que tocam canais de comunicação com cliente costumam exigir feature flags, revisões manuais e testes de smoke antes do deploy. A questão é se grandes plataformas digitais conseguem manter esse rigor à medida que aumentam a velocidade de release. Se a tendência for de mais automação e PRs frequentes, a camada de proteção precisa ser igualmente robusta para que nenhum fluxo dormente seja ativado por uma mudança colateral.
Fontes: Valor Econômico • Bloomberg Línea • CNN Brasil • Let’s Money