Implementação de Banking as a Service: como funciona?

Última atualização: 18 de agosto de 2026

Principais lições deste artigo

• Implementar BaaS exige alinhar três camadas ao mesmo tempo: regulatória, financeira e técnica.

• Definir produto, público-alvo e métricas de sucesso antes de qualquer integração técnica reduz retrabalho e orienta o escopo regulatório.

• Escolher um parceiro com participação direta no Pix, Open Finance e relatórios regulatórios automatizados reduz custos de setup e tempo de go-live.

• Validar webhooks, reconciliação e SLAs em sandbox com testes de idempotência e segurança é pré-requisito para evitar double-counting e falhas contábeis em produção. A Celcoin oferece APIs modulares, sandbox robusto e suporte regulatório completo para acelerar a implementação de Banking as a Service.

Passo 1: Definição do produto e público-alvo

Definir o produto e o público-alvo orienta todas as decisões regulatórias, técnicas e comerciais da operação de BaaS. Essa clareza reduz mudanças de escopo no meio do projeto.

• Mapear os produtos prioritários: conta digital PF ou PJ, Pix, cartão pré-pago, crédito embarcado, pagamento de contas.

• Definir o perfil do usuário final: pessoa física, pessoa jurídica ou ambos.

• Estabelecer métricas de sucesso do produto antes de iniciar o desenvolvimento técnico.

• Identificar canais de distribuição: app próprio, ERP, marketplace ou modelo white-label.

A Celcoin não oferece empréstimo direto para consumidores. A Celcoin fornece a infraestrutura tecnológica para que empresas ofertem produtos de crédito aos seus clientes.

Passo 2: Escolha do parceiro e análise de licenças

A escolha do parceiro de BaaS define quais produtos podem ser oferecidos e qual será o nível de complexidade regulatória e tecnológica. Empresas sem licença própria operam sob a licença de Instituição de Pagamento do parceiro. Empresas já reguladas integram sua própria licença ao Core Banking do parceiro.

• Verificar se o parceiro é participante direto no Pix e iniciador de pagamentos no Open Finance.

• Confirmar a cobertura de relatórios regulatórios, como DIMP, CADOCs, CCS, SCR e COSIF.

• Avaliar a modularidade das APIs e a qualidade da documentação e do sandbox. A Celcoin oferece APIs modulares, sandbox robusto e suporte regulatório completo para acelerar a implementação de Banking as a Service.

• Analisar o modelo de remuneração. Modelos centrados em transações tendem a reduzir barreiras de entrada em comparação com estruturas com alto custo de setup.

Passo 3: Mapeamento regulatório e compliance

Mapear as obrigações regulatórias em paralelo à escolha do parceiro evita retrabalho de arquitetura e de produto. A Circular 3.978/2020 exige uma abordagem proporcional ao risco para PLD/FT, incluindo a elaboração anual do Relatório de Avaliação de Risco Institucional.

• Mapear obrigações de KYC para PF e PJ conforme a Resolução BCB nº 44.

• Definir políticas de PLD/FT e monitoramento transacional em tempo real para o Pix.

• Estabelecer base legal para tratamento de dados sob a LGPD.

• Identificar obrigações contábeis e fiscais acessórias aplicáveis ao modelo de negócio.

Passo 4: Arquitetura técnica e integração via APIs

Estruturar a arquitetura técnica em camadas facilita a evolução do produto e o controle de riscos. Uma plataforma de BaaS costuma operar com APIs de sistema, de processo e de experiência.

• Implantar o gateway de API, a estrutura de identidade e os módulos de Core Banking.

• Configurar controles de segurança iniciais, como firewalls, detecção de intrusão e autenticação multifator.

• Definir políticas de governança de dados desde o início da arquitetura.

• Garantir que cada transação tenha identificadores únicos de ponta a ponta para rastreabilidade até o settlement.

Passo 5: Onboarding, KYC e KYB

A Resolução BCB nº 44 define os dados mínimos de KYC para pessoas físicas e jurídicas, incluindo identificação de beneficiários finais com participação relevante no capital social.

O fluxo padrão de onboarding segue uma sequência de validações para reduzir risco de fraude e de não conformidade.

