Por: Caio Fava Focaccia – Sócio Fundador
Em junho de 2025, o STJ decidiu que exchange responde objetivamente por fraude quando o sistema de segurança falha (REsp 2.104.122/MG). A relatora aplicou a Súmula 479 e tratou a exchange como instituição financeira.
A decisão faz sentido no caso concreto. O 2FA da plataforma não funcionou, o e-mail de confirmação não foi enviado, e a exchange não conseguiu provar que o cliente autorizou a operação. Se o sistema falha, a plataforma responde. Sem discussão.
O problema é o que veio depois. O mercado leu a decisão como regra geral: exchange responde por qualquer fraude envolvendo cripto. E não é assim.
Cripto não funciona como banco.
No banco, o cliente opera num ambiente fechado. App, internet banking, agência. O banco controla tudo — o sistema, o cartão, a autenticação, o processamento. Se alguém frauda dentro desse ambiente, é falha do banco, porque só o banco podia evitar.
Na exchange, o mundo é outro. O usuário pode sacar pra carteira própria e guardar cripto fora da plataforma. Pode conectar essa carteira a um protocolo DeFi que a exchange nem sabe que existe. Pode aprovar uma transação num smart contract malicioso. Pode entregar a seed phrase (a chave de acesso da carteira) num site de phishing que imita a exchange mas não é a exchange.
Nada disso existe no sistema bancário. Um correntista do Bradesco não tem como transferir seu saldo pra um protocolo descentralizado ou guardar seus reais num dispositivo físico fora do alcance do banco.
A Súmula 479 foi escrita pra esse ambiente fechado. Aplicar sem adaptação a um ecossistema aberto e descentralizado ignora como a tecnologia funciona. E como a tecnologia funciona define quem controla o quê — que é exatamente a pergunta que importa quando se fala em responsabilidade.
Os golpes são diferentes. A responsabilidade deveria ser diferente.
Nem toda fraude com cripto é igual. E a responsabilidade da exchange deveria depender de onde o golpe aconteceu.
Quando o golpe acontece dentro da plataforma — o sistema de autenticação falha, uma transação é processada sem autorização real do cliente, o 2FA é burlado por falha técnica — a exchange responde. É fortuito interno. É o caso do REsp 2.104.122. Correto.
Mas a maioria dos golpes que chegam ao Judiciário não são assim. O padrão mais comum é outro:
O cliente recebe um e-mail falso ou uma mensagem no WhatsApp. Clica num link. Insere login e senha num site fraudulento que imita a exchange. O golpista acessa a conta com as credenciais verdadeiras, passa pelo 2FA porque o próprio cliente aprovou no celular, e transfere os ativos.
Do ponto de vista da exchange: login correto, 2FA aprovado pelo titular, transação confirmada. O sistema fez o que deveria fazer. A fraude aconteceu fora — no e-mail do cliente, no site falso, na engenharia social que convenceu ele a clicar.
Ou então: o cliente compra cripto na exchange, transfere pra uma carteira própria, e de lá conecta num protocolo DeFi malicioso que drena tudo. A exchange nem participou da operação.
Ou: o cliente é convencido por alguém (ligação, rede social, romance scam) a transferir voluntariamente seus ativos pra outra carteira. A exchange executou a ordem que o próprio cliente deu.
Ou: o cliente investiu num token fraudulento que foi a zero. O criador do token inflou o preço, vendeu tudo e desapareceu. A fraude é do projeto, não da plataforma onde o cliente comprou cripto antes de transferir.
Em todos esses casos, o consumidor processa a exchange porque era “onde ele tinha conta”. Mas a exchange não causou o dano, não participou do golpe e não tinha como impedir.
O problema da prova.
Com a responsabilidade objetiva, o ônus se inverte. A exchange tem que provar que não falhou. No caso concreto do STJ, a ministra disse que a empresa deveria demonstrar que o cliente “atuou de maneira indevida em toda a cadeia de atos necessários para a conclusão da operação”.
Na prática, isso vira prova impossível.
A exchange consegue mostrar o login, o 2FA aprovado, a transação confirmada. Mas como provar que o e-mail do cliente foi hackeado fora da plataforma? Como provar que ele entregou a senha num site de phishing? Isso aconteceu fora do sistema da exchange. Ela não tem acesso ao e-mail do cliente, não controla o celular dele, não sabe quais sites ele acessa.
No banco, esse problema é menor porque o ambiente é fechado. No cripto, onde o usuário transita entre exchanges, carteiras, protocolos DeFi e dezenas de plataformas, as portas de entrada pra fraude são infinitas. A maioria não tem nada a ver com a exchange.
Pedir que a plataforma prove um negativo — que a falha não foi dela — quando a fraude pode ter acontecido em qualquer ponto de um ecossistema que ela não controla, é transferir um risco que ela não criou.
A própria jurisprudência bancária já resolve isso.
O STJ reconhece que banco não responde quando o correntista entrega cartão e senha a terceiros de forma voluntária. A distinção entre fortuito interno e fortuito externo existe e é aplicada no sistema financeiro tradicional.
O mesmo raciocínio cabe pra cripto. Se a fraude aconteceu dentro da plataforma, por falha do sistema, a exchange responde objetivamente. Se a fraude aconteceu fora — phishing externo, engenharia social, golpe em protocolo DeFi, rug pull de terceiro — a exchange deveria poder demonstrar a excludente.
Isso não tira proteção do consumidor. Isso acerta o alvo. Responsabiliza quem falhou, não quem estava mais perto na hora que o cliente foi procurar culpado.
O que falta.
O REsp 2.104.122 foi um passo importante. Deixou claro que exchange não pode se esconder atrás da tecnologia pra fugir de responsabilidade. Correto.
Mas o próximo passo é igualmente importante: reconhecer que exchange não é banco, que o ecossistema cripto é aberto por natureza, e que responsabilizar a plataforma por tudo que acontece fora dela não protege ninguém — só cria um sistema onde tanto faz investir em segurança ou não.
A jurisprudência precisa distinguir. O instrumento já existe: fortuito interno vs. fortuito externo. Só precisa ser aplicado com as adaptações que a tecnologia exige.