Finanças Embutidas e BaaS para Software PME: Como o SaaS Vertical Adiciona Pagamentos, Empréstimos e Emissão de Cartões

A Toast — uma plataforma de ponto de venda para restaurantes — faturou cerca de US$5 bilhões em serviços financeiros no ano passado. Suas assinaturas de software, o produto que foi originalmente criada para vender, renderam US$ 936 milhões. A "cauda" fintech é agora cinco vezes maior que o "cão" SaaS.

O mesmo padrão está se repetindo em todo o software vertical: as soluções para mercadores da Shopify representam 73% da receita. O mix de IPO da ServiceTitan foi de 71% de assinatura e 25% de fintech, mas analistas que observam a receita líquida nova veem a divisão convergindo para 55/45 — os pagamentos estão crescendo mais rápido do que o núcleo de software. No momento em que uma empresa de SaaS vertical atinge a Série B em 2026, a pergunta do investidor não é mais se deve embutir pagamentos, mas qual stack de finanças embutidas usar e quão rápido os empréstimos e cartões emitidos podem vir em seguida.

Isso é o que a indústria chama de finanças embutidas — produtos financeiros servidos dentro de softwares não financeiros — e a infraestrutura por baixo disso é o Banking-as-a-Service (BaaS). A oportunidade é real: projeta-se que a receita das plataformas dos EUA com finanças embutidas cresça de cerca de US$22 bilhões em 2021 para US$ 51 bilhões em 2026, e o mercado de BaaS está em um CAGR de 17,8% até 2031. Mas há um cemitério de ordens de consentimento, programas congelados e auditorias perdidas ao lado dessa oportunidade, e a maioria dos fundadores que caem nele não percebeu que estava operando um negócio semelhante a um banco até que um regulador os avisasse.

Este guia percorre o que realmente são as finanças embutidas, por que o SaaS vertical é o lar natural para elas, como é a stack em 2026, como escolher entre provedores e as armadilhas de conformidade que transformam lançamentos promissores em incidentes existenciais.

O Que "Finanças Embutidas" Realmente Significa

Finanças embutidas é uma abreviação para produtos financeiros — pagamentos, contas de depósito, cartões de débito, empréstimos, seguros, folha de pagamento — entregues dentro de um software que não é, à primeira vista, um produto financeiro. Uma plataforma de software de construção que permite que empreiteiros aceitem pagamentos ACH de seus clientes, mantenham o dinheiro em uma subconta e acessem um adiantamento instantâneo contra faturas não pagas está fazendo finanças embutidas. O mesmo vale para um sistema de gestão de clínica veterinária que emite cartões de débito com a marca para técnicos veterinários comprarem suprimentos.

O motor técnico por trás da maioria desses recursos é o Banking-as-a-Service: um banco regulamentado (o "banco patrocinador") aluga sua licença, seu acesso às redes ACH e de cartões, e seu razão segurado pelo FDIC para um provedor de middleware de fintech, que, por sua vez, expõe essas capacidades como APIs limpas que empresas de software comuns podem chamar. A empresa de software nunca detém uma licença bancária. No entanto, ela assume uma longa lista de responsabilidades operacionais e de conformidade que se parecem muito com a gestão de um banco quando se lê as letras miúdas.

Três produtos dominam a stack de finanças embutidas:

• Pagamentos embutidos. Aceitação de cartões e ACH em nome dos clientes finais da plataforma SaaS. Esta é a "droga de entrada" — mais fácil de implantar, mais rápida para gerar receita e a base sobre a qual tudo o mais se sustenta.
• Empréstimos embutidos. Adiantamentos de dinheiro contra recebíveis futuros, produtos de linha de crédito e empréstimos a prazo subscritos usando os dados de transações primários da plataforma. As taxas de serviço (take rates) e as margens líquidas são muito mais altas do que nos pagamentos.
• Cartões e contas emitidos. Cartões de débito com marca, cartões virtuais e contas operacionais seguradas pelo FDIC ("cartões de gastos" para equipes, "contas de ganhos" para trabalhadores gig, cartões de crédito de loja para compradores).