1. Coleta cadastral e verificação documental via OCR, com documentos como RG, CNH ou passaporte.

2. Biometria facial com prova de vida.

3. Checagem em listas de sanções, como PEP, OFAC, ONU e COAF.

4. Cruzamento com bases da Receita Federal e Serpro.

5. Para PJ, validação de CNPJ ativo, CNAE compatível, inscrição estadual e cadeia societária.

6. Monitoramento contínuo para reanálise periódica ou por evento de risco.

O Open Finance reduz fricção no eKYC ao permitir o compartilhamento de dados entre instituições autorizadas com consentimento do cliente. Esse modelo tende a aumentar a taxa de conversão no onboarding.

Passo 6: Configuração de liquidação, Pix e Open Finance

Configurar liquidação e reconciliação garante que o dinheiro se mova de forma correta e que todos os sistemas concordem sobre cada transação. Liquidação trata do fluxo financeiro no Sistema de Pagamentos Brasileiro, enquanto reconciliação compara registros internos e externos.

• Configurar a participação direta no Pix com monitoramento de transações em tempo real para identificar padrões suspeitos. Essa base de dados transacionais alimenta os controles contábeis.

• Implantar o ledger transacional com contabilidade de dupla entrada em tempo real para registrar cada movimento do Pix e garantir rastreabilidade completa, criando a fonte de verdade para conferência.

• Definir políticas de reconciliação em múltiplos níveis que comparem o ledger com dados do cliente final, operações internas e balancetes do provedor.

• Ativar o Open Finance para acesso e transmissão de dados financeiros com consentimento, o que habilita personalização de produtos e ganhos de eficiência.

• Estabelecer rotinas de reconciliação diárias ou horárias com automação de settlement e trilhas de auditoria completas.

Passo 7: Testes em sandbox e validação de webhooks

Executar testes em sandbox com dados sintéticos reduz o risco de incidentes em produção. A validação precisa ir além do caminho ideal de sucesso.

A validação de webhooks em sandbox deve cobrir entregas duplicadas, falhas de assinatura, sucessos tardios, sucessos duplicados e impactos na reconciliação.

Checklist de validação pré-produção:

• Verificar a assinatura no endpoint HTTPS usando o corpo bruto da requisição.

• Deduplicar eventos por ID do provedor antes de qualquer lançamento no ledger.

• Retornar código 2xx de forma rápida após a persistência segura do evento.

• Mapear eventos do provedor para estados internos de transação, como aceito, pendente, sucesso terminal e revertido.

• Executar testes de contrato e verificações de segurança automatizadas.

• Validar SLAs de disponibilidade, tempo de resposta das APIs e tempo de resolução de incidentes.

Passo 8: Go-live e monitoramento em produção

Realizar o go-live com uma revisão de arquitetura, classificação de dados e prontidão operacional reduz riscos no início da operação. O monitoramento em produção precisa ser contínuo.

• Ativar monitoramento baseado em IA para detecção de fraudes e padrões suspeitos em tempo real.

• Implantar observabilidade com logs de transação, contexto de exceções e evidências operacionais.

• Estabelecer runbooks para escalação de incidentes com acesso direto a decisores do provedor.

• Monitorar a taxa de auto-match da reconciliação, buscando níveis elevados de resolução automática.

• Configurar alertas via webhooks para tentativas recusadas, chargebacks e indicadores de fraude.

Passo 9: Expansão, automação e governança contínua

Usar a fase pós-estabilização para ampliar o portfólio e automatizar processos aumenta a eficiência e prepara a empresa para novos patamares regulatórios. A mesma infraestrutura pode sustentar volumes maiores e novos produtos.

• Adicionar novos produtos, como cartão pós-pago, DDA, remuneração de saldo, Open Insurance e crédito embarcado.

• Automatizar relatórios regulatórios, incluindo DIMP, CCS, CADOCs, COSIF e SCR.

• Implantar governança de dados contínua com revisão periódica do RARI.

• Planejar a migração para licença própria sem necessidade de trocar a infraestrutura tecnológica.

Erros comuns e pontos de atenção

