Seu próximo produto pode já existir. Só não com a sua marca.

Um software como serviço (SaaS) pode oferecer Pix, contas e repasses sem construir um banco inteiro, mas não deve tratar Banking as a Service (BaaS) ou white-label como caixa-preta. O diferencial continua na experiência, nas regras, na integração, na conciliação, na observabilidade e no plano de saída.

Por Reynier Rivero·Engenheiro de software·17 de setembro de 2026

Às 7h42, a fundadora de um software como serviço (SaaS) de locação abre o painel antes da primeira cobrança do dia. Ela quer que o inquilino pague o aluguel por Pix dentro do produto e que o proprietário receba o repasse sem uma planilha no meio.

Em menos de dez minutos, o pedido ganhou outras palavras: conta, conheça seu cliente (KYC), chave Pix, confirmação, conciliação, taxa, devolução, regra de repasse e continuidade do parceiro. Se o pagamento entrar e o parceiro ficar indisponível, quem informa o usuário? Se o locatário pagar duas vezes, qual valor pode ser devolvido? Se o proprietário trocar seus dados bancários, qual sistema sabe disso?

Esta é uma cena composta e inequivocamente hipotética. Ela não descreve uma empresa real nem uma oferta específica; reúne decisões que um founder precisa tomar quando transforma uma função financeira em parte do próprio produto.

O pedido parecia ser “adicionar Pix”. Na prática, ele era um pequeno sistema financeiro com uma marca na frente e várias responsabilidades atrás.

É aí que a conversa costuma sair do trilho. Alguns founders tentam construir tudo. Outros compram um pacote e descobrem tarde demais que não compraram controle. O produto financeiro não precisa ser construído inteiro para ser diferencial. Mas também não pode ser comprado como uma caixa-preta.

A marca aparece na frente. A responsabilidade não desaparece atrás.

Em 28/11/2025, o Banco Central do Brasil (BCB) e o Conselho Monetário Nacional (CMN) publicaram a Resolução Conjunta BCB/CMN nº 16, que disciplina o Banking as a Service (BaaS), exige transparência e identificação da instituição prestadora e permite adequar contratos vigentes compatíveis até 31/12/2026. A nota oficial do BCB ajuda a enquadrar a mudança: BaaS não é apenas um conjunto de endpoints com outra identidade visual.

Desde 01/09/2026, as instituições prestadoras de BaaS devem registrar e manter atualizados no Unicad os dados das entidades tomadoras com contratos vigentes, conforme a Instrução Normativa BCB nº 754 (IN BCB nº 754) e a versão vigente da IN BCB nº 330. Na leitura operacional apresentada pelo BCB, o registro citado é atribuído à prestadora. A empresa deve confirmar seu próprio enquadramento no contrato e com assessoria habilitada.

Para o SaaS, a consequência é simples e incômoda: esconder o nome do parceiro na interface não significa esconder a instituição prestadora, a governança, o fluxo de atendimento ou o caminho de uma ocorrência. White-label muda a apresentação. Não apaga a arquitetura de responsabilidades.

Pix não é plug-and-play

Em 19/08/2026, o BCB divulgou a versão 2.10.0 do manual e da interface de programação de aplicações (API) Pix, com melhorias técnicas na gestão de recorrências do Pix Automático. O manual técnico correspondente mostra o que a palavra API esconde: conexão de sistemas empresariais a participantes Pix para iniciar cobranças, receber confirmações e apoiar a conciliação.

Também não basta perguntar se o fornecedor “tem Pix”. A página de participantes publicada em 14/09/2026 distingue participação direta e indireta no Sistema de Pagamentos Instantâneos (SPI) e acesso direto e indireto ao Diretório de Identificadores de Contas Transacionais (DICT), o que afeta o desenho de dependências e de suporte. A lista oficial de participantes e modalidades é uma referência para essa conversa, não um selo automático de que qualquer produto esteja pronto para o seu caso.

No backlog do produto, “integrar Pix” deveria virar pelo menos estas decisões:

• escolher o provedor de serviços de pagamento (PSP) ou participante e documentar a cadeia de dependências;
• separar credenciais, escopos, ambientes e acesso por tenant;
• criar cobrança, código de resposta rápida (QR), expiração e confirmação como estados explícitos;
• tratar webhook repetido, resposta atrasada, timeout, retry e idempotência;
• guardar o vínculo entre cobrança, transação, usuário, repasse e registro contábil;
• definir devolução normal, cancelamento, erro operacional e fraude como fluxos diferentes;
• homologar cenários de sucesso, rejeição, indisponibilidade e reprocessamento.