Cada uma dessas camadas se potencializa com as outras, porque cada uma captura mais do fluxo de capital de giro do cliente.

Por Que o SaaS Vertical Tem a Vantagem Desleal

Um aplicativo de pagamentos horizontal vê a passagem de um cartão de crédito isoladamente. Uma plataforma de SaaS vertical vê o contrato que gerou a transação, as horas de trabalho agendadas contra o contrato, a fatura de materiais que deve ser paga até sexta-feira, a sazonalidade histórica de cada cliente no mesmo código postal e o saldo bancário do operador tendendo ao cheque especial.

Esse contexto é o fosso competitivo. Ele muda três coisas ao mesmo tempo:

1. A subscrição de risco (underwriting) torna-se mais barata e precisa. Uma empresa de SaaS de construção sabe quais empreiteiros recebem em dia e quais sempre têm 90 dias de recebíveis nos livros. Isso torna um produto de adiantamento de dinheiro uma aposta muito melhor do que um empréstimo genérico para pequenas empresas de um banco que só vê uma declaração de imposto de renda.
2. Os custos de distribuição colapsam. O cliente já está dentro do aplicativo. Não há funil de aquisição para um novo produto financeiro — há um banner dentro da tela em que o usuário já está. Analistas do setor estimam que as plataformas que embutem produtos financeiros com sucesso multiplicam a receita por cliente em três a quatro vezes.
3. A retenção se compõe. Uma vez que a folha de pagamento, os pagamentos e uma linha de crédito passam pelo seu software, os custos de troca tornam-se enormes. A camada fintech transforma uma assinatura de US$99 por mês em uma conta de serviços financeiros de US$ 5.000 por ano.

É por isso que o manual de fintech para SaaS vertical passou de uma "aposta lateral experimental" para uma "suposição padrão de planejamento de Série B" em cerca de quatro anos.

A Stack de 2026: Quem Faz o Quê

O mapa de fornecedores de finanças integradas está lotado, e as categorias se sobrepõem. Uma visão simplificada dos provedores mais frequentemente selecionados por equipes de software de PMEs em 2026:

Processamento e orquestração de pagamentos

• Stripe Connect e Stripe Treasury. O padrão voltado para desenvolvedores. APIs robustas, ótima documentação, ampla cobertura desde a aceitação de cartões até saldos armazenados e cartões emitidos. Ideal para equipes que desejam um único fornecedor para a maior parte da stack.
• Adyen for Platforms. Precificação por volume e forte presença global. Melhores condições econômicas acima de US$ 50 milhões em pagamentos processados; integração (onboarding) mais lenta e menos generosa em programas menores.
• Finix e Payabli. "PayFac como Serviço" — eles ajudam as plataformas a se tornarem facilitadores de pagamento (ou pelo menos parecerem um) sem a necessidade de construir toda a estrutura regulatória.

Bancário e contas (middleware de BaaS)

• Unit. O caminho mais rápido para lançar um programa para empresas de SaaS dos EUA que desejam manter saldos de clientes ou emitir cartões com marca própria. Produto forte, mas intimamente ligado a alguns poucos bancos patrocinadores.
• Treasury Prime. API multibancos — útil quando você deseja recursos de nível bancário, como repasse de seguro FDIC e pagamentos em tempo real, sem ficar preso a um único patrocinador.
• Synctera. Middleware focado em conformidade que tenta trazer ferramentas de BSA/AML para a experiência do desenvolvedor desde o primeiro dia.
• Column. Um banco que também expõe suas próprias APIs, removendo uma camada do "sanduíche" de middleware.

Emissão de cartões

• Marqeta, Lithic, Highnote. Infraestrutura de emissão de cartões para débito com marca própria, pré-pagos e, cada vez mais, programas de crédito. Marqeta escala; Lithic atrai equipes que desejam uma superfície mais enxuta e amigável ao desenvolvedor; Highnote foca em produtos de crédito e de consumo.

Empréstimos e capital

