O risco de depender de BaaS compensa a velocidade de escalar sua SaaS?

Em 2026, o sonho de todo software de gestão (ERP) ou plataforma marketplace é o mesmo: virar um banco. A lógica é fiscalmente sedutora. Por que cobrar apenas R$ 50 por mês de assinatura do seu cliente se você pode ganhar R$ 10 a cada R$ 1.000 que ele movimenta na conta digital que você mesmo emite? É nesse momento que o modelo de Banking as a Service (BaaS) aparece como a varinha mágica. Ele promete que, em poucas semanas, sua SaaS joga um logo em um cartão e começa a ganhar com o spread bancário, sem precisar de uma licença bancária própria que custaria milhões e demoraria anos.

Aqui na redação, acompanho de perto esse "casamento" entre softwares e bancos. O problema é que a infraestrutura de BaaS tem um lado sombrio que os contratos de vendas costumam esconder em letras minúsculas. Quando você terceiriza a infraestrutura financeira, você está na verdade terceirizando a sua permissão para existir como negócio financeiro. Se o banco parceiro tiver um problema de liquidez ou, pior, um rombo de compliance que chame a atenção do Banco Central, a sua operação inteira pode ser congelada da noite para o dia.

A pergunta não é se o BaaS vai matar as fintechs como conceito — ele é o motor delas. A pergunta é se ele vai matar o seu negócio específico por falta de autonomia.

A arquitetura da dependência regulatória

Para entender o risco, precisamos desmembrar como funciona o encanamento por trás do "emitir cartões" na prática. O seu SaaS não fala com a bandeira Visa ou Mastercard. Ele fala com um provedor de BaaS (como Pismo ou Stratu, para citar nomes que são referência de infraestrutura). Esse provedor, por sua vez, é "banqueiro" de um banco emissor ou cooperativa de crédito que carrega o risco de liquidez e o saldo nas contas.

Você cria uma lógica incrível no seu app: o usuário clica em "sacar", o dinheiro cai na conta dele. Mas tecnicamente, o que acontece é uma sequência de chamadas de API que passa pelo seu servidor, pelo BaaS, e cai no core do banco parceiro. O risco mora nessa intermediação. Em 2025 e início de 2026, vimos casos de provedores de infraestrutura que tiveram seus contratos rescindidos unilateralmente por bancos tradicionais que assustaram com a vigilância mais dura do regulador. O resultado? Milhões de usuários de fintechs ficaram com cartões bloqueados e contas congeladas sem aviso prévio.

Isso é especialmente perigoso se o seu fluxo de caixa depende desse dinheiro circular. Se você tem um SaaS de folha de pagamento e o cartão benefits para seus clientes é bloqueado, seu produto principal quebra. Você perde credibilidade não por erro do seu time de tecnologia, mas porque o compliance do banco parceiro falhou na revisão de um cliente pontual. É vital monitorar a saúde desse parceiro; se ele der sinais de problemas de liquidez ou tecnológicos, seu barco também afunda.

Quando o compliance vira uma bomba-relógio

O maior equívoco dos fundadores de SaaS que entram no BaaS é achar que o responsável por "limpar" o dinheiro é o banco. Sim, o banco é o responsável perante o regulador, mas o contrato de BaaS repassa para você a obrigação de fazer o KYC (Know Your Customer) e a triagem inicial de forma eficaz. A maioria dos provedores oferece uma camada de automação para isso, mas é você que define a regra do negócio.

Se a sua SaaS atende um setor de alto risco, como aposta online ou criptomoedas, e o banco parceiro decide que não quer mais esse perfil de risco na sua base — algo comum agora que o Basiléia III aperta o capital dos bancos — você terá o produto arrancado das mãos. Não há negociação. O banco simplesmente avisa: "em 30 dias encerramos a conexão".

Também existe o risco da complacência tecnológica. Muitas fintechs "alugam" a inteligência de prevenção à lavagem de dinheiro (PLD) do provedor BaaS. Se essa configuração não for ajustada para o perfil do seu usuário, você pode se tornar um veículo para golpistas. Quando a Polícia Federal ou o COAF bate na porta, o primeiro nome que aparece é o do banco, mas o processo se estende a todos os nós da cadeia. O custo de operacionalizar um time interno de compliance robusto, para não depender apenas da "caixa preta" do parceiro, muitas vezes anula a economia que levou você a contratar o BaaS.