O sistema não está pronto porque o QR apareceu na tela. Está pronto quando uma equipe consegue explicar o que acontece depois do pagamento, inclusive quando ninguém recebe uma resposta limpa do parceiro.

Três caminhos, três tipos de controle

Construir, comprar infraestrutura BaaS ou aplicar uma camada white-label são decisões diferentes. A tabela abaixo é uma heurística de desenho para founders, não uma avaliação de um fornecedor específico.

Construir tudo dá mais controle e também exige assumir mais superfície: segurança, monitoramento, integrações, processos de risco e, conforme o produto, as autorizações e responsabilidades aplicáveis. Comprar BaaS reduz o tempo até uma primeira versão, mas desloca o centro de gravidade para o contrato, os limites do parceiro e a qualidade dos eventos.

Construir versus comprar descreve principalmente a infraestrutura; white-label descreve como essa infraestrutura chega ao usuário e pode ser combinado com BaaS. Assim, uma empresa pode comprar o núcleo financeiro e ainda construir a experiência, as regras e a operação que diferenciam seu SaaS.

White-label é uma decisão de experiência, não um atalho regulatório. A própria Resolução Conjunta BCB/CMN nº 16 exige que a relação seja transparente e que a instituição prestadora possa ser identificada. A marca do SaaS pode liderar a jornada sem ser dona de cada camada que faz o dinheiro circular.

O que vale a pena construir

A fronteira mais produtiva costuma ser esta: comprar o núcleo difícil de justificar internamente e construir a parte que torna o recurso indispensável ao cliente.

• Experiência: telas, permissões, status, explicações e atendimento dentro do contexto do seu SaaS. Um marketplace precisa mostrar ao vendedor o que está disponível, pendente e repassado; um sistema de gestão empresarial (ERP) precisa mostrar como o recebimento afeta a conta a receber.
• Regras do produto: quando cobrar, quando liberar, qual taxa aplicar, como calcular o líquido, quem aprova uma exceção e o que fazer quando uma condição muda. Regra de repasse não deveria viver escondida em um painel do parceiro.
• Integração: uma camada adaptadora que traduza o modelo do SaaS para o contrato do participante. Se a troca de fornecedor exigir reescrever todas as telas, o acoplamento já venceu.
• Conciliação e operação: um registro interno que conecte cobrança, pagamento, taxa, repasse, devolução e estado final. O parceiro pode ser a fonte do evento financeiro; o produto ainda precisa saber explicar o que aconteceu.
• Observabilidade: trilha de auditoria, correlação de eventos, alertas de webhook parado, fila de reprocessamento e visão operacional por cliente. Sem isso, o suporte vira investigação manual.
• Saída: exportação de dados, mapeamento de contas, histórico de eventos, documentação, chaves sob controle contratual e um plano de migração testável. A saída não é uma cláusula para ler no dia da crise; é uma capacidade técnica.

Essa fronteira tem a mesma lógica de tratar uma integração como parte do produto, ideia explorada em integração como parte da experiência. O provedor pode executar uma função essencial. A decisão de produto sobre como essa função aparece, falha e pode ser substituída continua sendo sua.

Casos de desenho, não promessas de mercado

Os exemplos a seguir são recomendações de arquitetura. Não afirmam demanda comprovada, disponibilidade de uma solução específica ou existência de um produto pronto para cada caso.

• Marketplace: desenhe contas ou identificadores por vendedor, divisão do valor bruto, taxa da plataforma, valor líquido e repasse. O produto precisa explicar por que um vendedor recebeu menos ou ainda está pendente.
• SaaS vertical: coloque cobrança e recebimento no fluxo que o cliente já usa, como uma ordem de serviço, uma matrícula ou uma entrega. Evite criar uma carteira genérica só porque o parceiro oferece uma.
• Locação: modele aluguel, multa, repasse ao proprietário, devolução e mudança de dados bancários como estados auditáveis. O Pix é o meio; a confiança está na regra que fecha o ciclo.
• Recursos Humanos (RH): para benefícios, reembolsos ou pagamentos aprovados, separe quem solicita, quem aprova, quem recebe e quem concilia. Uma tela bonita não resolve uma permissão ambígua.
• ERP: faça a cobrança voltar para contas a receber, baixa, exceção e fechamento. O objetivo não é acrescentar um botão de Pix, mas reduzir a diferença entre o que o ERP acredita e o que o participante liquidou.

Em todos eles, a pergunta decisiva é a mesma: qual parte o cliente compra de você e qual parte você está apenas revendendo com uma camada de marca?