• Parafin, Kanmon, Liberis. APIs de crédito integrado que realizam a subscrição usando os dados de transação da plataforma e lidam com a originação, o serviço e (em alguns casos) o balanço patrimonial.

Livro-razão (Ledger) e movimentação de dinheiro

• Modern Treasury. Implementação de referência para infraestrutura de ledger dentro de plataformas; usada por empresas como Gusto e Marqeta para manter sua própria contabilidade em dia antes mesmo de o dinheiro chegar ao banco.
• Dwolla, Moov. Movimentação programática de dinheiro focada em ACH, frequentemente usada em conjunto com um processador de cartões.

A maioria dos programas ativos combina três ou quatro destes — por exemplo, uma plataforma de gestão de propriedades pode usar a Stripe para aceitação de cartões, a Unit para contas de rendimentos de proprietários, a Marqeta para cartões de débito com marca própria para gestores de propriedades e a Parafin para antecipação de recebíveis de aluguel.

Um Plano de Sequenciamento Realista

O erro mais comum é tentar lançar pagamentos, empréstimos e cartões em um único grande lançamento. Não faça isso. A complexidade de conformidade, operações e economia de cada camada é genuinamente diferente, e a sequência correta em quase todos os casos é a mesma.

Fase 1 — Pagamentos (meses 0 a 6). Adicione a aceitação de cartões para os clientes dos seus clientes. Esta é a camada de menor risco e maior volume. Construa a integração de modo que a plataforma ganhe uma pequena parte de cada transação (geralmente de 30 a 100 pontos-base). Use esta fase para consolidar a integração de clientes, as verificações de KYB (Know Your Business) e o monitoramento de fraudes.

Fase 2 — Contas e desembolsos (meses 6 to 12). Assim que os pagamentos estiverem estáveis, adicione a capacidade de os clientes manterem saldos dentro da plataforma, enviarem pagamentos via ACH e emitirem cartões virtuais para categorias de gastos específicas. Cartões de débito com marca própria costumam ser o segundo produto de cartão, não o primeiro.

Fase 3 — Crédito e capital (ano dois). Antecipações de caixa contra recebíveis vêm primeiro — são de curta duração, mais fáceis de subscrever e recuperadas automaticamente de pagamentos recebidos. Empréstimos a prazo e linhas de crédito vêm depois, pois exigem operações mais profundas de crédito, cobrança e baixa contábil (charge-off).

Dados da Bain & Company mostram que as plataformas que seguem este sequenciamento têm taxas de intermediação (take rates) significativamente mais altas e índices de inadimplência menores do que aquelas que tentam pular etapas. A tentação de lançar empréstimos cedo é forte porque a economia unitária é muito melhor do que a de pagamentos, mas a maturidade operacional necessária para absorver uma taxa de inadimplência de 4% é real, e quase sempre está ausente no primeiro ano.

A Armadilha da Conformidade que Ninguém Quer Comentar

Em fevereiro de 2024, o FDIC emitiu ordens de consentimento contra dois bancos por preocupações de segurança e solidez relacionadas ao BaaS — principalmente falhas na conformidade com a Lei de Sigilo Bancário (BSA) e na supervisão de terceiros. A ordem do Piermont Bank afetou programas operados através da Treasury Prime e da Unit. O Sutton Bank, que trabalha com fintechs incluindo Robinhood, Square e Upgrade, recebeu conclusões semelhantes. Mais ordens se seguiram ao longo de 2024 e 2025. O FDIC relatou doze ordens de execução apenas em maio de 2025. O Office of the Comptroller of the Currency emitiu ações comparáveis no lado dos bancos nacionais.

Quando um banco patrocinador recebe uma ordem de consentimento, a plataforma a jusante não recebe apenas uma carta severa — os programas frequentemente congelam, a integração de novos clientes para e, em alguns casos, os saldos existentes tornam-se difíceis de movimentar. Fundadores que estavam operando o que parecia ser "apenas um recurso de SaaS" descobrem subitamente que seu roteiro (roadmap) é refém de um regulador que nunca conheceram.