A conta matemática do lock-in tecnológico

Vamos falar de números concretos. Implementar uma conexão BaaS custa, em média, entre R$ 50 mil e R$ 150 mil em setup, sem contar as horas do seu time de engenharia. Além disso, você paga um "SaaS fee" mensal para a infraestrutura e repassa um pedaço do seu lucro (o split) ao provedor. Se você decide migrar para outro parceiro porque o atual aumentou as taxas — prática comum depois que você escala volume —, a dor é absurda.

Não existe um padrão de API universal para bancos. Tudo é proprietário. Mudar de parceiro significa refazer todo o processo de homologação com as bandeiras, reconfigurar a lógica de contas contábeis e, muitas vezes, forçar o usuário final a trocar de cartão físico. Isso é um "Churn" técnico. Se você tem 100 mil usuários ativos com um cartão na mão, migrar é inviável operacionalmente. O banco sabe disso e, por isso, costuma impor reajustes agressivos no terceiro ano de contrato. Você fica refém.

Esse cenário exige um comparativo frio com a alternativa antiga, que é ter uma conta digital PJ de banco tradicional apenas para repasse de valores, mantendo o financeiro separado da experiência do usuário. O BaaS dá uma experiência "sticky" (o usuário raramente sai de quem paga o salário dele), mas transfere o poder de precificação do seu produto para a entidade que segura a licença bancária.

Existe momento certo para quebrar o galho?

Apesar do cenário sombrio que pintei até aqui, eu não sou contra o BaaS. Ele é o único jeito de uma SaaS virar um unicórnio de forma rápida. O segredo está em tratar a infraestrutura bancária não como um "plugin", mas como o coração do seu negócio. Se você fatura menos de R$ 5 milhões em volume transacional mensal, o custo de construir um próprio banco ou de manter múltiplos parceiros para redundância é proibitivo. Nesse caso, o risco do BaaS é o custo de entrada.

O erro crasso é o SaaS que já tem fluxo de caixa alto e dependência vitalícia de um único parceiro, sem um plano de contingência. Em 2026, a estratégia inteligente — adotada por quem sobreviveu às "podações" de mercado dos anos anteriores — é a multi-bancaridade. Você conecta seu SaaS a dois provedores BaaS distintos e divide o volume de emissão de cartões entre eles. Se um cai ou aumenta o preço, você migra 20% do volume para o outro, mantendo a negociação ativa.

Além disso, fintechs que entendem o Open Finance estão deixando de ser apenas emissoras para se tornarem agregadoras de dados. O lucro não está mais tanto no "taxar o saque", mas em usar os dados bancários para oferecer produtos de crédito que não dependem unicamente da conta que você emitiu. Isso dilui o risco regulatório.

O veredito sobre o risco operacional

Voltando à pergunta inicial: o BaaS mata ou cria unicórnios? A resposta honesta é: ele cria unicórnios que podem ser abatidos a qualquer momento se não tiverem cuidado. O modelo não é uma tendência passageira; ele é a infraestrutura básica do mercado financeiro moderno. Ninguém mais vai construir um core bancário do zero a não ser que seja um gigante global.

Para o leitor que está decidindo agora: se a sua prioridade é sobrevivência e controle total, esqueça o cartão próprio e use APIs de transferência padrão (PIX/TED) via gateways de pagamento que não exigem conta corrente. Se a sua prioridade é ganhar relevância e valuation multiplicando o ARR da sua empresa, vá para o BaaS, mas assine o contrato achando que já está do outro lado do processo de divórcio. Tenha o plano B desenhado no código, reserve uma fatia do capital para compliance próprio e nunca, em hipótese alguma, assuma que a responsabilidade pelo dinheiro do seu cliente é do "banco lá em cima". Na hora do bloqueio, o cliente liga para você, e é você que vai ter que explicar o porquê do saldo travado.