O fornecedor precisa caber no contrato

Há sinais de uma direção semelhante fora do Brasil, mas ela não deve ser importada como promessa local. Em 03/09/2026, a FIS anunciou uma plataforma de embedded banking para bancos dos Estados Unidos, com APIs, kits de desenvolvimento (SDKs), widgets e aplicações white-label dentro de softwares empresariais; contas e pagamentos foram apresentados como planejados para o quarto trimestre de 2026. O comunicado da FIS é um sinal corporativo internacional. Não comprova disponibilidade no Brasil, licença local ou compatibilidade com Pix.

No Brasil, a Baasic descreve em sua documentação comercial uma infraestrutura de embedded finance white-label e detalha em Como funciona etapas como planejamento, conexão, configuração e homologação. A Celcoin, em sua documentação comercial sobre BaaS e Core Banking, descreve APIs, KYC, webhooks, Pix e homologação. Essas páginas mostram como os próprios fornecedores apresentam suas ofertas; não validam, por si só, licença, acordo de nível de serviço (SLA) ou capacidade contratual para o seu caso.

Antes de assinar, transforme a promessa em perguntas respondidas por contrato:

• Qual é a instituição prestadora? Qual é a entidade tomadora? Quem aparece para o usuário e em quais documentos?
• Quais contratos, termos, políticas e anexos regem conta, Pix, dados, repasses, taxas e encerramento?
• Quem responde por KYC, fraude, incidentes, atendimento, bloqueios, auditoria e comunicação com o usuário?
• Como exportar e portar dados, saldos, identificadores, histórico de transações, documentos e eventos?
• Como funcionam webhooks, assinatura, reenvio, ordenação, duplicidade, retries e reprocessamento?
• Existe sandbox real, ambiente de homologação, dados de teste, limites e critérios objetivos de aprovação?
• O que acontece se o parceiro mudar o produto, perder capacidade, encerrar a oferta ou deixar de atender o seu segmento?
• Como ficam limites Pix, aprovações, horários, transações recusadas e mudanças de risco?
• Qual é o fluxo do Mecanismo Especial de Devolução (MED) e quem opera cada etapa quando houver suspeita de fraude ou falha operacional?

Não aceite “integração via API” como resposta para todas as perguntas. Uma API pode ser tecnicamente acessível e operacionalmente impossível de substituir.

Devolução não é chargeback

Esse detalhe merece uma linha própria porque muda o produto de suporte. O documento de perguntas frequentes (FAQ) oficial de participantes do Pix explica que o Mecanismo Especial de Devolução (MED) atende hipóteses como fundada suspeita de fraude e falha operacional. O mesmo documento deixa claro que controvérsia comercial entre usuários não entra nesse escopo e que o MED não é um mecanismo de chargeback de cartões.

Se o inquilino cancela uma locação, isso não deve ser automaticamente descrito como MED. O SaaS precisa ter seu próprio fluxo de cancelamento e devolução comercial, além de integrar o procedimento específico do parceiro quando o caso realmente se enquadrar no MED.

O white-label não apaga o que precisa ser decidido

White-label não substitui automaticamente a análise de licenças, responsabilidades, custódia, titularidade e portabilidade de dados, nem a leitura do contrato. O que vale a pena construir é o controle sobre experiência, regras, operação e saída — para tornar a operação financeira útil, previsível e substituível.

A fronteira é uma decisão de produto

Se a ideia é adicionar Pix, contas ou repasses ao SaaS, comece desenhando a fronteira: o que precisa ser experiência própria, o que pode ser infraestrutura de parceiro, quais eventos você precisa controlar e como a operação continua se esse parceiro mudar.

A Prontavel pode ajudar a mapear essa fronteira e transformar o plano em integrações, controles, conciliação, observabilidade e saída. Dependendo do caso, isso pode começar por uma plataforma white-label, por software sob medida ou por uma combinação das duas camadas.

O próximo produto pode já existir. Mas a decisão sobre onde ele começa e onde ele termina ainda é sua.

Um limite importante

Este artigo é informativo e trata de arquitetura de software, Pix, embedded finance, BaaS e operação de produtos digitais. Não constitui aconselhamento jurídico, fiscal, contábil ou regulatório. Confirme o enquadramento da empresa, as responsabilidades contratuais, as autorizações aplicáveis e os fluxos com profissionais habilitados e com a instituição prestadora.

O serviço de que fala este artigo: Sua marca. Nosso desenvolvimento. Seu cliente nunca nos conhece.