Algumas obrigações específicas costumam atrapalhar as empresas de software:

• KYC e KYB (Know Your Customer / Know Your Business). Todo usuário final que mantém um saldo, recebe um cartão ou obtém um empréstimo deve ter sua identidade verificada de acordo com o padrão exigido pelo banco patrocinador — não o padrão que sua equipe de produto considera suficiente.
• Propriedade beneficiária e CIP. As regras do Programa de Identificação de Clientes aplicam-se a clientes empresariais, e a regra para coletar informações de proprietários beneficiários em limites de 25% de participação é aplicada literalmente.
• Monitoramento de transações e registro de SAR. Relatórios de Atividade Suspeita (SAR) não são opcionais. A plataforma geralmente faz o monitoramento de linha de frente; o banco patrocinador faz o registro. Se o monitoramento for fraco, o banco sofre o impacto regulatório e a plataforma sofre a rescisão do contrato.
• Marketing e divulgação. O que você diz sobre seguro do FDIC, juros e termos de crédito é regulado. "Segurado pelo FDIC" sem asterisco tem sido a causa de mais cartas de cessação e desistência do que quase qualquer outra frase.
• Gestão de reclamações e Reg E. Produtos financeiros para o consumidor trazem obrigações de proteção ao consumidor, incluindo cronogramas específicos para lidar com transações contestadas.

Uma regra prática útil: se um recurso exigiria uma licença caso você o fizesse sozinho, então a equipe de conformidade do seu banco patrocinador o tratará dessa forma também, mesmo que seu gerente de produto não o faça.

Escolhendo entre Construir, Comprar ou Fazer Parcerias

Existem três caminhos legítimos, e a resposta certa depende do capital, do apetite regulatório e de quão centrais os serviços financeiros são para o roteiro de longo prazo.

Modelo de parceria pura / indicação. A plataforma indica clientes a um provedor financeiro e ganha uma taxa fixa ou uma pequena participação na receita. Menor risco, menor potencial de ganho, mais rápido para lançar. Ideal para empresas SaaS onde as finanças são adjacentes, em vez de centrais.

Incorporado via middleware de BaaS. A plataforma parece e passa a sensação de ser um provedor financeiro para seus clientes, mas a atividade regulada fica com um banco patrocinador e um parceiro de middleware. A maioria dos programas de SaaS vertical está aqui. As take rates são reais, a carga de conformidade é real e a economia unitária começa a funcionar em escala moderada.

Carta patente, licença ou PayFac direto. Um pequeno número de plataformas eventualmente adquire uma licença de transmissor de dinheiro, torna-se um facilitador de pagamentos registrado ou busca uma carta patente bancária. Isso é caro, lento e só faz sentido quando o programa gera dezenas de milhões em receita de serviços financeiros e a economia ao eliminar o middleware supera o custo regulatório.

Um teste simples: se sua receita de serviços financeiros atual ou planejada for inferior a US$5 milhões por ano, faça parcerias ou use middleware. Entre US$ 5 milhões e US$50 milhões, o middleware quase sempre vence. Acima de US$ 50 milhões, você deve, no mínimo, modelar quanto custaria trazer mais parte da infraestrutura para dentro de casa.

O Jogo dos Números: Como São as Economias Reais

A economia difere drasticamente por produto. Ao construir um plano financeiro, use estas referências aproximadas de 2026 como ponto de partida e, em seguida, ajuste para o seu setor:

• Aceitação de cartão: 30 a 100 pontos-base do volume processado para a plataforma, após o banco patrocinador e o middleware receberem sua parte.
• ACH: Centavos de dígito único a taxas fixas de baixo valor em dólares, além de pequenas taxas de participação em fluxos de valor agregado.
• Cartões de débito / gastos emitidos: Divisão de intercâmbio que normalmente rende à plataforma de 50 a 100 pontos-base de gastos, subtraindo os custos de produção de cartões e gerenciamento de programas.
• Antecipação de recebíveis: Taxas anuais efetivas (APR) na faixa de 30 a 60%, com baixas (charge-offs) de 2 a 6% para uma carteira bem analisada. As margens líquidas após o custo de capital podem chegar a 8 a 15% das originações.
• Empréstimos a prazo: Taxas anuais mais baixas, maior duração, custo operacional mais alto. A margem depende fortemente do custo de capital e da operação de cobrança.