Evitar erros recorrentes em reconciliação, estrutura de contas, webhooks e governança reduz incidentes e custos operacionais.

• Falhas de reconciliação: ausência de identificadores únicos de ponta a ponta gera discrepâncias contábeis, dificulta o cálculo de resultados e aumenta o risco de fraude não detectada. Operações com alto volume podem acumular muitos casos problemáticos mesmo com baixas taxas de erro.

• Contas-bolsão: operar com estruturas em que recursos de terceiros não são individualizados mistura patrimônio do cliente com o da empresa, o que configura prática irregular vedada pelo Banco Central.

• Problemas com webhooks: processamento não idempotente causa double-counting no ledger, enquanto falhas de webhooks deixam registros pendentes quando o parceiro já considera o pagamento liquidado.

• Dependências entre times não mapeadas: o time financeiro controla a reconciliação, engenharia controla credenciais de API e confiabilidade dos webhooks, e o suporte do parceiro confirma o status dos pagamentos. Sem definição clara de ownership, incidentes se tornam escalações longas.

Critérios de sucesso

Medir o sucesso da implementação de BaaS com indicadores objetivos ajuda a ajustar a operação e priorizar melhorias.

• Estabilidade operacional: manter disponibilidade acima do SLA contratado e tempos de resposta dentro dos limites definidos em pré-produção.

• Tempo de implementação: concluir projetos simples em cerca de uma semana e operações complexas em até três meses, conforme a estrutura existente.

• Redução de retrabalho: alcançar alta taxa de auto-match na reconciliação e resolver breaks abertos de forma eficiente.

• Aderência regulatória: enviar todos os relatórios obrigatórios ao Banco Central, Receita Federal e SUSEP dentro dos prazos, sem notificações de irregularidade.

• Onboarding eficiente: concluir KYC e KYB em minutos para casos conformes, com taxa de conversão mensurável e trilha de auditoria completa.

Matriz de responsabilidades

A tabela a seguir mostra como as principais atividades regulatórias, operacionais e técnicas se distribuem entre o parceiro de BaaS e a empresa cliente. Use essa matriz para definir ownership de cada frente e reduzir lacunas de governança durante a implementação.

Atividade	Parceiro de BaaS	Empresa cliente	Responsabilidade compartilhada
Licenças regulatórias (IP)	Fornece a licença	Opera sob a licença	–
Infraestrutura de Core Banking	Mantém e atualiza	Consome via API	–
KYC e KYB dos usuários finais	Fornece ferramentas e fluxos	Implementa e monitora	Define políticas de risco
PLD e FT e monitoramento transacional	Oferece infraestrutura e regras base	Executa processos próprios e RARI	Gerencia alertas e escalação
Reconciliação e liquidação	Entrega dados estruturados via API	Configura rotinas e automação internas	Garante uso de identificadores únicos
Relatórios regulatórios	Gera e envia relatórios automatizados	Valida e aprova informações	–
Segurança cibernética	Opera infraestrutura multicamadas	Protege a aplicação própria	Realiza testes de penetração
Experiência do usuário final	–	Define design e produto	–

Funcionalidades e benefícios da Celcoin

A Celcoin opera com portfólio completo de licenças e tecnologia proprietária, mediando mais de R$ 30 bilhões em transações por mês e atendendo milhares de clientes, como fintechs, bancos digitais, ERPs e varejistas. Empresas sem licença própria podem operar sob a licença de Instituição de Pagamento da Celcoin em modelo BaaS. Empresas já reguladas integram sua licença ao Core Banking da Celcoin e mantêm a mesma base tecnológica ao longo do crescimento.

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Permitem integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes reduzem ciclos de integração e esforço de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos e antecipam geração de receita.
Distribuição white-label e embutida	Permite oferecer produtos financeiros com marca própria em diferentes canais.
Escalabilidade com confiabilidade	Infraestrutura em nuvem com alta disponibilidade mantém serviços estáveis mesmo em altos volumes.
Cobertura de pagamentos e crédito	Oferta de pagamentos e emissão de crédito aumenta conversão, receita por usuário e fidelização.
Acesso a dados e personalização	Dados e análises via Open Finance permitem ofertas mais aderentes ao perfil do cliente.
Compliance e conformidade integrados	Controles de KYC, AML e relatórios reduzem risco regulatório e encurtam ciclos de venda.
Prevenção de fraude e controles de risco	Monitoramento com IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.
Ecossistema de parceiros da Celcoin	Parcerias com bancos, redes e fintechs ampliam cobertura e velocidade de entrada no mercado.