Para pagamentos ACH incorporados B2B especificamente, as previsões do setor projetam que as plataformas capturarão cerca de US$4 bilhões em receitas líquidas de serviços de valor agregado até 2026, e o volume de cartões incorporados adicionará outros cerca de US$ 800 milhões em receita de plataforma. Esses números se somam devido a quem os captura — a plataforma que detém o relacionamento com o cliente e o contexto da transação, não o banco que detém a infraestrutura de pagamentos (rails).

Evite Estes Cinco Erros

Padrões que aparecem repetidamente em análises pós-morte de programas que falharam ou enfrentaram problemas:

1. Construir antes de contratar pessoal de conformidade. A primeira contratação para um programa de finanças incorporadas não é um engenheiro ou um gerente de produto. É alguém com experiência real em BSA/AML, idealmente com relacionamentos anteriores com bancos patrocinadores.
2. Tratar o banco patrocinador como um fornecedor em vez de um regulador. A equipe de conformidade do seu banco patrocinador tem poder de veto efetivo sobre o seu roteiro. Envolva-os cedo, mesmo quando não for obrigatório.
3. Pular o KYB para clientes "pequenos". Não há exceção para o pequeno. Não há exceção para "nós conhecemos este cliente". As regras se aplicam a todos os titulares de conta.
4. Subestimar o custo de capital para empréstimos. A margem financeira líquida na antecipação de recebíveis parece linda em uma planilha até você adicionar o custo de uma linha de crédito, baixas, custos de serviço e a depreciação periódica de uma safra (cohort) que deu errado.
5. Letting marketing get out in front of legal. A maioria das ações de fiscalização de serviços financeiros ao consumidor remonta a um único anúncio, uma única página da web ou um único banner no aplicativo. O texto de marketing para produtos financeiros precisa de um processo de revisão e um registro.

Onde a Contabilidade em Texto Simples se Encaixa

As finanças incorporadas criam um problema técnico de que quase ninguém fala até que ele apareça: a explosão do livro-razão (ledger explosion). Cada saldo de cliente, cada passagem de cartão, cada pagamento, cada desembolso de empréstimo, cada recuperação e cada estorno é agora um evento contábil em seu sistema, não apenas no do banco. Você precisa conciliar seus livros com um extrato de banco patrocinador, com o arquivo de liquidação do seu processador de cartões e com o relatório de um gestor de empréstimos — muitas vezes diariamente.

Fornecedores como a Modern Treasury existem precisamente porque os livros-razão tradicionais não conseguem acompanhar a velocidade da movimentação de dinheiro. Para as finanças internas da empresa — seus próprios livros, aqueles que o CFO precisa certificar — o mesmo princípio se aplica: transparência do livro-razão, trilhas de auditoria e a capacidade de criar scripts de conciliação contra fontes externas importam mais quando os serviços financeiros começam a fluir pela sua plataforma do que quando você era um puro negócio de assinatura SaaS.

Mantenha a Sua Contabilidade tão Transparente quanto o Seu Produto

As finanças embutidas transformam uma empresa de software em uma empresa que movimenta dinheiro — e a espinha dorsal contábil por trás do seu negócio deve ser pelo menos tão boa quanto o produto financeiro que você entrega aos clientes. O Beancount.io oferece contabilidade em texto simples e com controle de versão, totalmente transparente, automatizável por scripts e construída para o tipo de reconciliação de alta velocidade que as empresas SaaS com características de fintech necessitam. Não existem caixas-pretas nem dependência de fornecedor — seus livros residem em um arquivo de texto que você pode auditar linha por linha. Comece gratuitamente e veja por que desenvolvedores e equipes financeiras estão migrando para a contabilidade em texto simples à medida que sua infraestrutura financeira se torna mais complexa.