Conheça o banking da Celcoin para fintechs, bancos digitais, gestoras de fundos, varejistas e ERPs.

Próximos passos após a implementação

Tratar a implementação inicial como ponto de partida permite evoluir o negócio de forma estruturada. A empresa pode organizar a evolução em três frentes principais.

• Expansão de portfólio: adicionar produtos como cartão pós-pago, DDA, remuneração de saldo, Open Insurance e crédito embarcado conforme a demanda da base.

• Automação e eficiência: automatizar relatórios regulatórios, rotinas de reconciliação e processos de onboarding para reduzir custos e erros manuais.

• Governança e evolução regulatória: revisar o RARI anualmente, acompanhar atualizações do Banco Central e planejar a obtenção de licença própria de Instituição de Pagamento ou Instituição Financeira quando o volume justificar, mantendo a infraestrutura tecnológica do parceiro.

Perguntas frequentes

Quanto tempo leva uma implementação de Banking as a Service no Brasil?

O prazo depende da complexidade da operação e da disponibilidade das equipes. Implementações com poucos produtos e integração direta via APIs bem documentadas podem ser concluídas em cerca de uma semana. Operações com múltiplos produtos, migração de infraestrutura existente ou adaptação de sistemas legados podem levar até três meses. A qualidade da documentação do provedor, a maturidade técnica da equipe de engenharia e a clareza do escopo definido na fase inicial influenciam diretamente esse prazo.

Quais licenças são necessárias para oferecer serviços financeiros no Brasil via BaaS?

Empresas sem licença própria podem operar sob a licença de Instituição de Pagamento do provedor de BaaS. Esse modelo permite oferecer contas digitais, Pix, cartões pré-pagos, TED e pagamento de contas sem autorização própria do Banco Central. Empresas que já possuem licença de Instituição de Pagamento ou de Instituição Financeira integram essa licença ao Core Banking do provedor. A decisão entre usar a licença do parceiro ou obter licença própria depende do volume de transações, do modelo de negócio e do plano de crescimento.

Como funciona a reconciliação em plataformas de BaaS e quais são os principais riscos?

A reconciliação em BaaS compara o ledger transacional interno com os dados do parceiro e com extratos bancários externos. O principal risco é não usar identificadores únicos de ponta a ponta. Sem esses identificadores, transações duplicadas, falhas de webhooks e diferenças de timing entre o evento de pagamento e o settlement geram discrepâncias que se acumulam em operações de alto volume. Sistemas maduros alcançam altas taxas de auto-match e resolvem breaks abertos com eficiência. Estruturas de contas-bolsão, em que recursos de múltiplos clientes não são individualizados, permanecem vedadas pelas normas do Banco Central.

Quais são as obrigações de KYC e KYB exigidas pelo Banco Central para plataformas de BaaS?

As obrigações de KYC e KYB seguem os requisitos da Resolução BCB nº 44 detalhados no passo de onboarding. Além da coleta cadastral, o processo inclui verificação documental, biometria facial com prova de vida e checagem em listas de sanções. As evidências documentais precisam ser mantidas por pelo menos cinco anos para atender a auditorias do Banco Central. O Open Finance pode complementar esse processo ao permitir o compartilhamento de dados financeiros com consentimento do usuário.

É possível migrar de outra infraestrutura para um provedor de BaaS sem interromper a operação?

A migração para um novo provedor de BaaS pode ocorrer com impacto mínimo para o usuário final quando há boa documentação e planejamento. O processo costuma envolver mapeamento da estrutura atual, replicação dos fluxos em ambiente de testes, validação de reconciliação e webhooks e um plano de transição gradual para produção. A Celcoin oferece APIs modulares, sandbox robusto e suporte regulatório completo para acelerar a implementação de Banking as a Service.